Veel ict-projecten overschrijden door ‘voortschrijdend inzicht' het budget en de deadline. Tijdens het project veranderen prioriteiten en ontstaan nieuwe behoeften. De keuze is dan om het project (weer) bij te sturen of om stoïcijns op de eerder gedefinieerde eindstreep af te gaan. De tweede keuze leidt tot een eindresultaat waar niemand op zit te wachten. Er wordt vrijwel altijd gekozen voor bijsturen en dus meer tijd en meer geld in het project gestopt. Lars de Laat van Caesar Groep legt uit hoe je dit zoveel mogelijk kunt vermijden.
Het afwijken van originele toezeggingen is een logisch gevolg van de onzekerheid van het leven. Je kunt vooraf onmogelijk het volledige speelveld en alle mogelijke veranderingen daarbinnen overzien.
Logisch of niet, als je afspraken niet nakomt, dan is het investeren in een ict-project een slecht idee. Als investeerder weet je nooit welk rendement je mag verwachten. Het enige dat je weet uit het verleden behaalde rendementen, is dat ze lager zijn dan vooraf verwacht.
Geen oplossing zonder probleem
Naar mijn idee kun je wel degelijk afspraken maken én ze nakomen. Dit vereist dat een ict-project vanuit de juiste basis wordt gestart: het probleem dat opgelost moet worden.
In de dagelijks projectwereld zie je dat vooral vanuit de oplossing wordt gedacht en niet vanuit het probleem. Een organisatie is wel in staat om aan te geven wat zij wel of niet wil – functionaliteit x of y – maar te weinig waarom zij dit nodig heeft. Zonder te weten wat het probleem is, is de kans klein dat je met een goede oplossing komt.
Een ict-leverancier moet een klant daar bij helpen. Hoe? Vooral door dieper te graven en verder door te vragen. Wat wil de klant? Waarom wil de klant dat? Voor welk probleem moet het project een oplossing leveren? Bestaat dit probleem echt? Kunnen we het eens worden over de manier waarop een ict-systeem hiervoor een oplossing kan bieden?
Het probleem dat gedurende dit proces boven water komt, kan concreter gemaakt worden door het op te splitsen in deelproblemen. Deze deelproblemen moeten later worden afgedekt door elementen van de oplossing die het project gaat leveren. Het onderliggende business probleem waarover klant en leverancier het eens zijn, vormt zo de basis voor de scope van het project.
Oplossing de moeite waard
Met een basis voor de scope hebben we nog geen garantie dat we op tijd zijn en dus onze planning gaan halen. Een belangrijke vraag moet nog beantwoord worden: welke consequenties heeft het voortbestaan van de huidige situatie, ofwel: welke waarde vertegenwoordigt de oplossing? Wat gebeurt er als die oplossing er helemaal niet komt?
Een relevante vraag, want in feite is dit de enige goede reden om een ict-project te starten: aantoonbare waarde die de oplossing toevoegt aan de resultaten van de organisatie. Als dit inzicht in de waarde ontbreekt, dan is er geen reden om tijd en aandacht te besteden aan het project. Een project zonder waarde kent dan ook vaak een ‘waardeloze' uitvoering, in de zin dat vooraf besproken scope, planning en budget niet gehaald worden.
De waarde van elk van de elementen van de oplossing is de maatstaf voor het bepalen van de scope van het project. Wat waardevol is, bouwen we in de oplossing; wat geen waarde toevoegt, laten we achterwege. Vaak levert dit in een eerste gesprek irritaties op, maar als hierover tussen opdrachtgever en projectmanager consensus bestaat, is de scope van een project niet groter dan noodzakelijk en voor alle partijen volkomen helder en stuurbaar.
Kortom: de waarde van een oplossing vormt het kompas waarop opdrachtgever en projectteam blind moeten kunnen varen. Een project dat geen aantoonbare waarde heeft, is onstuurbaar. Zonder inzicht in die waarde is het naar mijn idee onzinnig om te beginnen aan het project.
Waarde is functie van de tijd
De rol van tijd, in de vorm van de opleverdatum van een project, wordt vaak onderschat. Toch is eenvoudig aan te tonen dat de waarde van een oplossing een sterke relatie heeft met tijdige levering van die oplossing. Stel dat een organisatie dankzij een oplossing maandelijks 25 duizend euro extra verdient, dan is het duidelijk dat drie maanden vertraging in feite een verliespost creëert van 75 duizend euro. Is het probleem gekoppeld aan een vaste datum – bijvoorbeeld als een oplossing dient ter ondersteuning van een bijzonder evenement – kan het effect van de factor tijd nog veel groter zijn. Wanneer het project in zo'n geval te laat wordt opgeleverd, kan de waarde wel eens volledig verdwenen zijn. Dat tijd geld is, is niet zomaar een cliché!
De waarde van een oplossing optimaliseer je dus door tijdig op te leveren. Om die reden is naast waarde ook de factor tijd cruciaal. Het is bizar dat uitloop door opdrachtgevers en projectteams al jaren geaccepteerd wordt. Overschrijding van de deadline leidt niet alleen vaak tot facturen voor meerwerk, maar reduceert ook de waarde van een oplossing!
Ruimte voor nieuwe inzichten
Betekent dit dat er nooit sprake is van nieuwe inzichten gedurende een project? Wordt er dan gekozen voor fixed scope – stoïcijns de gedefinieerde oplossing bouwen? Natuurlijk niet. De waarde van de oplossing moet continu centraal staan. Het vasthouden aan eerdere aannames terwijl de wereld anders blijkt te zijn, verlaagt de waarde van de oplossing. Als een project waarde moet toevoegen, geldt dat ook voor iedere verandering van scope. In de praktijk betekent dit dus dat een wijzigingsverzoek beoordeeld wordt op twee kenmerken: is de wijziging nodig om het probleem op te lossen (zo ja, dan hoort de wijziging binnen de scope en zal hij met ongewijzigde opleverdatum en budget meegenomen worden om het beloofde rendement te realiseren); voegt de wijziging waarde toe aan de oplossing en is die waarde hoger dan het (negatieve) effect op doorlooptijd en budget (zo ja, dan wordt de wijziging gehonoreerd en worden opleverdatum en budget aangepast om een hoger rendement te realiseren. Is het antwoord bij beide kenmerken ‘nee', dan wordt de wijziging terzijde geschoven.
In mijn opinie is een afspraak een afspraak en hiervan mag alleen worden afgeweken als het project meer rendement kan realiseren dan vooraf verwacht. Zo kun je ernaar werken het maximale uit de ict-investeringen te halen.
Lars de Laat, value manager Caesar Groep
Deze deelproblemen moeten later worden afgedekt door elementen van de oplossing die het project gaat leveren. Het onderliggende business probleem waarover klant en leverancier het eens zijn, vormt zo de basis voor de scope van het project.
“Is de wijziging nodig om het probleem op te lossen (zo ja, dan hoort de wijziging binnen de scope en zal hij met ongewijzigde opleverdatum en budget meegenomen worden om het beloofde rendement te realiseren).”
En stel dat het pas net voor een opleverdatum is opgemerkt?