olav m.j. christiansen bloghoved olav christiansen

Top og bund

Jeg har skrevet lidt i mine tidligere blogindlæg om forskellige måder at styre et projekt på. Denne gang vil jeg tage et spadestik dybere og se hvad nogle af forskellene egentlig er på de forskellige måder at gøre tingene på. Grundlæggende er der vel to typer projektmodeller, der konkurrerer lige for tiden: De topstyrede og de bundstyrede. Betegnelserne her står helt for min egen regning, men handler grundlæggende om dels hvor modellerne er opstået og dels hvor fokus er.

Det er jo ikke muligt i et blogindlæg at dække alt, så jeg vil kun lige kradse lidt i overfladen, men forhåbentlig er det nok til at man kan få et indtryk af de forskellige modeller.

PRINCE2 og Scrum

Igennem en del år har det især været to modeller, der har konkurreret, som repræsenterer hver deres måde at se tingene på: Den ene er PRINCE2, som er et godt eksempel på en topstyret model, dvs. en model der tager udgangspunkt i forretningen og anvender klassisk projektledelse som et grundlæggende element. Den anden er Scrum, der tilsvarende er en model, som kommer nedefra, dvs. som er et bud på hvordan leverandøren og udviklerne ser tingene. Ofte ser man de to modeller i en slags symbiose, hvor PRINCE2 (eller en anden topstyret model) anvendes til den overordnede styring af projektet, mens Scrum (eller noget der ligner) anvendes til selve fremstillingsprocessen.

Det er dog ganske sikkert at ingen af fædrene til ovennævnte to modeller havde forestillet sig det anvendt på den måde, da modellerne blev lanceret, så måske har begge lejre overset noget?

Lad os kigge lidt på hver af de to modeller for på den måske at prøve at forstå hvad forskellen er - og hvor de forskellige metoder har deres styrker og svagheder.

PRINCE2[tm]

PRINCE2 er det bedste eksempel på en 'topstyret' model, da det er den der anvendes af hele det officielle Danmark. Forkortelsen betyder helt enkelt PRojects IN Controlled Environments (version 2), altså en måde at holde projekter under kontrol. Hvordan forestiller man sig så at det skal ske? Her vil jeg lige indskyde at selv om PRINCE2 nok oprindeligt har sin inspiration fra IT-projekter, er det en generel projektmodel, der altså kan anvendes til alle typer projekter. Man kan bygge en bro, en bil eller et hus ved hjælp af PRINCE2, og modellen bliver generelt betragtet som 'best practice' (i hvert fald af dem, der har opfundet den).

PRINCE2 har undergået mindre ændringer igennem årene, men substansen er den samme. Den er baseret på syv principper, syv temaer og syv processer. Så burde det være nemt at huske.

Herunder er en kort oversigt på engelsk (så man slipper for en eller anden halvdårlig uofficiel oversættelse):

De syv principper:

  1. Continued Business Justification
  2. Learn from Experience
  3. Define Roles and Responsibilities
  4. Manage by Stages
  5. Manage by Exception
  6. Focus on Products
  7. Tailor to the Environment

De syv temaer:

  1. Business Case
  2. Organisation
  3. Quality
  4. Plans
  5. Risk
  6. Change
  7. Progress

De syv processer:

  1. Starting Up a Project (SU)
  2. Initiating a Project (IP)
  3. Directing a Project (DP)
  4. Controlling a Stage (CS)
  5. Managing Product Delivery (MP)
  6. Managing Stage Boundaries (SB)
  7. Closing a Project (CP)

Jeg lærte selv oprindeligt PRINCE2 på dansk, og noget af det hænger ved. Derfor kommer jeg sikkert til at bruge de danske udtryk i flæng. Eksempelvis hedder faser 'stages' på engelsk, men grundlæggende er det stadig det samme, man taler om: En tidsmæssig opdeling af et projekt i mindre dele. Var det ikke Cæsar, der sagde 'del og hersk'? Den del kan vi godt genkende fra andre modeller også.

Jeg vil opfordre læseren til selv at prøve at sammenligne principperne med dem fra det agile manifest. Jeg tror de fleste af principperne fra PRINCE2 sagtens kunne have været en del af de agile principper også, men de to grupper har altså valgt at fokusere på ret forskellige ting - selv om man sikkert har kunnet være enige om mange af principperne.

PRINCE2 handler om at man har kontrol over projektet fra start til slut. Og med 'man' mener man først og fremmest kunden, altså den organisation som bestiller, betaler og benytter sig af slutproduktet. Lad os dykke ned i nogle få af temaerne og enkelte af processerne:

Organisation

PRINCE2 taler om at overføre et mandat fra den bagvedliggende basisorganisation til projektorganisationen (som jo er midlertidig) via styregruppen. Styregruppen er altså projektets øverste beslutningsorgan. Dvs. hvis man på et tidspunkt skal have afklaret væsentlige problemer eller truffet vigtige beslutninger, som angår projektet, så kan det i sidste ende nå op til styregruppen. Til daglig er det dog projektlederen, der har ansvaret, og som derfor træffer de væsentligste beslutninger (sammen med den øvrige organisation). Projektlederen har også et mandat fra styregruppen i forhold til projektet, og skal følgelig arbejde indenfor det mandat.

Man taler om at man nedad i organisationen får et mandat og en ramme at arbejde efter. Hvis man så har et problem, der går ud over rammen, får man brug for at eskalere, dvs. at få nogen på et højere beslutningsniveau til at hjælpe med beslutningen. Dette er noget helt fundamentalt i PRINCE2 (manage by exception).

PRINCE2 interesserer sig ikke meget for hvad der sker under projektlederen, idet man forsøger at holde modellen meget generisk. Der er dog bl.a. nævnt muligheden for en 'teamleder', og man har også nogle anbefalinger til teknikker til produktfremstillingen, f.eks. produktbaseret planlægning.

Et væsentligt udgangspunkt i PRINCE2 er at der er tale om et kunde-/leverandørforhold (da modellen primært er udarbejdet til offentlige myndigheder), og derfor antager man også at projektlederen arbejder for kunden. I praksis ser man dog ofte at leverandører stiller med en projektleder, og der kan være tale om en slags parløb mellem to projektledere fra hver sin organisation.

Risikostyring

PRINCE2 har nogle gode metoder og teknikker i forhold til risikostyring, hvor man kan arbejde meget proaktivt med dette. Her ser jeg en stor modsætning til de fleste af de agile metoder, som er meget mere reaktive på dette punkt. Derfor vil jeg lige berøre det emne.

En risiko er en hændelse, der måske opstår på et tidspunkt og som kan påvirke projektet i positiv eller negativ retning (i praksis har man ofte mest fokus på de sidste).

Uanset hvordan man arbejder med projekter og IT-udvikling, bør man altid lave et minimum af risikostyring. Jeg har kendskab til flere organisationer, som slet ikke bruger det i deres projekter, men det er faktisk ikke særlig svært.

Kort fortalt er processen at man indsamler risici (det kan ske på flere måder), vurderer dem i forhold til sandsynlighed og konsekvens, og så tager man et aktivt valg omkring den enkelte risiko. Dette sidste er vigtigt. Ellers er det ret ligegyldigt. Gør man det rigtigt, sørger en ordentlig risikoproces for at man aldrig bliver rigtig overrasket. Hvis der opstår noget, som man egentlig ikke regnede med, så har man formodentlig ret hurtigt en idé om hvordan man kommer videre.

PRINCE2 taler om seks mulige handlinger for en risiko:

  • Undgå
  • Reducere
  • Plan B
  • Overføre
  • Acceptere
  • Dele

Det vil altså sige at før risikoen evt. indtræffer (og bliver til fakta), så har vi allerede bestemt os for hvad vi gør. Så vi mister altså ikke noget tid på først at skulle forholde os til det indtrufne og begynde at lave analyse, planer osv. Jeg tror de seks betegnelser er nogenlunde selvforklarende, men jeg vil lige kort gennemgå dem:

Undgå handler om at man sætter nogle ting i værk for helt at undgå at risikoen indtræffer. Det kan man gøre på mange forskellige måder afhængig af hvad risikoen er. Er man f.eks. bekymret for at nøglepersoner forlader virksomheden eller projektet, kan man ansætte nye og lære dem op eller man kan indføre en bonusordning eller lignende. Er man bekymret for om en tidsplan holder, kan man justere den til et realistisk niveau.

Reducere ligner undgå, men her forsøger man i stedet at minimere risikoen, enten ved at minimere sandsynligheden for at den opstår eller ved at reducere effekten, skulle den indtræde (eller begge dele). De to eksempler under undgå kunne egentlig lige så godt høre hjemme her.

Plan B (oprindeligt Fallback) handler om at man har en 'fallback-plan', altså en eller anden form for Plan B, som man vil følge hvis risikoen indtræffer. Et godt bud på en Plan B, der ofte bliver anvendt, er at håndtere noget manuelt hvis den automatiske løsning fejler.

Overføre handler om at overføre risikoen til nogle andre. Det kunne f.eks. være at man forsikrer sig ud af det.

Acceptere er vel det, man implicit gør hvis man slet ikke arbejder aktivt med risikostyring, dvs. at man accepterer at risikoen er der, men man gør ikke noget ved det. Det kan være man opfatter det som usandsynligt at risikoen indtræffer, eller måske er det for besværligt eller dyrt at gøre noget ved det. Så træffer man et aktivt valg om at acceptere risikoen, og forholder sig dermed først til det, hvis risikoen rent faktisk indtræffer.

Dele betyder at man deler risikoen med andre. Det kunne f.eks. være mellem kunden og leverandører.

Version2 har faktisk tidligere haft noget om dette, og her er et link til et indlæg hvor man kan se en skitse for hvordan man kan gribe det an (det er kun ét indlæg i en serie):
https://www.version2.dk/blog/praktisk-risikostyring-i-5-trin-33-52306

Processerne

Her er et overblik over hvordan PRINCE2 hænger sammen:

Illustration: Grafik fra prince2howto.com

Man starter yderst til venstre, men processen Starting Up a Project vil ikke nødvendigvis gøre at man starter projektet op for alvor. Den proces er nemlig med til at sikre sig at man får startet det rigtige projekt op. Hvis man i den fase finder ud af at man ikke bør gå videre i processen, så kan det godt slutte allerede der. Det er først når man går i gang med Initiating a Project at projektet starter op for alvor. Her er der altså en ekstra kontrol, hvor man kigger på en foreløbig Business Case for at se ret tidligt om det overhovedet kan betale sig at starte projektet. Det handler dog primært om at se på de helt grundlæggende ting, f.eks. hvis nogle forudsætninger skulle have ændret sig, siden man første gang fik ideen til projektet, men også om at få fastlagt lidt mere detaljeret hvad projektet egentlig går ud på samt at få et mandat til at gå videre.

De øvrige processer handler meget om hvordan man styrer den enkelte fase (samt overgangen mellem faserne) og hvordan man tilsidst afslutter projektet.

Scrum

Scrum er det bedste eksempel på en 'bundstyret' model, da den er ret udbredt her i landet og stadig en af de mest brugte agile modeller - også selv om den ofte anvendes på en helt anden måde end opfinderne havde regnet med, og selv om den ofte bliver tilpasset ret meget.

Organisation

I Scrum er der nogle ganske andre roller nævnt end dem, vi ser i PRINCE2. Der er primært nævnt tre forskellige roller (altså projektdeltagere) i et Scrum-projekt: Produktejeren (Product Owner), Scrum Master og selve Scrum-teamet (udviklere og øvrige, der deltager i selv konstruktionsdelen).

Her er en oversigtstegning:

Illustration: Grafik fra wikipedia

Man har ikke nogen egentlig proces for at starte et projekt, men man antager at man på et tidspunkt får udarbejdet en liste over de ting, der skal laves (Product Backlog). Det er produktejerens ansvar at vedligeholde denne liste og sørge for at få beskrevet tingene, sådan at Scrum-teamet kan tage fat i de enkelte opgave og begynde at arbejde på dem.

Hvor PRINCE2 har lagt meget op til at det er projektlederen, der giver udviklerne opgaver, så er Scrum i sit udgangspunkt ret anderledes: Her er det godt nok produktejeren, der prioriterer opgaverne, men det er Scrum-teamet som beslutter sig til hvad de mener at kunne levere i det næste 'sprint'. Et sprint er en kort periode (typisk 14 dage) og svarer ikke helt til PRINCE2's faser (men man kan forestille sig at man som en del af en fase har et antal sprints). Dette er baseret på estimater, og de er ofte ret grove i starten, men bliver bedre efterhånden som man har arbejdet med produktet/projektet i nogen tid.

Scrum handler meget om at teamet tager et fælles ansvar, og man holder typisk et dagligt kort møde, ofte benævnt 'stand up' (fordi man tit står op til møderne) eller slet og ret 'Scrum'. På mødet fortæller hvert af teamets medlemmer kort hvad man lavede i går, hvad man laver i dag og hvad man skal lave i morgen. Man fortæller også om man har nogle udfordringer, men det er vigtigt at man ikke går i løsningsmode på selve mødet.

En væsentlig forskel på Scrum og PRINCE2 er at man i Scrum ikke har nogen projektleder. Produktejeren har ansvar for produktet, Scrum Master har ansvar for processen, og Scrum-teamet har et samlet ansvar for det enkelte sprint. Så man får på den måde delt ansvaret på en lidt anden måde end ved en mere traditionelt topstyret model.

Som man måske kan regne ud, er der både fordele og ulemper ved den måde at arbejde på.

Den virkelige verden - både top og bund

Her er et uddrag fra en jobbeskrivelse som et eksempel på en måde nogle organisationer arbejder på: "Medarbejderen omskriver forretningskravene til backlog items, sådan at udviklerne ved, hvad de skal udvikle, efter det er overdraget til Scrum-teamet."

Som man måske kan ane af denne annonce (som er lettere omskrevet her), så er der her tale om en pudsig mellemting mellem forskellige modeller. Hvis det var ægte Scrum, burde kravene (som slet ikke er 'krav' når vi er i den agile jargon) blive skrevet direkte som Product Backlog Items (ofte forkortet PBI'er), f.eks. som User Stories. Og teksten lyder som om der måske er tale om offshore udviklere, hvilket også kan give udfordringer i forhold til den agile model.

Ofte ser man i den virkelige verden at man kombinerer de to modeller. Dvs. at man bruger noget, der ligner PRINCE2 til hovedstyringen af projektet. Når man så kommer til selv fremstillingen, bruger man en mere agil model, f.eks. Scrum. Så når visse virksomheder siger at de er 'agile' kan det være fordi de anvender en agil metode til fremstillingsprocessen, men ofte har man stadig en traditionel projektstyring ovenpå. Mange store organisationer laver rigtig mange ting med Scrum-teams, men man har så stadig en projektleder som et bindeled mellem Scrum-teamet og den øverste ledelse i projektet. Helt personligt mener jeg det er en dårlig måde at gribe det an på, da man får meget større afstand mellem ledelsen/forretningen og projektteamet. En meget bedre løsning er hvis projektlederen i stedet fungerer mere som en Scrum Master - det jeg vil kalde 'agil projektledelse' (eller sagt på en anden måde: Man forfremmer Scrum Master til også at være projektleder). Jeg har talt med projektledere i den type store organisationer, som indrømmer at de faktisk ikke aner hvad der foregår i de enkelte Scrum-teams, for det er jo Scrum Masterens job at gøre det. Hvordan kan de så vide hvordan det går i projektet? Det, mener jeg, ikke er særlig 'agilt'.

Kan top og bund mødes?

Det ser pudsigt nok ud til at de to parter (altså folkene bag hhvs. PRINCE2 og de agile modeller) er begyndt at nærme sig hinanden de senere år.

F.eks. har en ny variant af PRINCE2 set dagens lys for ikke så længe siden: PRINCE2 Agile. Essensen er stadig klassisk PRINCE2, men med bedre koblinger til forskellige måder at lave agil udvikling. Man kan læse mere på wikien her: PRINCE2 Agile

De agile bagmænd har heller ikke siddet stille. Det nye sort indenfor agil udvikling hedder SAFe: Scaled Agile Framework, og her er man kommet frem til dette monster af en procesmodel:

Illustration: Grafik fra www.scaledagileframework.com

Suk .....

Kære læser.

Kig lige på ovennævnte tegning og sig mig om du synes det er i overensstemmelse med det agile manifest? Er noget 'agilt' fordi ordet indgår i det? Her følger som en hjælp den allerførste linje fra det agile manifest: "Individuals and interactions over processes and tools"

(man har endda opfundet en 'agil business case' ...)

Læs mere hos SAFe og døm selv.

Personligt tror jeg desværre at vi har lang vej endnu før vi har fundet en model, der finder den rigtige balance mellem top og bund - mellem vandfald og agilt. En af grundene er måske at organisationerne glemmer at tilpasse projektmodellen til den virkelighed den skal bruges i (dvs. produktet, projektet og organisationen). Jeg har set en tendens i mange organisationer til at metodeafdelingen bliver nedlagt eller nedprioriteret, og det skyldes måske at man mener at have helt styr på metoderne nu. Men jeg mener rent faktisk at man har brug for dygtige metodefolk, hvis man skal have dette til at fungere optimalt.

Som altid ser jeg frem til at få nogle kommentarer fra læserne, især hvis I har erfaringer med noget af det, jeg har skrevet om.

Jeg har ikke selv nogen særlig praktisk erfaring med hverken PRINCE2 Agile eller SAFe. Jeg ved faktisk ikke om mange virksomheder har opdaget PRINCE2 Agile og taget det til sig. Men jeg ved at flere store organisationer er i fuld gang med at forsøge at få SAFe til at fungere, så er der nogle af jer der har nogle praktiske erfaringer med det, og vil fortælle os andre om det?

Kommentarer (0)
Log ind eller Opret konto for at kommentere