De eerste definitie die ik hoorde van projectmanagement is het managen van het project binnen de afgesproken tijd en budget en volgens de opgestelde specificaties. Waar we dan voor moesten oppassen is dat we niet te maken krijgen met steeds weer nieuwe eisen van onze klant. Het is de vrees van elke projectmanager. We wapenden ons tegen deze scope-creep door middel van een strakke, vaak contractueel afgedwongen, wijzigingsprocedure. Met de hakken in het zand betreden team en klant het strijdtoneel om aan het eind van de contractonderhandelingen met de samenwerking te beginnen. Resultaat? Iets waar de klant niet op zat te wachten. Als je dan ook nog projectmanager binnen de overheid bent en openbaar moet aanbesteden dan wordt het leven er ook niet prettiger door.

In deze blog probeer ik vanuit het agile perspectief te bewegen naar het overbekende en nog veel gevolgde managementparadigma. Ik noem het paradigma omdat het vooral een sterke overtuiging is hoe je bepaalde zaken moet beheersen. Of het ook wijs is, dat is een andere vraag. Je zou eens met wetenschappers moeten praten over al die technieken, de meeste hebben weinig tot geen voorspellende waarde. Toch vormen ze een belangrijk onderdeel van de praktijk die we elkaar aan leren en praten.

Projectmanagement werkt vanuit een beheersingsparadigma dat niet vriendelijk tegenover veranderingen staat. Heel lang hanteerde ik de spreuk: ‘Een projectmanager vertraagt de planning om de uitvoering te versnellen!’ De onderliggende aanname is dat ik wanneer ik daar voldoende tijd voor neem ik de meeste zaken vooraf kan specificeren en dus kan plannen. Wat blijkt nu in de praktijk van alle dag? Dat dit een foutieve aanname is. Een heleboel is niet goed te voorspellen. Het meeste moeten we allemaal nog ontdekken en in kaart brengen. In mijn vorige blog ben ik in gegaan op schattingen, nu verbreed ik de blik enigzins.

Dat wat zeker is, zouden we volgens het managementparadigma kunnen plannen en opleveren, echter dat werkt niet voor wat we nog niet helemaal zeker kunnen weten. Binnen agile spreken we van een productbacklog met zaken die we willen doen. Regelmatig schonen we deze op door onze wensen in lijn met de behoefte te brengen. Wanneer we de backlog verdelen in zekere producten en producten waar we nog een keuze voor moeten maken, dan zijn we een eind op weg. De zekere dingen schatten we zoals in de vorige blog geschreven, de onzekere gaan we uitzoeken wanneer de tijd daar rijp voor is. Niet zoals als in het managementparadigma, aan het begin van het project, nee tijdens wanneer we het kunnen weten. Stel je eens voor hoeveel tijd dit uitspaart. 

Maar dan zijn we er nog niet, want een ander probleem is de opdrachtgever. Dit is de uiteindelijke beslisser voor elke uitbreiding van de scope. Het is een vreemde snoeshaan, want hoewel deze verantwoordelijk is voor het organisatiebelang (vastgelegd in een businesscase) is het vaak niet de feitelijke gebruiker. Die mag, vertegenwoordigd door een senior gebruiker meepraten in de stuurgroep, maar niet beslissen. Ik stel voor de opdrachtgever af te schaffen en de senior gebruiker vastgesteld budget te geven om als een productowner te besluiten welke producten we voor dat budget willen hebben en kunnen aanschaffen en daar moet hij het dan ook maar mee doen. Er zit nog wel een adder onder het gras wat betreft randvoorwaardelijke producten, maar ook daar kunnen we een soortgelijke constructie voor ontwerpen.

Is dit te simplistisch? Ja dat is het! Is het agile? Neen dat is het niet. Je mag het wat mij betreft hybride noemen, maar als je mij een beetje kent dan weet je dat ik dat niet echt zie zitten. Wat is het dan, het is een poging om met de inzichten uit het agile paradigma naar dat van de beheersing over te brengen. 

Nu we de opdrachtgever hebben geëlimineerd moeten we het ook hebben over de businesscase Dat is het onderwerp van mijn volgende blog.