Ik begrijp het punt van de schrijver en het is ook een uiterst populair - en zeker niet nieuw - standpunt. Ik zie helaas maar al te vaak PM's die vrijwel niets van de harde kant weten en begrijpen. En dan gaat het nog veel erger mis. Hoe goed je ook omgaat met de zachte kant.

Mijn standpunt: de harde structuurkanten dienen gebaseerd te zijn op een psychologische visie. Zo zijn de PRINCE2 principes voor een groot deel gebaseerd op het omgaan met tegengestelde belangen (Business Cases) van klant en (interne) leverancier.

Wanneer de harde kant binnen een project goed geregeld is, zijn voorwaarden gecreëerd van de broodnodige zachte kant.

Beste Godfried, Nico heeft helemaal gelijk: we weten dit al heel lang en niet alleen via ervaringslessen. Ik promoveerde hier in 1996 op met een hypothese toetsend steekproefonderzoek. Mag ik je uitdagen een column (artikel) te schrijven over de vraag waarom er aan die zogenaamde harde vaardigheden nog steeds de meest aandacht wordt besteed?
Ik betwijfel wel of Nico met zijn slotzin gelijk heeft. Vaak is de zogenaamde harde kant zo goed geregeld, dat die voorwaarden er juist niet zijn.

'Geef een kind van 5 jaar een computer en hem ontgaat het leven op straat. Geef een jonge en onervaren projectleider Prince2 en hem ontgaat het leven in elke organisatie.'

Tja, dit blijft een dankbaar onderwerp waarover de meningen uiteen (blijven) lopen. Ook hier geldt m.i. dat beide nodig zijn. In welke balans hangt mede af van de aard van de organisatie en het project.
Daarbij zijn soft skills om het klip en klaar helder te krijgen van de projectdefinitie, de bedrijfsdoelstellingen en de toegevoegde waarde van het projectresultaat, keihard nodig om het project goed van start te laten gaan en tot een goed einde te brengen. Het effectief toepassen van deze communicatieve en analytische vaardigheden wordt nogals eens al 'hard' (skills) gepercipieerd. What's in a name ...

De quote van Marcel Thewissen waarmee hij zijn reactie op de column start, is zeer juist. De projectmedewerkers waaraan de projectleider leiding geeft zullen het moeten gaan doen. Die staan niet in het projectplan. Dus, projectleider, schets het gewenste eindresultaat in termen van de organisatie (bijvoorbeeld, snelle informatie over klanten naar onze verkopers) en niet in projecttaal. Vervolgens sumier en op hoofdlijnen aangeven (eerder aanstippen) wat dit betekent voor IT. En dan, projectleider, STOP. Het is aan jullie, projectmedewerkers, wat wil, kan en durft een ieder van jullie vanuit jullie expertise? Laat een ieder zijn krent pakken, de resterende pap wordt daarna verdeeld. Elke proctmedewerker die zijn krent in bezit heeft, ervaart dat als billijk. De projectleider ziet toe of een ieder voldoende verantwoordelijkheid neemt. Als dit genoeg is, is hij blij. Als dit onvoldoende gebeurt, dan maakt hij er een punt van.
Dit is het begin van een weg die het project, projectleider, projectmedewerkers in de realiteit houden en het plan op gepaste afstand houdt. Of simulaties hierbij kunnen helpen dit soort van kunst onder de knie krijgen, ik heb mijn twijfels. Wil je er meer van weten over deze manier van werken in projecten, dan verwijs ik je naar het artikel "Projectleider of projectduwer", nb in de vorige eeuw gepubliceerd in het vakblad Computable (5-2-1999), te vinden via http://www.computable.nl/artikel/ict_topics/loopbaan/1420544/1458016/projectleider-of-projectduwer.html

Marc Oskam
(auteur van het boek "Venijn in de start")