[vc_row padding_top=”0″ padding_bottom=”0″][vc_column][vc_column_text]In een vrij recente post op LinkedIn beschrijft de ervaren projectmanagementtrainer John Hermarij hoe er in de afgelopen decennia steeds weer hypes zijn geweest die één enkele oplossing promoten om projectfalen te voorkomen. En achter al die zogenaamde oplossingen zit telkens de veel te simpele analyse dat mislukkingen maar één enkele hoofdoorzaak hebben. He
t zou liggen aan de stakeholders; het zou liggen aan de waterval-aanpak; het zou liggen aan het ontbreken van een PMO; het zou liggen aan de vaardigheden van de projectmanager; het zou liggen aan gebrek aan certificering; het zou liggen aan de methode; het zou liggen aan de business case; het zou liggen aan… [vul hier je favoriete oorzaak van mislukkingen in].
Natuurlijk is er zelden één enkele oorzaak als een project faalt, er is vrijwel altijd sprake van een opeenstapeling van factoren. En het omgekeerde is ook waar: als projecten goed gaan is dat niet het resultaat van één enkel ding dat goed gedaan wordt: er moeten heel veel verschillende dingen op hun plaats vallen om een project succesvol te laten verlopen.
Er is veel casuïstiek en onderzoek hierover, maar het gevoel dat me al heel lang bekruipt als ik daarover lees is telkens weer: wat zijn de onderliggende patronen? Er moet toch een diepere structuur zijn die aan al die verschillende ‘failure modes’ ten grondslag ligt. Of zoals Polonius zegt in Hamlet: “though this be madness, yet there is method in it”.
Enkele jaren geleden kwam ik die ‘method’ op het spoor, toen ik het boek “Normal Accidents” las. Hierin beschrijft Charles Perrow hoe de kans op ongelukken in door de mens gemaakte systemen het resultaat is van twee factoren:
- complexe, niet-lineaire interacties met steeds meer feedback loops
- strakke koppeling tussen de verschillende componenten waaruit het systeem bestaat
Perrow beweert dat in elk systeem met niet-lineaire interacties én strakke koppelingen, ongelukken onvermijdelijk zijn – het zijn ‘normale ongelukken’, vandaar de titel van zijn boek.
Projecten zijn natuurlijk ook door de mens gemaakte (sociale) systemen, doelbewust ingericht, met verschillende componenten en met een aantal gereguleerde interacties tussen die componenten. Daarom geeft de analyse van Perrow een interessante visie op het hoe en waarom van projectfalen.
En tegelijkertijd geeft het aanwijzingen hoe de kans op projectfalen kan worden verkleind: we moeten projectorganisaties en -processen zo bouwen dat ze zoveel mogelijk lineaire interacties hebben (in tegenstelling tot complexe) en met weinig feedback, en zoveel mogelijk losse koppeling tussen de componenten (zo weinig mogelijk onderlinge afhankelijkheden).
Daarbij helpt het om een “kaart” te hebben van de projectwereld, waarin de mogelijke componenten van een project in beeld zijn gebracht. Dat helpt om de interacties en de koppelingen tussen de verschillende “bewegende delen” van een project inzichtelijk te maken, en er grip op te krijgen.
Daarvoor kan het Project Canvas worden gebruikt: een overzicht van de componenten van een project. Dat kun je gebruiken om de eigen huidige projectorganisatie systematisch te onderzoeken. Aan de complexiteit van een project kunnen we vaak niet veel veranderen: hoe groter een project, hoe complexer het zal zijn. Maar we kunnen wel invloed hebben op de manier waarop de interacties tussen de componenten worden ingericht, en op de mate van koppeling tussen alle componenten.
Stel jezelf de volgende vragen bij alle raakvlakken tussen de componenten: zijn de interacties vooral lineair of niet-lineair? Zijn de componenten strak geïntegreerd, of losjes gekoppeld? Misschien heeft ‘waterval’ toch nog wat te bieden hier…
De benadering uit “Normal Accidents” biedt ook interessante suggesties voor projectbeheer. Veel organisaties proberen ongelukken te voorkomen door extra veiligheidsmaatregelen te treffen. Maar extra veiligheidsmaatregelen kunnen de complexiteit van het systeem vergroten. De ironie is dan dat het toevoegen van veiligheidsmaatregelen de kans op een projectongeval kan vergroten…
Governance van een project is nodig, maar kunnen we het zo definiëren en inrichten dat we speling toevoegen, en daardoor de koppeling tussen de bewegende delen van een project losser maken? Hoe zou dat eruit zien?
Feedback is hier bedoeld als een interactie die direct ingrijpt op de parameters van de processen, zoals: als er bij het testen van een software-wijziging meer dan X openstaande problemen ontstaan, dan worden er direct Y extra ontwikkelaars toegevoegd aan het team totdat het aantal openstaande problemen weer minder is dan X.
Jullie suggesties hierover hoor ik graag: ralph@projectdoctor.online[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”20″][vc_column][vc_column_text]
Een bijdrage van
Ralph Goossens, bevlogen denker en kennisdeler 
over project management. Wil een booster zijn voor verdere professionalisering van het vak. Typering: professioneel / praktijkgericht / persoonlijk / podcastmaker. IPMA-B senior project manager met vele duizenden vlieguren, vele honderden uren training en intervisie, en vele tientallen tevreden klanten.
Alias: project doctor.[/vc_column_text][kleo_social_share][/vc_column][/vc_row][vc_row][vc_column width=”1/2″][vc_single_image image=”18182″ img_size=”large” onclick=”custom_link” img_link_target=”_blank” link=”https://www.hdmwp-demo.nl/de-waarde-van-lid-zijn/”][/vc_column][vc_column width=”1/2″][vc_single_image image=”17425″ img_size=”large” onclick=”custom_link” img_link_target=”_blank” link=”https://www.hdmwp-demo.nl/winkel/eventkalender/”][/vc_column][/vc_row][vc_row padding_top=”0″][vc_column][vc_posts_grid loop=”size:12|order_by:date|post_type:post|categories:813″][/vc_column][/vc_row]