Projectmanagement schiet vaak te kort

Cover stories

Ondanks, of misschien wel juist door de enorme aandacht voor het standaardiseren van projectmanagement, gaat er nog altijd veel mis bij de uitvoering van IT-projecten. Planning en mijlpaalproducten nemen een te centrale plaats in bij deze standaard methoden. De projectmanager richt zich teveel op het escaleren naar het hogere management bij het niet halen van de planning in plaats van te investeren in leren en samenwerken. Hoe voorkom je dat een IT-project in een neerwaartse escalatiespiraal terecht komt?

Falend projectmanagement

IT-projecten worden als middel ingezet voor het realiseren van IT-veranderingen. IT-projecten kennen vaak een moe...

Richard Vielvoye
Met genoegen heb ik uw artikel zitten lezen. Ik herken veel van de genoemde zaken en ik ben inderdaad ook van mening dat er meer creativiteit in het project terug mag komen.

Toch nog wat kritische kanttekeningen:
* er wordt wel snel gesprongen van blauwdruk-denken (De Caluwe) naar rooddrukdenken. Ik denk dat het situationeel is. Fase van ontwikkeling van het bedrijf en cultuur is sterk bepalend.
* ik denk dat de projectmanager ook meer de moed moet hebben om een project stil te leggen. Vaak blijven beslissingen inderdaad in de stuurgroepen hangen. Wanneer de projectmanager een project stil legt (als laatste redmiddel) is dat mijn inziens een professioneel middel om hier druk achter te zetten.
* in het verlengde van mijn vorige opmerking is het ook van belang om bij de start van een project stil te staan bij de rol van het beslisorgaan (de stuurgroep). Mijn ervaring is dat veel stuurgroepen worden bezet door lijnmanagers die geen projectmanagement-ervaring heeft en daardoor niet in staat zijn om het project slagvaardig te sturen.

Nogmaals, verder helemaal eens.

Gr,

Richard
Richard Puyt
Beste Leon,
Boeiende materie waarover je schrijft. Ook enorm herkenbaar. Je voorbeelden spreken tot de verbeelding. De klassieke technische projectmanager die afspraak=afspraak roept en planningen in beton giet. Typische projecten van de eerste orde (zie projectmatig werken van Gert Wijnen c.s.) of het blauwdrukdenken (uit Leren Veranderen van de Caluwé c.s.) van dezelfde firma. Wat ik mis in je analyse is de rol van de opdrachtgever. In de projectmanagement methodes (bijvoorbeeld PRINCE2) wordt hier ook nauwelijks aandacht aan besteed. De projectmanager is altijd de actieve figuur die het project trekt, maar er is minstens zo'n grote rol weggelegd voor de opdrachtgever. Goed opdrachtgeverschap houdt m.i. ook in dat de opdrachtgever niet klakkeloos alles accepteert wat de projectmanager voorstelt (bijvoorbeeld onrealistische planningen en dat je juist betrokkenheid toont. De praktijk is helaas vaak anders. Juist de opdrachtgever moet investeren in de samenwerking en coachend optreden als de projectmanager daar te weinig aandacht aan besteed. Er zijn twee titels op de markt (zover ik weet) die dit onderwerp verkennen, te weten: PRINCE2 voor opdrachtgevers van Michiel van der Molen en Help, ik heb een opdrachtgever van Nicoline Mulder.

Met vriendelijke groet,
Richard Puyt
Armand
Helemaal mee eens. Maar bij bijna alle klantorganisaties is het focus gericht op het instrumentarium en niet op de inhoud van het project. Mi is een projectplanning de neerslag van een heel proces. En niet meer dan dat.
Meer dan eens heb ik discussies gevoerd met stakeholders danwel projectmanagers die de planning als een heilig iets beschouwden. Of nog erger de project documentatiemethode (Ja maar volgens Prince......).
En als (extern) adviseur mbt projectmanagement krijg ik tijdens discussies wel eens te horen dat ik niets van Prince 2 begrijp. Nu heb ik ca 20 grote IT projecten geleid, van redelijk straight tot zeer complex en allemaal min of meer succesvol. Maar het gaat daarbij vooral om betrokkenheid, kennis van zaken en veel communiceren. En met dat laatste bedoel ik dus niet dat je vooral veel emailt. En de PM methode is daaraan ondergeschikt. Een hulpmiddel, niet meer en niet minder, maar zeker geen toverstafje voor succes.
Koos Overbeeke
Leon,
Mijn complimenten voor dit artikel. Een knappe analyse en uitwerking. Daarbij heb ik een kleine aanvulling. In de titel en de uitwerking leg je de nadruk op falend projectmanagerschap en gegeven de voorbeelden die je gebruikt lijkt dat ook aannemelijk.
Mijn ervaring is dat deze benadering te eenzijdig is. Er is namelijk ook de kant van de opdrachtgever. Eén van de verantwoordelijkheden van de opdrachtgever is het vinden en contracteren van een projectmanager ‘capable for the job’.
Ik zie te veel om me heen dat opdrachtgevers en inkopers van interim personeel bij de selectie van projectmanagers niet meer functie-eisen weten op te hoesten dan inhoudelijke materie kennis/ervaring aangevuld met Prince 2 en bijvoorbeeld ITIL. Met alle respect, dat zijn natuurlijk zwaar onvoldoende criteria voor de selectie van een projectmanager op het juiste niveau. Een personeelsbaas waar ik ooit mee werkte zei:”vraag je een aap dan krijg je een aap”.
Met andere woorden. Eens met je artikel met de kanttekening dat als er sprake is van falen dat de opdrachtgever dan evenveel blaam treft.
Vriendelijke groet,
Koos
Vincent Krijthe
Dank voor het goede artikel. Heel herkenbaar alhoewel ik eraan toe wil voegen dat management methoden en technieken niet het verschil maken mbt succesvol projectmanagement. De projectmanager zelf maakt het verschil.
Ik kan me vinden in de conclusie:
"Investeren in afstemmen en verbinding tussen IT-project, IT-beheerorganisatie en gebruikersorganisatie is een andere manier van leiding geven aan organisatieverandering waarbij ICT een belangrijke rol speelt."
Echter de meeste projectmanagers ontberen één of meerdere essentiële basisvaardigheden als communiceren, relaties aangaan, overtuigen, enthousiasmeren etc. om complexe organisatie/ICT projecten tot een goed eind te brengen. Teveel projectmanagers weten veel van ICT maar weinig van management. Hierdoor faalt nog steeds meer dan 60% van alle ICT projecten in Nederland.

Nico
In general I agree with the article. The project manger should not commit to project delivery dates or project cost with the project stakeholders unless he has the full support of the project team.

I don’t believe in doing estimates by myself: the project teams are the technical experts, and they should have the biggest say in how the project should be structured, and how long each activity will take. The project manager should be the facilitator in this process, as described in the article. As an added bonus, you will also get their buy-in and commitment.

The project manager should focus on scope. Most business users have the idea that it is quick and easy to change software. Focus on scope protects the team from these changes. That said, the project manager should not be inflexible. Scope change should be allowed to happen, but in a controlled way. This should lead to update cost and delivery dates.

Thanks for the thought provoking article.
Nico
Hans / H.P. Fransen
Lid sinds 2019
Het beschikken over het boekje met de regels, het beschikken over een scale aan projectemanagement instrumenten en het volgen van een cursus is bij lange na niet voldoende om een project goed uit te voeren. Ja, het is allemaal belangrijk en je moet het zeker doen. Besef dat wij er niet zijn voor deze hulpmiddelen maar dat deze er juist voor ons zijn en ons ten dienste staan. Zolang mensen het niet begrijpen gaat het nooit werken.

Wanneer bij de start van een poject de tijd wordt genomen om met elkaar vast te stellen wat er moet gebeuren, hoe dat wordt gemanaged, met welke middelen en door wie dan blijkt in praktijk dat 95% van het project op rolletjes loopt. De rest vormt een dagtaak voor de projectmanager door gewoon te luisteren naar de medewerkers en de voorliggende problemen in onderling overleg onmiddellijk met elkaar op te lossen.
Nico Viergever
Lid sinds 2019
Dit artikel gaat in het begin al mis. Volgens PRINCE2 bestaan er geen IT projecten, alleen projecten die toegevoegde waarde hebben, een doel hebben, Business projecten.
IT is een middel , geen doel (tenzij je voor een IT leverancier als Logica werkt natuurlijk). PRINCE2 geeft ook zeer duidelijk aan dat als gevolg van het bovenstaande en de daaraan gerelateerde conflicterende business cases, niet de leverancier, maar de klant het project dient te managenen. Helaas wordt dit stukje PRINCE2 meestal genegeerd, vooral door leveranciers (zoals Logica). Voor mij is dit een zeer belangrijke oorzaak waarom zoveel projecten falen: ze worden immers gezien als IT projecten met de leverancier aan het stuur...
Lex van Haarlem
(1) Albert Einstein zei: "We can't solve problems by using the same kind of thinking we used when we created them”.

(2) Problemen of veranderuitdagingen in organisaties ontstaan in de huidige kennismaatschappij onvermijdelijk in het licht van het conventionele managementdenken zoals dat op onze universiteiten en hogescholen wordt gedoceerd.
Ditzelfde denken ligt ook ten grondslag aan ICT-oplossingen.

(3) Hier ligt daarom een onvermijdelijke valkuil voor managers die met ICT-oplossingen problemen of veranderuitdagingen in organisaties willen aanpakken.

(4) De toepassing van nieuwe ICT-oplossingen zal dan ook alleen op een soepele manier kunnen verlopen als deze op een onconventionele wijze tot stand komt of in het bijzondere geval dat er in een bedrijfsvoering geen sprake is van noemenswaardige problemen of veranderuitdagingen.

(5) Als het in het artikel genoemde “investeren in leren en samenwerken” niet voldoende vergaand ‘out-of-the-box’ gaat (lees: in de betreffende situatie onvoldoende onconventionele consequenties heeft), blijven bovenstaande beweringen van kracht en de huidige praktijksituatie van teveel tegenvallende ICT-projecten ongewijzigd.

Met name in organisaties waarin het zogenaamde diversiteitsdenken (met een open oog voor zachte aspecten)reeds is doorgedrongen, is het van belang hier niet lichtzinnig aan voorbij te gaan (zie hiervoor de column van Pierre Mellegers op deze website: http://www.managementsite.nl/columns/1385/Diversiteitsdenken-een-organisatie-onderzoek-naar-verschillen-in-en-buiten-ons-zelf.aspx).

(6) Het in ICT-projecten conventionele samenspel tussen leveranciers en klanten is gebaseerd op een diepgewortelde conditie van ‘gecontroleerd wantrouwen’.

Zolang daar sprake van is, is “investeren in leren en samenwerken” een fars (zie in dit verband ook mijn reactie “CRM is geen ICT: eye opener of open deur” op deze site van 22-07-08; http://www.managementsite.nl/352/ICT-en-Internet-CRM-is-geen-ICT.aspx).

(7) Deze beweringen zijn kort door de bocht geformuleerd, maar de praktijk van zoveel mislukkingen waarover ook het artikel spreekt, maakt het aanbrengen van nadere nuances slechts tot een activiteit voor liefhebbers.

Zelfs als bovenstaande stellingen niet gelden voor alle ICT-projecten, blijven er nog teveel ICT-projecten over, waarvoor deze stellingen in hoofdlijnen wel gelden.

Deze situatie bestaat al minstens dan 20 jaar!
Sander Galjaard
Een herkenbare situatie. Projectmanagement is vaak gericht op de 'harde' of 'expert'-kant. Resultaten dienen met zo min mogelijk budget een zo hoog mogelijk rendement opleveren.
De vergelijking met het projectmanagement in het onderwijs gaat niet helemaal op, maar wel herkenbaar.

In het innovatie-en onderzoeksproject van Expeditie Durven Delen Doen (www.expeditiedavinci.nl en www.durvendelendoen.nl) gaat het juist over 'leren innoveren'. De 7 C's (commitment, community, consistentie etc.) van Sietske Waslander kunnen fungeren als evaluatiekader voor de proceskant van innovatie/projectmanagement.
Het Da Vinci College in Leiden doet daar op dit moment prachtige ervaringen mee op. Sturen op resultaat en op proces. Onderzoek naar de innovaties wordt door de docenten zelf gedaan.
Kernbegrippen zijn: eigenaarschap, uitgaan van passie, betekenisvol, samenwerken en participatie. De insteek is dat de innovaties en onderzoek daarnaar duurzaam zijn en een blijvende plek krijgen binnen de onderwijsorganisatie.
Binnenkort verschijnt een artikel in Opleiding&Ontwikkeling hierover.
christoph maria ravesloot
Het artikel projectmanagement gaat in op hoe en waarom projectmanagers in de IT te kort schieten. Het lijkt niet alleen in de IT zo te gaan. In de civiele techniek en in de bouw wordt ook relatief weinig aandacht geschonken aan de creativiteit van samenwerkende mensen. Als je ingenieurs vraagt van welke verstoringen in een op te starten project ze de meeste hinder verwachten te ondervinden, dan noemen ze altijd hun eigen onderlinge samenwerking en de samenwerking met de omgeving buiten het project als potentieel het meest verstorend. Als je kijkt naar de agenda van vergaderingen en werkoverleg, dan komen die verstoringen niet aan de orde.
In de bouw blijkt het mogelijk te zijn om uit te rekenen hoeveel agendatijd besteed zou moeten worden aan te voorziene verstoringen. Het zogenaamde PSU product (Project Sense of Urgency) is het product van de door het team ingeschatte complexiteit index (van 1 = eenvoudig, tot 5 is meest complex) en een door het team ingeschat potentieel aan verstoringen in vier categorien: Techisch, Organisatorisch, Samenwerking en Externe Dynamiek. Maximaal mogen 10 punten worden toegekend aan deze index. Index x Factor = PSU product. Bij eenvoudige projecten kunnen maximaal 10 PSU product eenheden worden gescoord, bij een meest innovatief complex project 50 PSU product eenheden.
Één PSU eenheid komt ongeveer overeen met 20 minuten agendatijd op een werkconferentie zoals een projectstartup of een projectflollow up. Een PSU van een eenvoudig project duurt dan ongeveer 200 minuten = 3 uur 20'. Een innovatief groot en complex project vraagt om een PSU van 50 x 20 minuten = ruim twee dagen.
Als je deze berekening een aantal keren gebruikt, valt op dat de geagendeerde tijd voor teambuilding en voorkomen van escalatie drastisch toeneemt en dat de planning al snel aangepast wordt aan realistische uitgangspunten en niet meer op opportunisme van de projectleider en opdrachtgever kunnen worden gebaseerd.
Tijdens de werkconferentie kun je bovendien het leervermogen vergroten en de creativiteit bevorderen door unanieme besluitvorming op basis van geen bezwaar (consent) in te voeren. Daarmee maak je het mogelijk dat teamleden op basis van gelijkwaardigheid met elkaar omgaan. Dat vergroot het probleemoplossend vermogen van het team drastisch!

christoph maria ravesloot
lector Innovatie Bouwproces en Techniek
Avans Hogeschool
Hogeschool Zuyd

anne-Mie Hautekeete
Beste, ik werk in een culturele overheidsdienst en als ik de term IT-project vervang door een sociaal-artistiekproject klopt het artikel ook nog steeds :-)
het is inderdaad zo dat projecten met veel proces en creatieve imput ook niet te betonneren zijn. Nochtans durf ik ook wel eens diegene te zijn die bij de medewerkers hamer op mijlpalen en deadlines, maar dan vooral in functie van het niet uit het oog verliezen van de doelstellingen. Een creatief proces durft nogal eens uit te waaieren (te veel perceiving om het in MBTI termen te noemen). Het spreekt vanzelf dat mijlpalen dan geformuleerd worden op wat ik in eigen vakjargon "veranderingsknopen" zou noemen.

Gelijkenissen tussen IT en creatieve processen een toeval? Streven computer en IT niet voortdurend de technische perfectie van de menselijke hersenen na?

Heb het artikel met interesse gelezen inclusief andere commentaren!
thanks
Anne-Mie
Hans de Jong
Enkele losse gedachten, vanuit het projectmanagement van softwareontwikkeling.

Wat ICT-projecten onderscheidt van andere projecten is de complexiteit van problemen en oplossingen, de veranderlijkheid van de omgeving en van de wensen en eisen.

In het begin van een ICT-project is er nog zo weinig bekend over de details in de eisen die gesteld zullen gaan worden, dat het onmogelijk is een planning op te stellen die ergens op slaat. De klanten kunnen zich er geen voorstelling maken hoe ze straks zullen gaan werken. Dat groeit wel tijdens de duur van het project, als de eerste resultaten worden getoond. Maar dat kan ook betekenen dat er grote wijzigingen komen in de eisen en wensen.

Als er in het project gebruik gemaakt zal worden van nieuwe technologie, dan zal er geexperimenteerd moeten worden, en doodlopende wegen bewandeld worden.

Dit alles kost tijd, en hoeveel tijd dat gaat worden, is maar moeilijk in te schatten, zeker niet bij de start van het project.

In een ICT-project moet wel rekening gehouden worden met onzekerheid en verandering. Daarom wordt PRINCE 2 vaak aangevuld met een softwareontwikkelingsmethode zoals RUP (Rational Unified Process), en een AGILE projectmanagementaanpak.

RUP bevat de best practices van vele projectmanagers, gaat uit van structured prototyping, en stelt dat met het vaststellen van het projectplan een raming van het project kan worden gemaakt met een onzekerheidsmarge van 400 %...

De kern van Agile is dat klanten en ICT'ers samen in kleine stapjes toewerken naar een steeds beter resultaat, en dat verandering goed is. De nadruk ligt dus op de zachte kant van projecten uitvoeren.
Leon Dohmen
Dank voor jullie reacties. Stuk voor stuk opmerkingen / aanvullingen die zeker hout snijden. Het is niet mogelijk om op alle reacties individeel in te gaan. Twee zaken wil ik er nog graag uitlichten. Namelijk de rol van de opdrachtgever en training en opleiding:

1. Rol van de opdrachtgever
Als ik deze belicht vanuit mijn eigen kennis en kunde valt me op dat de opdrachtgever regelmatig op de achtergrond verblijft. Vaak wordt de projectmanager / leider door projectmedewerkers gezien als verlengstuk van de opdrachtgever. Als de projectleider onafhankelijk opereert en bewust als verlengstuk van de opdrachtgever acteert dan is de opdrachtgever geen kritieke succesfactor voor het investeren in leren en samenwerken. Hij kan lekker het project volgen in de luwte.

2. Training en opleiding
De (h)erkenning van het probleem doet me concluderen dat projectmanagers / leiders de verkeerde training krijgen. Het ontwikkelen van vaardigheden in het hanteren van instrumenten krijgt voldoende aandacht. Het trainen van vaardigheden om leren en samenwerking te stimuleren is het grote manco in deze trainingen en opleidingen. Dus, aanpassen die trainingen en opleidingen voor projectmanagers / leiders is dan het devies!

Nogmaals dank voor jullie bijdrage,
Leon Dohmen

Teun van Aken
We weten dit allemaal al heel lang, ik schreef er in 1996 mijn proefschrift over. En gegeven de herkenning, die in de reacties zijn te zien, schreef Leon Dohmen niets nieuws. De vraag rijst dan: Waarom gaan we er dan toch mee door? Wat is er mis met opdrachtgevers, die toch ook de lage succesratio van projecten (inderdaad: niet alleen IT-projecten) kennen? Wat is er mis met projectmanagers die iedere keer weer hetzelfde blijven doen? Waarom verkopen die eenzijdige instrumentele opleidingen voor projectmanagers nog steeds?
Pas als we op die vragen naar de oorzaken achter de oorzaak van falen de antwoorden weten te achterhalen, kunnen we echt maatregelen bedenken.
Willem Mastenbroek
Pro-lid
De kern van het probleem is vaak dat de opdrachtgever onvoldoende meedoet. De reguliere lijnorganisatie is vervolgens niet betrokken. De koppeling met de business is absoluut onvoldoende.

Dit is de aanloop tot mislukking, zeker als de gewenste veranderingen de actieve inzet van de lijnorganisatie vragen. En dat is zeer vaak het geval! Elders https://www.managementsite.nl/organisatierot beschrijf ik de volgende ervaring:

“Onlangs vertelde de baas van een grote productie-afdeling mij met zichtbaar genoegen dat het kwaliteitsproject op zijn laatste benen liep. Eindelijk kon er weer normaal gewerkt worden. Jarenlang was hij, naar zijn idee, afgeknepen met verzoeken (lees: opdrachten) om medewerkers in projectgroepen te laten participeren. Daarbij kwamen nog allerlei onderzoeken van externe figuren, die zijn medewerkers voor de voeten bleven lopen. Vooral het rapport over de vermijdbare kwaliteitskosten was bij hem en zijn mensen verkeerd gevallen. "Alsof we ons hier niet uit de naad werken!" Enfin, de projectgroepen hadden hun werk gedaan. Er waren nog wel bijeenkomsten om de resultaten over te dragen. "Nou, ze zoeken het maar uit, misschien iets voor de coördinatoren."

Ik zie te vaak hoe een goed opgetuigde projectorganisatie de verantwoordelijkheid voor verbetering uit de lijnorganisatie haalt. Niet gepland of bedoeld maar het gebeurt! De sturing en betrokkenheid van de top verdwijnen naar de achtergrond en het leidinggevende kader wordt onvoldoende aangesproken op de eigen verantwoordelijkheid.

De projectaanpak is in tal van organisaties verworden tot een chronische kwaal. Zijn er problemen oftewel ‘uitdagingen’; we lossen het op met een project. Kordaat en doelgericht! Dat is de routine. Velen geloven hier kennelijk in. Zeker als tal van verstandige mensen een gezicht trekken alsof het zo hoort.

Soms is men zo gewend aan deze aanpak dat men zich niets meer voor kan stellen bij het alternatief van "Hou het in de lijn!" Vaak ook wordt het idee om het verantwoordelijke management de zaken op te doen pakken afgedaan met: 'Geen tijd' of 'Men kan het niet aan'.

Mijn stelling is: Dat kan gebeuren. Maar dan moeten we elkaar niet wijsmaken dat we dit met de projectaanpak oplossen. Dan is dat het probleem wat we onder ogen moeten zien en waaraan we wat moeten doen.


Ada Cheang
Complimenten! Echt een goed artikel.
De punten die in het artikel terugkomen zijn heel herkenbaar.
Het probleem van projectmanagement is dat men zich altijd op het proces richten en veel minder op de inhoud.

Meer over ICT & Internet