Where will all the project managers go to?

Recently I did a couple of lectures in Vilnius / Lithuania, it was a good and productive time to meet my friends over there. I took some extra days to see the sites togehter with my wife. Next to all the churches, the nice food and beer, the visit to the KGB Museum, or rather the dungeon where they tortured and murdered al those people that had the intellect to speak out, this really left a deep impression on both of us. But that’s not the topic of this blog. In the evening I gave a lecture to the national project management association on the “management of complexity“. 

On one of the slides I quoted a research done by the Boston Consulting Group that from 1955 to 2010 the level of complexity for organisations was multiplied by 6. But also, the level of complicatedness within our organisations has increased 35 times. So for CEO’s the world of business has become six times complexer, opposed to their employees that have experienced an increase of thirty five in complicatedness (that is the complexity for employees). A lot has to do with procedures, processes, standards, methodologies, silly reporting, silo’s, etc. The delta between 35 and 6 is the area of simplification and it is there where we need to start our journey in managing complexity.

Suddenly a number of my project management friends realized, that the consequence of simplifying our organisations will be that less project managers are needed. That came as a shock, because for decades project managers have been fighting the complexity fires lit by senior management. Where will all these competent and dedicated project managers go to? I could give a good answer to this question and it made me think, where to? In the Netherlands this simplification has cost scores of project managers their job. Where to?

The only thing I could utter was: “There will always be a need for good people that are able to deliver results”. But this answer is only half of the full answer, let me elaborate. One thing you need to realize you are not your profession, as long as you remain professional there will always be a path to walk. Some of you will remain project manager, because in those area’s were new things are needed someone needs to create the circumstances in which people can excel. Perhaps it isn’t called project management any more, but what the hack, as long as you have fun and can earn a living. My career started as a math teacher, then I became programmer, project manager, interim manager, trainer/consultant, author and lecturer. Sometimes I like to fiddle about with DTP software, if you would ask me my profession I could same something like Ideas Alchemist

One thing I have come to realize, in order to be valuable to others, you need to posses working knowledge on context. It is highly advisable to become subject matter expert of something. Even when you want to become a leader. I do not think there is a future for generalists any more, you need an adaptable nature in order to survive. Expand your mind and dive deep into something that has your passion. Then and only than there will always be a place for you.

De tegenstelling die #agile oproept

Voor sommigen is het een rode lap op een stier, een tenenkrommende vergelijking: agile versus waterval. Wanneer je gevoelig bent voor taal is dat begrijpelijk, want integenstelling tot waterval is agile geen metafoor. Door beiden tegenover elkaar te stellen vergelijk je appels met peren. Agile is een eigenschap, iemand is agile of in goed Nederlands wendbaar. Iemand is niet waterval, waterval is geen eigenschap, het is iets, terwijl agile altijd in combinatie komt met iets. In deze blog zoek ik een nieuwe metafoor die ik tegenover waterval kan gebruiken. Ik noem hem nog even metafoor X (M-X).

Het grote verschil tussen waterval en M-X is dat de eerste lineair is, de gebeurtenissen stromen als water naar beneden naar het eindpunt, de oplevering. Er is wel wat gespetter opzij, maar de kern van de beweging is een linaire lijn. Deze komt precies overeen met het westerse concept van tijd, een linaire lijn van links naar rechts die, uiteraard, omhoog gaan, er is immers niets anders dan vooruitgang. Dat dit beeld desastreuze gevolgen heeft voor onze aarde wordt alleen nog door klimaatsceptisch ontkend. M-X is circulair, het water draait rondjes, het is een vortex of in goed Nederlands een draaikolk. Het is een plan-do-check-act cyle die per rotatie naar het doel gaat. In aanvang is dat doel nog niet bekend, maar gaande weg zoemen we er op in. Het begint groot en algemeen, draait snel een ronde, toetst de aannames en reageert om met de volgende ronde te beginnen.

Nu is het niet meer waterval tegenover agile, maar waterval tegenover de draaikolk en pas op dat je niet duizelig wordt, want verandering is iets wat we omarmen.

Kenmerkend voor de vortex is dat we in iteraties werken een cirkel waarin we steeds een tastbaar toetsmoment hebben waarop we in staat zijn om te toetsten of de aannames die we deden aan het begin een goede interpretatie waren. We zijn niet gestart met een businesscase en een gedetailleerde investeringsbeoordeling, die – zoals bij waterval – steeds weer opnieuw getoetst moet worden, nee, we zijn begonnen met een veroorloofbaar verlies, een veel kleiner financieel commitment dan bij waterval. Elke keer weer bepalen we het volgende verlies dat we ons kunnen veroorloven. Het is overzichtelijk en zorgt voor een veel betere controle over de inzet van mens, middelen en liquiditeit dan waterval. We hoeven geen exceptierapportages, gevolgd door exceptieplannen te schrijven. De kansen en de risico’s zijn veel beter te overzien door de korte terugkoppellussen (iteraties) dan wanneer we de levenscyclus van een project volgen met zijn vaak rigide stage-gate modellering.

De vortex aanpak is naar mijn volle overtuiging superieur aan de waterval. Dit enkel en alleen al omdat deze overeenkomt met bijna alle natuurlijke processen. Er zijn seizoenen die elk jaar weer terugkeren. Zie hoe de bomen groeien, van het ene jaar naar het andere, in de winter minder dan in het lente. Elk jaar worden we een jaartje ouder, dat is zo vast als het maar kan. Het is de weg van de natuur. De agile methoden volgen de vortex en komen daar uit waar we op dat moment willen zijn. Wanneer je agile methodieken in de waterval stopt, dan gaat dat fout, je moet dan niet de vortex de schuld geven, het is de waterval en niets anders die de oorzaak van het falen is.

De vortex kent zijn rituelen die het kortcyclische in standhouden, het groomen van de backlog, het plannen van de sprint, de daily standup, het werk zelf, de demo en de retrospective, alleen keren terug in een stroom van werk dat uiteindelijk leidt tot een tevreden klant. 

Gebruik een theorie en dood de methode!

In Nederland zijn we verzot op methoden, procedures en protocollen. Er is een heus boek met alle projectmanagementmethoden die er in Nederland zijn en het wachten is op een soortgelijk boek over agile methoden. Dergelijk boeken tonen eerder het failliet van onze vakvolwassenheid aan dan de rijkdom van ideeën. Nu moet ik u iets opbiechten, heel lang geleden heb ook ik een projectmanagementmethode geschreven, een van de velen die in de vergetelijkheid is verdwenen. Maar goed ook want dan was mijn naam aan een methode gekoppeld en zo wil ik eigenlijk niet herinnerd worden. Want methoden raken achterhaald en dat lijkt me een schrikbeeld om met iets wat achterhaald is geassocieerd te worden. Maar dat is een heel ander onderwerp. Laat ik maar eerlijk zijn, ik heb niets met best practices, methoden en standaards, geef mij maar een goede theorie.

Een goede theorie bestaat uit een aantal aannames over de werkelijkheid die te toetsen zijn. Zaken waarvan we kunnen stellen dat ze waar of niet waar zijn. Dingen die we kunnen testen. Een goede theorie bestaat uit een samenhangende verzameling aannames die elk op zich falsifieerbaar is. De meeste methoden bestaan uit honderden van dit soort aannames en het is juist die veelheid die maakt dat het niet goed is aan te tonen of het werkt. Een ding kan je best wel zeggen, dat methoden zaken onnodig complex maken. Ik weet niet of je wel eens geprobeert hebt alle activiteiten van PRINCE2 te doen, of alle processen van ISO 21500, of de PMBOK, vergeet het maar je houdt geen tijd over om nog je project te managen. Maar zeg je dan, je moet gebruiken wat je uitkomt, oke, maar dan zie ik het nu van een methode niet. Anders dan alleen iedereen in de organisatie te dwingen op een andere manier dan dat ze deden voor men de methode verplicht stelde.

Terug naar de theorie. Alles begin met de aanname dat een bepaalde werkwijze een verbetering is. Bijvoorbeeld de aanname dat “een risicoregister tot een betere beheersbaarheid van de risico’s leidt” . Of dit zo is weten we nog niet, maar laten we eens besluiten om dat te toetsen. We kunnen de projectevaluaties in duiken en kijken of er een verschil is tussen de projecten die er wel en die er geen hebben. Hier is een mooie rol weggelegd voor het PMO. Er zou een positieve correlatie moeten zijn, maar dan ben je er nog niet correlatie is nog geen causaal verband. In ieder geval hebben een aanknopingspunt om verder te experimenteren.

Maar het kan ook nog op een andere manier, elke persoon met een leidinggevende rol kan hiermee aan de slag, zowel in de waterfal of de agile vortex. Laten we de goede oude Deming Cirkel weer eens beet pakken:

  1. Plan een experiment
  2. Doe het experiment
  3. Check of dit aan de verwachting voldoet
  4. Acteer op de afwijkingen, ga naar 1)

Op die manier blijf je in een eindeloze lus doorgaan en in elke feedbacklus verfijn je de theorie die steeds waarschijnlijker wordt. Wat nu wanneer je de pech hebt dat je in een organisatie werkt met methodefetisjisten. Wel dan neem je een van de delen van de methode en zet de experiment op, als je durft zet je het experiment zo op dat het falsifieert. Je bereikt hierdoor na verloop van tijd een aanpassing van de standaard die zich uiteindelijk evolueert tot een theorie. Je dood de methode om de theorie te redden.

Want een theorie is niet wat iemand van iets denkt, integendeel, een theorie is iets dat werkt in de praktijk waar zij is getest.