Ik kan me nog goed herinneren dat ik gevraagd was naar aanleiding van mijn boek “High Reliability Projectmanagement, hoe cultuur het regelt” een verhaal te houden bij de ABN AMRO. Net terug van vakantie las ik de mail met het verzoek een titel en een stukje tekst aan te leveren. Ik vroeg mij hardop af waarom ik ook alweer ja had gezegd op de uitnodiging. Ik had immers niets met ICT-projecten of banken.
Nog snel las ik de mail en las dat de bank volledig wilde overgaan op agile werken. Daar gaan we weer, dacht ik. Steeds meer organisaties denken met het omarmen van een methodiek meer grip te krijgen op hun projecten. Opvallend is dat dergelijke methodieken vaak vanuit de ICT-sector komen. Denk aan Prince 2, Agile, Scrum. Overheidsorganisaties dachten met nieuwe contractvormen meer grip te krijgen op allerlei projectrisico’s. Zo gingen meerdere organisaties volledig over op UAVGC-contracten. Een poging om meer controle te krijgen binnen projecten. Binnen Plan B noemen we dit: simplificeren.
“Stel, u voelt zich al geruime tijd niet lekker en gaat naar de dokter. En de dokter zegt direct bij binnenkomst; Ah, ik zie het al. Ik heb hier een potje met pillen. Elke dag een tabletje en binnen een week bent u van al uw problemen af.”
Begrijp mij goed. Ik ben niet tegen Agile, Prince 2, PMBOK, of welke methodiek ook. Maar pas op dat je niet voorbijgaat aan de essentie van projectmanagement, namelijk dat het altijd een unieke opgave betreft. Je moet dus op zoek naar de essentie van de uitdaging, de cruciale succesfactor in je project. En daarop ontwerp je vervolgens je aanpak, organisatie, contractvorm en methodiek.
Wat voorbeelden van cruciale succesfactoren? Bij de bouw van een Covid-19 vaccinfabriek voor Janssen draait alles om tijd! Met de uitbreiding van een kindervoedingsfabriek draait het om (voedsel)veiligheid! Bij de nieuwbouw van een vliegveld in bewoond gebied draait het om draagvlak! Hoe je achter je cruciale succesfactor komt en je project hierop inricht is een interessant onderwerp voor een volgend artikel.
De zaal stroomde vol. Normaalgesproken kwamen er gemiddeld 100 personen op een dergelijk lezing af. Dit keer waren er 400 geïnteresseerden. Mogelijk waren ze getriggerd door de titel van de lezing. Met deze oude sheet heb ik de toehoorders een spiegel voorgehouden en uitgedaagd eens kritisch naar hun eigen communicatie te kijken.
Per statement heb ik ze heel veel vragen gesteld.
(Daar waar IT-afdeling staat kan je natuurlijk ook allerlei andere afdelingen invullen.)
Gedacht is nog niet gezegd
Kan het zo zijn dat niet-IT-ers (zoals ik):
… IT ingewikkeld vinden? Dat zij IT zien als een ingewikkelde black box?
… hun te automatiseren processen zelf helemaal niet zo goed kennen?
Gezegd is nog niet gehoord
Kan het zo zijn:
… dat ieder mens eigenlijk een slechte luisteraar is?
… dat we horen wat we willen horen?
… dat we dingen weglaten die we niet willen horen?
Gehoord is nog niet begrepen
Kan het zo zijn:
… dat het veiliger voelt onze eigen mening te verkondigen dan de ander echt te begrijpen?
… we toch (ondanks “domme vragen bestaan niet”) bang zijn domme vragen te stellen?
… we bang zijn ontmaskerd te worden dat we er niet zoveel van begrijpen?
Begrepen is nog niet toegepast
Kan het zo zijn:
… dat wijsheid met de jaren komt maar eigenwijsheid ook?
… we toch liever het onaangename, onwennige, onbekende vermijden?
… we toch liever de eigen vertrouwde weg kiezen?
Hoe lost een methodiek of contract bovengenoemde vragen op? Met deze sheet wilde ik de toehoorders vooral uitdagen om, voordat ze een oplossing kiezen, het probleem uitgebreid te verkennen. Stel ‘domme’ vragen. Laat het schuren aan de voorkant. En dan zul je zien dat de oplossing waarschijnlijk niet per se schuilt in agile werken, maar vooral in samenwerken.
Vind je dit een interessant onderwerp en zou je hier met ons verder over willen praten? Neem dan contact op, we horen graag van je!
Geschreven door Bernard Sluis, maart 2021