Scope er det avtalte omfanget av arbeid som et prosjekt skal levere. Scope creep er den gradvise, ukontrollerte utvidelsen av det omfanget — den jevne strømmen av "små tillegg" som stille undergraver tidsplanen. Å administrere scope betyr å kontrollere endringer, ikke å avvise dem.
✓ Document what's IN scope
✓ Document what's explicitly OUT of scope (the underused half)
✓ Define "done" / acceptance criteria
✓ Get stakeholders to agree before work starts
En skriftlig, avtalt grense lar deg senere si "det er en endring" med bevis.
Endringer er ikke dårlige — ukontrollerte er det. Når en ny forespørsel kommer, kjør den gjennom en enkel gate:
1. Is it really needed now, or is it a "nice to have"?
2. What's the impact on timeline / cost / other work?
3. Make the trade-off VISIBLE → "yes, but it pushes the date / drops X"
4. Get the stakeholder to decide with full information
Hovedtaket: aldri stille absorber ekstra arbeid. Gjør hver tilføyelse til et bevisst avveining som interessenten eier.
Midtveis i prosjektet ber en interessent om å "også støtte masseopplasting — burde være raskt." I stedet for å presse det inn, svarer du: "Vi kan det, men det legger til omtrent en uke. Forskyver vi datoen, eller skyver vi analyticsfunksjonen til neste release?" Nå er det deres valg, med kostnadene på bordet.
Si ja til hver forespørsel for å være hjelpsom, så misse fristen. Teamet ser ut til å ha mislyktes, mens det faktisk stille påtok seg ekstra arbeid.
Scope creep er den vanligste grunnen til at prosjekter glir — ikke fordi én endring er stor, men fordi dusinvis akkumuleres usynlig.
Å administrere scope holder prosjektet ærlig: endring er greit, men kostnaden er alltid eksplisitt og eies av den som vil ha det.