Hoe beheer je scope creep op een project?

Question

Accepted Answer

**Scope creep**, de gestage ophoping van "nog één dingetje", is hoe projects die op koers lijken stil weg te zakken. De oplossing is niet om alles af te wijzen; het is om **elke toevoeging een zichtbare, expliciete afweging** tegen tijd te maken in plaats van stille absorptie.

## Hoe je scope beheert

```text
✓ Define DONE up front — written, agreed scope
✓ Make the cost of every addition VISIBLE ("yes, and that pushes us a week")
✓ Track changes — a changelog of what got added/cut
✓ Protect a core MVP — defend the must-haves fiercely
✓ Use a PARKING LOT — capture good ideas for "later," don't reject them
✓ Escalate trade-offs to whoever owns priority — let them choose
```

## De sleutelstap

Weiger nieuwe verzoeken niet ronduit, dat maakt jou de blokkeerder. Maak in plaats daarvan de afweging zichtbaar: "We kunnen dat toevoegen. Dat betekent dat de deadline een week later wordt of we verwijderen feature X. Wat wil je?" Nu is het een *zakelijke* beslissing, genomen door de juiste persoon, met open ogen.

## Een concreet voorbeeld

Halfverwege het project voegt de PM steeds "kleine" aanpassingen toe. Je start een gedeeld scope-wijzigingenlog. Opeens ziet iedereen dat het originele twee-weekse project drie weken aanvullingen heeft opgeslorpt, en wordt het gesprek over de deadline duidelijk en makkelijk.

## Waarom het belangrijk is

Onbeheerde scope creep is de stille doodkiller van deadlines, geen enkele verandering voelt groot, maar ze stapelen zich op tot een mislukking.

Afwegingen expliciet maken houdt het team beschermd, de stakeholders geïnformeerd, en de schuld weg van engineering wanneer scope, niet inspanning, de oorzaak was.