Een van de voornaamste oorzaken die wordt gegeven bij projecten die mislukken of verwachtingen in ieder geval niet waar maken is ‘complexiteit’. Andersom geredeneerd zijn projectmanagement methodieken juist opgebouwd om van ‘groot naar klein’ te gaan en om ‘ingewikkelde zaken overzichtelijk’ te maken.
Is complexiteit in projecten relevant?
Ja natuurlijk! “Als het makkelijk was, dan kon iedereen het” – een van mijn gevleugelde uitspraken pleit juist voor complexiteit als factor in projectsucces. En daar zit wat in. Ter illustratie heb ik een project wel eens vergeleken met het ophangen van een plankje in de bijkeuken:
- Initiatiefase: Wasmiddelen staan in de weg en er is ruimte voor een plankje.
- Businesscase: Plankje kost geld, maar wasmiddelen nemen ruimte in en die ruimte is je winst.
- Projectstart met voorbereiding: We hebben nodig; tijd, plankje, beugels, ophangmateriaal, gereedschap en de beschikking over de bijkeuken.
- Planning: zaterdag ochtend materialen halen en klaarleggen, eind van de ochtend uitvoer en oplevering rond de lunch. Uitloop eventueel na de lunch valt binnen de met de opdrachtgever afgesproken marge. Uiteraard maak je een gantt-chart waarin activiteiten en hun afhankelijkheid (eerst boren, dan schroeven) naar voren komt.
- Risicomanagement: Er zit een stopcontact in de buurt van waar je moet boren, dus stroom er maar p
reventief af als mitigerende maatregel. - Communicatieplan: Van 11:00 tot 12:00 op zaterdagochtend is er geen stroom en wordt er geboord; even afstemmen met stakeholders. Daarna is er de beschikking over nieuwe functionaliteit en voegen we een handige infographic toe over hoe het plankje gebruikt dient te worden
- Stakeholdermanagement: Kinderen kunnen geen tv kijken, de wasmachine draait even niet en de lampen zijn uit – iedereen even informeren, inclusief de buurman die last kan hebben van boor herrie.
En zo kan ik nog even door gaan. Het wordt een lijvig project en uiteraard totaal overbodig, niet lean en inefficiënt. Alhoewel, is dat zo? Als je de aanpak eigenlijk wel prettig vindt kan het zijn dat je simpelweg onbekend bent met het ophangen van een plankje. Juist dan is het doorlopen van een projectproces prettig; je kunt de werkzaamheden op een rij zetten, risico’s beoordelen en bewust de effecten op de ‘stakeholders’ analyseren.
Complexiteit is een subjectieve maatstaf
Wat voor een organisatie met een lage taakvolwassenheid, weinig ervaring en een lage kenniscompetentie flink complex is, kan voor een andere organisatie business as usual zijn. En zo kan het zijn dat het ophangen van een plankje bij de ene organisatie een project heet en bij het andere een doorsnee klus.
Een begrijpelijke reflex is de inhuur van mensen die een hogere taakvolwassenheid hebben, meer ervaring en kennis over het onderwerp waar de eigen organisatie niet mee bekend is. Dit compenseert alleen maar voor een stukje van de geconstateerde complexiteit; louter uitbesteden lost kennisgebrek niet op en creëert afhankelijkheid, terwijl volledige kennisoverdracht vaak meer tijd kost en langer duurt dan in het projectkader acceptabel is. Outsourcing werd gezien als dé oplossing: besteed complexiteit inclusief het oplossen er van in het geheel uit en je hebt er geen last meer van.
Omgang met complexiteit in projecten
De feitelijke oorzaak van problemen in projecten is niet de ‘complexiteit’ op zich, maar het onderschatten er van. Dat dit bij aanvang niet wordt geïdentificeerd is op zich geen probleem, maar het tijdig anticiperen op complexiteit en hier op acteren wel. Complexiteit en samenhang met taakvolwassenheid en kenniscompetentie zou onderdeel uit kunnen maken van het toetsingskader waar met name grote en kostbare projecten tegen getoetst zouden moeten worden. Voor het project feitelijk start of net na de start, maar niet naderhand in een parlementaire enquete.
Een voorbeeld van een ‘agile’ toetsingskader vind je in de Projects: Done! methode.
