De klant had last van voortschrijdend inzicht

Toevallig stuitte ik in een oude Computable, één van 2009, op het artikel ‘Omgaan met voortschrijdend inzicht’. Met dit artikel ben ik het natuurlijk volledig oneens, maar ik zal de auteur eerst zijn betoog laten doen. “Een succesvol project is een project dat precies die functionaliteit levert die het probleem oplost waarvoor het project werd gestart en wel op de afgesproken datum en binnen het afgesproken budget.” Daar valt natuurlijk niet zoveel op af te dingen. Maar vervolgens verzucht de auteur “Wie kan garanderen dat het projectdoel op tijd en binnen budget behaald wordt ondanks ‘voortschrijdend inzicht?” Hij noemt de volgende oorzaken, waardoor dit inderdaad vaak niet lukt:

• Een veel voorkomende oorzaak van de introductie van ‘andere inzichten’ is het inzetten van nieuwe mensen gedurende het project. Nieuwe mensen kunnen nadruk leggen op onderwerpen die nog onderbelicht zijn gebleven. Dit op zich is positief, maar gebeurt dit in een laat stadium van het project, dan pakt het toch vaak negatief uit voor het totale project.
• Een andere belangrijke oorzaak voor het ontstaan van voortschrijdend inzicht is het niet overzien van het gehele gebied. Een oplossing die vanuit systeemontwikkeling daarvoor aangedragen kan worden, is een Agile projectaanpak. Hierin worden kleine stapjes richting het gewenste eindresultaat gemaakt. Dit zorgt ervoor dat voortschrijdend inzicht snel expliciet gemaakt wordt, maar geeft nog geen houvast hoe ermee om te gaan. Indien zelfs de indruk wordt gewekt dat de iteraties in een Agile-project bedoeld zijn om ‘andere inzichten’ op te nemen, is de kans groot dat een dergelijk project niet op tijd worden opgeleverd (of slechts met concessies aan belangrijke scope).

De auteur beëindigt zijn artikel met een tiental tips hoe je kunt vermijden, dat een klant die last heeft van voortschrijdend inzicht, daadwerkelijk het project kan beïnvloeden.

Project of klant centraal?

De essentiële vraag hierachter is natuurlijk, wat centraal moet staan in een project. Is dat het op tijd en binnen budget opleveren van het projectresultaat, zoals dat ooit gespecificeerd is of gaat het om een bruikbaar middel voor de klant, waarmee die klant in de toekomst bedrijfsdoelstellingen kan realiseren. Ofwel, staat de klantbehoefte centraal of het ’succesvolle’ project? Natuurlijk zal iedere automatiseerder zeggen, dat het om de klant gaat en dat de klant wil dat het afgesproken resultaat binnen de randvoorwaarden wordt opgeleverd. Dat klinkt logisch en logica  mag je ook verwachten van een automatiseerder. Veel automatiseerders vinden eigenlijk, dat gebruikers zich zo weinig mogelijk moeten bemoeien met de briljante oplossing, die zijn voor hen hebben bedacht. Als eindelijk het gedoe rond het projectcontract afgehandeld is, dan kan de echte automatiseerder los, niet langer gehinderd door de ongein uit de omgeving. Dat de gebruikers het uiteindelijke resultaat de ‘schitterende oplossing voor het verkeerde probleem’ vinden, ligt natuurlijk aan de gebruikers. Zij hebben niet volledig of correct gespecificeerd wat hun behoefte was of ze zijn tussentijds van gedachten veranderd, wat getuigt van instabiliteit in hun denken of zelfs onbetrouwbaarheid. De schuld ligt hiermee dus volledig aan de kant van de opdrachtgever en de gebruikers, die maar niet snappen hoe moeilijk het is om een goed programma te schrijven voor de vaak onlogische behoefte van de gebruikers. Als de software die gebruikers niet goed past, dan kunnen ze toch gewoon hun werkwijze aanpassen? Daar hoef je niet zo ingewikkeld over te doen, aldus de automatiseerders. Dat kwaliteit doorgaans gedefinieerd wordt als ‘het voldoen aan overeengekomen en vanzelfsprekende behoeften’, daar hebben die automatiseerders vaak geen boodschap aan. Want als die behoeften zo vanzelfsprekend zijn, dan kun je ze toch gemakkelijk definiëren? Intussen weten veel automatiseerders wel, dat ze dit soort dingen niet meer hardop mogen zeggen, maar de meeste ‘hardcore’ automatiseerders denken nog wel zo.

Voortschrijdend inzicht verbetert de perceptie van het projectresultaat

Voortschrijdend inzicht is geen zwakte maar wijsheid. Het toont aan, dat de organisatie nog steeds leert en voortdurend haar processen verbetert. Dat is ook de kern van ieder kwaliteitssysteem: het is niet in beton gegoten maar dynamisch, zodat nieuwe inzichten steeds weer verwerkt kunnen worden en bedrijfsprocessen steeds effectiever en efficiënter uitgevoerd kunnen worden. In een project wordt doorgaans een middel gecreëerd om een verbetering te faciliteren. Het gaat dus vaak om een nog niet bestaande situatie, die nog niet volledig uitgekristalliseerd is en dus per definitie verbetering behoeft. Het project kan hiervoor ondersteunend zijn, wanneer steeds tijdens het project feedback wordt gegeven aan de organisatie. Dit is wat u vroeg, maar is dit ook wat u bedoelde? Dat kan niet worden gerealiseerd door onleesbare en veel te gedetailleerde ontwerpen op papier, maar wel door werkende tussenresultaten op te leveren. Met die tussenresultaten kan de gebruikersorganisatie werken. Ze komt er dan razendsnel achter of het resultaat inderdaad voldoet aan de (ook vanzelfsprekende) behoeften. En dan kan er nog in het project bijgestuurd worden. Als er echter geen afspraken gemaakt worden over de afbakening in tijd en geld, zullen deze standaard worden overschreden. Dit kan eenvoudig worden voorkomen door in timeboxes met een vaste doorlooptijd en een vaste inspanning te werken en van te voren het aantal timeboxes af te spreken. Daarmee wordt het project fixed price, fixed date. Na iedere timebox is er een sessie, waaraan deelgenomen wordt door de gebruikers en de ontwikkelaars. In iedere sessie wordt getoond, wat het ontwikkelteam in de vorige timebox heeft gerealiseerd en wordt vastgesteld, wat het ontwikkelteam in de volgende timebox gaat doen. Zo worden de behoeften in volgorde van prioriteit in de verschillende timeboxes afgehandeld. Is er sprake van voortschrijdend inzicht, dan wordt dit met een prioriteit toegevoegd aan de lijst met behoeften. Na de laatste timebox, zullen er waarschijnlijk dan nog een paar behoeften met een lage prioriteit overblijven. Deze worden niet meer uitgevoerd, want ze behoren waarschijnlijk thuis in de categorie ‘nice to have’. Tijdens het project worden zo dus een aantal behoeften met een lage prioriteit vervangen door voortschrijdend inzicht met een hogere prioriteit, zodat per saldo de gebruiker tevredener zal zijn over het projectresultaat. 

Denkwijze iteratief ontwikkelen centraal

Natuurlijk weet ik ook wel, dat Agile methoden als Scrum en RUP gemaakt zijn voor software ontwikkeling. Ook in andersoortige projecten echter is deze denkwijze goed bruikbaar. De timeboxes zijn dan misschien niet altijd even mooi, maar van belang is, het project op te delen in deelprojecten, die elk een werkend resultaat opleveren. Uiteindelijk gaat ‘fitness for use’ om een werkende oplossing in een werkende organisatie. Als met de oplossing het bedrijfsproces effectief en redelijk efficiënt uitgevoerd kan worden, dan kan die vaak beter maar in productie genomen worden, ook al voldoet de oplossing nog niet aan alle wensen en specificaties. Juist in de praktijk van alledag blijkt na enige gewenning dat veel van de openstaande wensen in feite niet zo belangrijk zijn en dat een aantal andere ineens veel meer prioriteit moeten krijgen. Als tijdens het project niet alle budget is opgebruikt (dat kun je plannen), dan is er nog voldoende geld voor de eerste verbeterslag, zonder dat hiervoor extra geld beschikbaar moet komen. Uiteraard lost deze denkwijze niet alle problemen op met projecten en is zij niet in ieder project te realiseren. Waar het mij omgaat, is dat een project niet als gevolg van een Pavlov-reactie, ‘conform to specifications’ ingericht moet worden, waarbij het behoeften en de projectomgeving bevriest voor de duur van het project. Dat is niet realistisch en projectmanagers die de klant centraal stellen, mogen hun project niet hierop inrichten. Zij doen hun klant tekort en blijven dan ook vaak zitten met een ontevreden klant. Omgekeerd moeten klanten en opdrachtgevers dit ook niet eisen van de projectmanagers van hun interne of externe leverancier. Zij moeten aangeven welk doel de oplossing moet dienen en wat het beschikbare budget is. Dat werkt beter dan een business case, die gebaseerd is op wishful thinking. En ook beter dan een formele wijzigingsprocedure, die op voorhand al leidt tot toename van de overhead. In plaats daarvan wordt binnen het project voor een wijziging een slimme, werkbare oplossing verzonnen, die minimaal voldoet aan ‘fitness for use’.