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 moeizaam verloop en leiden lang niet altijd tot voldoende resultaat. De enorme aandacht de afgelopen 10 jaren voor standaard projectmanagementmethoden zoals PRINCE2 heeft hier geen verbetering in gebracht. Een van de belangrijke oorzaken die hier achter schuilgaat, is dat IT-projecten zich teveel beperken tot alleen de techniek. De met de technische verandering gepaard gaande organisatieverandering wordt vaak niet (h)erkend. Ook is een niet realistische opleverdatum voor het bouwen van de technische oplossing een extra handicap. Met de tot de techniek beperkte scope en te ambitieuze opleverdatum als uitgangspunt wordt een planning van het IT-project gemaakt, die bestaat uit tijdlijnen en mijlpaalproducten. Ondanks de genoemde manco’s van beperkte scope en niet realistische opleverdatum, krijgt de planning een soort ‘heilige’ status. Afwijkingen op de planning worden niet getolereerd en vrijwel meteen verheven tot issues of geëscaleerd naar het hogere management.

Escaleren en de neerwaartse spiraal

De basismanagementstijl van de meeste projectmanagers die IT-projecten leiden, is gericht op het halen van tijdlijnen en mijlpaalproducten van de technische scope. Deze op instrumenten gerichte managementstijl lijkt op het werken volgens het blauwdruk denken van de theorie van de Caluwé en Vermaak . Managers van dit type escaleren veel naar het hogere management bij het niet halen van de planning. Dat is hun plicht vinden ze, want zo is het geleerd op de cursus projectmanagement. Naarmate er meer afwijkingen komen op de planning, neemt het aantal escalaties toe. De projectmanager is al zijn tijd kwijt aan uitleggen en verantwoorden wat er zoal fout gaat. Van werken aan het projectresultaat komt niets meer terecht. In sommige praktijksituaties van IT-projecten is escaleren naar het hogere management op een bepaald moment aan de orde van de dag. De sfeer raakt verziekt. Projectmedewerkers werken onder hoge druk en geloven niet meer in een positief resultaat. Het IT-project zit gevangen in een soort escalatiemodus en is ‘ten dode’ opgeschreven.

‘Gevangen’ in 300 Microsoft Projectregels (1)
Bij een groot uitbestedingcontract bestond 1 van de deelprojecten uit het overdragen van het beheer van 2.500 PC’s van de interne IT-organisatie naar een externe IT-leverancier. Het uit te besteden beheer bestond uit telefonische ondersteuning via een helpdesk en indien nodig kwam een IT-beheerder langs om het probleem te verhelpen. 10 van de IT-beheerders van de interne IT-organisatie verhuisden mee naar de externe leverancier. Zij kregen dus een andere werkgever.Een projectmanager van de leverancier gaf leiding aan dit deelproject. Hierbij werd hij o.a. ondersteund door projectmedewerkers van de klant. Van een vergelijkbaar eerder uitgevoerd project kopieerde de projectmanager de planning en deed hier en daar wat aanpassingen. De planning bestond uit ongeveer 300 regels, uitgewerkt met het programma Microsoft Project. Deze regels in de planning waren voor de projectmedewerkers van de klant moeilijk te begrijpen. Deze projectmedewerkers van de klant maakten zich vooral zorgen over veranderingen in de werkinhoud en samenwerking wanneer het uitbestedingcontract was ingevoerd. Dit zagen zij niet terug in de planning. Niet alle projectmedewerkers werkten vanaf dezelfde locatie.Via wekelijkse telefonische conferenties stemde de projectmanager van de leverancier af met de projectmedewerkers over status en voortgang van het deelproject. Hij gebruikte hiervoor de planning met de 300 regels. De projectmedewerkers werden geacht acties uit te voeren volgens de planning maar snapten niet goed wat de regels bijdroegen aan het resultaat van het deelproject. De projectmedewerkers van de klant maakten zich vooral zorgen over de organisatorische veranderingen. De projectleider van de leverancier bleef echter hameren op het halen van tijdlijnen en mijlpaalproducten in de planning.

Elke week naam de frustratie en irritatie toe bij zowel de projectmanager als de projectmedewerkers. Frustraties en irritaties mondden uit in escalaties naar het hogere management. Het deelproject leek hopeloos vast te lopen.

De op instrumenten gerichte managementstijl komt waarschijnlijk voort uit angst en onzekerheid om niet ‘in control’ te zijn. Ondanks toenemende aandacht voor andere, minder op instrumenten gerichte, managementstijlen wordt binnen IT-projecten nog vaak geacteerd op basis van ‘command en control’. Maar wat stuurt de projectmanager dan precies (bij) als de planning van een IT-project incompleet of gebrekkig is?

Investeren in leren en samenwerken

Projectmanagers die IT-projecten leiden moeten af van het idee dat elk IT-project vanaf de tekentafel kan worden ontworpen en gepland. Eerder is al aangegeven dat veel IT-projecten de scope beperken tot de techniek. Vanwege het enorme aanbod uit bestaande en nieuwe technologieën is het zelfs voor deze ‘beperkte’ technische scope al vrijwel onmogelijk om aan het begin van een project een complete en juiste planning te maken voor de te bouwen IT-oplossing. Daarnaast worden veranderingen in de werkinhoud en samenwerking tussen mensen als gevolg van IT-veranderingen, gestuurd en ontwikkeld door voortschrijdend inzicht waarbij ontdekken en leren centraal staan. Mensen moeten dan ondersteund worden in plaats van opgejaagd omdat het IT-project achter ligt op de planning. Leer en onderzoeksruimte zijn nodig om de IT-verandering en organisatieverandering te kunnen absorberen. Investeren in leren en samenwerken vergroot de veranderkracht van de organisatie.

Het belang van juist gekozen werkvormen

De projectmanager moet niet escaleren als het IT-project achter ligt op de planning maar investeren in werkvormen die leer- en onderzoeksruimte bieden. Vooral werkvormen waarbinnen leren centraal staat zoals workshops (gelegenheid waarbij men gezamenlijk creatief bezig is), demonstraties en testsessies zijn hier goed te gebruiken. Werkvormen zorgen voor interactie en dialoog tussen mensen. Sommige werkvormen richten zich vooral op (grote) groepen. Andere werkvormen richten zich meer op het individu en zorgen voor de echte verankering van de IT- en organisatieverandering in de medewerkers, door medewerkers actief mee te laten doen en te laten leren en samenwerken.

Een fout gekozen werkvorm
Een werkvorm dient te passen bij het doel. Een workshop bijvoorbeeld dient vaak als werkvorm om knelpunten bij het functioneren van een afdeling boven water te krijgen. Management en medewerkers van de betreffende afdeling zitten dan in dezelfde workshop. De kans is groot dat niet iedereen actief meedoet en vrijuit durft te spreken, waardoor in de workshop maar de helft van de knelpunten boven water komt. De uiteindelijke oplossing is maar een halve oplossing. Het is dan beter om knelpunten via tweegesprekken te verzamelen en vervolgens geanonimiseerd te presenteren.

Goed gekozen werkvormen zorgen ervoor dat management en medewerkers de kans krijgen, om zich voor te bereiden op de aanstaande IT-verandering en organisatieverandering. Investeren in werkvormen die collectieve leer- en onderzoeksruimte bieden regelt afstemming en verbinding tussen het IT-project en management en medewerkers die de verandering ondergaan. Dit zorgt voor een soepeler verloop van het IT-project en leidt tot een beter resultaat. Het goed regelen van afstemming en verbinding gebeurt via:

  • Het vaststellen van het gezamenlijke doel en richting;
  • Het kiezen van een passende veranderaanpak;
  • Het stimuleren van betrokkenheid en samenwerking;
  • Het stimuleren van het leerproces;
  • Het verbeteren van de persoonlijke bijdrage;
  • Het ontwikkelen van veranderkracht.

Dit vraagt om een ander type projectmanager. Een type dat niet alleen technische en instrumentele vaardigheden heeft maar ook weet hoe je afstemming en verbinding regelt ter ondersteuning van het collectieve leerproces van mensen. Dit vraagt om een type projectmanager dat niet onzeker of ongeduldig wordt als het IT-project achter ligt op de planning. De meeste cursussen over projectmanagement besteden te weinig aandacht aan het regelen van afstemming en verbinding tussen IT-project, IT-beheerorganisatie en gebruikersorganisatie.

‘Gevangen’ in 300 Microsoft Projectregels (2)
De projectmanager van de externe IT-leverancier werd vervangen door een ander type projectmanager. Een type manager dat zich meer richtte op het afstemmen en verbinden van het deelproject met de IT-beheerorganisatie en de gebruikersorganisatie.In een aantal workshops, die samen 2 ½ dag duurden, werkte hij aan het creëren van het gezamenlijke doel en richting. Dit waren zeer intensieve sessies die veel energie kostten. Er werden duidelijke afspraken gemaakt over de inhoud en het resultaat van het deelproject. Ook de veranderingen in de werkinhoud en samenwerking werden gepresenteerd. Dit gebeurde allemaal zonder verwijzing naar de 300 regels in de eerder opgestelde planning.De serie workshops werd afgesloten met een presentatie waarin de vertegenwoordigers van IT-beheer- en gebruikersorganisatie formeel om goedkeuring werd gevraagd om het deelproject voort te zetten en implementatie ervan te gaan regelen. De workshops hadden bijgedragen aan het vormen van een gezamenlijk doel. Binnen deze workshops werden betrokkenheid en samenwerking gecreëerd, die in de voorafgaande maanden broodnodig werden gemist. De persoonlijke bijdrage en het leerproces van de vertegenwoordigers kregen een flinke impuls.

De vertegenwoordigers van de IT-beheerorganisatie en gebruikersorganisatie hadden nu meer vertrouwen in een verder goed verloop van deelproject. Het overdragen van het beheer van 2.500 werkplekken kon beginnen.

Samenvatting

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. Deze manier van leiding geven leidt tot flinke verbeteringen in de veranderresultaten. Uit praktijkcases in het boek ‘Regie voeren over organisatieverandering met ICT’  valt af te leiden dat deze vorm van regie voeren kan leiden tot een verhoging van wel 44% van het veranderresultaat, met als gevolg dat veranderingen beter aansluiten bij de verwachting en het organisatiedoel terwijl de verandering ook daadwerkelijk als verbetering wordt ervaren.

Leon Dohmen is ICT management consultant bij Logica en doceert Management of Technology aan de Rotterdam Business School voor Master- en MBA-programma’s.

Kom met uw praktijkervaringen op het terrein van managen en organiseren

Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)

Word een pro!

SCHRIJF MEE >>

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
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
Pro-lid
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!
Rob Buijtendijk
Naar mijn mening raakt het artikel slechts het oppervlak van waar het binnen projecten (en dus ook ICT projecten) echt over gaat.

De kern van ieder project bestaat uit: mensen en verandering. Ieder project hoe klein, groot, simpel of complex brengt een verandering teweeg in de werksituatie van mensen in een organisatie.

Het is ontstellend te zien hoe weinig aandacht hieraan gegeven wordt in de bekende projectmanagement methodieken. Alhoewel het uitvoeren van projecten een blauwe verander interventie is, zegt dat niets over de meerkleurige aanpak die binnen het project (onder bepaalde condities) gekozen en ingezet kan worden om de verandering echt te laten beklijven en zo tot echt project resultaat te komen.

Waarom dan toch zo blauw? hoor ik u denken. Het antwoord is volgens mij even simpel als ontluisterend: methoden leiden tot een schijnzekerheid en schijntastbaarheid, mensen niet. De projectmanagers van tegenwoordig kiezen voor de makkelijkste weg: weg van de mensen. Mijn betoog luidt dan ook dat we dit soort projectmanagers niet meer nodig hebben. We hebben een grote behoefte aan projectleiders: mensen die andere mensen leiden in de verandering.

Wat een mooi vak is dat zeg!!!
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