Sådan får du det agile PMO til at fungere og bevarer kontrollen over dine agile projekter

5 målepunkter, som giver overblik i det velfungerende agile PMO At mange organisationer kører agile projekter er der ikke noget nyt i. Der er heller ikke noget nyt i, at en agil tilgang til projekter og projektledelse øger sandsynligheden for projektsucces betragteligt. Der er også mange organisationer, der har etableret et PMO, hvilket kun kan anbefales, hvis man ønsker at bevare overblikket, og få en samlet status på sine projekter. Men hvad gør man så, hvis projekterne kører agilt, mens virksomhedens PMO fortsætter, som det plejer på god gammeldags vandfaldsmanér og i henhold til traditionelle projektmetoder? Det hænger ikke rigtigt sammen, og man er nødt til også i PMO-funktionen at få forståelse for agile principper og selv blive mere agil. Man vil ikke kunne opnå de gevinsterne ved at bruge agile metoder, hvis holdningen i virksomhedens PMO er: ”Kør I bare agilt, men husk lige at udfylde jeres projektdokumenter, og glem heller ikke vores 2-timers projektstatusmøde hver fredag”. Men hvad laver man egentlig i et PMO, og har det sin berettigelse i en agil verden? Svaret på det sidste spørgsmål er JA, og svaret på det første kommer her: Eksempler på funktionerer, der kan ligge i et PMO

• Projektradar: Der indhenter troværdig information om projektfremdrift og –økonomi. PMO er ledelsens øjne og ører ift. de kørende projekter.
• Kontroltårn: Som udarbejder de processer, som projektlederne skal følge, og følger op på, at det sker. PMO bidrager til at øge forudsigeligheden i projektresultaterne
• Ressourceansvarlig: Sørger for udvælgelse, udvikling og fastholdelse af projektledere
• Porteføljemanager: Er med til at prioritere porteføljen, og fastholde sammenhæng mellem denne og de tilgængelige ressourcer
• Gevinstansvarlig: Følger op på, om de gevinster, der var baggrunden for at gennemføre givent projekt bliver realiseret som forventet

Traditionelt har PMO-funktionen været set som en slags ”politimand” i forhold til projektlederne, og sådan en er der faktisk også brug for. Projektledere kan være lidt primadonna-agtige, og mener sjældent, at netop deres projektadfærd kan trænge til justering. Forståelsen af at køre virksomhedens projekter ensartet for at optimere projektsucces ligger ikke lige for, hvis man har været projektleder i mange år, og mener, at man har godt styr på sagerne. Men det er ikke desto mindre én af de faktorer, der kan højne kvaliteten i og resultaterne af virksomhedens projekter. Uanset om man kører projekter efter traditionelle metoder, efter agile metoder eller har kombineret de to, så der det et faktum, at standardisering i projektleverancen øger kvaliteten og medvirker til at forkorte projekters gennemløbstid. Men hvad så, hvis man pludselig vælger at køre agile projekter? Det er en kendt sag, at projektsucces målt på tid, penge og målsætning er større, hvis man vælger en agil tilgang, men passer det ikke skidt med det traditionelle PMO? NEJ, er det korte svar. Projektets natur som sådan ændrer sig jo ikke, bare fordi man vælger en agil projekttilgang. Men man er nødt til at måle på nogle andre ting, end dem man plejer at måle på i et PMO. Her får du 5 målepunkter, som kan anvendes i det agile kontroltårn. Disse 5 punkter kan desuden bidrage til at overbevise en virksomhedsledelse om, at det ikke er et udvikler eller et leverandør tag-selv-bord, hvis man vælger at kombinere Scrum med den eksisterende, traditionelle projektmetode, og dermed give dem mere ro i maven og tillid til processen.

1. Mål på velocity: Dette har ikke til formål at skrue et teams velocity i vejret, men simpelthen at måle på, om teamets velocity-mål svarer nogenlunde til det, de i praksis kan levere sprint for sprint. Så får man forudsigelig omkring hvad man realistisk kan forvente, at et givent team stabilt kan præstere.
2. Mål på kvaliteten af estimaterne: Dette giver et billede af, om teamets overordnede estimater af product backlog er holdbare, når man sammenligner med detailestimeringen af sprint backlog. Det vil med tiden øge træfsikkerheden i teamets estimater, og dermed minimere økonomiske risici.
3. Følg op på behandling af impediments: Det er ikke nok, at teamet registrerer, hvad der forhindrer fremdrift. Scrum Masteren skal også aktivt handle på disse, og gøre noget ved forhindringerne, så check at dette sker.
4. Mål på, at Scrum principper for test og dokumentation følges: Det er et vigtigt Scrum-princip, at et sprint ikke er færdigleveret før leverancerne er testet og dokumenteret. På den måde bygger man kvalitet ind i projektet, og får rettet fejl tidligst muligt i processen. Det sparer tid og penge. Mange penge.
5. Check at release-planer følges: At køre agilt er ikke ens betydende med, at planer, sprintlængde, velocity m.v. kan ændres i tide og utide. Der skal være gode grunde til at ændre sine release-planer. Følg op på, at det der, aftales på hvert sprint planlægningsmøde, også bliver leveret, så release-planer kan følges.

Måler man på disse punkter, er der nærmest garanti for, at det agile PMO vil få et meget robust overblik over de agile projekter og dermed over kvaliteten i projektporteføljen.