Hvordan håndterer du scope creep på et prosjekt?

Question

Accepted Answer

**Scope creep**, den stadige oppsamlingen av "bare en ting til", er hvordan prosjekter på sporet stille glir av. Løsningen er ikke å si nei til alt; det er å gjøre **hver tilføyelse en synlig, eksplisitt avveining** mot tid, i stedet for en stille oppslukelse.

## Hvordan kontrollere scope

```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
```

## Nøkkeltrekket

Ikke avvis nye forespørsler rett ut, det gjør deg til blokkeren. I stedet bringe avveiningen til overflaten: "Vi kan legge det til. Det betyr at enten fristen flyttes en uke eller vi dropper feature X. Hva vil du?" Nå er det en *forretnings*-beslutning, tatt av riktig person, med åpne øyne.

## Et konkret eksempel

Midt i prosjektet holder PM-en på med å legge til "små" justeringer. Du starter en delt scope-endringslogg. Plutselig ser alle at det opprinnelige to-ukersprosjektet har absorbert tre uker med tillegg, og samtalen om fristen blir åpenbar og enkel.

## Hvorfor det betyr noe

Uhåndtert scope creep er den stille drapsmannen for frister, ingen enkelt endring føles stor, men de summerer seg til en miss.

Gjør avveininger eksplisitte holder teamet beskyttet, interessenter informert, og skylden vekk fra ingeniørfag når scope, ikke innsats, var årsaken.