Er Prince2 relevant for et smidig prosjekt?

Jeg har ledet prosjekter etter smidige prinsipper i mer enn 10 år. Både med hyppige endringer etter hvert som prosjektet opparbeider kunnskap, og med til dels kontinuerlige leveranser. Før smidige prinsipper ble populært brukte jeg forskjellige varianter av vannfallsprosesser: PROPS, RUP og Systeks iterative utviklingsprosess som vi kalte PRIS.

Nå har jeg sertifisert meg i Prince2. Prince2 er en av verdens mest brukte prosjektledelsesprosesser, den er generell, har eksistert nærmest uforandret siden 2009 (mindre revisjon i 2018), og kan brukes til å bygge en boligblokk eller oljeplattform. Hvis du ønsker å lære mer om Prince2, se https://en.wikipedia.org/wiki/PRINCE2 . I 2015 kom Prince2 Agile. Men kun som en tilpasning av leveranseprosessen. Alle Prince2 prosesser og prinsipper er fortsatt intakte. Se http://prince2agile.wiki/An_Overview_of_PRINCE2_Agile

Det åpenbare spørsmålet er da: Er Prince2 prosessen relevant for et programvareutviklingsprosjekt i dag? Når nesten alle bruker smidige prinsipper? Den virker jo svært firkantet, ledelsestung, og lite endringsvillig. Spesielt ser den ut til å bryte med prinsippene i «Agile Manifesto»:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Svaret er faktisk ja. Og i offentlige prosjekter er vi også forpliktet til å følge Prosjektveiviseren til Difi, som igjen er basert på Prince2.

Planlegging og kontroll

Alle prosjekter skal levere noe innen en viss tid, til en viss kost, med en viss kvalitet, og med et visst omfang. Det er svært vanskelig, for ikke å si umulig, å låse alle disse 4 parameterne i et utviklingsprosjekt, eller et anskaffelsesprosjekt med en viss grad av integrasjon og tilpasninger. I Prince2 forsøker man initielt å låse alle 4, og i tillegg ha et budsjett for endringer. Endringer blir da unntaket, og man ønsker ikke for mange endringer, dette for å beholde kontrollen over tid og kost.

For å beholde kontrollen over alle disse 4 parametrene i prosjektet anbefaler Prince2 at et stort antall dokumenter skal produseres, 3 nivåer av planer skal utarbeides og følges opp, revisjoner skal gjennomføres av mange forskjellige roller, rapporter skal skrives og registre skal vedlikeholdes. Dette er klart i strid med «Agile Manifesto»: «Working software over comprehensive documentation».

3-nivå planlegging

Prince2s ledelsesfilosofi er «Management by exception», hvor hvert ledelsesnivå har frihet til å operere innenfor planen på dette nivået sine toleranser. Ledelsesnivået over skal ikke behøve å ta aksjon før disse toleransegrensene overskrides. Og ledelsen kan gjøre opp status etter hver fase (Stage). Dette er en god tanke. Problemet er at det blir for lang avstand fra ledelse (de som vil ha noe) og teamet (de som skal lage og/eller anskaffe det). Informasjon går tapt underveis og beslutninger tar for lang tid.

Min erfaring fra slike prosjekter er at teamet ikke helt identifiserer seg med planene og klarer heller ikke å nå fristene som er satt opp. Prosjektleders oppgave blir da å be teamet gjøre en ekstra innsats og/eller rapportere forsinkelser. Over tid sliter dette på teamet og produktiviteten går ned.

Endringer i omfanget i en slik situasjon er da selvsagt ikke populært. Det vil jo forsinke planene ytterligere.

Den smidige tilnærmingen og Prince2

Den smidige tilnærmingen er en mer direkte kobling mellom «de som vil ha noe», representert ved produkteier, og teamet (de som skal lage noe). Planen er representert som en produktkø med brukerhistorier (og andre oppgaver som skal løses). Produktkøen er prioritert, slik at det er det viktigste som realiseres først.

Teamet er med og «størrelses-estimerer», dvs. hvor stor tror teamet at en brukerhistorie er i forhold til en annen. For å kvantifisere bruker vi gjerne «story points».

Hvis produktkøen er implementert i et godt verktøy, som for eksempel Jira, så kan produkteier til enhver tid måle faktisk framdrift ved å ta ut en «burn down»-rapport for hvor mange «story points» teamet har implementert innenfor en tidsperiode, for eksempel en sprint. Legg merke til at smidige metoder kun teller «ferdige» historier, dvs. når den er klar for produksjon. Dermed unngår prosjektet alle oppgaver som er «80% ferdige» — og har 80% av tiden igjen for å ferdigsstille. Med andre ord: det er virkelig progresjon som måles.

Men en produktkø kan endre seg og reprioriteres hele tiden av produkteier. Dette skjer i praksis svært ofte, siden en del av den smidige filosofien er å ønske endringer velkommen, ettersom teamet lærer mer og mer når leveransene starter og brukerne gir tilbakemeldinger. Og leveransene skal starte så tidlig som mulig!

Samtidig kan ledelsen føle at de mister kontrollen over hva som skal leveres i prosjektet når innholdet i produktkøen endrer seg. Og om prosjektet fortsatt kommer til å realisere forventet forretningsverdi.

Prince2-kunnskap kan gi ledelsen kontroll over et smidig prosjekt

Hvert element i produktkøen skal typisk ikke ta mer enn 1–3 dager å implementere, så den blir for detaljert å gå igjennom for ledelsen.

De overordnede brukerhistoriene (Epos) kan imidlertid være godt egnet og kan på mange måter sammenlignes med en fase i Prince2. Innenfor hvert epos kan brukerhistoriene endre seg uten at ledelsen behøver å involveres, og dette kan sammenlignes med «Management by exception» i Prince2.

For å få til dette må du som produkteier være litt bevisst og kjenne til Prince2. Hvert epos bør da ikke være større enn at alle brukerhistoriene bør kunne implementeres innen en eller to sprinter i Scrum, eller noen få uker i Kanban. Brukerhistoriene innenfor et epos bør ha nogenlunde lik prioritet. Hvert epos bør også ha en forretningsmessig forankring eller beskrivelse, slik som Prince2 anbefaler (“kontinuerlig forretningsmessig forankring”).

Hvis et epos reprioriteres, eller nye kommer til, bør ledelsen involveres. Og uansett bør en representant for ledelsen være jevnlig til stede ved demoer.

På denne måten får ledelsen kontroll over tid og kost, men omfanget vil endre seg hele tiden.

Min erfaring er at dette er en god ting. Prosjektet leverer hele tiden det som er viktigst for «de som vil ha noe». På grunn av virkelig måling av framdrift med «burn down charts» vil ledelsen raskt kunne se om framdriften er mye lavere enn forutsatt, og avbryte prosjektet før de store kostnadene har påløpt. Og selv da kan det tenkes at det som er utviklet har en verdi, siden det viktigste er utviklet først.

Til slutt

Jeg har i dette innlegget bare tatt for meg en liten del av prosessene i et prosjekt. I de neste innleggene vil jeg ta for meg hvordan man kan inkludere andre deler av Prince2 prosesser og prinsipper uten å bryte med smidige prinsipper. Målsetningen er å kunne levere så mye forretningsmessig verdi som mulig, med så lite administrasjon som mulig.

PS!Vi søker flere dyktige medarbeidere. Se våre ledige stillinger her