Scope creep is een gevreesd verschijnsel binnen de software ontwikkeling. Een groot deel van de projecten krijgt ermee te maken. Bij scope creep neemt de omvang van het te ontwikkelen systeem ongemerkt of ongecontroleerd steeds verder toe.
Scope creep is in traditionele/waterval projecten een veelvoorkomend probleem omdat daarbij zowel de scope, het budget als de deadline vast staan. Een toename van de scope heeft direct negatieve invloed op het budget en/of de doorlooptijd. Dit is een van de redenen dat zoveel ict-projecten uitlopen en meer kosten dan gepland.Ik zal hier laten zien dat met een fundamenteel andere werkwijze het scope creep monster definitief tot het verleden behoort.
Dat de requirements wijzigen tijdens de looptijd van het project is niet te voorkomen. Onderzoek van C. Jones heeft aangetoond dat de requirements bij een eenjarig project gemiddeld met 27 procent toenemen. Bij een project van anderhalf jaar is dat al 43 procent en bij een tweejarig project maar liefst 63 procent. De belangrijkste oorzaken van wijzigingen in de requirements zijn voortschrijdend inzicht, wijzigende behoeften van de business en onvolledig of onjuist geëliciteerde (ontdekken en eruit halen van bepaalde interne processen) requirements.
Er zijn drie manieren om te voorkomen dat de omvang van een software ontwikkelproject ongemerkt of ongecontroleerd toeneemt.
1. Geen wijzigingen toestaan
Vanuit projectmanagement oogpunt is dit de eenvoudigste oplossing. Het plan van aanpak en de planning zijn gebaseerd op de goedgekeurde requirements. Als er geen wijzigingen in die requirements worden toegestaan, is de kans groter dat het project volgens plan verloopt en dus succesvol is… of toch niet?
Wanneer is een project succesvol? Als het project het systeem (dat aan alle vooraf overeengekomen requirements voldoet) conform plan binnen budget en tijd wordt oplevert? Of als de opdrachtgever en de andere stakeholders een systeem krijgen dat aan hun behoeften voldoet binnen een voor hun acceptabel budget en tijd? In het tweede geval beslist de business zelf of ze extra tijd en geld over hebben voor nieuwe of gewijzigde requirements. Dit brengt ons bij de tweede mogelijkheid om scope creep te voorkomen.
2. Een goed wijzigingsbeheerproces
Om in te spelen op voortschrijdend inzicht en toch grip te houden op het project, is een effectief wijzigingsbeheerproces vereist. Hiermee kunnen wijzigingen in de requirements en de financiële en planningstechnische consequenties daarvan, weloverwogen doorgevoerd worden. Ieder wijzigingsverzoek wordt dan geregistreerd, geanalyseerd en toe- of afgewezen. Bovendien moet iedere goedgekeurde wijziging doorgevoerd worden in de software en in de documentatie. Nadeel van een wijzigingsbeheerproces is dan ook dat het veel tijd en geld kost. Dit is in de praktijk vaak de reden dat het wijzigingsbeheer niet zo nauw wordt genomen, met alle gevolgen van dien. Een ander belangrijk nadeel is dat de business stakeholders zich geremd voelen of erger nog ontmoedigd worden om verbeteringen/wijzigingen aan te dragen. Het gevolg is een systeem dat slechts gedeeltelijk aansluit bij de behoeften van de gebruikers.
Er is nog een derde en radicaal andere manier om scope creep te voorkomen: op voorhand geen (gedetailleerde) scope vaststellen. Als je een project niet begint met een goedgekeurde set aan requirements dan kunnen ze ook niet wijzigen of toenemen. Dit vergt een totaal nieuwe projectaanpak en brengt ons bij optie drie.
3. De scope geleidelijk laten ontstaan
We hebben de afgelopen decennia ervaren dat het vrijwel onmogelijk is om de requirements en de scope van het te ontwikkelen systeem op voorhand vast te stellen. Het inzicht en een groot deel van de requirements wijzigen immers tijdens het project. Als we de business de mogelijkheid geven om just in time te bepalen welke requirements ze de komende twee (of vier) weken willen laten implementeren, dan hoeven we de requirements niet aan het begin van het project vast te stellen. Dit kan alleen als het it-project iteratief en incrementeel werkt. Op deze manier groeien de requirements (het ontwerp, de software architectuur) en het systeem geleidelijk tot het gewenste eindresultaat. Dit is te vergelijken met het steeds groter groeien van een boom.
De business krijgt dus zelf het stuur in handen en kan tijdens het ontwikkelproces meerdere malen op basis van de opgeleverde software besluiten of het systeem verder uitgebreid moet worden en of ze daar nog geld aan uit willen geven. Op deze manier vervalt de noodzaak om op voorhand afspraken te maken over fixed date, fixed cost en fixed scope. Het it-project biedt de business de flexibiliteit om gaandeweg te ontdekken waaraan ze het meeste behoeften hebben.
Nadeel van deze werkwijze is dat het zowel voor de it'ers als voor de business een fundamenteel andere werkwijze is. Het kost tijd en training (learning by doing) om je die eigen te maken.
Leuk artikel!
Een scope creep kun je bijna nooit voorkomen! Het is niet zomaar dat in de projectbegroting ook wijzigingsbudget, calamiteitbudget en post onverwachte voorzieningen opgenomen zijn.
Geen wijziging toestaan (optie 1), zal moeilijk zijn als de opdrachtgever ziet dat het product niet aan zijn behoeftes voldoet. Je kunt niet gewoon stug doorgaan! Afhankelijk van hoe groot de wijziging is, wat de afspraken omtrent de wijziging van scope is, kun je deze optie soms toepassen als de opdrachtgever dat accepteert.
Een goed wijzigingsproces (optie 2) is een must voor een project, vooral tijdens de uitvoering. Maar uiteindelijk voorkomt dit Scope creep niet!
De scope geleidelijk laten ontstaan (optie 3), leuk maar wie gaat de kosten betalen van het product dat steeds duurder en duurder schijnt te worden? De opdrachtgever wil altijd in het begin van het project de zekerheid en houvast hebben. Ik denk niet dat ze akkoord gaan met deze optie.
Ik ben van mening dat de oplossing voor dit probleem meer aangeboden wordt door het uitvoeren van een haalbaarheidsonderzoek met een degelijke risicoanalyse. Door dit onderzoek kun je meer duidelijkheid verschaffen omtrent wat het project is en wat je moet opleveren. Vervolgens dit opnemen in je PID met de benodigde informatie om de grenzen van je scope aan te duiden. Er zijn ongetwijfeld nog meer maatregelen, maar eerlijk gezegd, als ze echt gewerkt hadden dan hadden we niet zo hoge percentages zoals wat je hierboven benoemd hebt!
In een aantal situaties is optie 3 misschien wel mogelijk, maar in de meeste gevallen zal de opdrachtgever eerst een maximum budget willen weten wat voor het project moet worden uitgetrokken. Dit kan alleen als je op zijn minst een indicatie hebt van de requirements en de scope.
Optie 1 is niet realistisch. Afgzeien nog van het feit dat er soms wettelijke wijzigingen moeten worden doorgevoerd in een al lopend project, is het altijd zo dat er nieuwe wensen en eisen vanuit de gebruikers worden aangedragen, omdat de wereld nu eenmaal veranderd tijdens het project en de software goed moet werken in de wereld van de gebruikers.
Optie 2 is volgens mij de meest effectieve. Helaas wordt er in de praktijk echter te vaak alleen uitgegaan van impact analyses opgesteld door experts en wordt er meestal geen gebruik gemaakt van meer formele methoden van scopemanagement, zoals bijvoorbeeld Northern scope (of Southern scope). Impact analyses van experts zijn vaak (veel) te optimistisch, waardoor het change management proces uiteindelijk nog steeds zijn doel voorbij schiet.
Mooie uiteenzetting Nicole. Optie 1 en 2 is de PRINCE2 manier. Niets mis mee, tenminste als je alleen maar must-have’s te realiseren hebt. Ben je die fase voorbij, dan lijkt mij optie 3 de beste. Je moet dan wel je omgeving mee hebben. Bij dat voor elkaar krijgen kan jouw artikel goede munitie zijn!
Je zou ook van tevoren kunnen vaststellen hoeveel je ongeveer kan & wil uitgeven, het budget van een project zou een uitvloeisel moeten zijn van een business case. Als je d.m.v. een business case een maximaal budget hebt vastgesteld, dan zou je toch optie 3 redelijk moeten kunnen uitvoeren, je moet dan wel netjes bijhouden hoeveel waarde er is gerealiseerd, en waar je financieel staat…..
Optie 1 is inderdaad zelden realistisch.
We zijn al decennia lang gewend om optie 2 toe te passen. Prince 2 doet dat inderdaad ook. Toch kost het, in mijn ogen, onnodig veel tijd en energie om het project en de vele wijzigingen te managen. Als het al lukt om aan scope creep te ontkomen. Jaap, ook must-have requirements bevatten op het ondergelegen detailniveau minder belangrijke requirements.
Optie 3 wordt steeds vaker toegepast. Zoals Joost aangeeft kun je daarbij een budget afspreken. Dan mag de opdrachtgever/business iedere 2 of 4 weken bepalen welke requirements het ontwikkelteam de komende weken moet implementeren. De opdrachtgever bepaalt dus zelf hoe het systeem ‘groeit’ en of er nieuwe functionaliteit wordt toegevoegd of bestaande functies gewijzigd. Hiervoor is wel een incrementele en iteratieve aanpak noodzakelijk (zie uitleg op mijn weblog op reaco.nl). Het project eindigt als de afgesproken deadline is bereikt, het budget op is of als de opdrachtgever vindt dat de overige requirements geen extra investering meer waard zijn.
Gelukkig slagen we er de laatste jaren steeds beter in om de voordelen van optie 3 aan opdrachtgevers uit te leggen. Het is namelijk een essentieel onderdeel van agile software ontwikkeling.
Leuk artikel. En inderdaad de bekende valkuilen bij opties 1 en 2 zijn overduidelijk en veel voorkomend. Doch wil ik nog toevoegen dat voor optie 3 ook bepaalde gevaren schuilen. Men kan namelijk “doorslaan” en zeker als de business geen financiele verantwoording hoeft af te leggen zodra dit anders is ingericht. En ik mis de mogelijkheid om optie 3 te combineren met optie 1 en 2. Deel een systeem op en afhankelijk van de aanwezige kennis per deel beslissen wat de aanpak wordt. Want ook optie 3 is niet altijd de meeste efficiënte oplossing. Dit vereist wel enige kunde van de medewerkers en vooral de projectleider.
Nicole, de titel dekt de lading van het artikel niet. Je geeft manieren aan om met scope creep om te gaan. Daarmee behoort scope creep niet tot de verleden tijd. Ik sluit me aan bij CK dat een groot project in delen moet worden gesplitst. Elke met een eigen scope. Door die delen dan niet te groot te laten worden, ga je pas echt aan de slag om de kans van scope creep kleiner te maken. Daarna hebben wij heel goede ervaring om scope creep te minimaliseren. Heel vaak zijn projecten gericht op het leveren van een bepaalde scope die bijv. in een business case is beschreven. Maar gemist wordt waarom die scope nu precies noodzakelijk is. Door in de business case bewust terug te gaan naar het doel van de business en het probleem waarom dat doel niet behaald wordt, heb je het stuur in handen om scope-wijzigingen te sturen. Is een wijziging noodzakelijk omdat anders het probleem niet wordt opgelost? Dan moet het in het project erbij komen. Is de wijziging niet noodzakelijk voor het oplossen van het probleem? Dan hoort het ook niet in het project thuis. Op deze wijze heb je geen scope-creep meer. Wel soms voortschrijdend inzicht, maar de scope blijft hetzelfde: het oplossen van het probleem!
Goed artikel.
De opdrachtgever/business mag iedere 2 of 4 weken bepalen welke requirements het ontwikkelteam de komende weken moet implementeren…hier heb je het over Agile.
De laatste jaren lijkt de watervalval methode vaak als “slecht” te worden bestempeld. Deze methode is echter mijns inziens nog steeds zeer goed omdat ze alle stakeholders verplicht op voorhand na te denken. Een softwareproject laten groeien als een boom is een mooie metafoor maar in wezen onrealistisch. Agile en steeds opnieuw terugkerende korte iteraties geven de stakeholders meer hoop en zin omdat ze regelmatig werkende software delen te zien krijgen. Aan de andere kant zet het laten groeien van de requirements de deur open om problemen te krijgen met de dure wijzigingen in de software architectuur. Hoe later een fout (of een afwezigheid van een requirement) wordt ontdekt, hoe duurder het wordt dit te “herstellen”. Dit wordt maar al te vaak vergeten.
Als een 1/n relatie, plots een n/n blijkt te zijn en een associatieve entiteit moet worden toegevoegd in de database dat heeft dit gevolgen voor queries, stored procedures, objectstructuren, klassen, functies, unit testen…..
Het eeuwige probleem blijft dat mensen niet kunnen definiëren wat ze exact willen maar toch een vaste prijs of maximum budget willen. Ik vergelijk het even met de bouw van een huis.
Stel dat je een huis wil laten bouwen, maar je weet nog niet hoe breed de gevel moet zijn, of er een kelder in moet, of het alleenstaand is en hoeveel verdiepingen er moeten zijn. Je vraagt dan wel wat dit maximaal gaat kosten. Denk je dat hier een zinvol antwoord op bestaat?
Je begint met de fundering, bouwt de muren, en je maakt het huis wind dicht. Plots beslist de bouwheer dat er een kelder in het huis gebouwd moest worden. En eigenlijk, nu je toch bezig bent, mijn nieuwe meubels hebben geen plaats genoeg. Kan het huis geen 3 meter breder worden gemaakt?…
Dit is de manier waarop software projecten vaak lopen. Je kan ingrijpende wijzigen wel nog doorvoeren, maar ze worden peper duur en dat wordt dan weer niet aanvaard door de opdrachtgever.
Ik denk dus dat korte iteraties er net voor zorgen dat mensen minder gaan nadenken en minder moeite gaan doen om te definiëren wat er ontwikkeld moet worden met een vaak negatief gevolg op de scope creep. Het is een zegen voor de opdrachtgever, maar geen zegen voor developers.
Immers, opdrachtgevers kunnen de boom (verderop in het project) toch laten groeien zoals ze willen. Het gevolg is dat developers proportioneel veel meer tijd steken in het rechtrekken van steeds veranderende aspecten.
Een zaligmakende manier bestaat er niet. Zowel Agile als waterval hebben voor en nadelen.
Nu ook budgetten sterk onder druk staan wordt het vaak wel heel moeilijk om nog wat te verdienen aan maatwerk in onze Westerse economie (of je moet *S*A*P* heten 😉 ).