Een belangrijke reden voor het verschuiven van projectdeadlines, het overschrijden van budgetten of het niet behalen van het projectdoel, is 'voortschrijdend inzicht'. Elk project heeft er mee te maken: gedurende het project ontstaan nieuwe en andere inzichten. In de volksmond vaak 'voortschrijdend inzicht' genoemd, in projectmanagementtermen wordt regelmatig de Engelse term 'scope creep' gebruikt. Het is vaak de reden (of het excuus) waarom een project niet succesvol is. Een succesvol project is naar mijn mening een project dat precies die functionaliteit levert die het probleem oplost en dat op de afgesproken datum en binnen het afgesproken budget. Wie kan garanderen dat het projectdoel op tijd en binnen budget behaald wordt ondanks 'voortschrijdend inzicht'?
Andere inzichten
Er zijn meer wegen die naar Rome leiden, een bekend gezegde. Gedurende een project komt er maar al te vaak iemand met een ander inzicht hoe het resultaat ook bereikt kan worden. Maar 'ander inzicht' is wat anders dan 'voortschrijdend inzicht'. Een ander inzicht hoeft niet vernieuwend te zijn. Al bij het kiezen van de oplossing zijn diverse oplossingsvarianten bedacht, waarbij om bepaalde redenen een keuze gemaakt is voor de uiteindelijke oplossing. Vaak blijft het documenteren van deze varianten en de daarbij gemaakte keuzen achterwege. Gedurende het project verwatert het beeld op de reden van het afvallen van andere alternatieve oplossingen.
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. Je dient dus van te voren goed na te denken welke mensen je gedurende het project nodig hebt. Iedereen die je nodig denkt te hebben, dient vanaf het begin van het project echt betrokken te worden en te zijn.
Te groot
Een belangrijke reden 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).
Indien bij start van het project het gevoel bestaat dat niet zeker is welke mensen betrokken dienen te zijn gedurende het gehele traject, is dat vaak een indicatie dat het project te groot wordt. Belangrijk is projecten als geheel klein te houden, zodat de betrokkenen het probleem gebied als geheel kunnen overzien.
Interpretatieverschillen
Al houd je je projecten klein en heb je een gedegen vooronderzoek gedaan met een vaste groep mensen, dan nog kan er een verschil van inzicht ontstaan. Al is het maar dat beschrijvingen verschillend geïnterpreteerd worden. In een project zijn diverse rollen: een klant die een op te lossen probleem heeft; een analist die een functionele oplossing voor het probleem beschrijft; een ontwerper die dat weer omzet in een te bouwen applicatie en tot slot een ontwikkelaar die de oplossing daadwerkelijk bouwt. Vier rollen op een rij, die over het algemeen via papieren documenten met elkaar communiceren: interpretatieverschillen liggen dan snel op de loer. Hoe voorkom je interpretatieverschillen? Dit kan bijvoorbeeld door het aanleggen van twee woordenlijsten: één van de business voor de techniek en één van de techniek voor de business. Alle rollen dienen immers elkaars taalgebruik te begrijpen!
De tweede actie die helpt om interpretatieverschillen te voorkomen, noem ik de 'omgekeerde bewijslast'. Als rollen op elkaar aansluiten, wordt meestal wel een sessie belegd waarin de 'aanleverende' rol het document uitlegt aan de 'ontvangende' rol. Het nadeel hiervan is, dat niemand kan vaststellen of de boodschap goed is overgekomen. Pas daarom de omgekeerde aanpak toe: de ontvangende rol leest en interpreteert de input voor zijn rol en presenteert op basis daarvan de oplossingsrichting aan de aanleverende rol. In deze setting kan de aanleverende rol vaststellen of de ontvangende rol alles goed begrepen heeft.
Stabiliteit van het fundament
Ondanks deze voorzorgsmaatregelen krijgt toch elk project te maken met 'voortschrijdend inzicht'. Dan komt het er op aan om daar zorgvuldig mee om te gaan. Juist om het halen van het projectdoel op de afgesproken datum te kunnen realiseren. Een belangrijke vraag is dan: 'Waar is het project op gebaseerd, wat is het fundament van het project?' Is dit een beschrijving van de oplossing (het resultaat) of een beschrijving van het op te lossen probleem (de aanleiding)? De reden achter een project is een bepaald probleem dat opgelost moet worden. In het project dient daarom niet de oplossing maar het probleem het fundament te vormen. In gevallen dat toch 'voortschrijdend inzicht' optreedt, dient dit inzicht getoetst te worden aan het probleem dat opgelost dient te worden. Alleen als het probleem zonder het 'voortschrijdende inzicht' niet juist opgelost wordt, dient het inzicht in de onderhanden release meegenomen te worden. Alle inzichten die niet bijdragen aan het op te lossen probleem, mogen terzijde geschoven worden. Alle inzichten die wel bijdragen maar niet strikt noodzakelijk zijn, mogen geen vertraging veroorzaken in het oplossen van het probleem: ze kunnen eventueel in een volgende release opgenomen te worden.
Samenvatting: hoe om te gaan met voortschrijdend inzicht?
- Maak en bespreek van te voren een aanpak hoe met voortschrijdend inzicht omgegaan wordt.
- Houdt de scope van het project klein, zodat betrokkenen het geheel kunnen overzien.
- Zorg dat het project één probleem oplost en dat dit SMART beschreven is, zodat het oplossend vermogen van inzichten daartegen afgewogen kan worden.
- Doe bij de voorbereiding op het project een goede inventarisatie van iedereen die gedurende het project betrokken dient te zijn en betrek deze mensen vanaf het begin bij het project.
- Documenteer alternatieve oplossingen, waar niet voor gekozen is, met de reden waarom de keuze daar niet op gevallen is.
- Leg twee woordenlijsten aan: 'van business voor techniek' en 'van techniek voor business' zodat zo min mogelijk spraakverwarring ontstaat.
- Pas 'omgekeerde bewijslast' toe: laat de ontvangende rol uitleggen aan de aanleverende rol hoe zaken geïnterpreteerd zijn.
- Sta 'voortschrijdend inzicht' in het lopende project alleen toe, als het probleem zonder doorvoering van dit inzicht niet juist wordt opgelost.
Pas je deze stappen toe op je project, dan stijgt de kans op een succesvol project aanzienlijk!
Alexander Vermeulen
System analist
Caesar Groep
Beste business case 2009
De redactie van Computable zoekt naar de beste business case van het jaar 2009. Een vakkundige jury buigt zich over voorgedragen cases en kiest de uiteindelijke winnaar.
Via een invulformulier kunnen bedrijven hun business case bij Computable aandragen. Uiteraard zijn business cases van afgeronde projecten welkom, maar ook de business cases van nog lopende of nog te starten projecten zijn welkom. Zolang de business case of het project maar linkt aan het jaar 2009.
Het aanmelden van business cases kan tot en met 20 januari 2010. In april 2010 worden de beste business cases van 2009 bekendgemaakt, mede in de jaargids Computable Business Cases 2010.
Omgaan met voortschrijdend inzicht (“VI”) in de systeemontwikkeling is mijn inziens per definitie agile werken. De waterval/SDM-aanpak faciliteert het niet, anders dan door Change Advisory Boards en extra rekeningen (lekker integer…).
Agile biedt wel degelijk houvast om om te gaan met VI, namelijk door alle requirements te prioriteren en ook binnen de iteratie de onderlinge prioriteiten toe te kennen. Op die manier borg je namelijk dat je binnen tijd en binnen budget de belangrijkste software (=hoogste business value) oplevert. Ik heb in 8 jaar agile ontwikkeling nog niet meegemaakt dat een klant ontevreden was over de opgeleverde deelfunctionaliteit. Gewoon een kwestie van verwachtingen managen en werkende software laten zien.