Kies de organisatievorm die past bij ‘de opdracht’: organiseer je het als project, als programma, in de lijn, of agile?
5 minuten
Door Ron Linssen
Van symptoom naar oorzaakbestrijding met als doel om het percentage succesvolle ICT-projecten significant te verhogen. Deze week deel 1 van 5: Kies de organisatievorm die past bij ‘de opdracht: organiseer je het als project, als programma, in de lijn, of agile?’. Waarom is het zo belangrijk om de juiste organisatievorm te kiezen bij het specifieke karakter van een opdracht? Op basis van welke criteria doe je dat? Wat zijn veel voorkomende missers? En wat zijn de gevolgen hiervan?
Voordat ik antwoord kan geven op de vragen, is een stuk achtergrond en theorie van belang. Daarom neem ik je eerst kort mee in de verschillende organisatievormen
Project
Een ‘project’ is een tijdelijke organisatie met als doel een concreet eenmalig doel te bereiken dat met gelimiteerde middelen (tijd, geld, resources) moet en kan worden bereikt. Het is een organisatievorm met voor én nadelen.
De voordelen (als je goed doet): verantwoordelijkheden zijn helder, resultaten zijn helder en er is een duidelijke planning over wat wanneer wordt opgeleverd en hoeveel het gaat kosten. Betrokkenen weten precies wat er wanneer van hen verwacht wordt. Het is bekend wat de kosten, de doorlooptijd én wat de kwalitatieve en kwantitatieve baten zullen zijn: er is een positieve Return On Investment (ROI).
De nadelen: er wordt een stuk overhead opgetuigd in de vorm van een projectorganisatie met een projectleider, een stuurgroep, en een of meerdere sub teams die zich moeten houden aan best practice producten die nodig zijn om het project beheersbaar te laten zijn. Ruwweg is minstens 10% van de totale kosten hiervoor nodig. Dit betekent dat bij een project met een budget van € 1.000.000 moet gerekend worden dat € 100.000 nodig is voor de projectbesturing, ‘overhead’. Als er een externe projectleider nodig is, red je het niet met dat bedrag of het moet een korte doorlooptijd kennen.
Kortom, waarom een project als organisatievorm kiezen? Als de voordelen opwegen tegen de nadelen. Als de kans groot is dat er meer dan € 100.000 verspild wordt door inefficiency en/of verloren kansen.
Welke alternatieven organisatievormen zijn denkbaar?
In de lijn
Beleg het ‘in de lijn’. Als de lijnorganisatie (een organisatie met een organisatiestructuur die van onder tot boven een duidelijke hiërarchische opbouw heeft) hiervoor tijd heeft, dan zitten ze erg ruim in het jasje, dat zou niet moeten kunnen. Hier is een normale lijnorganisatie niet op berekend. Vaak wordt dit toch, deels gedaan, “omdat we het leuk vinden voor de afwisseling”. Een verkeerd argument, dat spreekt voor zich!
Programma
Het valt mij op dat er veel misvattingen zijn over een programma als organisatievorm. Meestal wordt het gebruikt als een verzameling projecten die door één programmamanager wordt bestuurd, zonder dat er enige samenhang hoeft te zijn tussen die projecten. Het is meer een organisatie van werk, een hiërarchie.
Dit is niet zoals een programma is bedoeld: het bereiken van strategische doelen waarbij niet helder is in hoeveel stappen het bereikt zal of kan worden. Zeker is dat het opgedeeld zal worden in stappen, soms of veelal projecten.
Dit maakt programmamanagement volkomen anders dan projectmanagement. Waar een project moet worden gestuurd op één doel, meerdere concrete resultaten en een strak plan en budget, wordt een programma bestuurd op de richting waarbij uiteraard op de eventuele deelprojecten wel strak gestuurd kan worden.
Waar een project ‘de reiziger is die naar één plaats toegaat’ is een programma ‘de trekker die nog niet weet waar hij zal eindigen maar wel minimaal een X aantal ervaringen wil hebben opgedaan over 3 jaar’.
Agile
Veel organisaties denken dat projecten als besturingsvorm niet meer nodig zijn; “we doen het toch agile?” Een -veel voorkomende- misvatting die goed inzichtelijk te maken is met de Stacey Matrix:
Bron: Quantra Project Succes best practices
Deze matrix stelt je in staat een afweging te maken welke organisatievorm zou passen op basis van (on)zekerheid op twee variabelen:
‘Wat’: de Y-as: de (on)zekerheid over wát er moet komen: weten we hoe het eruit moet zien? Hoe het moet werken? Voor wie het is bedoeld? Etc.;
‘Hoe’: de X-as: de (on)zekerheid over hóe we dit resultaat kunnen bereiken.
Als zowel de X als Y laag zijn, is er grote zekerheid over wát er moet komen en hóe dit gerealiseerd kan worden. Dit leent zich prima voor een sterke mate van standaardisatie met bijvoorbeeld ‘Lean’ / ‘Six Sigma’ of verregaande (‘just-in-time') automatisering.
Bij het tegenovergestelde: X en Y zijn hoog (dus veel/alles is onzeker), past een sterke ‘chaos’ aanpak, dit vereist continue bijsturing en bewaking van onzekerheden. Maar ook: doen en zien waar we uitkomen. Daartussen zit een gebied waar projecten cq de agile aanpak prima kunnen passen. Onthoud daarin één van de kernprincipes van een project: het moet een uniek resultaat opleveren. Dat mag best wat onzekerheid hebben, zoals over het ‘wat’ als het ‘hoe’ maar het moet wel beheersbaar te maken zijn: het moet immers in een beperkte vastgestelde hoeveelheid tijd en geld op te leveren zijn.
Als dat niét lukt: maak er dan geen project van en kies voor een andere aanpak. Wanneer de onzekerheden groter zijn, past een agile-werkwijze beter. Hierbij wordt met korte cycli gewerkt, waardoor onzekerheden met iedere cyclus een stukje worden bepaald en ingevuld.
Waarom is het zo belangrijk om de juiste organisatievorm te kiezen bij het specifieke karakter van een opdrach
Daarbij verwijs ik bij voorkeur weer naar de Stacey Matrix. Dit is namelijk de meest gebruikte matrix om een betere inschatting te kunnen maken van organisatievorm versus complexiteit en ontvankelijkheid. Lastige theorie misschien maar onthoud: niet alles is geschikt voor agile werken. Hetzelfde geldt voor een project of voor in de lijn. Gebruik de X en Y as met onzekerheden als hulpmiddel.
Wat gebeurt er als er voor de verkeerde organisatievorm wordt gekozen?
Scenario 1
Wat beter een project had kunnen zijn maar in ‘de lijn’ is opgepakt? De kans is groot dat het (veel) langer duurt en wellicht nooit de beoogde resultaten worden bereikt, al is het maar omdat deze niet formeel zijn vastgelegd en bewaakt.
Scenario 2
Wat beter een project had kunnen zijn maar agile is opgepakt? Lastiger. Als dit echt goed is gedaan en de resultaten zijn vertaald in backlog items, dan zou het prima een vergelijkbare of zelfs betere uitkomst op kunnen leveren dan wanneer het in project was gedaan. Volgens de theorie. De werkelijke praktijk die ik zie wijst anders uit. Als meerdere organisatieonderdelen betrokken zijn met meerdere productowners gaat veel tijd verloren. Het kán, maar ik zou echt de voorkeur geven aan de project-organisatievorm.
Scenario 3
En andersom? Als het als project aangevlogen is maar achteraf gezien beter agile of in de lijn gedaan had kunnen worden? Dan is de kans erg groot dat dit project ook kan worden toegevoegd aan de lijst van gefaalde projecten. Dat brengt ons bij de volgende vraag:
Op basis van welke criteria bepaal je of ‘project’ de best passende organisatievorm is?
Naast de Stacey Matrix moet vooral vast worden gehouden aan de definitie van een project zoals deze hierboven is beschreven. Dat maakt de keuze bijna eenvoudig: kan er geen afgebakend doel worden vastgesteld? Concreet te definiëren resultaten waarbij maar voor één uitleg vatbare acceptatiecriteria beschreven zijn? Nee: maak er dan géén project van. Mijn advies? Probeer alsnog het doel concreter te maken en de resultaten te concretiseren. Lukt dat niet? Dan past een agile werkwijze om te trachten het doel in kleinere stappen te behalen. Geen concreet doel en resultaten, dan ook géén project van maken! Dat is vragen om mislukking.
Wat zijn veel voorkomende missers en wat zijn hiervan de gevolgen?
Alles in een ‘agile team’ willen doen. Dat kan heel goed gaan maar vereist een zeer volwassen adoptie van agile werken, waaronder goede samenwerking tussen productowners. En neen, het Scaled Agile Framework (SAFe) is géén vervanger hiervoor. SAFe is namelijk bedoeld voor grootschalige softwareontwikkeling en dus voor totaal iets anders.
Alles als een project willen doen. Een projectorganisatie wordt niet ontbonden, wat wel de bedoeling is als het doel is behaald, maar semiautomatisch voortgezet om het vervolg op te pakken, release 2. Of gaan wat anders doen. Onthoud: Geen concreet doel en resultaten? Kies niet voor project als organisatievorm!
Een programmavorm kiezen, terwijl de resultaten zeer goed vast te stellen zijn. Door dan voor de programmavorm te kiezen, is er te veel vrijheid en is de kans dat er langer over wordt gedaan dan noodzakelijk of de resultaten niet bereikt groot. Zijn de resultaten goed vast te stellen, maak er dan een project van.
Een programmavorm kiezen omdat we hiermee onderscheid willen maken in hiërarchie en de meer ervaren projectmanager een programma toewijzen in plaats van een project. Zie het vorige antwoord.
En tot slot: de keuze voor een vorm wordt gedaan in de begin, ideefase. Hoewel dan de (on)zekerheden vastgesteld kunnen worden kunnen omstandigheden altijd wijzigen. Dit staat los van de organisatievorm.
Het is dus niet alleen noodzakelijk om de vorm in het begin vast te stellen maar ook aan de hand van de concrete actuele situatie te blijven bewaken of de gekozen vorm nog altijd de best passende is.
Hierover meer in de vervolgartikelen in deze reeks van 5 die de volgende donderdagen worden gepubliceerd.
Ron Linssen