Wat zorgt er voor dat de laatste stap in het proces van de realisatie van een project ”live gaan en het krijgen van decharge” niet wordt gezet; wat houdt de opdrachtgever tegen?
In de praktijk is het vaak eindeloos zwoegen om een plan voor een verandering of implementatie van een pakket te kunnen afronden. In de voorbereiding lijkt alles goed te gaan, de gevoeligheden in de duivelsdriehoek (tijd, kwaliteit en geld) zijn in kaart gebracht, de scope van de opdracht is bepaald en goed bewaakt gedurende de rit en dan toch op het allerlaatste moment, als puntje bij paaltje komt, neemt de opdrachtgever niet het besluit om de knop om te zetten. Wat zorgt er voor dat de laatste stap in het proces,' live gaan en het krijgen van decharge', niet wordt gezet; wat houdt de opdrachtgever tegen?
1 ) contractuele problemen; de opdrachtgever en opdrachtnemer hebben toch interpretatieverschillen of andere verwachtingen van hetgeen geleverd zou worden. Op het laatste moment realiseert de opdrachtgever zich dat als hij de knop omzet er geen weg meer terug is en de gebruikers/klanten over hem/haar zullen vallen. De situatie kan zich dan voordoen dat het project wel 'live' is gegaan maar decharge niet wordt gegeven omdat sturing op het team daarna ontbreekt. Het projectteam kan eindeloos blijven bungelen en geen nieuwe uitdagingen aangaan. Ga terug om de tafel zitten, gebruik de offerte als checklist en definieer samen welke aspecten opgelost moeten worden, wat dat eventueel gaat kosten in tijd, kwaliteit en geld. Bespreek samen waarom dit argument nu pas wordt opgebracht en leer er met z’n allen van.
2 ) timing ongunstig; een product heeft in de ontwikkelingsfase wat vertraging opgelopen of plotseling blijkt er een reden om toch nog even extra uitstel te vragen. Meestal vinden dit soort vertragingen hun oorsprong bij Marketing en Communicatie. Bijvoorbeeld omdat een concurrent net een (beter?) product heeft gelanceerd, het bedrijf al onder vuur ligt in de media en geen nieuws over kinderziektes in jouw product kan gebruiken . Bij het ter beschikking krijgen van een product is het op het juiste moment aandacht vragen voor het product van groot belang. De Stemwijzer moet een paar weken voor de verkiezingen 'live' zijn, daarna heeft het geen zin meer. Als je doelgroep op vakantie is of met andere dingen bezig (reorganisatie, ander groot project) vergeet het dan maar. Bespreek bij elke afwijking van de planning (dus zo vroeg mogelijk in het project) wat de consequentie is voor de oplevering, wat wel een gunstig moment is en of je tot die tijd beschikbaar moet zijn. Probeer waar mogelijk harde deadlines af te spreken met de opdrachtgever. Jij kan het niet helpen dat er vertraging is, in veel gevallen kan men de decharge geven en het 'live' gaan nu ook wel zonder jou afhandelen.
3 ) technische problemen; de verandering of implementatie van een pakket is op de tekentafel vaak fantastisch maar zodra er allerlei testen op worden losgelaten of deze 'op proef' wordt doorgevoerd, blijkt er nog van alles aan te mankeren of niet te voldoen aan de vooraf gedefinieerde kwaliteitseisen. Dit zorgt vaak voor uitstel, het niet verlenen van decharge of zelfs terugdraaien van het project tot het moment dat de bugs'' , 'showstoppers' of andere onvolkomenheden (undocumented features) zijn opgelost. Kan de opdrachtnemer het zelf oplossen dan kan het snel gaan, maar ben je afhankelijk van een andere leverancier (bij standaardpakketten nogal eens het geval) dan rest je niets anders dan de volgende release af te wachten of 'live' te gaan met een halffabricaat. Uitstel of tijdelijke opschorting van het project lijken de enige reële opties. Zorg dus vanaf het begin van de opdracht dat de opdrachtnemer precies weet wat er te verwachten valt, wat kom je brengen, meld problemen direct en beloof geen dingen die je niet waar kunt maken. Het kost jezelf meestal uiteindelijk geld en imagoschade omdat je de kwaliteit niet levert die je hebt beloofd en alles veel langer gaat duren.
4 ) financiële problemen; om de verwachtingen tussen opdrachtgever en opdrachtnemer in evenwicht te brengen is vaak meer inspanning en tijd nodig. Die moet betaald worden en dat geld is niet altijd beschikbaar. Zeker als een 'fixed fee' is afgesproken levert dit nogal eens problemen op. Het dilemma voor de opdrachtgever dient zich aan tussen genoegen nemen met een kwalitatief niet optimaal product of uitstellen tot dat er nieuw budget beschikbaar is/komt. Ook hier mag je hopen dat je in de voorbereiding genoeg over dit soort zaken hebt besproken en vastgelegd om samen met de opdrachtgever na te lopen of de verwachtingen terecht zijn. TIP: denk hierover na tijdens het offerte fase, wees reëel over de te verwachten kosten en onzekerheden in de aanbieding, neem 10 tot 25 procen extra marge op in de begroting voor onvoorziene zaken, die doen zich altijd wel ergens in het project voor, dat voorkomt een hoop ellende achteraf.
5 ) gebrek aan vertrouwen; misschien wel de meest hardnekkige en ongrijpbare factor in deze is gelegen in de menselijke psyche. Zodra de opdrachtgever het gevoel heeft dat hij onvoldoende credits zal krijgen in zijn eigen organisatie voor hetgeen hij oplevert bij 'live' gaan, zal hij elk argument aangrijpen om uitstel te eisen/vragen. Ook kan het product bij nader inzien gewoon niet bij de klant passen, niet de juiste actie op het juiste moment zijn of de verwachtingen niet waarmaken. Het kan gebrek aan zelfvertrouwen zijn, aan vertrouwen in de kwaliteiten van de opdrachtnemer of aan het product. In veel gevallen is dat voor de opdrachtnemer volkomen ondoorzichtig. Het product is immers volgens de afspraak binnen tijd, kwaliteit en budget opgeleverd, binnen de scope die vooraf is bepaald en dan nog komt de decharge aan het team niet omdat men niet durft? TIP: neem als opdrachtnemer de tijd om na te denken of het product bij de organisatie past en bespreek je twijfels met de opdrachtgever. Neem communicatie met de organisatie zeer serieus (je kan niet genoeg communiceren!) en sta open voor signalen dat er mogelijk toch onvrede met het op te leveren product is. Bespreek dit zodra je dit hoort met de opdrachtgever dan kunnen jullie samen interventies bedenken om het probleem tijdig te tackelen. Alle mogelijkheden moeten op tafel komen van het kwalitatief laten toetsen door een derde van het op te leveren product tot een simulatiespel om de realiteit zo goed mogelijk na te bouwen, elk idee dat bijdraagt aan het wegnemen van de onzekerheid helpt.
Wat te doen als opdrachtnemer als je alles goed gedaan hebt en toch niet 'live' gaat? Ga het gesprek aan met de opdrachtgever, vraag om de reden en bespreek deze, vraag decharge ook al is het besluit tot uitstel genomen. De organisatie moet nu zelf over de ‘koudwatervrees’ heen komen. Uiteraard kan je met een checklist aantonen dat je hebt opgeleverd wat was gevraagd, je kunt met begeleiding van gebruikers of cursussen de interne credits proberen op te voeren. Een project doe je samen en het behoudt van de relatie tussen en reputatie van beide partijen staat op het spel, dus wees voorzichtig.
En soms, heel soms, als het een mislukt project of experiment betreft, is het beter om inderdaad niet 'live' te gaan. Daarvoor geldt dan het oud-Hollandse spreekwoord 'beter ten halve gekeerd dan ten hele gedwaald'.
Wanneer je als project ook het beheer organiseert en uitvoert….van de nieuwe communicatie-infrastructuur, dan is live gaan minder een probleem, want het is onderdeel van je project en een onderdeel van de staande organisatie.
Je bent dan niet alleen verantwoordelijk voor de overgang, maar ook voor alles wat er uit voort vloeit. Tevens ziet de organisatie dan zonder de verantwoordelijkheid te dragen wat het echte eindresultaat is.
interessante gedachte Maarten. Doel je op een PPS achtige constructie, waarbij je je voor langere tijd aan elkaar verbind?
Mijn ervaring is dat dat heel goed kan werken. Maar het vraagt wel veel vertrouwen, met name aan de opdrachtgevende zijde; zowel in het proces als in de relatie. Beide partijen moeten niet het onderste uit de kan willen halen (dubbeltje eerste rang vs winstmaximalisatie) en – minstens zo belangrijk – heel duidelijk meetbare doelen stellen.
Heb jij ervaringen (best practices) waaruit blijkt dat dit werkt? Ben ik erg benieuwd naar, want nu houden we elkaar vooral in een houdgreep.
@Tom,
de ervaringen die ik heb als projectmanager van grote communicatie-infrastructuur projecten zijn, dat enerzijds de organisatie waar je het project organiseert, implementeert en runt, de kat uit de boom wil kijken:
klopt het eigenlijk allemaal wel wat het project gedaan heeft,
wordt het niet over de schutting gekieperd
als het project met de overgang opgedoekt wordt hebben we geen verhaal
staande organisatie heeft nog het beheer van de oude infra en dus eigenlijk gene tijd en na 10 jaar nieuw is soms een “shock”.
en ja het kan ook in pps constructie en ook dat gaat goed. Daarnaast het is tevens het bewijs dat de communicatie infrastructuur goed geland is als het beheer na de overgang goed loopt, gedocumenteerd geborgd etc is.
Je vraagt je soms af waar de negatieve insteek vandaan komt, met name bij ICT projecten. Je draait een heel project, de organisatie investeert veel geld en tijd en het projectmanagement levert issue en andere rapportage bij de stuurgroep aan tijdens het project.
En dan zal je bij live gang niet doorzetten? Dan heb je een mislukt project, falende sturing en je werk als projectleider niet goed uitgevoerd.
Projecten moeten als vanzelfsprekend in productie gaan en als dat niet het geval is dan dient de stuurgroep al veel eerder maatregelen te treffen om het einddoel te behalen.
Argumentatie voor de finish zal vrees ik altijd onvoldoende blijven. Gelukkig of eigenlijk jammer genoeg zijn bestuurders mild, doorgronden de problemen niet en accepteren uitloop in alle varianten, tijd, geld en kwaliteit. Opdrachtgevers dienen vooral zichzelf in de spiegel aan te kijken.
Ik lees in dit artikel een aantal zaken die (naar mijn mening) door elkaar gegooid zijn! Verder lees ik verschillende scenario`s waar al in een Prince2 aanpak een oplossing of werkwijze voor bedacht is. Ik kan me niet voorstellen dat een projectmanager vandaag de dag geen Princ2 opleiding gedaan heeft!
Punt 1: Het is de taak van PM om in de initiatiefase een duidelijke PID op te stellen. Hoe meer duidelijkheid in dit document hoe minder ellende tijdens het project. Als de opdrachtgever op het laatste moment zich realiseert dat …… dan is het jouw probleem niet. In het PID is duidelijk aangegeven wat de oplevering van het project is. Wat daarna met het product gaat gebeuren (sturing, ondersteuning etc) is ook jouw zorgen als PM niet! Dat had al in business case of haalbaarheidsonderzoek door de opdrachtgever uitgezocht moeten worden. Dus ….ik snap het advies en aanpak van schrijfster voor dit punt niet!
Punt 2: Ben je ervaren projectmanager? Dan moet je al weten dat je bij elke gebeurtenis het effect daarvan op verschillende onderwerpen van het project moet analyseren. Ik heb het over risico management! Als uit deze analyse blijkt dat je het project beter moet stop zetten of je meer geld nodig hebt of de kwaliteit naar beneden gaat of …. dan leg je dit aan de opdrachtgever voor en vraag je om zijn mening en keuze. Dus What`s news in dit punt en tip? Risico management hoort bij je vak als projectmanager!
Punt 3: als je je project in fases opdeelt dan heb je bij een faseovergang een toetsing voordat je het product naar volgende ontwikkelingsfase mag brengen. Als uit deze toetsing blijkt dat het product niet aan verschillende kwaliteitsnormen of afspraken voldoet dan moet je als PM en of leverancier dit oplossen, PUNT. Als je als PM in de initiatiefase zaken tegen komt die door sales beloofd zijn en verkocht zijn terwijl je ziet dat ze niet waar gemaakt kunnen worden(voordat je aan de uitvoering begint) dan ga je naar je organisatie terug en leg je het probleem voor. Dit is in de beginfase van het project en ver van “live “ gaan! Als je pas later en dichtbij live gaan erachter komt dat je de zaak niet waar kan maken dan moet je je afvragen of je als PM of je organisatie als een ict leverancier geschikt zijn om dit vak uit te oefenen.
Punt 4: Dit is juist de uitdaging van de ict-projecten vandaag de dag! Dit zien we vaak bij de aanbestedingen van de overheid. Tip van de schrijfster wordt al toegepast en is zeker bij de sales bekend! Maar toch lost dit het probleem niet op! Mijn tip? Die heb ik niet als het om aanbesteding en fixed price projecten gaat. Succes!
Punt 5: Raar punt! Wat heeft het probleem van opdrachtgever en zijn organisatie met jouw werk als PM te maken? Je hebt je producten opgeleverd zoals het in het PID stonden. Het eind product voldoet aan de eisen zoals het in kwaliteitscriteria beschreven stond. Dus? Tip: maak van het probleem van de klant geen eigen probleem!
P.S. ik ben het met reactie van Willem zeer eens!
Beste lezers, allereerst dank voor jullie reactie op mijn stuk. Ik heb dit artikel geschreven omdat ik al deze verschillende redenen om geen decharge te krijgen zelf of in mijn directe omgeving heb meegemaakt of zie gebeuren. Alle Prince2 of andere projectleidersopleidingen ten spijt. Natuurlijk kan je veel voorkomen door je aan de vaste uitgangspunten van de methodiek en structuur van je projectplan te houden, maar we werken ook met mensen. Mensen die vaak geen idee hebben hoe een ICT gerelateerd project voor hen zal uitpakken, waarbij de projectleider aan de kant van de business wel weet wat hij wil bereiken maar geen idee heeft hoe dat te bereiken. Mijn artikel is dan ook een pleidooi om een ICT project te zien als een veranderproject. Dat wil zeggen dat het zoeken naar de noodzaak voor de verandering, het zoeken naar draagvlak op alle niveaus in de organisatie en vooral communicatie centraal zouden moeten staan. En het mag niet verbazen dat juist dit vaak de oorzaak is van veel ellende. We communiceren wel als ICT-ers met staatjes en voortgangsrapportages maar vragen we ooit hoe de ‘arme’ toekomstige gebruiker zich voelt of wat de projectleider/owner in de business eigenlijk verwacht en of dat nog steeds door ons gerealiseerd wordt? Ik kom te vaak tegen dat we netjes langs de lijnen van het projectplan lopen en ons niet realiseren dat het resultaat van onze activiteiten gebruikt moet gaan worden door mensen van vlees en bloed. En ja Reza, die hebben twijfel, die durven soms gewoon even niet omdat de organisatie meer verwacht dan wij leveren.
Beste Anja,
Er is een verschil tussen het uitvoeren van een project als externe projectleider en interne projectleider. De spelregels in deze twee situaties zijn zeer verschillend. Mijn vraag is, waar ben je in je artikel vanuit gegaan? In het begin van mijn reactie gaf ik aan dat ik een aantal zaken door elkaar gegooid zie. Dit is er een van.
Een externe PM heeft als doel om de zaken die later in PID aangegeven en vastgelegd zijn binnen de gestelde tijd, budget en kwaliteit op te leveren. Dit is de business case van de externe PM en is heel anders dan business case van de organisatie die een ander doel heeft met het uitvoeren en resultaten van het project.
Juist omdat ict-projecten een verandering teweegbrengen is het belangrijk dat er eerst een haalbaarheidsonderzoek in fase-0 uit te (laten)voeren om te weten wat het effect van deze verandering op de organisatie(gebruikers & beheer), productie, business etc is. Dit is de taak van de opdrachtgever. De resultaten van dit onderzoek zou je als PM terug moeten zien in business case van de opdrachtgever. Deze kan je als input gebruiken voor verschillende interactie met je opdrachtgever gedurende verschillende projectfases.
Juist omdat ict-projecten een verandering teweegbrengen moeten ze volgens methodieken zoals Princ2 uitgevoerd worden zodat de effecten van deze verandering beheerst blijft.
Een projectmanager vandaag de daag heeft meer in zijn toolbox nodig dan alleen Princ2! Een training zoals IPMA-C/B/A helpt je om als projectmanager ook met zachte kanten (soft skills) van het project (lees mensen) naast andere aspecten zoals financiële zaken kennis te maken. Deze onderwerpen zijn onmisbaar voor en PM.
Een projectmanager moet vandaag de daag een super mens zijn. Dit heb ik al eerder in verschillende artikelen op deze site toegelicht.
Anja,
Als ik verhaal tot de essentie terug breng gaat het allemaal om het proces verwachtingsmanagement, een niet gedefinieerd of te definiëren proces omdat verwachtingen menselijk en dus niet altijd logisch zijn. De mens kent, in tegenstelling tot een computer namelijk meerdere vormen van denken. Leuk en Niet Leuk zijn dan misschien binaire waarden maar geen harde waarheden.
@ Anja
wanneer je i.p.v. over veranderproces, naar verbeterproces gaat…..
en inderdaad voortgangsrapportages dragen echt niet bij aan een decharge, daar zijn andere zaken voor nodig in een project.