Scope creep is het verschijnsel waarbij - bij het ontwikkelen van software - de omvang van het het te ontwikkelen systeem ongemerkt of ongecontroleerd steeds verder toeneemt. Problematisch omdat "[e]en toename van de scope direct negatieve invloed (heeft) op het budget en/of de doorlooptijd. Dit is een van de redenen dat zoveel ICT-projecten uitlopen en meer kosten dan gepland."
Nicole de Swart - auteur van het Handboek requirements, Brug tussen business en ICT - onderscheidt in haar artikel Nooit meer scope creep drie manieren om scope creep te voorkomen:
-
Geen wijzigingen toestaan: projectmanagement-technisch verleidelijk om het projectresultaat binnen tijd en budget op te leveren, dankzij een plan van aanpak en planning die gebaseerd is op de vooraf goedgekeurde requirements. Kwalitatief gezien minder, wanneer dit betekent dat opdrachtgever en andere belanghebbenden een systeem krijgen dat niet aan hun behoeften voldoet.
-
Een goed wijzigingsbeheerproces: een wijzigingsbeheerproces kan worden ingezet als hulpmiddel om rekening te houden met wijzigingen en tóch grip te houden op het project: "wijzigingen in de requirements en de financiële en planningstechnische consequenties daarvan, [kunnen] 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 is alleen dat wijzigingen veel tijd en geld kosten en dit de belanghebbenden remt om te komen met verbeteringen en/of wijzigingen.
-
De scope geleidelijk laten ontstaan: op voorhand géén (gedetailleerde) scope vaststellen, maar "business de mogelijkheid geven om just in time te bepalen welke requirements ze de komende twee (of vier) weken willen laten implementeren". Voorwaarde hierbij is dat softwareontwikkeling iteratief en incrementeel plaatsvindt, waarbij de requirements en het systeem geleidelijk groeien tot het gewenste gewenste eindresultaat. "Als je een project niet begint met een goedgekeurde set aan requirements dan kunnen ze ook niet wijzigen of toenemen."
Volgens De Swart is het onvermijdelijk dat requirements wijzigen tijdens de looptijd van het project. Ze baseert zich hierbij op onderzoek van C. Jones die heeft aangetoond dat de requirements bij een eenjarig project gemiddeld met 27% toenemen. Bij een project van anderhalf jaar is dat al 43% en bij een tweejarig project maar liefst 63%.
Als belangrijkste oorzaken van veranderende requirements noemt De Swart voortschrijdend inzicht, wijzigende behoeften van de business en onvolledig of onjuist geëliciteerde requirements: "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."
De Swart bepleit voor een 'fundamenteel andere werkwijze' waarbij: "De business zelf het stuur in handen (krijgt) en iedere iteratie op basis van de opgeleverde software (kan) 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."
Bron: Nooit meer scope creep, Nicole de Swart
Between what happens to us and our response to it is a space. In that space lies our freedom, growth and happiness.
Stephen Covey
Freedom to give full attention to what you want (vs. It being held hostage by unmanaged stuff) is the GTD promise.
David Allen
In theorie is er geen verschil tussen theorie en praktijk; In praktijk wel.
Chuck Reid
Thinking In Systems
A Primer
Donella H. Meadows
Bij Bol.com
Jan Hendrik Stam stelt in zijn artikel “Nut en noodzaak van business requirements” (Computable, 16/12/2012) dat door aandacht te besteden aan het vaststellen van business requirements veel hoofdpijnpunten voorkomen kunnen worden: “De toepassing van business requirements is daarmee bittere noodzaak. Groot voordeel: het is echt geen rocket science.”
Stam maakt onderscheid tussen twee niveaus van requirements: (1) ‘gedetailleerde requirements’ en de ‘requirements van een hoger niveau’ (2). Het eerste niveau omvat de functional requirements (Wat moet het product kunnen?) en non-functional-requirements (Welke eisen stellen we aan de werking?), terwijl het bij het ‘hogere’ niveau gaat om de business requirements (‘Waarom doen we dit?').
Volgens Stam richten organisaties zich bij het ontwikkelen van software vaak vooral op de functionele en niet-functionele requirements en wordt er minder tot geen aandacht besteed aan de business requirements. Dit terwijl de business requirements juist van belang zijn om vooraf helder te krijgen wat de business eigenlijk wil bereiken. Bezinnen vóór het beginnen lijkt logisch, maar volgens Stam blijven organisatie vaak het antwoord schuldig op deze vraag en wordt desondanks de ontwikkeling toch voortgezet. Het verwaarlozen van de business requirements is niet zonder risico: dure of uitlopende projecten, oplossingen die duur zijn in het gebruik of oplossingen die überhaupt niet wordt gebruikt.
De nieuwe software moet – als het goed is – een oplossing bieden voor een probleem. Business requirement zijn noodzakelijk om vooraf helder te maken waaraan de nieuwe oplossing moet bijdragen. Stam spreekt in dit verband over een ‘continue heroverweging’, waarbij twee afwegingen noodzakelijk zijn: (a) hoe verhouden de kosten van de oplossing zich tot de baten, (b) zin er omstandigheden en/of ontwikkelingen in de buitenwereld die reden zijn om de business requirements bij te stellen. Stam ziet business requirements als hulpmiddel om het bestaansrecht van een project doorlopend te blijven toetsen.
“Als gevolg van die continue heroverweging kan blijken dat het niet zinvol is om met de ontwikkeling door te gaan. Het voordeel is dat je dat dan in een vroeg stadium kunt signaleren. Het alternatief is bovendien onwenselijk: als je je tijdens de ontwikkeling niet stoort aan wat er in de buitenwereld gebeurt kan het gebeuren dat de uiteindelijke oplossing bij voltooiing volledig obsoleet blijkt te zijn.”
Volgens Stam hebben bij het opstellen van requirements de verschillende belanghebbenden (stakeholders) vaak verschillende, zelfs conflicterende belangen hebben. Het is zaak te kom tot een set aan requirements “die voor alle stakeholders acceptabel is, waarbij ook meteen gezegd is dat niet iedere stakeholder helemaal gekregen heeft wat hij van origine wenste”. Stam stelt dan ook: “Goede communicatie met stakeholders, maar ook tussen stakeholders onderling is een voorwaarde voor een complex aan requirements waarmee iedereen kan leven en dat een oplossing oplevert die echt bijdraagt aan de business.”
“De vertaling van business requirements naar een werkbare oplossing zal onherroepelijk betekenen dat niet iedereen krijgt wat hij wilde. (…) Sommige requirements zullen organisatiebreed gedeeld worden, maar andere zullen conflicteren. Stakeholders moeten daarom in staat zijn het belang van hun eigen onderdeel voor de business goed in te schatten, vooral ook in verhouding tot de organisatie als geheel. Dat betekent dat het eigen belang niet overschat moet worden, maar zeker ook niet onderschat. (…) De stakeholders moeten … verder kunnen kijken dan hun neus lang is en the big picture voor ogen houden.”
Naast het belang van goede requirements en welwillende stakeholders, is het – aldus Stam – ook nodig om op managementniveau weloverwogen requirements bij te stellen bij veranderende omstandigheden. “Elke verandering heeft meestal ook een financiële dimensie. Met andere woorden: er moet vaak geld bij. Het management moet in principe bereid zijn die investering te doen. Voordeel daarbij is wel dat die financiële injectie - middels business requirements - valt te verantwoorden en niet, zoals in veel gevallen, in een zwart gat wordt gekieperd.”
Tot slot, bepleit Stam ("Om te borgen dat het eindproduct maximaal bijdraagt aan de business") de requirements van alle stakeholders vast te leggen in een zgn. requirements traceability matrix. Met deze matrix is het niet alleen mogelijk inzichtelijk te maken welke requiremetns voor welke belanghebbenden belangrijk zijn, maar kan ook worden aangegeven hoe requirements zich tot elkaar verhouden.
Bron: Nut en noodzaak van business requirements, Jan Hendrik Stam (Capgemini) in Computable, 16/12/2012
Als je een persoon haat, dan haat je iets in hem dat een onderdeel is van jezelf. Wat geen onderdeel is van onszelf stoort ons niet.
Herman Hesse
Alice in Organisatieland
Alice doet aan de hand van de ongeschreven regels allerlei ontdekkingen over organisaties
Johan Boudewijns
Bij Managementboek
