Niets mooier dan een frisse start

Aan het begin van een IT-project is, na een uitgebreide voorbereiding, selectie en onderhandeling, iedereen goed gemotiveerd en enthousiast om het IT-project aan te pakken.

De opdrachtgever is blij dat het project eindelijk van start gaat, de leverancier is blij dat hij het selectietraject succesvol heeft overleefd, de gebruikers zijn blij, want eindelijk gaat er iets gebeuren en de automatiseerders kijken met belangstelling uit naar het nieuwe systeem dat ze gaan maken: een kans om nieuwe techniek toe te passen en de mooiste toepassing te maken die ze ooit hebben gemaakt.

Kortom: iedereen blij, enthousiast en positief over de goede afloop. Na zo’n gedegen voorbereiding kan het niet meer mis gaan!

Het begin verloopt soepel

Het enthousiasme van alle betrokkenen werkt aanstekelijk. De gebruikers bespreken de eisen en wensen, developers passen nieuwe technieken toe, de eerste resultaten zijn er vlot, de opdrachtgever heeft nog maar beperkt geld uitgegeven, alles is nog mogelijk, de leverancier ziet dat er nog veel te factureren valt.

In mijn praktijk als gerechtelijk deskundige kom ik dit regelmatig tegen. De projectomvang en het budget zijn, kort na de start, nog uitstekend met elkaar in evenwicht.

Gaandeweg het IT project veranderen de zaken

Aan de kant van de leverancier is men wat terughoudender bij het inwilligen van vragen (wensen? eisen?) van de gebruiker, de gebruikers doen wat ervaring op met de eerste resultaten en formuleren de eisen wat nauwkeuriger, opdrachtgever ziet een belangrijk deel van het budget verbruikt, maar heeft niet de indruk dat er al voldoende geleverd is, de leverancier blijft optimistisch, de developers ervaren dat de nieuwe techniek toch niet alle beloften waarmaakt die ze eerder ontdekt dachten te hebben.

Kortom: het project begint te knellen

Bij strikt projectmanagement hoort men nu stevig op de rem te trappen, maar het is mijn ervaring dat vrijwel alle betrokkenen optimistisch blijven. Automatiseerders hebben dat van nature en vaak leeft de gedachte dat het in de laatste fase wel sneller zal gaan, men heeft immers veel ervaring opgedaan. De praktijk leert anders.

Een realist is een optimist die wijzer is geworden

Projectstatus en budget lopen steeds verder uit elkaar

En dan komt er een moment dat het echt gaat knellen.

De leverancier komt tot de conclusie dat het resterende budget echt niet meer voldoende is voor de rest van het project, gebruikers beginnen te klagen over de beperkte functionaliteit die is gerealiseerd (je mag toch wel verwachten dat), automatiseerders beginnen over te werken om deadlines te halen en de opdrachtgever moet zich bij bestuur, directie of andere beslissers verantwoorden over het budget dat gespendeerd is en het resultaat dat niet daarmee in overeenstemming lijkt te zijn.

En dan escaleert het project

Er worden boze brieven gestuurd, hakken gaan in het zand, ingebrekestellingen dreigen.

Wat nu?

Recentelijk ben ik als gerechtelijk deskundige (weer) met zo’n situatie geconfronteerd. Gelukkig hadden zowel opdrachtgever als leverancier de intentie om samen tot een oplossing uit deze benarde situatie te komen.

De essentie van de oplossing die ik, na het nodige aan onderzoek, met partijen heb uitgewerkt is tweeledig:

• Ga terug naar de vereiste kernfunctionaliteit
• Ga er op zo kort mogelijke termijn daadwerkelijk mee werken

Terug naar de kernfunctionaliteit

Bij de beoordeling van kernfunctionaliteit ga ik altijd terug naar het MoSCoW prioriteitsprincipe. Kort samengevat:

• Must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;
• Should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;
• Could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;
• Would haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als “won’t haves”.

Een belangrijk verschil van prioriteitstelling volgens de MoSCoW-methode met eigen gekozen prioriteiten (bijvoorbeeld prioriteit 1, 2 of 3) is dat MoSCoW primair uitgaat van de objectieve eisen van het systeem, terwijl eigen gekozen prioriteiten veelal een subjectieve beoordeling vormen vanuit gebruikers- of leveranciersperspectief.

Werken met de MoSCoW-methode is niet eenvoudig

Een product owner, projectmanager of architect die stevig in zijn of haar schoenen staat is essentieel, NEE zeggen en moeilijk kijken moet standaard worden.

Er dienen pijnlijke keuzes gemaakt te worden

Lastig, maar echt vereist om zo’n project tot een succesvol einde te brengen.

Ga met het systeem werken

Iedere IT-toepassing kent zijn beperkingen. Gebruikers zien hun kans schoon om bij de implementatie van een nieuwe IT-toepassing te streven naar een perfecte oplossing. Laat me duidelijk zijn: de perfecte IT oplossing bestaat niet en bestaat nooit.

Dit staat nog los van het feit dat men zich geen duidelijk beeld kan vormen van de impact van de nieuwe IT-toepassing op het functioneren van de organisatie en de processen die met het nieuwe systeem worden ondersteund.

Een IT-systeem verandert de organisatie. En dat wordt pas echt duidelijk als het in gebruik genomen is.

Door invoering uit te stellen wordt het niet makkelijker

Het probleem (de ingebruikname) verdwijnt niet als je het uitstelt, sterker het probleem wordt eerder groter door het uitstel.

De manier om meer van het functioneren van het nieuwe systeem te weten te komen is om er daadwerkelijk mee te gaan werken. En dan niet in een experimenteeromgeving, maar ik bedoel echt ermee werken. Natuurlijk zijn er vooraf de nodige testen geweest, dus de functionaliteit moet in basis in orde zijn. Tegelijk is de enige echte test het nieuwe systeem daadwerkelijk in gebruik nemen.

Het alternatief voor geen mislukking

Aandachtspunten voor deze fase van het project (budget en project lopen uit elkaar) zijn voorbijgekomen: objectieve priotiteitstelling, strakke controle, gaan gebruiken.

Het project en het budget komen niet vanzelf met elkaar in lijn. Een uitstekende oplossing is om, voordat het echt escaleert, een onafhankelijke IT-deskundige naar de status te laten kijken en een onafhankelijk advies te laten formuleren.

Vreemde ogen dwingen, zei mijn moeder altijd

En zo is het maar net. Beter vroegtijdig recht gezet, dan achteraf voor het gerecht gezet.