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:

1. 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.

2. 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.

3. 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