Een paar dagen geleden schreef ik een artikel voor Computable over de geur van dode vis in projecten. Toen ik zo-even keek naar de reacties, zag ik dat ik een gevoelig punt had geraakt. Er waren op dat moment 25 reacties, waarmee dit artikel in de top drie van artikelen van de afgelopen tijd stond waarop het meest gereageerd was.
De meeste reacties lieten zien dat ik niet de enige ben die regelmatig dode vis ruikt in projecten. Het gaat dan om de geur van bederf die rond een project gaat hangen. Op papier ziet het project het best mooi uit, maar je ruikt dat dit project op een mislukking aanstuurt. Er is een verschil tussen de papieren werkelijkheid en de wereld van de projectleden die weten dat het project niet op tijd gaat opleveren. En toch zeggen ze niets.
Ik vroeg me af hoe je als buitenstaander merkt dat zo’n project gaat mislukken. Ik wees op projectleden die weglopen (uit angst om de schuld te krijgen?). Verder wees ik op ongemakkelijke stiltes die er vallen als de projectleider weer eens mooi spreadsheet laat zien met targets, deliverables en mijlpalen.
In de reacties werd meermalen gewezen op wat ik maar even de ‘menselijke factor’ noem. Je moet als projectleider doorvragen als je merkt dat de projectleden niet alles vertellen. Een van de mensen die reageerden verwoordde het mooi als ‘wie projectleider wil zijn, moet minstens kunnen communiceren en non-verbale communicatie begrijpen’. Daarmee raakt hij de spijker op zijn kop: er kan een verschil zijn tussen de papieren werkelijkheid en de ‘echte’ werkelijkheid en als projectleider moet daarmee om kunnen gaan.
Maar het wordt natuurlijk wel steeds lastiger om daarmee goed om te kunnen gaan. Toen ik (opa vertelt) in de it verzeilde was het heel gebruikelijk om met z’n allen in een hok gezet te worden. Je zag elkaar iedere dag en na afloop van een project wist je niet alleen dat iemand gewoon goed kon programmeren, maar je wist ook wanneer zijn vrouw een verjaardag had en wat zijn hobby’s waren. Heel gezellig allemaal.
Maar de laatste tien jaar werken we steeds meer in teams die geografisch verspreid zijn. En die geografische spreiding gaat tot India, Thailand en de Verenigde Staten aan toe. En het moet gezegd worden dat heel veel projecten in dergelijke opzet goed lukken. Netjes op tijd opgeleverd tegen kosten die een stuk beneden het oude niveau liggen. En daar was het om te doen.
Maar soms mislukken dit soort van projecten ook. En het lastige is dat die projecten er op papier heel mooi uitzagen tot vlak voor het moment dat het project als een rotte vis uit elkaar spatte. Ongetwijfeld zal de menselijke factor daar dan wel een rol gespeeld hebben. Wellicht hadden we het van doen met projectleider die beter thuis waren in Excel dan in coachingsvaardigheden. Dat is heel begrijpelijk. Maar het is wel verdomd lastig om daar nu lekker de vinger achter te krijgen.
Volgens mij moeten we weer werken aan onze antenne om de signalen op te pikken dat er een verschil is tussen wat we zien op de mooie voortgangsverslagen en wat er nu echt gebeurt in een project. Volgens mij zouden we dan scherp moeten letten op personeelsverloop, ontwijkende antwoorden en een voortdurend geschuif met deliverables. Dat kan wijzen op problemen binnen een project. En die kunnen we maar beter snel op het spoor komen, voor het te laat is.
Beetje vreemde kop, moet in mijn ogen zijn, “bedorven vis wordt duur betaald”. Immers als je vis koopt is deze meestal al dood en klaar om gegeten te worden, nog niet bedorven…
Aansluitend op de opmerking van hk; ik zie veel reacties met inhoudelijk goed commentaar, maar toch verloopt deze discussie soms bar slecht. Als je het goede van de bovenstaande reacties op een rijtje zet, dan kan je bijna een heel hoofdstuk over projectmanagementervaring schrijven. Maar zo als hierboven lukt het niet; waarom?
Veel ict’ers hebben moeite om helder over niet-technische zaken te communiceren. Ze reageren (te) snel en vergeten daarbij te vragen wat bedoel je precies.
Het resultaat is het “inhoudelijk vrijwel allemaal net langs elkaar heen schuiven”, zoals hk al schreef. Vooral als ict’ers in teams werken die geografisch verspreid zijn zoals het voorbeeld van Tom van Maanen, dan gaat het mis als men vooral via e-mail communiceert. Men schrijft langs elkaar heen, ment raakt gepikeerd en van samenwerken blijft weinig over dan elkaar vliegen afvangen. En dat verzwakt de positie van de ict’er in moeilijk lopende projecten.
Bijvoorbeeld als opdrachtgevers te weinig commitment in zich hebben, of onderbaasjes van de gebruikers de boel willen frustreren, dan kunnen ict’ers in principe een heel goede analyse maken van de gevolgen en ook met allerlei oplossingen komen. Maar als ze via e-mail over elkaar heen vallen, dan houd je rotte vislucht.
Een paar oplossingen: zet dus geen technische nurd op de stoel van projectleider, proces-, of functioneel ontwerper, et cetera. Kies de juiste mensen voor de juiste plekken bij het juiste project. Daarom, accepteer en waardeer de verschillende sterke kanten van de verschillende soorten ict’ers. Beloon ze naar waarde voor het team, niet zozeer naar hun hiërarchische positie. Dan willen nurds met te weinig sociale en communicatieve vaardigheden ook niet zo snel op de verkeerde stoel gaan zitten.
Verder probeer zo veel mogelijk op dezelfde werkplek te werken. Kan dat niet, maak dan meer gebruik van geavanceerde video conferencing.
Er loopt een hoop door elkaar heen. In de twee artikelen over de rotte vis gaat het steeds over projecten waarin outsourcing en offshoring een grote rol spelen. Is die uitbesteding naar landen hier ver vandaan is inmiddels niet achterhaald? Dat is vragen om rotte vis. Haal dan die mensen hier naartoe en voer het werk ter plaatse uit. Geen garantie maar het helpt wel denk ik.
@JohnvanVoren Je schrijft: zet geen technische nerd op de sturende en leidinggevende positie. Als een technische nerd staat voor iemand die geen sociale en communicatieve vaardigheden heeft dan heb je gelijk. Maar is dit een regel?
Een gebrek aan deze vaardigheden is niet exclusief voorbehouden aan technische nerds en er zijn vast ook techneuten die wel die vaardigheden hebben. Ik denk juist dat de ICT beslissers enige technische kennis en ervaring zouden moeten hebben en als ze dat niet hebben hun licht op steken bij de technische mensen. En de adviezen ter harte nemen. Ik ben het nog niet tegengekomen, er spelen ook vaak hele andere belangen bij ict-projecten. Het gaat vaak ook heel veel geld en dan gaat het snel over meer dan een goede oplossing.
Dat kan ook een van de oorzaken van de rotte vis zijn, beslissingen met technische gevolgen genomen door mensen zonder kennis, ervaring en gevoel voor techniek.
@Ewout Je hebt het over de ambtelijke omerta. Ik denk dat de omerta bij ons allemaal speelt, op vele niveaus. Bij mij in ieder geval wel. Ik ben hier nog geen mensen tegengekomen die zomaar uit de school klappen over alle misstanden die men meemaakt in het werk. Ik heb het hier op site alleen maar gezien bij artikelen over reorganisaties, ontslagrondes etc en dan zijn het stuk voor stuk anonieme reacties. Neemt niet weg dat je je binnen een ‘eigen’ project zou moeten kunnen uitspreken ook al is dat niet altijd gewenst.
@Louis Kossen, natuurlijk er zijn techneuten die uitstekend kunnen communiceren en veel empathie tonen. Maar uitgaande van de definitie van een nerd is een techneut dan ook niet per se een nerd, en is een nerd niet per se een goed technicus. Een nerd zet zich af van doorsnede medewerkers en/of wordt door hen apart gezet.
Een nerd inzetten in functies waar veel afgestemd moet worden (zoals beschreven niet alleen PL of PM), levert daarom een onnodige hindernis op.
Een nerd kan wel veel waarde hebben voor een groep omdat die andere problemen en andere oplossingen ziet. Een nerd hoeft daarbij ook niet geniaal te zijn, wat ze meestal ook niet zijn. Technisch goede nerds kunnen zelfs meer waarde hebben dan anderen en moeten dat ook materieel en niet-materieel beloond zien. Helaas worden ze meestal minder goed beloond en daarom willen ze vaak de PL of PM functie. Helaas, soms lukt het ze. En dat is net zo erg als de keuze voor een PL of PM in de ICT “zonder kennis, ervaring en gevoel voor techniek”.
Op projecten komen nu eenmaal veel verkeerde mensen af en mensen met de verkeerde motieven. Als Prince2 goed gehanteerd zou worden, dan zou regelmatig al in de eerste fase tot een vroegtijdig einde besloten worden. Maar op basis van die verkeerde motieven, zoals angst voor gezichtsverlies en verlies van omzet, wordt er een valse can-do houding aangenomen en wordt alle logica overboord gegooid. Bij pakweg één op de vijf projecten gaat het dan ook behoorlijk meuren.
De geur van rotte vis bij IT projecten ontstaat vaak al voor de start van een project. Er is nauwelijks leiding bij de start, de ambities worden hoog opgestapeld en het opportunisme viert hoogtij. Budgetten worden laag ingeschat, planningen optimistisch en de tijd van projectleden wordt voor de 3 of 4e keer geclaimd.
Na een proces van besluitvorming, (en laten we wel zijn daar zijn we in NL helemaal niet goed) dat meestal uitloopt in de tijd wordt er een valse of vage start gemaakt, de planning is dan al onhaalbaar, maar de projectleider met IPMA, Prince en allerlei andere methoden in zijn koffer beloofd dat het allemaal goed gaat komen.
Vaak merk je dan al dat het project fout zit en de projectleider blijft ervoor gaan en zich laat verleiden om mooi weer te gaan spelen in plaats van realisme toe te passen.
Nogmaals ten overvloede.
Wie als projectleider bij het management aangeeft dat je met een project te maken hebt dat alleen maar scheef kan gaan stuit op een muur.
Wie dan nog de moed heeft in de eigen organisatie te ventileren dat een project slecht in elkaar steekt en de geplande doelen onmogelijk in de voorgeschreven tijd te realiseren zijn wordt snel “gevroten”.
Daarom is het zaak als projectleider ook het management (of een lid daarvan) deel van het project te maken, op basis van gelijkwaardigheid.
Zorg voor openheid in de projectgroep en schuw niet een lid van het management te corrigeren. Daarvoor is moed nodig en een beetje talent in communicatie.
Oja, nog een variant die ik tegenkom. Salestraject doet meer dan een jaar er zijn allerlei mensen mee bezig, nu is de kogel door de kerk en wil de klant ook meteen dat de deadline gehaald werd die in het begin van het traject geroepen werd. Veel berekeningen zijn gemaakt op basis van aannames en door niet IT-ers.
Nu moet het project uitgevoerd worden, maar de mensen die het moeten gaan doen zien dat de aannames niet kloppen en dat zeker nog niet alles duidelijk is. Maarja, het is verkocht en nu moet het geleverd worden, hoe slecht het ook klinkt….
@JohnvanVoren Conclusie mag in ieder geval zijn dat de meeste techneuten geen nerds zijn.
@Henri Dat is iets wat ik denk teveel voorkomt, beslissingen op ict gebied met technische gevolgen worden genomen door niet ict’ers. Alle reden om de de harde ict’ers (ict afdeling) een belangrijke rol te geven en leidend en beslissend te maken. Ik weet het, dat is vloeken in de kerk alhier.
Henri,
Zeer herkenbaar. Dit is en blijft lastig en kan je alleen maar voorkomen door duidelijke intern approval proces op te stellen waar in de technische mensen ook betrokken zijn.
Was het niet scope creep en gebrek aan focus die de dooddoeners waren?
En het feit dat het werk vaak slecht te overzien is en vrijwel niemand in ons vakgebied echt een goede schatting kan maken? Computers doen blijkbaar altijd alles anders dan je verwacht.
Of de techneuten die het mooier maken dan aan de klant beloofd is? (en dus langer moet werken en bovendien code produceren die bij andere vragen opwerpt.. waar is dit nu voor?
O nee, het ligt natuurlijk aan de projectleider dat ie dat niet in de gaten heeft….
Ja en natuurlijk aan de sales die het project heeft verkocht.
En waar is die oude regel gebleven om maximaal 1 nieuw ding in een project uit te voeren?
tja, dan komt bij mij de vraag bovendrijven … menselijke factor accepteren of mensen niet meer laten programmeren?