Scope creep

Each extra request looks reasonable alone. Together they blow the timeline, dilute focus and delay the thing that needed to ship and be learned from. For a small team the cost is sharper than it looks, because time is the scarcest resource and every unplanned addition takes it directly from testing the part that mattered.

It also damages trust. A two-week job that takes six weeks leaves the client or the team feeling the project is out of control, even though every addition was requested.

• Write the scope down before starting, including what is explicitly out, not only what is in.
• When a good idea appears mid-build, log it for later instead of absorbing it.
• Ask whether the addition serves the original goal or a different one.
• Price or schedule every change request, so its cost is visible to whoever asks.
• Ship the defined version first and learn from it.
• Revisit the logged ideas after launch, with real usage to judge them.

Scope is the agreed list of what a project will deliver. Scope creep is that list growing without anyone deciding it should. A stakeholder asks for one small extra, a developer adds a nice touch, a client wants one more report. None of them looks like a big change.

It happens most in work that has no written boundary, and in work where the person asking for changes does not see the cost.

• Having no written scope. Without a boundary there is nothing to say no against.
• Saying yes to "small" extras. Several small additions add up to a large one, and each is easier to accept than the pile.
• Absorbing changes quietly. If the person asking never sees the cost, they have no reason to stop.
• Confusing change with creep. A deliberate change that is priced, scheduled and agreed is just a new scope. Creep is the unplanned kind.
• Treating the logged ideas as a to-do list. Review them after launch with real usage, and most can be dropped.
• Letting several people add scope. Name one person who approves changes.