Hoe repareren we #projectmanagement?

Ik vind dat ons denken over projectmanagement radicaal moet veranderen omdat we anders niet goed in staat zijn om de enorme kansen die voor ons liggen het hoofd te bieden. De meeste auteurs over projectmanagement zijn het er over eens: voor een project bepaal je concrete doelstellingen en zorg je ervoor dat je een kwalitatief goed resultaat oplevert binnen tijd en budget. Het lijkt zo simpel, maar toch wringt er iets. Te vaak horen we dat projecten tegenvallen daar waar het gaat om het behalen van de doelstellingen. Dat heeft alles te maken met de verwachtingen die de standaard projectmanagementliteratuur wekt. Immers als het management van een project betekent dat je het afgesproken en van te voren op schrift gestelde resultaat oplevert en wel binnen hetzelfde opschrift gestelde budget en voor de afgesproken deadlines, dan is het natuurlijk niet vreemd dat mensen ontevreden zijn wanneer je een of meer van deze drie doelstellingen niet realiseert.

Als schattingen gemiddelden zijn, is het statistische vanzelfsprekend dat er een niet te onderschatten deel van de projecten op een of meer van de grote drie (tijd, geld en de kwaliteit van het resultaat) mis gaat. Het niet goed begrijpen hoe onzekerheid werkt is de voornaamste reden waarom de klassieke projectmanagementtheorie regelmatig teleurstellende resultaten oplevert. De vraag is of projectmanagement te repareren is. Er zijn velen die stellen dat Agile Werken een oplossing is. Gedeeltlijk blijkt dit ook zo te zijn. In de softwareontwikkeling heeft zich een radicale Agile revolutie afgespeeld. Hoewel ook hier mislukkingen zijn, lijkt het in ieder geval een stuk beter te werken dan de klassieke methode. Is het mogelijk om iets van de zogenaamde Agile Mindset over te brengen naar de klassieke wereld? Ik denk het wel, want iedereen die ooit is ondergedompeld in Agile Denken zal op een andere manier naar de wereld van klassiek managen kijken.

Zelf vind ik een van de voornaamste aspecten van Agile Denken dat je de actualiteit in plaats van het plan in het middelpunt plaatst. Uiteraard zijn er ook nog andere belangrijke zaken, maar ik houd het nu even op deze. Wat betekent dit nu werkelijk? Want als je, klassiek gezien, een doel stelt dan doe je juist het tegenovergestelde. Je bent immers dan van plan om je doel te realiseren. Want dat hebben we geleerd, stel een doel en plan je weg naar dat doel. Werkt dat nu echt? Is dat nu echt wat er gebeurd? Ik betwijfel het, in mijn persoonlijke leven heb ik wel zoiets als doelen, maar als ik kijk naar wat ik dagelijks doe, is dat ik dat doel steeds aanpas aan de mogelijkheden die zich voordoen. Al slingerend bereik ik iets wat ik achteraf mijn doel noem. Maar dat is het bij aanvang nooit geweest. Die keren dat ik een plan maak is dat meer een poging om een gemaakte beslissing de rechtvaardigen. Voor het plan komt het streven! Ik doe het plan met een reden.

In de reden zit fix voor projectmanagement. Niet in de businesscase of in het doel van het project. De reden van het project bepaalt de richting. De reden van een CRM systeem is dat de organisatie zijn klanten goed te woord wil staan. De reden van een breder snelweg is de doorstroming te bevorderen. De reden van een nieuw automodel is om meer omzet en winst te draaien. De reden van een veranderingstraject is om beter op marktbewegingen te reageren. Het zou de reden van een project moeten zijn die we gebruiken om te sturen, niet de in het plan vastgelegde en SMART gemaakte doelstellingen. Steeds proberen we zo snel mogelijk vast te stellen of het gekozen pad aansluit bij de reden waarom we het project doen. Bij elke stap kiezen we of we de kosten en de inspanning kunnen dragen om uit te zoeken of de richting de juiste is. Budgetten worden veroorloofbare verliezen. Al slingerend zoeken we, om nog eens maar een klassieke term te gebuiken, naar de meest optimale prijs/kwaliteit verhouding. Dat is de manier waarop we de missie van ons project vervullen.

Projectmanagers hebben beheersing altijd fout begrepen

De hele projectmanagementtheorie is zo verouderd als maar kan en zij is door en door rot. De mensen die projecten in beheerste omgevingen hebben bedacht zijn verantwoordelijk geweest voor een paradigma dat niet meer in deze snel veranderende tijden werkt. Ik vraag me zelfs af in welke mate het uberhaupt ooit gewerkt heeft. Het hele idee dat je een organisatie van te voren kunt ontwerpen is iets wat alleen in de sprookjesboeken voor managers voorkomt.

In ‘Making Sense of the Organisation’ van Karl E. Weick schrijft hij over het vermeende vermogen van de manager om de activiteiten van zijn ondergeschikten zowel te coordineren als te beheersen. Dit veronderstelt de volgende aannames:

  1. Beheersing is onevenredig verdeeld (top-down).
  2. Mensen leggen beheersmaatregelen op.
  3. Activiteiten zijn het object van die beheersing.

Wanneer we dit bezien in het licht van de agile ontwikkeling dan stel ik dat zolang je nog denkt dat dit juiste aannames zijn, dat je dan nog niet de juiste mindset hebt om de beloften van Agile te oogsten. Dan is het nodig dat je alsnog een paradigmaverschuiving ondergaat. Weick stelt drie alternatieve aannames voor:

  1. Beheersing is evenredig verdeeld (zelfsturing).
  2. Ideeen zijn de oorzaak van beheersmaatregelen.
  3. Ideeen zijn het object van die beheersing.

Het klassieke beeld van de organisatie is die van de hark met de CEO aan de top. Een sterke man of vrouw die de richting uitzet en deze met ‘beveel en heers’ implementeert in de organisatie. Met belonen en straffen werd de visie gerealiseerd. Maar dat, dat werkte niet. Hoe dan?

Wanneer we de organisatie zien als een stad met inwoners, de burgemeester heeft wel een belangrijke rol maar z/hij is zeker niet de baas. Een stad gedijt bij grote mate van zelfsturing en organisatie. De overheid zorgt voor de grenzen, maar daar houdt het mee op. De wijze waarop men beheerst, heeft te maken met de organisatie die we willen bouwen. Het idee is leidend. Daarom zijn de agile waarden en principes uit het Manifesto ook zo belangrijk, zij vertegenwoordigen een idee en dat idee zorgt voor de beheersing die nodig is.

Wat we moeten beheersen zijn de ideeen? Het is de mindset die we moeten bewaken, niet de activiteiten die de mensen doen, dat kunnen de teamleden zelf wel. Agile Leiders bewaken de mindset, niet meer en zeker niet minder.

Er is geen #businesscase voor #opdrachtgevers en #businesscases

Ik wil beginnen met een stukje geschiedenis. Mijn allereerste project was in het begin van de tachtiger jaren van de twintigste eeuw (ik vind dat beter klinken dan de vorige eeuw;-). Toen spraken we nog niet over opdrachtgever, eerder hadden we het over de klant. Maar we lieten dat een beetje in het midden. Ook verwachten we niet veel van onze klant of degene die ons op de klus zette. Een projectmanager in die tijd dook in de klus, werkte als het moet tachtig uur per week, en zorgde ervoor dat de klus geklaard werd. Overigens vaak met – net als nu – tegenvallende resultaten op het gebied van doorlooptijd, kosten en opgeleverde functionaliteit. Het duurde langer, kostte meer en leverde meer of iets anders.

Toen gingen we professionaliseren en kopieerden we technieken uit de productiepraktijk in projectmanagement. Er ontstonden methoden en standaards, de belangrijksten waren en zijn in zekere zin nog steeds PRINCE2 en PMBOK, waarbij de eerste een methode zegt te zijn en de tweede een standaard. Ik weet niet of jij het verschil ziet, maar ik ken beiden, wat mij betreft behoren ze tot hetzelfde genre. Pretentieus doch zeer populair, het zal wel aan mijn skeptische en kritische geest liggen. Overigens noemen beiden het belang van op maat maken wel op de een of andere manier. Massaal gingen mensen deze toepassen, in ons deel van de wereld werd het voornamelijke PRINCE2. 

Er zijn een paar zaken in PRINCE2 waar ik mijn pijlen op wil richten: de businesscase en de opdrachtgever of de executive. Deze laatste is eindverantwoordelijk en eigenaar van de eerste. Er staat een uitgebreide lijst met verantwoordelijkheden van de opdrachtgever in de PRINCE2 manual. Als je deze laat lezen aan projectmanagers die nog niet zijn blootgesteld aan PRINCE2 dan kijken ze je verbaasd aan. Ik heb dit een aantal keren gedaan. De meeste projectmanagers vinden dan dat de opdrachtgeverszaken juist door hun gedaan moeten worden. Dat heb ik zelf ook altijd gedacht, totdat ik werd blootgesteld aan PRINCE2.

Toen wij na verloop van tijd in Nederland een kritieke massa PRINCE2 projectmanagers hadden ontstond er hierdoor een behoefte aan trainingen voor opdrachtgevers. Deze voldeden immers niet aan de lijst van verantwoordelijkheden die PRINCE2 noemde. Dat niemand zich publiekelijk heeft afgevraagd of misschien de lijst verantwoordelijkheden fout was, heeft mij altijd bevreemd. Projectmanagement hoort zich aan te passen aan de praktijk en niet omgekeerd. Wie zegt dat PRINCE2 best practice is kan goed verkopen maar heeft het niet bij het juiste eind, het is een practice en daar houdt het mee op.

Wat kunnen we leren van het agile paradigma, geen almachtige opdrachtgeven, geen machtige projectmanager, in plaats daarvan een productowner die de klant vertegenwoordigd. Als we die nu eens overbrengen naar de projectorganisatie. De persoon heeft functioneel inhoudelijke kennis van wat er nodig is. Het is de stem van de klant in het project. Van het hoger management is er een pot geld beschikbaar gesteld om een volgende fase in te gaan. Geen businesscase, maar dat wat ondernemers een veroorloofbaar verlies noemen. Vergelijk het met een aandelenoptie. Het is een fractie van wat de totale kosten van het project kunnen worden. Tijdens de uitvoering sprint men in een vaste candans van de ene increment naar de andere, de productowner bepaalt de inhoud van het werk het team wat ze de volgende sprint kunnen doen. Het schatten van de fase verloopt zoals in een vorige blog is beschreven. Aanvankelijk weet men de doorlooptijd niet zeker, maar na een aantal iteraties kan men redelijke goede voorspellingen doen. Aan het eind van de fase bepaalt men of men verder gaat. Is het antwoord negatief, dan stopt men. Omdat men van te voren besloten heeft dat het verlies veroorloofbaar was kan het alleen maar meevallen. 

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 te reizen.