Försenat projekt: agera smart i stället för att bara vänta

Ett försenat projekt utlöser en reflex: kräv att de tar igen tiden. Ofta är det precis fel drag. En försening är ett symtom, och behandlar du symtomet utan att förstå orsaken riskerar du att göra skadan värre. Innan du bestämmer vad du ska göra behöver du veta varför det gick fel – och sedan agera, för att bara vänta är det dyraste alternativet av alla.

Börja med orsaken, inte med kravet

Förseningar har olika rötter, och varje rot kräver sitt eget svar. Tre är vanligast:

• Ni har ändrat kraven. Har omfånget vuxit under resans gång är förseningen delvis er egen. Då är svaret att prioritera, inte att kräva.
• Leverantören har underskattat. Var estimaten för optimistiska behövs en ärlig omplanering baserad på vad ni nu vet, inte på den ursprungliga gissningen.
• Leverantören är underbemannad. Har rätt personer inte funnits på plats är det ett resursproblem hos dem som de måste lösa, inte något ni kan pressa fram med tempo.

Fråga rakt ut och begär ett konkret svar. En leverantör som inte kan förklara varför det blev försenat kan sannolikt inte heller styra upp det.

Omprioritering är oftast snabbaste vägen ut

När orsaken är klar är den vanligaste bästa åtgärden inte mer tid eller mer folk, utan mindre scope. Att lansera en mindre men fungerande version i tid slår nästan alltid att vänta på att allt blir klart.

Ställ den avgörande frågan: vad måste verkligen finnas för en första lansering, och vad kan komma efteråt? Nästan alla kravlistor innehåller mer än vad en första version behöver. Skär bort det som kan vänta, lansera kärnan, och bygg vidare därifrån. En senareläggning bör vara sista utvägen, inte den första reflexen.

Fällan att sätta in fler utvecklare

Den mest lockande och mest missförstådda åtgärden är att bemanna upp. Instinkten säger att fler händer betyder snabbare färdigt. I ett sent mjukvaruprojekt är det ofta tvärtom.

Nya personer kan inte projektet. De måste läras upp av just de utvecklare som redan är hårt belastade, vilket bromsar teamet precis när det behöver fart. Effekten kommer, om den kommer, långt senare än förseningen kräver. Att lägga folk på ett sent projekt gör det klassiskt nog ännu senare. Ompröva alltid det greppet innan du tar till det.

Ett scenario

Säg att en lansering skulle skett i mars men teamet meddelar i februari att det inte hinns. Reflexen är att kräva mars ändå eller att sätta in fler utvecklare. Ett klokare drag: sätt er ner och gå igenom kravlistan. Av tjugo funktioner visar det sig att tolv räcker för en meningsfull första version. Ni lanserar de tolv i mars som planerat och lägger de åtta i en version två i maj. Deadlinen hölls – ni ändrade bara vad som skulle levereras till den, inte när.

När formella verktyg hör hemma

Avtal med viten och formella påtryckningar har sin plats, men den platsen är sällan mitt i ett bygge du vill rädda. Så länge du behöver teamets goda arbete framåt är hårda påtryckningar kontraproduktiva – de förgiftar relationen med just de personer du är beroende av.

Formella verktyg hör hemma när samarbetet i praktiken havererat och frågan har blivit hur du skyddar dina intressen eller tar dig ur avtalet. Då är de nödvändiga. Som första reaktion på en försening är de nästan alltid fel. Ta det konstruktiva samtalet först; spara juridiken till när det verkligen behövs.

Så slipper du hamna här igen

De flesta stora förseningar var en rad små som ingen agerade på i tid. Bota det med synlighet: tätare avstämningar, riktiga demos av fungerande delar och en uppdaterad prognos löpande, inte bara vid milstolpar. Ser du en liten glidning i vecka tre kan du styra om medan det är lätt. Upptäcker du den först vid tänkt lansering är valen betydligt smärtsammare.

Vi på Weapp arbetar med öppen prognos och regelbundna demos just för att förseningar ska bli synliga medan de fortfarande är små. Vill du ha hjälp att rädda ett projekt som glidit, eller en second opinion? Titta på våra tjänster eller hör av dig.