De meest gemaakte fout vaneen ict-projectmanager/leider is het niet goed luisteren naar zijn/haar opdrachtgever. Je moet nee durven zeggen. Maar een opdrachtgever heeft ook zijn verantwoordelijkheden. Samengevat communicatie is erg belangrijk voor een project.

Tijdens acquisitie worden geweldige voordelen aan potentiële opdrachtgever voorgespiegeld. De opdrachtgever wil dit heel graag geloven. Heb minder geloof in mooie praatjes. Geef uitvoerders de belangrijkste rol, zij weten hoe weerbarstig het kan zijn om een idee om te zetten naar een bruikbaar product. Kortom het gaat om de inhoud en niet om de verpakking.

De kop geeft groot aan dat de project manager niet leert, maar het artikel geeft ook duidelijk aan dat de opdrachtgever niet leert.
Afhankelijk of men de project manager als uitvoerende ziet of als bepalend zou de kop misschien beter kunnen zijn dat de opdrachtgever niet leert en dat de project manager dit accepteert.

Enige nuancering van de conclusie is misschien op zijn plaats:
 
Individuele ict-projectmanagers leren wel van hun eigen ervaringen als het gaat om het slagen of falen van projecten (Ropponen & Lyytinen, European Journal of Information Systems, 1997).
 
In mijn eigen onderzoek, dat betrekking heeft op het effect van risicomanagement op het succes van ict-projecten, kom ik eveneens tegen dat projectmanagers hun eigen ervaringen uit voorgaande projecten gebruiken bij de inrichting en sturing van hun volgende projecten.
 
Het lijkt er echter op dat deze individuele kennis en ervaringen niet of nauwelijks door anderen worden opgepikt, en dus dat de algemene verspreiding en toepassing van deze kennis beperkt is. Iedere projectmanager heeft zijn/haar eigen leerschool, en leert vooral: “the hard way”.

Het is mij al lange tijd helemaal duidelijk dat er weinig geleerd wordt. Het artikel toont dat aan en ook de reacties zijn veelzeggend. De belangrijkste reden voor falen wordt nauwelijks onderkend: verwarring van middel en doel.
Als je het hebt over ict-projecten, stel je het middel voorop. Het gaat blijkbaar alleen over techniek. Daarom stel ik dat ict-projecten falen omdat het ict-projecten zijn.
 
Het zou al een stuk beter gaan wanneer we het hebben over zakelijk verantwoorde projecten met een ict-component.

Leren van fouten van anderen, beschreven in 1982. Het stukje lijkt wel geschiedenisles van Aart van Dijk. ik ben van mening dat er nog heel 'Passievolle' project-mananagers zijn, die goed luisteren, doorvragen, en dagelijks veel gebruikers zeer tevreden maken met schaalbare oplossingen. Doe aanvullend eens een comunicatieonderzoek vanuit de opdrachtgever, want zelfs al zijn (ict-)projecten omschreven in Tender, het kan altijd fout gaan in de communicatie. En zijn we dan niet betrokken?

Er zijn ook projectmanagers die wel leren van eerdere fouten.

Sommige projectmanagers leren inderdaad niet van hun fouten maar de meeste wel. Echter de opdrachtgevers leren niet van de fouten en sturen alleen maar op budget en willen voor een dubbeltje op de eerste rang zitten.

Goh echt. Zelfs niet na een Prince of IPMA certificering
Geloof mij, project management heeft alles te maken met je boerenverstand gebruiken en nuchter te blijven. Gewoon sturen op tijd (planning) en geld (budget). Bij eventuele tijdsoverschrijding gewoon eerlijk zijn en niet blijven liegen dat het allemaal wel goed komt.
 

Aart van Dijk redeneert vanuit een werkelijkheid waarin goed en fout duidelijk gedefinieerd zijn. In de werkelijkheid is dat niet zo.
 
Opdrachtgevers willen geen reëel beeld geven van investeringen, omdat projecten anders geen doorgang vinden. Oopdrachtnemers willen graag projecten binnenhalen, waarbij op prijs wordt beoordeeld.
 
Requirements liggen vrijwel nooit vast, omdat dat bijna niet te doen is en wijzigen gedurende de rit om goede redenen.
 
Ict-afdelingen hebben andere doelen dan business-afdelingen en operationeel wordt anders tegen zaken aangekeken dan op de werkvloer.
 
De 129 factoren uit het proefschrift zijn allemaal bekend en beïnvloeden het resultaat. Het is echter maar de vraag of iedereen voor hetzelfde resultaat gaat.

Sturing op tijd en geld? Randstadrail faalde voorspelbaar omdat er alleen op tijd en geld werd gestuurd. Heathrow T5 eindigde ook op tijd en binnen budget. Ook hier speelt weer het thema 'leren'.
Al ongeveer twintig jaar geleden wees onderzoek in Australië uit dat alle projecten die op tijd en geld eindigden vijf jaar later werden gezien als falend.
 
Sturen op tijd en geld alleen is een variant op het thema van doel en middel verwarren.

De opdrachtgevers hebben vaak boter op hun hoofd. Lekker uitbesteden aan een derde partij. Dan zijn zij van de verantwoording af.
Die kunnen dat vaak zelfs niet met de beste wil van de wereld managen, maar het levert gelukkig wel een dikke boterham op.

Ik denk dat op de eerste plaats de fouten die de projectmanager heeft gemaakt door hem zelf zullen moeten worden onderkend. Zodra het besef er is kan hij deze in toekomstige situaties voorkomen. Een project manager is ook maar een mens...
 
Er is nog een verzachtende omstandigheid. Ieder project is uniek. Hoezeer is de projectmanager in staat om ook in een geheel andere situatie, setting, dezelfde optredende fouten tijdig te herkennen en te voorkomen, dan wel op te lossen? Niet dat het hem vrij pleit om niet te leren van zijn fouten, maar de kans bestaat...

Het niet leren van fouten kan op elk gebied geplaatst worden. De kop is dan ook niet bijzonder.
 
Kijkende naar de internationale certificering en de steeds zwaarder wordende competentie modellen voor de projectmanagers dan kan je niet zeggen dat ze het vak niet begrijpen of de deskundigheid missen. Als dat zo is dan moeten alle PRINCE2, IPMA en PMI opleidingen herzien worden.
 
Verder wordt niet duidelijk wat nu verstaan wordt wat nu een mislukt project is? Als het project vanaf start met een gedegen wijzigingsprocedure aan kan geven en verklaren dat zij uit de oorspronkelijke stuurmiddelen (Scope, Tijd, Budget of Kwaliteit) zijn gelopen, dan is dit voor mij geen mislukt project.
 
Ook is het logisch dat iets kleins overzichtelijker is. Daar heb ik geen onderzoek voor nodig. Grote projecten hoeven ook geen problemen om te leveren. Je kan een project indelen in meerdere fases en daarmee e.e.a onder controle en sturing te houden. Zie onder PRINCE2 2009 tailering projecten.
 
Tja, en wat is nu groot?
 
Waar ik het wel mee eens ben is de slechte communicatie met...(niet alleen opdrachtgevers),onvoldoende betrokkenheid van de toekomstige gebruikers en het gebrek aan toewijding bij het senior-management.
 
Kortom, op basis van het artikel ben ik niet van mijn stoel gevallen. Ik zal kijken of ik meer wetenschap kan vinden bij deze promovendus waar ik misschien wat aan heb en nieuw/bruikbaar is voor mij.
 
John Roos
06 81430098
 

Interessant artikel. De nieuwe lichting ict-projectmanagers leert niet van de fouten die anderen eerder hebben gemaakt. Dat klopt in het algemeen. Dit zegt veel over hoe het lijnmanagement (en accountmanagers van de detacheerders) nog steeds (deel)projectleiders door laten stromen naar de positie van projectmanager en over hun gebrekkige begeleiding.
De young potentials worden te vaak snel op een voetstuk gezet om ze daarna aan hun lot over te laten. Bij elke stap in je loopbaan kun je hulp gebruiken. Opdrachtgevers moeten niet alleen de juiste mensen kiezen, maar ze ook in staat stellen om te leren de opdracht goed uit te voeren. Veel zaken leer je pas goed door ervaring. Bij een cursus leer je vooral technieken, maar weinig hoe je als persoon om moet gaan met nieuwe uitdagingen.
De kaalslag onder de ervaren, te 'dure' projectleiders heeft vele kostbare flops opgeleverd. Die ervaren projectleiders zien veel eerder dat de projectsituatie niet klopt. Ze durven dit ook te zeggen omdat ze dit niet als hun eigen falen zien, maar als een gemeenschappelijk probleem.
Opdrachtgevers leren net zo min van de fouten bij ICT-projecten. Toch zijn zij niet alleen in formele zin de eindverantwoordelijke. Opdrachtgevers moeten er voor zorgen dat de startsituatie voldoet aan de eisen van het project, dat de verdere communicatie met de projectleden goed is, dat de gebruikers, beheerders, betrokken blijven bij het project, et cetera.
Ict-projecten zijn bedrijfsprojecten. Maar vooral ict-projecten zijn vaak slecht gefundeerd omdat ze niet tot de core business van de opdrachtgever horen. Veel ict-projecten zijn niet eens projecten, maar een nog uit te werken ict-programma, een ict-experiment, of slechts een opgeblazen illusie met een ict-component. Opdrachtgevers zouden in veel gevallen niet eens het startsein voor een project moeten geven omdat het geen echt project is, de business case niet deugt, enzovoorts.
 
Kortom:
- Projectleiders moeten niet te snel doorstromen omdat ze relatief goedkoop zijn, maar moeten de tijd krijgen om zich te ontwikkelen tot goede projectmanagers.
- Ervaren projectmanagers moeten voor de arbeidsmarkt behouden blijven.
- Opdrachtgevers moeten leren hoe een project met een ict-component te definiëren en hoe deze goed aan te sturen.
- Aankomende ict-projectmanagers moeten leren wat (= hoe weinig) het algemene management weet van projecten met een ict-component.

Een methodologie als Prince2 kan een mooie kapstok zijn om een project aan te hangen, maar het geeft geen houvast aan de projectmanager op cruciale aspecten zoals planning en communicatie. En het is juist bij deze aspecten dat de meeste projecten de mist in gaan.

Projectmanagement zal nooit een exacte wetenschap worden, maar is overgeleverd aan de mate waarin een PM in staat is de welbekende best practices op maat toe te passen. Daarbij zijn best practices niet eeuwig houdbaar, ook die zijn onderhavig aan voortschrijdend inzicht.

Dit artikel roept bij mij meer vragen op dan dat het antwoorden geeft.
Wie bepaalt of een project faalt? Welke objectieve criteria zijn daarvoor vast te stellen, onafhankelijk van het perspectief van de (be)oordeler? Hoe is eenduidig vast te stellen wie wanneer verantwoordelijk was voor de gemaakte "fouten"?
 
Nogal wiedes ook dat eenvoudige projecten (met minder activiteiten en kortere doorlooptijden) minder problemen met zich meebrengen dan complexere projecten (met meer mensenwerk, meer communicatiemomenten, meer omgevingsfactoren en langere doorlooptijden en dus meer kans op externe invloeden en wijzigende verwachtingen).
 
Ik geloof niet in checklists die proberen de toekomst te voorspellen of fouten te voorkomen (zie "The Black Swan" van Nicholas Taleb). Het is achteraf (met de wetenschap van vandaag...) makkelijk te verklaren waarom een bepaalde keuze niet juist heeft uitgepakt, en te concluderen dat we met een andere keuze een betere uitkomst zouden hebben gehad.
De checklist kan verworden tot een doel op zich, en dat heeft tot gevolg dat het resultaat/doel van het project ondersneeuwt. Of dat het project dan maar geannuleerd of uitgesteld wordt, wat dikwijls ook geen wenselijke conclusie is..(?)
 
Het is (en blijft) kortom de taak van de opdrachtgever en de opdrachtnemer om een evenwicht te vinden in pragmatisme en controle, en het gezamenlijk aanvaarden van de consequenties van gemaakte keuzes - inclusief de openheid van communicatie en de keuze voor de in te zetten project manager(s).
Het is (en blijft) de taak van de project manager om met de hem/haar ter beschikking staande kennis, ervaring en middelen (inclusief methodieken zoals Prince en PMBOK) het project te managen, en aan begin en eind van het project een kritisch (self-)assessment uit te voeren.

Kan je leren van een boekje? Leren doe je volgens mij door iets voorgedaan te krijgen, dan zelf te doen onder begeleiding en dan zelfstandig te doen. Neem als (te onervaren) projectmanager dus niet te veel hooi op je vork. Ambitieus zijn is niks mis mee, maar organiseer hulp als je dat nodig hebt.

Projectmanagers moeten inderdaad leren van hun fouten en sommige kunnen dat ongetwijfeld beter dan anderen...
 
Echter enige nuance is ook op zijn plaats; een projectmanager rapporteert altijd aan een stuurgroep en of directie van de uitvoerende kolom. Helaas heb ik bij diverse grote ICT bedrijven schrikbarende uitvoerende directeuren en verkoop directeuren meegemaakt; als deze types geen kaas gegeten hebben van projectmanagement, worden de PM-ers simpelweg overruled wanneer zij aan de bel trekken om zaken die niet goed lopen aan te kaarten (vaak moet dit in samenspraak met de klant) en oplossingen uitwerken. Als de directies hun kop maar lang genoeg in het zand steken (of alleen maar kunnen roepen dat het moet worden 'af-gemanaged'), dan ontploft het project vanzelf, waarbij de projectmanager wordt aangewezen als boosdoener, alleen ben ik helaas in de werkelijkheid zowel bij klant als leverancier teveel directeur-tjes tegengekomen die domweg niet luisteren of ingaan op de wensen van de PM om de doelstellingen wel te halen.. dit frustreert alleen maar en maakt het vaak onmogelijk om grotere projecten succesvol af te ronden... Jammer maar zo werkt de IT markt in Nederland, de PM-ers verdwijnen, en de incompetente directeurtjes blijven zitten....

Hele treffende reacties die ik hierboven lees. Mensen die denken dat een PM iemand is die de verantwoording overneemt van de opdrachtgever, dat de PM bepaalt wat er gaat gebeuren, dat hij/zij de oplossingen bedenkt. Terwijl de baan van PM eigenlijk simpel(?) is: manage het project zijnde het transitieproces door te structureren binnen een projectstructuur met de juiste personen, de juiste stakeholders, door voortdurende gerichte communicatie en beslissingen daar te leggen waar ze horen: bijde opdrachtgever. Simpel toch?
Nu nog even doen en het lef te hebben om opdrachtgever ook de verantwoording laten BLIJVEN dragen......

Als kleine aanvulling lijkt het me ook dat - naast de projectmanager en opdrachtgever - de betreffende ICT-onderneming niet lijkt te leren van eerdere fouten.
 
Het verbaast me zeer als ik constateer dat er nieuwe offertes gemaakt worden zonder een compleet afgewerkte checklist en het project kan dan de brokken opruimen, exeptions produceren etc.

Artikel dat de andere kant belicht maar dan vanuit beheer gezien:
 
http://www.computable.nl/artikel/ict_topics/beleid/3287121/2379250/beheer-heeft-goed-opdrachtgeverschap-nodig.html

Is dat proefschrift ergens digitaal te vinden? Ik ben namelijk beneiuwd naar wat daar instaat. Ik kan moeilijk een mening vormen aan de hand van dit korte Computable stukje.

Wat ik mis in dit artikel en alle reacties, is dat de projectmanager zelf maar een zeer beperkte invloed heeft op hoe hij zijn projecten bestuurt. Vaak staat de scope, de datum en het budget al vast en zijn de contractuele randvoorwaarden vastgezet. Daarna mag hij pas aan de slag.
 
Het is dus niet de projectmanager die het resultaat bepaalt want een belangrijk deel van het succes ligt in de handen van de organisaties zelf: de stuurgroepleden, de contractmanagers en de juristen.

Anko Tijman, een projectmanager bepaalt "scope, de datum en het budget" van de projecten die een (deel)projectleider mag uitvoeren.
Als je die rechten niet hebt, dan moet je de titel projectmanager niet aanmeten en ook niet de verantwoordelijkheid op je nemen.
 
Als je als (deel)projectleider niet met de GOKIT-factoren kan leven, dan ga je samen met de projectmanager naar een oplossing zoeken. De projectmanager moet er voor zorgen dat het (deel)project kan worden uitgevoerd. Nadat dit geregeld is, kan de deel)projectleider er alsnog voor zorgen dat het project goed uitgevoerd wordt.
 
Als je gedetacheerd wordt of projectleider van de leverancier bent, dan moet je eerst naar je accountmanager stappen en deze vertellen dat deze namens de opdrachtnemer een probleemopdracht heeft aangenomen. Dan kan daarna met z'n allen naar een redelijke oplossing gezocht worden. Als je accountmanager en diens baas hier niet aan willen meewerken, zoek dan een goede werkgever.
 
Niemand heeft baat bij het verzwijgen of ontkennen van een probleem en dus bij een valse start van een project.

Fantastisch die reacties. Nagenoeg alle reacties snijden hout. De meeste genoemde punten komen aan bod in het proefschrift. In dit artikel kan de journalist natuurlijk slechts een tipje van de sluier oplichten. Het proefschrift omvat 520 pag.
En natuurlijk zijn er ook veel succesvolle projecten!

Wat ik in de discussie nog mis, is het volgende. De projectmanager (PM) leert vaak wel degelijk "the hard way", maar deze kennis, verpakt in een boodschap, wil iedereen lang niet iedereen altijd horen. Vaak komt de PM klem te zitten tussen OG en andere belanghebbenden bij het al of niet welslagen van het project en de wijze waarop deze volgens hem/haar tot stand moet komen. De PM wordt heel vaak niet gehoord in zijn boodschap hoe het wel te doen. Dit past niet, kost te veel (geld, tijd), dat resultaat leveren we later met een ander deelproject op, etc.
 
Neemt niet weg, dat de meeste projecten een evaluatiefase kennen (decharge), dit ook nog gedocumenteerd en ontsloten wordt, maar meestal niet ter kennis wordt genomen bij het opstarten van andere projecten door andere PM'ers. Een gemiste kans!

Project management is slechts nuttig indien het een bepaald doel dient; het doel van een IT project moet altijd zijn om uiterlijk (liever eerder) binnen 8 a 10 maanden (deels) in productie te gaan. De toets van IT projecten is niet het project management, maar het slagen van de applicatie in de praktijk. Overschrijding van de 8 a 10 maanden betekent: stoppen van het project.

Een project wordt gestuurd op meer dan alleen tijd en geld. Er zijn vier stuurelementen: tijd, geld, kwaliteit en scope. Een wijziging in 1 van deze 4 heeft invloed op 1 of alledrie van de overige. In dat spanningsveld moeten PM, opdrachtgever en leverancier blijven acteren. Dat er niet geleerd zou worden, vind ik een vrij baude uitspraak, maar dat het beter kan dan nu in het algemeen bij de uitvoering van projecten daar ben ik het wel mee eens. Projectmanagement wordt meer en meer een echt vak en daarin zie je ook een professionalisering van de PM's. De lessen worden wel geleerd, maar we zijn er nog (lang?) niet.

Tijdens mijn studie heb ik veel over IT projectmanagement geleerd. Daarbij kwamen alle genoemde punten wel aan bod en achteraf gezien is projectmanagement toch wel het een van de best onderwezen delen van de opleiding geweest.
 
Nu werk ik 'onder' een of andere bozo die een hogere (WO) studie heeft gedaan en 'ervaring' heeft als projectmanager.
 
Projecten falen natuurlijk in alle opzichten en ik weet hem als het echt uit de hand loopt wel te overtuigen dat een bepaalde maatregel toch echt nodig is. De keer dat ik dat niet heb gedaan werd de schuld doodleuk afgeschoven op een gestresste en al overwerkte collega...dat zijn geen leuke ervaringen.
 
Dat verwijt ik de projectmanager niet eens zozeer, maar wel degene die hem aan heeft genomen en er nog steeds van overtuigd is dat deze persoon zijn/haar werk uitstekend doet.
 
Het is me na een aantal pogingen wel duidelijk dat ik zelf op de markt met alleen mijn diploma als kandidaat voor (zelfs junior) projectmanager niet serieus genomen wordt.
 
Maar wat zegt ervaring als er projectmanagers rondlopen die duidelijk niet willen leren en directeuren die niet objectief beoordelen? Lang leve de netwerkmaatschappij...

Developer, misschien kent jouw projectmanager de theorie van projectmanagement heel goed en heeft hij alle kans gehad om de theorie aan de praktijk te toetsen, maar wil hij helemaal geen projectmanager zijn. Misschien wil hij gewoon hogerop komen en gebruikt hij daarvoor een soft spot van de directeur. Dan hoeft hij niet eens de skills van een projectleider te ontwikkelen en mag hij zich straks projectdirector of CIO noemen dankzij zijn skills die jij niet bij je studie geleerd hebt.
 
Daar kan je ook veel van leren, maar zorg er voor dat je bijtijds ergens anders komt. Van positieve ontwikkelingen leer je meer nuttige zaken. Zaken kan je vaak op meerdere manieren goed doen, maar op ontelbare manieren fout.

Weledelzeergeleerde Heer Van Dijk,
 
allereerst wil ik u feliciteren met uw promotie / titel van Doctor of Engeneering.
 
Ik ben, vanuit vaktechnisch oogpunt, zeer geïnteresseerd in het proefschrift en de daaraan verbonden conclusies en waar mogelijke verbeterpunten liggen.
 
Ik ben wel bereid te leren van mijn “eigen”, maar ook andermans, eerder gemaakte fouten om uiteindelijk effectievere en efficiëntere ICT-projecten te kunnen begeleiden c.q managen.
 
Ik zou u dan ook bij deze willen vragen of u mij dit proefschrift ( in digitale vorm) zou kunnen toezenden of op welke andere manier ik uw proefschrift zou kunnen bemachtigen.
 
Bij voorbaat bedankt voor uw respons,
 
Hoogachtend,
 
Eric Klaver

Het artikel legt teveel focus op de rol van projectmanager voor het succes en falen van een project. Daarmee zeg ik niet dat de projectmanager geen belangrijke rol zou hebben. Te vaak merk ik dat de projectmanager centraal staat in dit vraagstuk, naast de projectmanager zijn er meer personen verantwoordelijk voor een project. Aart van Dijk stelt dat 'veel Projecten zijn te ambitieus en de oorzaak ligt bij het gebrek aan deskundigheid in het vakgebied'
Wie maakt een projectdoelstelling ambitieus? De organisatie die de opdracht verstrekt, de stuurgroep of de projectmanager?. In mijn beleving zijn alle drie verantwoordelijk voor het ambitieniveau. Projectmanagers moeten hun vak beheersen bijhouden. Dit geldt eveneens voor opdrachtgevers en stuurgroepleden? Maar, hoe deskundig zijn deze laatstgenoemde functionarissen? Uit onderzoek is gebleken dat de meeste deelnemers aan bijvoorbeeld Prince2 trainingen projectmanagers en projectuitvoerders zijn. Opdrachtgevers en stuurgroepleden scholen zich veel minder op het gebied van projectsturing/-beheersing. Veel organisaties worden zwaar belast met een hoge mate van veranderingen. Projecten worden met veel ambitie gestart. Door het vaak ontbreken van een integraal overzicht, portfoliomanagement & resourcemanagement, zijn projecten gedoemd te mislukken. Project scenario’s worden vaak beoordeeld vanuit de projectdoelstelling met een hoge verwachting over 'short time to market & low cost'. Beter zou zijn om scenario’s te beoordelen vanuit een bredere scoop, portfolio en beheersbaarheid. Projectmanagers zouden zich onafhankelijker kunnen opstellen ten opzichte van de opdrachtgever en meer moeten staan voor de werkelijkheid en niet zaken mooier maken dan dat ze zijn. Transparantie en voorspelbaarheid zijn hier voor mij sleutelwoorden. Goede voorbereiding en “start up”, staan vaak onder druk door het ontbreken van een tactisch inzicht bij de opdrachtgevers (portfoliomanagement) en hoge operationele sturing. Dit maakt het voorspelbaar maken alleen maar lastiger. Aart stelt verder dat projectmanagers te weinig leren van hun fouten en dit kan ik alleen maar bevestigen. Organisaties dienen een klimaat te creëren waar fouten gemaakt mogen worden en waar openlijk gesproken kan worden over deze fouten. Door deze aanpak ontstaat er ruimte om te leren.
In de laatste tien jaar is het ene na het andere projectbesturingsmodel geïntroduceerd. Het adopteren van een dergelijk model is niet zaligmakend. Er moet veel meer gebeuren om projecten succesvol te laten zijn. Projecten worden succesvoller wanneer organisaties zich meer inrichten op projecten. Ik wil afsluiten met de vraag waarom lijkt het dat projectmanagers helderziende moeten zijn. De drang naar zekerheid drukt realisme weg. Wat maakt het zo moeilijk om te gaan met voortschrijdend inzicht. Omgaan met voortschrijdend inzicht en voorspelbaar zijn vraagt om kleinere trajecten en of dit nu meerdere kleinere projecten zijn of fases van een project is niet relevant. In ieder geval is de projectmanager geen helderziende, hij/zij heeft te dealen met voortschrijdend inzicht. Het zou ons allen helpen als opdrachtverstrekkers, stuurgroepleden en projectmanagers gezamenlijk gaan optrekken en de realiteit niet schuwen. En wellicht zit hier ook het verbeteren van Business alignement.

Beste Eric Klaver,
 
Leuk dat je belangstelling hebt voor mijn proefschrift.
Geinteresseerden kunnen mijn proefschrift aanschaffen door het storten van € 78, - op giro 644362 t.n.v. Avdede-Info bv te Zoetermeer.
Svp afleveradres vermelden.
Veel succes er mee.
Mocht je nog vragen hebben, laat het me weten
(aart.vandijk@planet.nl).