Prosjektledelse: tradisjonell, iterativ eller hybrid?

Som de fleste prosjektledere (og organisasjoner) sliter du sannsynligvis med å velge den optimale leveransetilnærmingen. De fleste av oss er klar over at tradisjonelle tilnærminger ikke garanterer vellykket levering, og ser alltid etter en bedre måte.

Smidige eller iterative utviklingsteknikker har fått mye svært positiv omtale de siste årene som en betydelig forbedring, noe som har ført til mer vellykket prosjektleveranse. Derfor lurer sannsynligvis din organisasjon, i likhet med de fleste andre organisasjoner i dag, på hvor og hvordan disse smidige eller iterative utviklingsteknikkene best kan brukes til å forbedre både leveringstiden og resultatene ved levering av prosjekter.

Kort sagt går iterative utviklingsteknikker ut på å planlegge, utvikle og implementere prosjektfunksjonalitet i små biter (eller iterasjoner). Nøkkelen til vellykket iterativ levering er at hver lille del i praksis fungerer som et mindre miniprosjekt under paraplyen til prosjektet som helhet. Som følge av dette kan hver miniprosjektiterasjon bedre planlegge innsatsen som kreves for å levere en toukers iterasjon kontra en toårsplan. Siden vi i tillegg planlegger i intervaller på to uker, kan vi enkelt tilpasse planen for de neste to ukene for å ta hensyn til eventuelle identifiserte endringer.

Agile kontra tradisjonell casestudie

Jeg vil ta en kort pause for å beskrive en ikke-teknisk situasjon, der man lyktes bedre med en smidig tilnærming enn med en tradisjonell plan.

La oss bruke et eksempel på planlegging av en hel dags aktiviteter – det er prosjektet. I likhet med et stort prosjekt er det mye usikkerhet og risiko forbundet med dette: vi vet ikke hva som skjer etter lunsj som kan påvirke planen vår, men tradisjonen er at vi utarbeider en omfattende plan for hva vi skal gjøre hver time av dagen, fra vi våkner klokken seks til vi legger oss klokken elleve.

Innen kl. 09.00 ligger vi etter skjema fordi trafikken forsinket oss på vei til jobb – kl. 10.00 blir vi kalt inn til et hastemøte – og innen kl. 12.00 var det å komme seg til kontoret den eneste daglige oppgaven som var fullført, og selv det var forsinket.

La oss nå se på dette som et smidig prosjekt der alt vi planlegger er neste iterasjon: å gjøre seg klar til å forlate huset (så brukerhistoriene er: dusj, frokost og at barna kommer seg av gårde til skolen). Alt dette ble levert til rett tid og innenfor budsjettet.

Så planlegger vi neste iterasjon med trygghet, som er å komme seg til kontoret (kjøre til bussterminalen, ta pendlertog til stasjonen og deretter bybuss til kontoret).

Dette fungerer ikke særlig bra: Den første brukerhistorien (kjøre til bussterminalen) har problemer med trafikken, så vi endrer brukerhistorien til å kjøre til kontoret, og blir enige om at de to andre brukerhistoriene kan fjernes fra iterasjonsplanen. Ved ankomst planlegger vi neste iterasjon. Men midt i planleggingssyklusen legges en ny historie til (hastemøtet), og den tar hele den neste iterasjonen.

Til slutt, etter lunsj, roer det seg, og vi kan se på backlogen og starte på oppgavene med høyest prioritet – vi fullfører to iterasjoner som omhandler elementene med høyest prioritet på ettermiddagen.

Hvis vi hadde holdt oss til den tradisjonelle planen, ville vi aldri ha fullført disse elementene med høyest prioritet, ettersom de ble flyttet til neste dag på grunn av planforskyvningen som følge av pendlingen til kontoret.

Hva er den beste tilnærmingen – smidig, tradisjonell eller hybrid?

Det er denne fleksibiliteten til å tilpasse seg endrede forretningsbehov som smidige eller iterative metoder er best på, og det er derfor mange organisasjoner tar dette i bruk. MEN, er organisasjonen din egentlig klar til å «satse alt» på smidig? Erfaringen min er at det ofte er mange hindringer for fullskala innføring av smidig metodikk, og da særlig sterkt etablerte organisasjonsretningslinjer som ofte ikke er fullt ut kompatible med smidige tilnærminger.

Retningslinjer som krav om fast budsjett, beskrivelse av gevinstrealisering og måldato før et prosjekt kan godkjennes, er viktige (men ikke egentlig smidige). På samme måte er organisasjonsmessige implementeringsretningslinjer som må følges for å sikre at eksisterende drift ikke påvirkes, avgjørende (men det er definitivt ikke smidig).

Som et resultat sliter mange organisasjoner med hvordan de skal bevare noen sentrale «tradisjonelle prosesser» samtidig som de tilpasser seg iterative metoder. Svaret er en hybrid leveransemodell. Deler av prosjektet kan leveres ved bruk av tradisjonelle ledelsesmetoder, og andre kan være iterative.

Hybrid leveransemodell

Den vanligste hybridmodellen jeg har støtt på, støtter tradisjonell prosjektoppstart og -planlegging, etterfulgt av en serie iterasjoner med pauser for tradisjonelle implementeringsaktiviteter for utgivelser, etterfulgt av enda en serie iterasjoner og tradisjonell implementering.

I denne modellen utvikler jeg en tradisjonell leveransebasert arbeidsnedbrytingsstruktur (WBS), som identifiserer kjerneleveransene som trengs i organisasjonen for prosjektgodkjenning, som prosjektmandat, prosjektstyringsplan og prosjektbudsjett.

Disse innledende leveransene kan utvikles og styres ved bruk av tradisjonelle metoder for å vise ledelsen at dette prosjektet er hensiktsmessig og er et godt sted å investere ressurser.

Når prosjektet er godkjent, kan det deretter gå over til en iterativ tilnærming der en backlog med historier vedlikeholdes, og historiene med høyest prioritet velges og utvikles fullt ut i neste iterasjon. Visningen av prosjektet endres fra den tradisjonelle Gantt-diagramvisningen til en interaktiv dra-og-slipp-tavle som muliggjør dynamisk tilordning av historier til iterasjoner.

Når som helst, ofte daglig, kan produkteieren legge til, slette og endre historiene i backlogen for å gjenspeile endrede forretningsbehov.

På slutten av hver iterasjon pauser vi og gjennomfører en retrospektiv evaluering av suksesser og feil, og gjør endringer for å implementere nødvendige forbedringer. Deretter, og viktigst av alt, går vi gjennom produktbacklogen og velger ut de viktigste historiene som kandidater for neste iterasjon. Denne tilnærmingen sikrer at prosjektet til enhver tid arbeider med det mest verdifulle og hensiktsmessige arbeidet.

I hver iterasjon kan teamet bruke smidige prinsipper, som daglig stand-up, og diskutere statusen for historiene som er planlagt for den gjeldende iterasjonen. På denne måten har teamet full kontroll over arbeidet som er fullført i løpet av en iterasjon, samtidig som det sikres at prosjektet som helhet forblir oppdatert og tilgjengelig for virksomhetsrapportering opp mot ressurskapasitet og status for portefølje og program.

En nøkkel til smidige prinsipper er evnen til å implementere den endelige løsningen i små utgivelser. Dette gir fordelen av å kunne bruke foreløpig funksjonalitet for å oppnå noen av de forventede forretningsfordelene så raskt som mulig.

I tillegg gir det fordelen med tidlig validering av løsningen, slik at eventuelle justeringer enkelt kan tas med i de gjenværende brukerhistoriene i produktbacklogen. Derfor, så snart nok historier med høy prioritet er fullført i iterasjonene, går prosjektet tilbake til en tradisjonell syklus og gjennomfører standard implementeringsoppgaver som organisasjonen krever.

Prøv Microsoft Project kostnadsfritt

Prøv Microsoft Project gratis i én måned

Finn ut hvordan

Disse utgivelses- og implementeringsaktivitetene blir planlagt og kontrollert ved hjelp av tradisjonelle tilnærminger, og sikrer at definerte prosesser blir fulgt for å begrense eventuelle påvirkninger på eksisterende drift når nye prosjekter blir implementert.

Etter at den første utgivelsen er fullført, går prosjektet tilbake til smidige tilnærminger og begynner å jobbe seg gjennom en ny sekvens med iterasjoner for å fortsette utviklingen av de gjenværende brukerhistoriene.

Selv om denne «fasedelte» tilnærmingen til å kombinere smidige og tradisjonelle tilnærminger er vanligst, kan du kombinere tilnærminger for å støtte spesifikke prosjektleveransekrav. For eksempel ledet jeg et prosjekt som krevde et ekstremt høyt nivå av etterlevelse og validering under implementeringen av et nytt produkt i en svært strengt regulert bransje. Derfor ble størsteparten av prosjektet mitt planlagt og kontrollert ved hjelp av tradisjonelle metoder.

Men det var en del av prosjektet som gjaldt forretningsanalyse, der selskapet mitt utvant den enorme mengden med ytelsesdata som systemet genererte. Denne delen var best egnet for en smidig tilnærming. For BI-komponenten i prosjektet (som kjørte parallelt med det tradisjonelle arbeidet), valgte vi brukerhistoriene med høyest prioritet – som kunne fullføres i en treukers sprint – og fullførte en iterasjon.

Siden mange av disse brukerhistoriene var av utforskende karakter, opprettet vi ofte nye brukerhistorier, enten for ytterligere utforskning eller for å opprette spesifikke ytelsesrapporter. Disse ble rett og slett lagt til i backloggen for vurdering til neste sprint.

Med denne tilnærmingen hadde jeg én enkelt prosjektplan som sikret at jeg gjennomførte alle påkrevde rapporterings- og regulatoriske trinn, samtidig som det fortsatt var rom for en svært fleksibel tilnærming til utviklingen av den ikke-regulerte forretningsrapporteringskomponenten i prosjektet.

Det at alt arbeidet var samlet i én enkelt tidsplan ga et samlet perspektiv på alt som skjedde i dette prosjektet:

Informasjonen jeg trengte for å administrere tilordning av ressurser til de mest passende oppgavene (tradisjonelle eller smidige), var umiddelbart tilgjengelig

Muligheten til å opprette kraftige ukentlige og månedlige statusrapporter var tilgjengelig

Smidig er en svært kraftfull tilnærming til prosjektlevering som bør gi betydelige fordeler for organisasjonens samlede verktøykasse for prosjektlevering. Den kan brukes frittstående, som en del av en trinnvis leveringstilnærming, eller integrert i en hybrid leveringsstruktur.

Nøkkelen er å ta i bruk de smidige prinsippene som hjelper organisasjonen din med å lykkes med leveransene, samtidig som man følger de tradisjonelle prosessene som har gjort organisasjonen din vellykket frem til nå.

Steve Caseley har over 35 års erfaring med Microsoft Project og har vært en aktiv bruker av Microsoft Project siden den første utgivelsen. Han er redaktør for flere bøker om Microsoft Project og beste praksis for prosjektledelse. Han er Principal Consultant hos Sensei Project Solutions, der han hjelper store organisasjoner med å oppnå fremragende resultater innen prosjektlevering ved hjelp av verktøysettet for Microsoft Project Portfolio Management (PPM).

RELATERTE PRODUKTER
Office 365

Kom i gang med Microsoft 365

Det er Office slik du kjenner det samt verktøy som gjør samarbeid enklere, slik at du får gjort mer, når som helst og hvor som helst.

Kjøp nå

Relatert innhold

Administrer bedriften

Hvorfor hater administrative ledere prosjektledere?

Mer informasjon

Forretningsinnsikt og ideer utgjør ikke profesjonell rådgivning om skatt eller økonomiske spørsmål. Kontakt din egen skatte- eller økonomirådgiver for å diskutere situasjonen din.