Scope creep: when “one small change” takes over the project

Scope creep starts when small agreements stop being visible as project decisions. Each seems minor, but together they change the scale of delivery.

What is and is not a scope change

Not every additional action should be a paid change. Fixing a feature that fails agreed criteria fulfils an existing obligation. Clarifying an ambiguous requirement also calls for an assessment of both parties' responsibilities.

A change is a new need or approach that cannot reasonably be inferred from agreed scope. Distinguishing these categories prevents both unjustified charges and unpaid extra work for vendors.

How to recognise scope creep

• New features are agreed verbally in meetings.
• Ideas go directly to developers without the product owner's decision.
• There is no change log, or it is updated afterwards.
• Costs and dates grow, while the baseline scope stays formally unchanged.
• Each department tries to add its own needs to the implementation.
• Nobody knows what was removed when new work was added.
• The team does not distinguish defects, clarifications and new requirements.

Every change involves a trade-off

The price is not always another invoice. With a fixed team and budget, a new feature can replace a lower-priority item. Alternatively, the deadline or funding can change.

Problems arise when the organisation expects to retain the same scope, deadline and budget while work increases. The cost then appears as lower quality, delay or acceptance disputes.

A minimum change-control process

1. Describe the need and its business rationale.
2. Classify it as a defect, clarification or new scope.
3. Assess impact on cost, schedule, risk and other features.
4. Recommend adding, deferring, replacing another item or rejecting.
5. Obtain a decision from an authorised owner.
6. Update the backlog, budget, schedule and documentation.

Prevention before the project starts

• Define the goal and boundaries.
• Document exclusions.
• Agree priorities and first-release scope.
• Prepare acceptance criteria.
• Specify change estimation and approval in the agreement.
• Assign one owner for product decisions.
• Review the change log regularly.

Change can add value

A good process does not block ideas. It distinguishes changes that increase value from features added simply because somebody saw a similar screen elsewhere.

The key question is not “can we add it?” but “is this the best use of the remaining budget and time?” Ongoing change control is part of client-side IT project oversight.