Projektledning: traditionell, iterativ eller hybrid?

Precis som de flesta projektledare (och organisationer) har du sannolikt svårt att välja den optimala leveransmetoden. De flesta av oss inser att traditionella arbetssätt inte garanterar en lyckad leverans och letar alltid efter ett bättre sätt.

Agila eller iterativa utvecklingsmetoder har fått mycket positiv uppmärksamhet de senaste åren som en betydande förbättring, med resultatet att projekt levereras mer framgångsrikt. Därför funderar din organisation sannolikt, precis som de flesta organisationer i dag, på var och hur de här agila eller iterativa utvecklingsmetoderna bäst kan användas för att förbättra både punktligheten och framgången i projektleveranser.

Sammanfattningsvis innebär iterativ utveckling att man planerar, utvecklar och implementerar projektfunktioner i mindre delar (eller iterationer). Nyckeln till en lyckad iterativ leverans är att varje liten del i praktiken fungerar som ett mindre miniprojekt inom ramen för det totala projektet. Som ett resultat kan varje miniprojekt-iteration bättre planera den insats som krävs för att leverera en tvåveckorsiteration jämfört med en tvåårsplan. Eftersom vi dessutom planerar i tvåveckorsperioder kan vi enkelt anpassa planen för de kommande två veckorna för att hantera eventuella förändringar som upptäcks.

Agil kontra traditionell fallstudie

Jag vill pausa en kort stund för att beskriva en icke-teknisk situation, där mer framgång uppnåddes med hjälp av en agil metod än en traditionell plan.

Låt oss använda ett exempel på planering av en hel dagsaktiviteter som är projektet. Precis som i ett stort projekt finns det en stor osäkerhet och risk för detta: vi vet inte vad som kommer att hända efter lunch som kan påverka vår plan, men traditionen bjuder att vi tar fram en heltäckande plan för vad vi ska göra varje timme på dygnet, från det att vi vaknar klockan 6 på morgonen till dess att vi går och lägger oss klockan 11 på kvällen.

Klockan 09.00 ligger vi efter i schemat eftersom trafiken försenade oss till jobbet; klockan 10.00 blir vi inkallade till ett akutmöte; och vid lunchtid är den enda dagliga uppgift som har slutförts att ta sig till kontoret, och till och med det är försenat.

Nu behandlar vi det här som ett agilt projekt där allt vi planerar är nästa iteration: att göra oss redo att lämna hemmet (så berättelser är: duscha, äta frukost och få iväg barnen till skolan). Allt detta levererades i tid och inom budget.

Med förtroende planerar vi därför nästa iteration, som är att ta oss till kontoret (köra till bussterminalen, ta pendeltåget till stationen och sedan ta stadbussen till kontoret).

Det går inte särskilt bra: Den första berättelsen (köra till bussterminalen) stöter på problem med trafiken, så vi ändrar användarberättelse till att köra till kontoret och kommer överens om att de andra två berättelser kan tas bort från iterationsplanen. Vid ankomst planerar vi nästa iteration. Men mitt i planeringscykeln läggs en ny berättelse till (nödmötet) och det tar hela nästa iteration.

Till slut, efter lunch, lugnar läget ner sig och vi kan titta på backloggen och börja med de högst prioriterade uppgifterna. Vi har slutfört två iterationer som hanterar de högst prioriterade objekten på eftermiddagarna.

Om vi hade hållit fast vid den traditionella planen hade vi aldrig hunnit slutföra de här högst prioriterade delarna, eftersom de flyttades till nästa dag på grund av förseningar i planen som orsakades av pendlingen till kontoret.

Vilken är den bästa metoden – agil, traditionell eller hybrid?

Det är just den här flexibiliteten att anpassa sig efter förändrade verksamhetsbehov som agila eller iterativa metoder är bäst på, och därför många organisationer inför dem. MEN, är din organisation verkligen redo att satsa fullt ut på agilt? Enligt min erfarenhet finns det ofta många hinder för fullskalig agil implementering, framför allt väletablerade organisationsprinciper som ofta är mindre än helt kompatibla med agila arbetssätt.

Principer som att behöva en fast budget, en redogörelse för nyttorealisering och ett måldatum innan ett projekt kan godkännas är viktiga (men inte särskilt agila). På samma sätt är det avgörande att följa organisationspolicyer för implementering, så att det inte uppstår några påverkan på befintlig drift (men det är definitivt inte agilt).

Som ett resultat kämpar många organisationer med hur de ska bevara vissa viktiga ”traditionella processer” samtidigt som de anpassar sig till iterativa metoder. Svaret är en hybrid leveransmodell. Delar av projektet kan levereras med traditionella ledningsmetoder, och andra kan vara iterativa.

Hybridleveransmodell

Den vanligaste hybridmodellen jag har stött på stöder traditionell projektstart och planering, följt av en serie iterationer med avbrott för traditionella implementeringsaktiviteter för versioner, och därefter ytterligare en serie iterationer och traditionell implementering.

I den här modellen utvecklar jag en traditionell leverensbaserad uppdelad arbetsstruktur (WBS), som identifierar de kärnprodukter som behövs i organisationen för projektgodkännande, till exempel Project Charter, Projektledningsplan och Projektbudget.

Dessa startprodukter kan utvecklas och hanteras med traditionella metoder för att visa ledningen att det här projektet är lämpligt och är en bra plats att investera resurser i.

När projektet har godkänts kan det sedan övergå till en iterativ metod där en backlog av berättelser upprätthålls och där de högst prioriterade historierna väljs ut och färdigställs helt i nästa iteration. Projektets vy ändras från det traditionella Gantt-diagrammet till en interaktiv drag-and-drop-tavla som möjliggör dynamisk tilldelning av berättelser till iterationer.

När som helst, ofta dagligen, kan produktägaren lägga till, ta bort och ändra artiklarna i kvarvarande uppgifter för att återspegla de föränderliga affärsbehoven.

I slutet av varje iteration pausar vi och gör en retrospektiv utvärdering av framgångar och misslyckanden, och gör ändringar för att genomföra nödvändiga förbättringar. Sedan, och viktigast av allt, går vi igenom produktbackloggen och väljer de viktigaste berättelserna som kandidater för nästa iteration. Det här arbetssättet ser till att projektet arbetar på det som är mest relevant och ger högst värde.

I varje iteration kan teamet använda agila principer som dagliga avstämningar och diskutera statusen för de berättelser som är schemalagda för den aktuella iterationen. På så sätt har teamet full kontroll över arbetet som slutförs inom en iteration, samtidigt som det säkerställer att det övergripande projektet förblir aktuellt och tillgängligt för rapportering i hela organisationen avseende resurskapacitet samt portfölj- och programstatus.

En nyckel till agila principer är möjligheten att implementera den ultimata lösningen i små versioner. Detta har fördelen att kunna använda preliminära funktioner för att uppnå några av de förväntade affärsfördelarna så snabbt som möjligt.

Dessutom har den fördelen med tidig validering av lösningen, så att eventuella justeringar enkelt kan räknas in i återstående artiklar i produktloggen. Så snart som tillräckligt många berättelser med hög prioritet har slutförts i iterationerna skulle projektet därför gå tillbaka till en traditionell cykel och utföra de standardimplementeringsuppgifter som krävs av organisationen.

Prova Microsoft Project kostnadsfritt

Prova Microsoft Project kostnadsfritt i en månad

Mer information

Dessa lanserings- och implementeringsaktiviteter kommer att planeras och kontrolleras med hjälp av traditionella metoder och säkerställa att fastställda processer följs för att minimera eventuella konsekvenser för befintliga åtgärder när nya projekt implementeras.

När den första versionen är klar återgår projektet till agila metoder och börjar gå igenom en annan sekvens med iterationer för att fortsätta utveckla de återstående berättelser.

Även om den här “stegvisa” metoden för att blanda flexibla och traditionella metoder är vanligast, kan du kombinera metoder för att stödja specifika projektleveranskrav. Till exempel ledde jag ett projekt som krävde en extremt hög nivå av regelefterlevnad och validering när en ny produkt implementerades i en mycket hårt reglerad bransch. Därför planerades och styrdes större delen av mitt projekt med traditionella metoder.

Det fanns dock en del av projektet för business intelligence där mitt företag granskade den stora mängd prestandadata som systemet genererade; den här delen stöds bäst med en flexibel metod. För BI-komponenten i projektet (som kördes parallellt med det traditionella arbetet) valde vi de berättelser med högst prioritet – de som kunde slutföras inom en treveckorssprint – och genomförde en iteration.

Eftersom många av dessa berättelser var av utforskande karaktär skapade vi ofta nya berättelser, antingen för mer utforskning eller för att ta fram specifika prestandarapporter. Dessa lades helt enkelt till i backloggen för att övervägas inför nästa sprint.

Med det här tillvägagångssättet hade jag en enda projekttidsplan som säkerställde att jag uppfyllde alla rapporterings- och regelkrav, samtidigt som den gav ett mycket flexibelt metod för att utveckla den icke-reglerade komponenten för affärsrapportering i projektet.

Att ha allt arbete i ett enda schema gav en samlad vy över allt som pågick i det här projektet:

Den information jag behövde för att hantera resursallokeringar till de mest lämpliga uppgifterna (traditionella eller agila) fanns direkt tillgänglig

Möjligheten att skapa kraftfulla vecko- och månadsstatusrapporter fanns på plats

Agilt är ett oerhört kraftfullt arbetssätt för projektleverans som bör ge betydande fördelar för organisationens övergripande verktygslåda för projektleverans. Det kan användas fristående, som en del av ett stegvis leveranssätt eller integreras i en hybrid leveransstruktur.

Det viktiga är att införa de agila principer som hjälper organisationen att nå framgång i leveransen, samtidigt som de traditionella processer som hittills har bidragit till organisationens framgång följs.

Steve Caseley har över 35 års erfarenhet av Microsoft Project och har varit en aktiv användare av Microsoft Project sedan den första versionen släpptes. Han är redigerare för flera böcker som rör metodtips för Microsoft Project och Projekthantering. Han är huvudkonsult på Sensei Project Solutions, där han hjälper stora organisationer att uppnå högsta kvalitet i projektleveransen med hjälp av verktygsuppsättningen Microsoft Project Portfolio Management (PPM).

RELATERADE PRODUKTER
Office 365

Kom igång med Microsoft 365

Det är samma Office som vanligt, med extra verktyg som hjälper dig att samarbeta på ett bättre sätt så att du får mer gjort – när du vill, var du vill.

Köp nu

Närliggande ämnen

Hantera mitt företag

Varför hatar chefer projektledare?

Läs mer

Insikter och idéer för företag ger inte professionella råd om skatt och ekonomi. Kontakta en professionell rådgivare om du vill diskutera din situation.