Projektstyring: traditionel, iterativ eller hybrid?

Ligesom de fleste projektledere (og organisationer) kæmper du sandsynligvis med at vælge den optimale leverancemetode. De fleste af os erkender, at traditionelle tilgange ikke garanterer en vellykket levering, og vi er altid på udkig efter en bedre måde.

Agile eller iterative udviklingsteknikker har de seneste år fået meget positiv omtale som en væsentlig forbedring, der resulterer i mere vellykket projektlevering. Derfor spekulerer din organisation sandsynligvis ligesom de fleste andre i dag på, hvor og hvordan disse agile eller iterative udviklingsteknikker bedst kan bruges til at forbedre både rettidigheden og succesraten for projektleverancer.

Kort sagt planlægger, udvikler og implementerer iterative udviklingsteknikker projektfunktionalitet i små bidder (eller iterationer). Nøglen til en vellykket iterativ levering er, at hver lille bid i praksis fungerer som et mindre miniprojekt under det samlede projekts paraply. Som resultat kan hvert miniprojekt i en iteration bedre planlægge den indsats, der kræves for at levere en to-ugers iteration i stedet for en toårsplan. Når vi desuden planlægger i to-ugers intervaller, kan vi nemt tilpasse planen for de næste to uger, så den tager højde for eventuelle identificerede ændringer.

Agil kontra traditionel casestudie

Jeg vil en kort holde pause for at beskrive en ikke-teknisk situation, hvor man opnåede større succes ved hjælp af en agil tilgang end med en traditionel plan.

Lad os bruge et eksempel med at planlægge aktiviteter for en hel dag – det er projektet. Ligesom et stort projekt er der stor usikkerhed og risiko forbundet med dette: vi ved ikke, hvad der vil ske efter frokost, som kan påvirke vores plan, men traditionen foreskriver, at vi udarbejder en omfattende plan for, hvad vi skal gøre hver time i løbet af dagen, fra vi vågner kl. 6 om morgenen til vi går i seng kl. 23.

Klokken 9 er vi bagud i forhold til tidsplanen, fordi trafikken forsinkede os på vej til arbejde; klokken 10 bliver vi kaldt ind til et akut møde; og ved middagstid var den eneste daglige opgave, vi havde fuldført, at komme til kontoret, og selv det var med forsinkelse i forhold til planen.

Lad os nu behandle det som et agilt projekt, hvor alt, vi planlægger, er den næste iteration: at gøre os klar til at forlade huset (så historierne er: brusebad, morgenmad og børnene af sted til skole). Alt dette blev leveret til tiden og var inden for budgettet.

Så med ro i sindet planlægger vi den næste iteration, som er at komme til kontoret (køre til busterminalen, tage pendler-toget til stationen og derefter bybussen til kontoret).

Det fungerer ikke særlig godt: Den første historie (køre til busterminalen) har problemer med trafikken, så vi ændrer brugerhistorien til at køre til kontoret og er enige om, at de to andre historier kan fjernes fra iterationsplanen. Ved ankomst planlægger vi den næste iteration. Men midt i planlægningscyklussen bliver en ny historie tilføjet (det akutte møde), og den kommer til at tage hele den næste iteration.

Til sidst, efter frokost, falder tingene til ro, og vi kan se på backloggen og begynde på opgaverne med højeste prioritet; vi afslutter på vellykket vis to iterationer, der håndterer de højst prioriterede emner om eftermiddagen.

Hvis vi havde holdt os til den traditionelle plan, ville vi aldrig have gennemført disse højst prioriterede emner, da de blev udskudt til næste dag på grund af den forsinkelse i planen, som pendlingen til kontoret medførte.

Hvad er den bedste tilgang – agil, traditionel eller hybrid?

Det er denne fleksibilitet til at tilpasse sig skiftende forretningsbehov, som agile eller iterative metoder er bedst til, og hvorfor mange organisationer tager det til sig. MEN er din organisation virkelig klar til at sætte “alt ind“ på agilitet? Min erfaring er, at der ofte er mange hindringer for fuld agil adoption, især fast forankrede organisationspolitikker, som ofte er mindre end fuldt forenelige med agile tilgange.

Politikker som kravet om et fast budget, en beskrivelse af gevinstrealisering og en planlagt dato, før et projekt kan godkendes, er vigtige (men ikke særligt agile). På samme måde er organisatoriske implementeringspolitikker, som skal følges for at sikre, at eksisterende drift ikke påvirkes, kritiske (men bestemt ikke agile).

Derfor kæmper mange organisationer med at bevare nogle af de vigtigste “traditionelle processer” , samtidig med at de tilpasser sig iterative metoder. Svaret er en hybrid leveringsmodel. Dele af projektet kan leveres ved hjælp af traditionelle styringsmetoder, mens andre dele kan være iterative.

Hybrid leveringsmodel

Den mest almindelige hybride model, jeg er stødt på, understøtter traditionel projektopstart og -planlægning, efterfulgt af en række iterationer med pauser til traditionelle implementeringsaktiviteter for udgivelser, efterfulgt af endnu en række iterationer og traditionel implementering.

I denne model opretter jeg en traditionel leverancebaseret arbejdsopgavehierarki (WBS), som identificerer de kerneleverancer, der er nødvendige i organisationen for projektgodkendelse, såsom Project Charter, Project Management Plan og Project Budget.

Disse indledende leverancer kan udvikles og styres ved hjælp af traditionelle metoder for at vise ledelsen, at projektet er relevant, og at det er et godt sted at investere ressourcer.

Når projektet er godkendt, kan det derefter overgå til en iterativ tilgang, hvor en ordrebeholdning af historier vedligeholdes, og de højest prioriterede historier udvælges og udvikles fuldt ud i den næste iteration. Projektets visning ændrer sig fra den traditionelle Gantt-diagramvisning til et interaktivt træk-og-slip-tavle, der gør det muligt dynamisk at tildele historier til iterationer.

Når som helst, ofte på daglig basis, kan produktejeren tilføje, slette og ændre historier i ordrebeholdningen, så den afspejler de ændrede forretningsbehov.

Ved slutningen af hver iteration holder vi pause og gennemfører en retrospektiv evaluering af succeser og fejl og foretager ændringer for at implementere de nødvendige forbedringer. Derefter, og vigtigst af alt, gennemgår vi produktbackloggen og udvælger de vigtigste historier som kandidater til den næste iteration. Denne tilgang sikrer, at projektet til enhver tid arbejder på det mest relevante arbejde med den højeste værdi.

I hver iteration kan teamet bruge agile principper som daglig gentagelse og diskutere status for de historier, der er planlagt til den aktuelle iteration. På den måde har teamet fuld kontrol over det arbejde, der udføres inden for en iteration, samtidig med at det sikrer, at det samlede projekt forbliver opdateret og tilgængeligt til rapportering på tværs af virksomheden i forhold til ressourcekapacitet samt portefølje- og programstatus.

En nøgle til agile principper er evnen til at implementere den endelige løsning i små udgivelser. Det har den fordel, at man kan bruge foreløbig funktionalitet til at opnå nogle af de forventede forretningsfordele så hurtigt som muligt.

Det har også den fordel, at løsningen kan valideres tidligt, så eventuelle justeringer nemt kan indarbejdes i de resterende historier i produktbackloggen. Derfor vil projektet, så snart der er gennemført nok højprioriterede historier i iterationerne, vende tilbage til en traditionel cyklus og udføre de standardimplementeringsopgaver, som organisationen kræver.

Prøv Microsoft Project gratis

Prøv Microsoft Project gratis i en måned

Få mere at vide om, hvordan

Disse udgivelses- og implementeringsaktiviteter bliver planlagt og styret ved hjælp af traditionelle tilgange og sikrer, at definerede processer følges for at begrænse enhver påvirkning af eksisterende drift, når nye projekter implementeres.

Når den første version er færdig, vender projektet tilbage til agile tilgange og begynder at arbejde sig gennem endnu en række iterationer for at fortsætte udviklingen af de resterende historier.

Selvom denne "faseinddelte" tilgang til at kombinere agile og traditionelle metoder er den mest almindelige, kan du kombinere metoder for at understøtte specifikke krav til projektleverancen. Jeg ledede for eksempel et projekt, der krævede et ekstremt højt niveau af overholdelse og validering, mens vi implementerede et nyt produkt i en meget reguleret branche. Derfor blev størstedelen af mit projekt planlagt og styret ved hjælp af traditionelle metoder.

Der var dog en business intelligence-del af projektet, hvor min virksomhed udnyttede den store mængde ydelsesdata, som systemet genererede; denne del blev bedst understøttet af en agil tilgang. For BI-komponenten i projektet (som kørte parallelt med det traditionelle arbejde) valgte vi de historier med højeste prioritet – dem, der kunne gennemføres i et sprint på tre uger – og afsluttede en iteration.

Da mange af disse historier havde en undersøgende karakter, oprettede vi ofte nye historier – enten til yderligere udforskning eller til at oprette specifikke ydelsesrapporter. Disse blev blot føjet til backloggen til overvejelse i det næste sprint.

Med denne tilgang havde jeg en enkelt projektplan, som sikrede, at jeg opfyldte alle de rapporterings- og regulatoriske trin, der var påkrævet, samtidig med at der stadig var en ekstremt fleksibel tilgang til udviklingen af projektets ikke-regulerede forretningsrapporteringskomponent.

At have alt arbejdet inden for én enkelt plan gav et samlet overblik over alt, der skete vedrørende dette projekt:

De oplysninger, jeg havde brug for til at styre ressourceallokeringer til de mest passende opgaver (traditionelle eller agile), var straks tilgængelige

Muligheden for at oprette effektive statusrapporter hver uge og hver måned var lige ved hånden

Agile er en meget effektiv tilgang til projektlevering, som vil give din organisation betydelige fordele i det samlede værktøjssæt til projektlevering. Den kan bruges som en selvstændig løsning, som en del af en faseinddelt leveringsmetode eller integreret i en hybrid leveringsstruktur.

Det vigtigste er at anvende de agile principper, som hjælper din organisation med at opnå en vellykket levering, samtidig med at I følger de traditionelle processer, som har hjulpet din organisation med at skabe resultater indtil nu.

Steve Caseley har over 35 års erfaring med Microsoft Project og har været aktiv bruger af Microsoft Project siden den første version. Han er redaktør af flere bøger om Microsoft Project og bedste praksis for projektledelse. Han er chefkonsulent hos Sensei Project Solutions, hvor han hjælper store organisationer med at opnå fremragende projektlevering ved hjælp af Microsoft Project Portfolio Management-værktøjssættet (PPM).

RELATEREDE PRODUKTER
Office 365

Kom i gang med Microsoft 365

Det er det Office, du kender, plus de værktøjer, som er med til at forbedre samarbejdet, så du kan få mere fra hånden – når som helst og hvor som helst.

Køb nu

Relateret indhold

Administrer min virksomhed

Hvorfor kan direktører ikke lide projektledere?

Læs mere

Business Insights & Ideas tilbyder ikke professionel rådgivning i skat eller økonomi. Du skal kontakte din egen skatte- eller finansmedarbejder for at drøfte din situation.