Scope-uitbreiding beheren: technieken en hulpmiddelen voor projectmanagers

Wat is sluipende scope-uitbreiding?

Van sluipende scope-uitbreiding is sprake wanneer de opleveringen of functies van een project worden uitgebreid ten opzichte van wat oorspronkelijk is afgesproken, maar de projectplanning of het budget niet wordt aangepast om met die verandering rekening te houden.

Dit verschilt van een scopewijziging, waarbij officiële beslissingen worden genomen om de oorspronkelijke scope van een project aan te passen, zoals de doelstellingen, het budget, de opleveringen, de planning, de verantwoordelijkheden of andere onderdelen.

Sluipende scope-uitbreiding kan elk project met een vaste scope beïnvloeden. Het kan zowel opzettelijk als onopzettelijk gebeuren en kan afkomstig zijn van allerlei belanghebbenden die bij een project betrokken zijn.

De reden dat we zoveel aandacht besteden aan sluipende scope-uitbreiding is dat het kan leiden tot projectfalen. Door sluipende scope-uitbreiding kun je een deadline missen, je budget erdoorheen jagen (of overschrijden!) door kostenoverschrijdingen en bovendien nog steeds het verkeerde opleveren. Oei!

3 soorten sluipende scope-uitbreiding

Sluipende scope-uitbreiding kan verschillende vormen aannemen. Dit zijn enkele veelvoorkomende oorzaken:

• Beslissingen niet nemen en/of documenteren: belanghebbenden veranderen vaak van gedachten of kunnen geen consensus bereiken over de projectscope door veranderende organisatorische prioriteiten
• Te optimistische projectschattingen: het team onderschat de benodigde inspanning om projecttaken uit te voeren en mijlpalen te behalen en belooft daardoor te veel over wat tot de scope van het project behoort (tijdens de uitvoering kan dit zich soms uiten in giftige positiviteit)
• Goud op de rand: onnodige functies aan het product toevoegen die geen onderdeel waren van de oorspronkelijke vereisten.

Wie veroorzaakt sluipende scope-uitbreiding?

Het is nuttig om je project te bekijken om vast te stellen wie sluipende scope-uitbreiding kan veroorzaken. Door sluipende scope-uitbreiding vroegtijdig te identificeren, kun je de beste aanpak bepalen om het probleem aan te pakken.

PS: Spookt sluipende scope-uitbreiding door je project?

Scope Creep Made Even Creepier: Keep Him Away from Your Projects

Lid van het projectteam

Soms kunnen leden van het projectteam sluipende scope-uitbreiding veroorzaken. Mogelijke redenen zijn:

1. Het teamlid heeft geen duidelijk beeld van de projectscope

Breng aan het begin van het project alle vereisten of projectopleveringen in kaart in een scopeverklaring, projectplan of werkverdelingsstructuur (WBS) en zorg ervoor dat teamleden deze documentatie goed kennen. 

Als de scope wordt vastgesteld, betrek het team dan zoveel mogelijk bij deze gesprekken. Als dat niet haalbaar is, organiseer dan op zijn minst een projectstartbijeenkomst om ervoor te zorgen dat iedereen op één lijn zit. Voer tijdens de uitvoering regelmatig overleg met het team om ervoor te zorgen dat iedereen dezelfde informatie heeft.

2. Het teamlid wil ontwikkelen wat hij of zij zelf wil, in plaats van wat binnen de scope valt

Door je team te betrekken bij het vaststellen van de scope, creëer je draagvlak voor wat zij zullen ontwerpen en bouwen. Zorg ervoor dat iedereen als team samenwerkt. Als iemand op eigen initiatief iets buiten de scope gaat produceren, leidt dat tot verwarring en mogelijke wrijving met andere teamleden.

3. Het teamlid neemt beslissingen zonder anderen erbij te betrekken

Soms kiest een teamlid een manier om een probleem op te lossen die gevolgen heeft voor de scope, vaak zonder zich daarvan bewust te zijn.

Zelfs een halve dag extra werk om iets net iets anders te doen, kan gevolgen hebben voor de rest van je project. Als een ontwerper bijvoorbeeld besluit om functionaliteit aan een website toe te voegen (zoals een zoekbalk) zonder dit met de ontwikkelaar te bespreken, kan dit gevolgen hebben voor de planning van het project.

Zorg voor de juiste omstandigheden voor projectsucces door een cultuur van vertrouwen en transparantie op te bouwen. Wanneer iemand rechtstreeks bij jou een probleem aankaart, deel dit dan breder als er een grotere beslissing moet worden genomen. Laat mensen samenwerken om oplossingen voor problemen te vinden. Zorg ervoor dat iedereen regelmatig contact heeft (persoonlijk of op afstand). 

De meeste succesvolle projecten komen voort uit teams die goed samenwerken.

Interne belanghebbenden

Belangrijke belanghebbenden binnen je organisatie kunnen de reikwijdte van een project beïnvloeden. Ze hebben misschien een visie voor de organisatie waarbij er meer voor jouw project moet worden opgeleverd, of ze willen misschien een andere agenda doordrukken.

Een klantrelatie is voor een organisatie bijvoorbeeld soms belangrijker dan binnen de reikwijdte van je project blijven.

Zorg ervoor dat je interne belanghebbenden begrijpen wat je probeert op te leveren en wanneer. Als iets een domino-effect op je project zou hebben, beschrijf dan duidelijk welke impact dit zou hebben—financieel, op het gebied van reputatie of anderszins.

Externe gebruikers

Gebruikersonderzoek zou (hopelijk) onderdeel moeten zijn van de opzet van je project of product. Feedback van gebruikers op een product kan een reeks gebeurtenissen in gang zetten die uiteindelijk de reikwijdte vergroot. Wat gebeurt er als je feedback van je gebruikers krijgt waar je niet omheen kunt? Zelfs als dit de reikwijdte vergroot, moet je ermee aan de slag.

Wanneer je de resultaten van het onderzoek hebt verzameld, bekijk je deze samen met je team om vast te stellen welke noodzakelijke wijzigingen moeten worden doorgevoerd. Bepaal prioriteiten, zodat je begrijpt welke wijzigingen de grootste impact op de gebruikerservaring zouden hebben. Bepaal vervolgens welke wijzigingen je zonder problemen kunt opnemen zonder de reikwijdte te beïnvloeden.

Als een van de noodzakelijke wijzigingen tot een grotere reikwijdte zou leiden, bespreek dit dan met je klant of belanghebbende. Bereid je voor met inzicht in wat er zou gebeuren als je besluit de wijziging niet door te voeren.

Derde partijen

Als je afhankelijk bent van derde partijen om je project op te leveren—of het nu gaat om een extern bedrijf, een API van een derde partij of een contentleverancier—moet je de afhankelijkheden bij de projectstart in kaart brengen. Denk na over de impact die deze afhankelijkheden op je project kunnen hebben en hoe ze de reikwijdte ervan kunnen beïnvloeden.

Wat als je contentleverancier je bijvoorbeeld content stuurt die niet in een gemakkelijk te implementeren of naar je website te uploaden indeling staat? Zou dit extra tijd aan je planning toevoegen? 

Je kunt niet op elke eventualiteit anticiperen, maar door een risicogerichte planning te hanteren en deze afhankelijkheden aan het begin van een project met de klant te bespreken, krijg je inzicht in de mogelijke impact voordat je met een probleem wordt geconfronteerd.

Projectmanager

Wij kunnen als projectmanagers soms scope-uitbreiding veroorzaken. Het is bijzonder verleidelijk om te proberen dingen binnen je bestaande budget en tijdsbestek te laten passen, zonder dit aan je klant te melden.

Hoewel het zeker een moeilijk gesprek kan zijn om te zeggen dat je iets niet kunt doen zonder een wijzigingsverzoek, is dit gesprek veel gemakkelijker eerder dan later in de levenscyclus van het project te voeren.

Als jij of je team een probleem vaststelt, werk dan mogelijke oplossingen uit. Als er bijvoorbeeld extra werk nodig is, kijk dan wat er in plaats daarvan uit de reikwijdte kan worden gehaald—is er iets dat je in je project doet maar dat niet nodig is voor de eerste release? 

Leg deze opties en een aanbeveling voor aan de klant of belanghebbende.

Klant

We kunnen dit onderdeel niet afsluiten zonder een belangrijke veroorzaker van scope-uitbreiding te noemen: je klant. Pas op voor klanten of projectsponsors die “kleine” verzoeken toevoegen die de oorspronkelijke reikwijdte geleidelijk uitbreiden, van gedachten veranderen of nieuwe manieren voorstellen om dingen te doen die van invloed kunnen zijn op de benodigde inspanning. 

Wees eerlijk en direct als ze om iets vragen dat tot scope-uitbreiding zal leiden. Formuleer je antwoorden ook zo dat je niet simpelweg “nee” zegt, maar in plaats daarvan een alternatief voorstelt. Bijvoorbeeld:

“Dit nieuwe verzoek zal deze specifieke impact hebben op de tijd/het budget. We hebben naar de prioriteiten gekeken—zullen we dit in plaats daarvan vervangen door dat? Het bereikt een vergelijkbaar resultaat omdat…”

2 Voorbeelden van scope-uitbreiding

Nu we de typen en oorzaken van scope-uitbreiding hebben besproken, belichten we twee casestudy's die laten zien hoe scope-uitbreiding in je projecten kan ontstaan.

Casestudy over scope-uitbreiding #1

Je denkt misschien dat je slim genoeg zou zijn om scope-uitbreiding te voorkomen voordat deze plaatsvindt, maar daarmee zou je onderschatten wat scope-uitbreiding nu juist zo, nou ja, sluipend. maakt.

Stel je voor dat je gebruikersfeedback verzamelt over hoe je prototype presteert. Je had met je klant afgesproken met hoeveel gebruikers je zou praten, welke feedback je zou accepteren en hoe lang de commentaarperiode zou duren. Je had ook afgesproken feedback te verwerken tot aan een specifieke grens van het aantal uren dat nodig was om eventuele oplossingen te implementeren.

Zodra de commentaarperiode is afgelopen, wordt de klant gebeld door iemand uit het senior management die geen deel uitmaakte van de testgroep en vraagt of je deze persoon er nog bij kunt betrekken. Je had een limiet gesteld aan het aantal mensen dat commentaar kon geven, maar hoeveel kwaad kan het om één persoon toe te voegen? Bovendien wil je een goede indruk maken op leidinggevenden, dus stem je in met deze toevoeging op het laatste moment.

Voor je het weet, heeft die senior medewerker zijn hele team erbij betrokken. Ze willen een aparte testrondleiding en zijn ontstemd omdat hun specifieke gebruikssituatie niet is opgenomen.

Hoewel je voet bij stuk kunt houden en voorkomt dat de vereisten veranderen, heeft de extra onderhandelingstijd, om nog maar te zwijgen over de aanvullende communicatie met belanghebbenden om overeenstemming te bereiken over het doel van het project en de doelstellingen, al anderhalve week opgegeten van een toch al krappe planning. Scope-uitbreiding slaat opnieuw toe!

Casestudy over scope-uitbreiding #2

Het is ook belangrijk om te beseffen dat scope-uitbreiding niet per se voortkomt uit een verzoek van een klant.

Stel je voor dat je projectmanager bent en een project overneemt met een klassieke watervalaanpak, met daarin schetsontwerpen en een ontwerpfase, gevolgd door ontwikkeling.

Je raakt aan het begin van de ontwikkelfase betrokken. De taak is eenvoudig: je bouwt de frontend boven op een backend met het merk van een andere leverancier.

Je had de schetsontwerpen en ontwerpen goedgekeurd en alles doorgenomen met de klant en het bureau… wat kon er mogelijk misgaan? Nou! Het bleek dat het andere bureau zijn backend voortdurend aanpaste en regelmatig nieuwe code uitbracht.

Ironisch genoeg hielden ze er geen rekening mee dat jouw bureau voortbouwde op de oude code, waardoor jouw code bij elke nieuwe versie defect raakte.

Om dit te herstellen, besluit je dat het team de code opnieuw moet nalopen en bijwerken zodat deze werkt met de voortdurende wijzigingen van het andere bureau. Hiermee was geen rekening gehouden, maar het was wel noodzakelijk.

In eerste instantie bestond het extra werk uit af en toe een kleine oplossing op ad-hocbasis, maar er begonnen steeds meer problemen op te treden. Hoewel je dit bij de klant aankaartte, probeerde je het extra werk in je project op te nemen in plaats van de klant erop te wijzen dat er eerst een gezamenlijke oplossing moest worden vastgesteld voordat je verderging met de ontwikkeling.

Ach, de wijsheid achteraf! Wat gebeurde er? Je raakte steeds dieper verstrikt in het opnieuw ontwikkelen van de bestaande code: de planning werd verlengd, je miste je deadline en je bureau kwam tegen het einde van het project zwaar onder druk te staan. Het team raakte gedemotiveerd, de klant was niet tevreden en uiteindelijk liep het project twee maanden vertraging op.

Zo voorkom je scope-uitbreiding

Hier zijn enkele strategieën om de kans te verkleinen dat scope-uitbreiding je projecten binnensluipt:

• Definieer vanaf het begin duidelijk de reikwijdte van je project, waarbij je idealiter het projectteam betrekt om draagvlak te creëren. Gebruik een verklaring van werkzaamheden om vast te leggen wat wel en niet binnen de reikwijdte valt. Communiceer de reikwijdte vervolgens aan teamleden en belanghebbenden bij het project, waaronder de klant.
• Betrek het hele team bij het opstellen van onderbouwde schattingen op basis van de vereisten. Om het risico op onjuiste schattingen te verkleinen: 1) reserveer tijd voor een ontdekkingsfase om te bepalen wat je gaat bouwen 2) gebruik tijd en materiaal in plaats van een contract met een vaste prijs en 3) leg minder strikt vast welke functies je gaat bouwen. Richt je op de gewenste resultaten.
• Stel noodplannen op om ervoor te zorgen dat je voldoende tijd reserveert voor QA. Overweeg ook geautomatiseerd testen om tijd te besparen—de artikelen Voor- en nadelen van handmatig en geautomatiseerd testen en Beste automatiseringstools zijn nuttige referenties.
• Stel aan het begin van een project een veranderingsbeheerplan op waarin wordt beschreven hoe je wijzigingen in de reikwijdte zult afhandelen. Als je wijzigingsverzoeken wilt gebruiken, beschrijf dan het proces voor wijzigingsbeheer dat je zult volgen.
• Werk tijdens de uitvoering van het project nauw samen met je klant. Laat de voortgang van het project of het statusrapport van het project zien, verbeter waar nodig en betrek de klant gedurende het hele traject, zodat er geen verrassingen zijn.
• Breng problemen proactief ter sprake, zodra ze zich voordoen of, idealiter, voordat ze zich voordoen (mits je een oplossing hebt uitgewerkt om het probleem aan te pakken!). Gebruik een risicobeheerplan om je proces voor risicobeheer vast te leggen. Houd een risicoregister bij en beoordeel dit regelmatig om potentiële risico’s te volgen.
• Stel vragen om binnenkomende verzoeken te prioriteren. Zorg ervoor dat deze verzoeken niet onbedoeld de reikwijdte uitbreiden, werk dupliceren of onnodige extra functies opleveren. Bespreek elk verzoek met het team om inzicht te krijgen in de impact ervan op het projectbudget en de planning, evenals in het verwachte resultaat voor de gebruiker, zodat je het verzoek dienovereenkomstig kunt prioriteren.
• Betrek gebruikers vroegtijdig. Het is verleidelijk om onszelf wijs te maken dat wij (de klanten, het bedrijf, het team) de gebruikers goed genoeg kennen om geen contact met hen te hoeven hebben. De realiteit is dat je veel tijd kunt verspillen door een richting in te slaan die geen waarde toevoegt als je niet al vroeg gebruikersfeedback verwerkt. Op dat moment kan je reikwijdte ontsporen.

More Articles

• Projectmanagement voor evenementen 101: een beginnersgids
• De ultieme gids voor factoren in de ondernemingsomgeving
• AI in klantlevering: belangrijkste toepassingen, hulpmiddelen en een stapsgewijs adoptiekader

Hoe je ongecontroleerde reikwijdte-uitbreiding aanpakt

Als je project het slachtoffer wordt van ongecontroleerde reikwijdte-uitbreiding (of als je een project met een te ruime reikwijdte hebt overgenomen), raak dan niet in paniek. Je hebt nog steeds de mogelijkheid om jezelf uit deze situatie te redden. 

Hier volgen enkele stappen die ik heb genomen bij het overnemen van een problematisch project dat het slachtoffer was geworden van ongecontroleerde reikwijdte-uitbreiding:

• Begin met het uitleggen van de situatie aan je klant of belanghebbende. Leg uit hoe je in deze situatie terecht bent gekomen en wat je herstelplannen zijn om de situatie aan te pakken. Het heeft geen zin om de situatie mooier voor te stellen dan ze is. Dit is nu eenmaal de situatie.
• Doe aanbevelingen voor manieren om zaken eenvoudiger te maken zonder waarde op te offeren. Dit kan betekenen dat je bepaalde functies een lagere prioriteit geeft of concessies doet aan functies die “leuk om te hebben” zijn, totdat je iets kunt uitbrengen als een snelle vervolgrelease. Bereid een presentatie voor je klant voor waarin de afwegingen tussen elk van je benaderingen duidelijk worden uiteengezet.
• Breng het team op de juiste omvang. Dit kan betekenen dat je iemand die ondermaats presteert laat vertrekken of een duurdere medewerker vervangt door een goedkopere medewerker om op het budget te besparen. Deze gesprekken zijn onaangenaam, maar het alternatief is mogelijk het verlies van je klant, wat grotere gevolgen kan hebben voor de hele organisatie.
• Pak de gevolgen aan. Soms vereist het rechtzetten van een zinkend schip dat je je trots inslikt en de algehele winstgevendheid van het project opoffert om een waardevolle klantrelatie te herstellen. Het kan nodig zijn extra uren te maken om iets eerder dan gepland over de finish te brengen als manier om het goed te maken. De sleutel is om deze pijn te beperken tot een kortetermijninspanning, zodat het geen slechte gewoonte wordt.

Houd er ook rekening mee dat ongecontroleerde reikwijdte-uitbreiding soms gunstig kan zijn. In plaats van het te zien als de sluwe vijand, kun je het eenvoudigweg beschouwen als verandering. En verandering kan zeer gunstig zijn voor het product dat je maakt. Het is de manier waarop je die verandering beheert die van invloed is op het project—niet het verzoek om de verandering door te voeren.

Je moet er simpelweg op letten dat je het herkent wanneer het gebeurt, vooral wanneer het niet duidelijk is, en het ter sprake brengen voordat het zonder enige vorm van herplanning verdergaat.

Hoe je scopebeheer toepast in Agile

Ongecontroleerde reikwijdte-uitbreiding doet zich doorgaans voor bij projecten met een vaste reikwijdte. Maar wat als je een agilemethodologie gebruikt?

Agile omarmt verandering—en eerlijk gezegd zouden agileprojectmanagers dat ook moeten doen. Zoals een van de basisprincipes van agile stelt:

Verwelkom veranderende vereisten, zelfs laat in de ontwikkeling. Agile processen benutten verandering in het concurrentievoordeel van de klant.

Als je bijvoorbeeld werkt met de scrummethodologie en er een nieuwe vereiste binnenkomt, voeg je die toe aan de backlog om deze samen met de product owner en het team te prioriteren. Als deze vereiste tijdens de sprintplanningsbijeenkomst inderdaad in de sprint terechtkomt, geef je iets anders een lagere prioriteit.

Het doel van agile is itereren, wat betekent dat je ontwerpt, bouwt, test, leert en de cyclus vervolgens herhaalt. Omdat agile projecten de details niet vooraf volledig uitwerken, blijft er ruimte voor verandering: je kunt het ene gebruikersverhaal vervangen door een ander dat evenveel inspanning vereist. Verandering leidt tot het best mogelijke product binnen de beschikbare tijd.

Wat geldt dan als ongecontroleerde scope-uitbreiding in een agile project? Ongecontroleerde scope-uitbreiding kan ontstaan als je product owner verzuimt functies of taken een lagere prioriteit te geven wanneer er een nieuwe vereiste wordt toegevoegd.

Daarnaast kan diegene verzuimen de benodigde inspanning voor de nieuwe taak af te wegen tegen die van de taak met een lagere prioriteit, waardoor extra inspanning in een al te krappe cyclus kan worden gepropt.

Zorg ervoor dat je nieuwe functies die aan de backlog worden toegevoegd, opdeelt in verhalen en inzicht krijgt in de benodigde inspanning, zodat je ze dienovereenkomstig kunt prioriteren.

Ongecontroleerde scope-uitbreiding is in een agile project doorgaans veel gemakkelijker te beperken, juist omdat de agile methodologie verandering aanmoedigt en deze in de structuur van de methodologie zelf verwerkt.

In een watervalproject wordt je product waarschijnlijk stap voor stap gebouwd totdat je aan het einde het glanzende nieuwe eindproduct voltooit. Dit kan ertoe leiden dat je denkt dat alles een prioriteit is.

Als je geen duidelijke prioriteiten tussen functies hebt, is het moeilijk te bepalen wat je uit de scope kunt halen wanneer er wijzigingen in de projectvereisten naar voren beginnen te komen.

Wat nu?

Wil je contact leggen met andere digitale projectmanagers om hulpmiddelen en beste praktijken te delen? Word lid van onze community en krijg toegang tot meer dan 100 sjablonen, voorbeelden en casussen en leg via Slack contact met honderden andere digitale projectmanagers.