15. maj 2017
Jan Pries-Heje, Professor på RUC og ekstern underviser hos Mannaz
Overvejer du at bruge agil projektledelse? Eller er du allerede i gang? Læs med her, og få it-professorens syn på projektledelsesmetodens muligheder, potentiale og begrænsninger.
Agil projektledelse er for alvor ved at få fodfæste i Danmark. Mange virksomheder har således for længst implementeret metoden. Men andre tøver stadig og er i tvivl om, hvorvidt agil projektledelse vil skabe værdi for dem. Lad os derfor starte med at sætte nogle få ord på, hvad det er, som agil projektledelse kan. Svaret ligger i den agile projektledelsesforms evne til at absorbere forandringer hurtigt og effektivt. Den er simpelthen født til at håndtere forandringer. Og dermed kan den agile form bedre håndtere den fart, hvormed virksomhederne tvinges til at forandre og tilpasse sig omverdenen.
Ofte ved virksomhederne ikke engang selv, hvordan udfordringerne skal løses, og så er det svært at lave en kravspecifikation. Alligevel har mange prøvet at lave en kravspecifikation på klassisk vis, som de er kommet galt afsted med. De har ikke været tilstrækkeligt inde i stoffet, og selvom de måske har spurgt brugerne i jagt efter klarhed, så har de svar, de har fået, været noget i retningen af, at det nye skal være som det gamle bare lidt bedre og hurtigere. Eller for at pensle det helt ud, så svarer det til at ønske sig en hurtigere hest i stedet for at udvikle en bil. Her opstår fejlen allerede, fordi man tager udgangspunkt i det gamle, selvom teknologien giver os helt nye muligheder, eksempelvis via digitale platforme, IA og robotteknologi.
”De korte iterationer med brugerinvolvering er selve fundamentet for det agile princip.”
Det er ikke underligt, at det er svært for brugerne at definere, hvad de får brug for i fremtiden. Vi står nemlig over for markante forandringer, og ikke engang eksperterne er enige om, hvad fremtiden helt præcist bringer. Men netop i mødet med det ukendte og det upræcise har den agile projektledelse sin styrke. Den agile projektledelsesform omfavner nemlig forandringer, fordi metoden er iterativ. Man laver måske en hurtig prototype, får feedback fra brugerne og tilretter eller laver så en helt ny prototype, hvis den første skød forbi. På den måde er brugerens feedback i centrum af udviklingen i modsætning til den klassiske metode, hvor brugeren typisk først ser slutproduktet ved projektets afslutning. De korte iterationer med brugerinvolvering er selve fundamentet for det agile princip. Brugerinvolveringen er afgørende, fordi projektteamet naturligvis ikke kan være eksperter i alt, i stedet skal de have et tæt samarbejde med en bruger med beslutningsmandat. Og her er beslutningsmandatet nøgleordet, for det hurtige svar sikrer hurtig fremdrift og sparer oceaner af ventetid.
Den omfattende brugerinvolvering kan virke voldsom, fordi projektejeren skal være til rådighed næsten hele tiden. Det er prisen for projektets hastighed, og jeg oplever da også ledere, som siger, at de ikke har tiden. Er det tilfældet, så passer agil projektledelse ikke ind i den pågældende organisation, for tilgængeligheden er en præmis for succes med det agile. Brugerinvolveringen gør også, at agil projektledelse ikke egner sig til projekter, hvor brugerne ikke er tydelige, eksempelvis hvis man skal lave et datagrundlag, som skal bruges af nogle andre systemer. En grundlæggende forudsætning for agil projektledelse er desuden, at alle kan løse alle opgaver i teamet, men i rigtig mange virksomheder har man specialiseret sig i fagområder. Der er måske en analytiker, en it-arkitekt og en digital designer, og de kan kun løse egne opgaver, og så får man ikke glæde af fx Scrum, når man står med et team bestående af 6 specialister. Til gengæld er faren for flaskehalse stor, og i de tilfælde er agil projektledelse heller ikke oplagt.
”Øvelse gør mester – specielt når det handler om agil projektledelse.”
I forbindelse med en artikel jeg skrev for nylig om agil projektledelse, interviewede jeg ni forskellige virksomheder, og min erfaring var, at ingen brugte Scrum-metoden fuldt ud. Min oplevelse var snarere, at virksomhederne havde taget de dele, som de kunne bruge og havde tilpasset metoden til deres virkelighed. Lidt overraskende, men jeg synes, det er positivt, for det vigtigste er, at virksomhederne finder en metode, som sikrer fremdrift og succes. Indtil videre har erfaringerne i øvrigt vist, at Scrum og andre agile metoder egner sig bedst til små projekter med op til 15 deltagere, men lige nu presses den grænse. Det store spørgsmål er, hvor store teams der kan køre agilt? Det er her, vi kommer til at se den næste innovation inden for agil projektledelse, hvis du spørger mig. For at lykkes med store teams kræver det i hvert fald, at man gør sig umage.
I forhold til agil projektledelse kan de klassiske, offentlige organisationer komme til at støde sig på den uformelle form, som du ser i fx Scrum. I de små teams vil det formentligt gå fint nok, men så snart projektet bliver større, kan det være udfordrende. Årsagen ligger i den hierarkiske opbygning i de offentlige organisationer, som gør det svært at uddelegere beslutningsmandatet til projektejeren. Selvom det måske går lidt langsommere med udbredelsen af agil projektledelse i det offentlige, så viser en undersøgelse udført af Mannaz og RUC, at 40% af danske virksomheder har prøvet agil projektledelse mindst én gang. Det giver mening, for der er mange fordele ved den agile form, selvom der selvfølgelig også er et mindset og nogle rammebetingelser, som skal være på plads. Hvis du gerne vil i gang med agil projektledelse, er det vigtigt, at du ikke bare går ”all in”. Hvert projekt skal vurderes i forhold til hvilken projektledelsesform, som egner sig bedst. Det er ikke agil eller intet. Og så skal du vælge en sikker vinder som dit første projekt. Agil projektledelse er nemlig noget, man skal øve sig lidt på, så lad være med at starte med dit mest risikofyldte projekt.
