Ni!

Wij keken allemaal naar de films en de televisieseries. Zo absurd dat je er niets van begreep, maar dat deed er niet toe. Je riep ‘Ni!’ en dan hoorde iedereen ineen te krimpen van angst en weg te kruipen. Als de anderen dan ‘it’ in een zin zeiden, dan waren het juist de ridders die ineenkrompen. Dolle pret, voor puberale nerds. Ik was zo’n fan dat ik zelfs de tweede versie uit mijn hoofd kende: “We are the knights who say ‘Ekke ekke ekke ekke ptang zoo boing’!”. Ik weet nog dat ik daar heel trots op was.

En nu blijk ik zelf last te hebben van zo’n woord - of eigenlijk een hele zin. Ik hoor de zin uitgesproken worden en ik krimp ineen. Ik wil weg. Ik doe mijn handen over mijn oren en mijn ogen dicht. Bij ’Ni!’ hoort iedereen bang te worden maar bij deze woorden ben ik de enige. Iedereen knikt instemmend maar bij mij voelt het alsof mijn hart een slag overslaat, alsof ik weer een jaar korter leef. Die zin - ik durf hem bijna niet op te schrijven - is “we spreken heel duidelijk af wat we gaan opleveren!”. Meestal wordt hij door projectmanagers uitgesproken. Daarna wordt hij klakkeloos door allerlei andere mensen om de projectmanager heen overgenomen. En ik maar schrikken en lijden.

Zodra je eenmaal heel duidelijk afgesproken hebt wat je op gaat leveren ga je nooit meer nadenken over wat je allemaal anders of beter op zou kunnen leveren

Raar natuurlijk om bang te zijn van die zin. Toch is het echt zo. Die zin is het begin van alle ellende. We gaan niet opleveren wat belangrijk is, we gaan ook niet opleveren wat de klant gelukkig maakt. We gaan al helemaal niet het beste opleveren wat we zouden kunnen opleveren. Nee, we leveren op wat we afgesproken hebben. Dat is meestal niet hetzelfde. Dat is eigenlijk nooit hetzelfde! Zodra je eenmaal heel duidelijk afgesproken hebt wat je op gaat leveren ga je nooit meer nadenken over wat je allemaal anders of beter op zou kunnen leveren. Vanaf dat moment zitten jij en je klant muurvast. En dat vind ik een heel enge gewaarwording. Eng voor mijzelf en voor onze klanten en gebruikers.

Ik heb wel eens geprobeerd er tegenin te gaan maar dat levert alleen maar rare gesprekken op. Ik zeg dan “Willen we niet liever ‘heel vaag’ afspreken wat we gaan opleveren?” en dan kijken ze me natuurlijk allemaal meewarig aan. Als ik dan uitleg dat je flexibiliteit wilt, dat de klant niet van te voren kán weten wat hij straks wil hebben, dan geven ze me allemaal gelijk, om daarna vooral weer ‘lekker duidelijke’ afspraken te maken.

Ik ben nog op zoek naar het ‘it!’ van de projectmanagers, het tegenwoord waardoor zij ineenkrimpen en weerloos worden.

REACTIES:

Als gevolg van een technisch mankement worden de ingevoerde reacties niet zoals gebruikelijk getoond. Hieronder een bloemlezing uit de ingezonden reacties op deze blog:

Anoniem:

End to end visie, zeldzaam aanwezig bij de meeste PM's...

Abe Kornelis:

Daan,

Er is geen toverwoord om te voorkomen dat je wordt vastgelegd op afspraken die al verouderd zijn op het moment dat de inkt droog is. Wel zijn er een aantal argumenten, en die heb je grotendeels al zelf aangedragen. Het gaat er ook niet om de project-manager te overtuigen; dat gaat je niet lukken. Met zijn/haar scope op "tijdige voltooiing van het project binnen budget in tijd en geld" is het juist essentieel om duidelijke en meetbare afspraken te maken.
Echter, vanuit de opdrachtgever - die in de regel beslissingsbevoegd is over de hoeveelheid tijd en geld beschikbaar voor het project - is er wel degelijk groot belang bij behoud van flexibiliteit. Wil je agile werken? Dan moet je toch echt inbouwen dat we richten op een bewegend doel. Dus moet je ook in je project-definitie die flexibiliteit inbouwen. Zo creëer je de beste kansen om maximale waarde te realiseren vanuit de project-inspanningen.
En zoals we soms time-boxen in plaats van een afgetimmerde planning te maken (met schijn-zekerheid, want alles verandert toch voortdurend), zo kunnen we ook kort-cyclisch ontwikkelen, testen, en opleveren. Maar dan moet je je project-definitie niet meer ophangen aan functionaliteit. Je doet er dan verstandig aan om je project te definiëren in deel-plannen die je afzonderlijk kunt prioriteren. Voor elk deelplan kun je een ontwikkelplan opstellen: wat willen we maken, welke kwaliteit moet het hebben, hoe gaan we het exploiteren, wat mag het kosten in tijd en geld? Voor je totale project leg je niet vast welke functionaliteit allemaal gerealiseerd moet worden. In plaats daarvan spreek je af wat het beschikbare budget is. Afhankelijk van de voortgang over de deel-opleveringen kunnen prioriteiten worden bijgesteld, en kunnen eventueel zelfs nieuwe ideeën worden opgenomen. Na elk deeltraject of zelfs na elke sprint, kan worden geëvalueerd of er voldoende meerwaarde is gerealiseerd om door te gaan.
Agile werken en klassiek project-management staan op gespannen voet met elkaar. De rol van de project-manager verandert. Hij/zij moet niet langer sturen op complete voltooiing van alle functionaliteit die ooit is vastgelegd toen we nog niet beter wisten. De rol verandert in die van een proces-begeleider, die vooral bewaakt dat er goed wordt samengewerkt (vooral als er meerdere teams betrokken zijn), dat de prioriteiten helder zijn, dat er goed wordt afgestemd met de opdrachtgever, etc. Het klassieke probleem dat het project op tijd af is, maar dat er zo veel kwaliteit is ingeleverd dat de meerwaarde slechts zeer beperkt is, verdwijnt hiermee niet van tafel, maar de controverse tussen kwaliteit enerzijds en volledige en tijdige oplevering anderzijds wordt hiermee wel beter behapbaar. Per onderdeel kan steeds opnieuw een afweging gemaakt worden. Vooral als binnen klant-organisatie het besef leeft (of ontstaat) dat inleveren op kwaliteit wordt betaalt met meer haperingen, meer incidenten, meer support calls, en meer onderbrekingen in het ontwikkel-proces, dan kan er een goede afweging ontstaan tussen de verschillende aspecten. De klassieke project-manager heeft hierin weinig meerwaarde te bieden, maar een project-manager die er in slaagt om de betrokkenen te helpen elkaar te begrijpen en die optreedt als facilitator in het beslissingsproces, die project-manager heeft recht van bestaan in de 21e eeuw.

Koen van Vliet:

Beste Daan, hoe herkenbaar! Zowel het verhaal van Monty Python als jouw tegenwoordige "Ni".
Ik vertel je een verhaaltje dat een Agile Coach mij ooit vertelde. Ik zal niet zeggen dat ik het dagelijks vertel, maar in ieder geval wekelijks. Zeg tegen zo'n projectmanager het volgende:
"Ik heb een opdracht voor je. Ga morgenochtend, als je binnenkomt, naar de eerste de beste programmeur en vraag hem zo gedetailleerd mogelijk op te schrijven wat hij vandaag gaat doen. Aan het einde van de dag ga je weer naar die programmeur en vraagt hem zo gedetailleerd mogelijk op te schrijven wat hij vandaag heeft gedaan. Hoe groot is de kans dat die twee lijstjes identiek zijn?".
Een beetje realistische projectmanager zal zeggen "NUL".
Jouw reactie: "Precies! Dus, als één programmeur zijn eigen werk geen acht uur vooruit kan plannen, hoe arrogant zijn wij dan dat we projecten van 40 man een jaar vooruit willen plannen?".
Nadat ik deze zin hoorde (2009) heb ik nooit meer een gedetailleerde planning gemaakt.
Succes ermee!

Jos Vossen:

Misschien is 'ontevreden klant' het tegenwoord. Een klant die krijgt wat is afgesproken is niet per sé een tevreden klant. Hij had het misschien tot anders bedoeld.