Scope creep: what one extra dashboard does to the plan
The dashboard is a good idea. It still needs time, testing and someone to build it. Compare adding it, replacing another deliverable and saving it for the next release.
The warehouse barcode pilot is nearly ready. During a review, someone asks for a live dashboard showing picking progress.
It would help the supervisors. The team says yes, puts it on the task list and keeps the same launch date. Nobody decides what happens to the work already promised.
Scope creep is uncontrolled growth in what a project is expected to deliver. A new request becomes a problem when the team absorbs it without assessing and agreeing its effect on time, resources, cost or the original result.
Change control gives the team a way to evaluate that request and record a decision. A worthwhile change can be approved. The plan then needs to reflect what was approved.
First, check what was already included
Our fictional project covers a barcode pilot in one warehouse zone. It includes working transactions, labels, trained users and a simple daily report. A live dashboard was explicitly excluded from this release.
That last detail matters. If the dashboard had been part of the agreed acceptance criteria, discovering it late would expose missing planned work. It wouldn't become optional just because the estimate omitted it.
The project charter example establishes the assignment and decision authority. The work breakdown structure makes the deliverables easier to inspect. Use those agreed boundaries before arguing about whether a request is small.
Here, the dashboard adds a new deliverable. The manager asks the delivery specialist to estimate the build, its additional tests and the effect on the remaining pilot work.
Four days of work need somewhere to go
There are eight working days left in this simplified plan. One delivery specialist does the remaining work in sequence, with the warehouse team available for the planned reviews.
| Remaining work | Specialist effort and duration |
|---|---|
| Complete the transaction interface | 3 working days |
| Build the agreed daily report | 2 working days |
| Run pilot acceptance checks | 2 working days |
| Train users and hand over | 1 working day |
| Total | 8 working days |
The dashboard needs four more specialist-days, including its additional tests. It must be ready before the pilot acceptance checks if it is included at launch. The original two-day acceptance activity still covers the integrated pilot.
For this example, each specialist-day costs €600. The remaining baseline work therefore costs 8 × €600 = €4,800. These are fictional remaining delivery costs, not the project's full budget or an estimate for a real dashboard.
There is no spare capacity in this sequence. Changing the task list changes the finish unless something else changes too.
Compare the responses before agreeing to one
The team has three responses worth putting beside each other.
| Response | Pilot work remaining | Finish from now | Remaining pilot cost | Consequence |
|---|---|---|---|---|
| Add the dashboard | 12 specialist-days | Working day 12 | €7,200 | Keep the daily report and add four days |
| Replace the daily report | 10 specialist-days | Working day 10 | €6,000 | Remove two days, add four; confirm the dashboard meets the reporting need |
| Defer the dashboard | 8 specialist-days | Working day 8 | €4,800 | Keep this pilot unchanged; assess and fund later work separately |
Replacing the report doesn't recover all four days. It releases two. The net addition is still two days and €1,200.
Deferring the dashboard doesn't make its cost disappear. It leaves the work outside this pilot. Someone must decide whether and when to fund it later.
Try a different dashboard estimate below. Keep the same specialist and original work so the comparison stays clear.
Same work capacity, different choices
Where will the new work fit?
One delivery specialist, eight working days in the original remaining plan. All work below runs in sequence.
Revised pilot finishDay 124 working days beyond the target
Remaining pilot cost€7,200€2,400 above the remaining baseline
Swipe sideways or focus the timeline and use arrow keys. The task selector and table show the same values.
Interface: day 0 to day 3, 3 specialist-days. Keep the daily report and add the dashboard before acceptance.
| Work | Start | Finish | Cost |
|---|---|---|---|
| Interface | 0 | 3 | €1,800 |
| Daily report | 3 | 5 | €1,200 |
| Dashboard | 5 | 9 | €2,400 |
| Acceptance | 9 | 11 | €1,200 |
| Handover | 11 | 12 | €600 |
At a two-day estimate, replacing the two-day report preserves day 8 in this model. Adding the dashboard still pushes the finish to day 10. That difference follows from the work removed, rather than from calling the request minor.
Actual projects need dependency and resource checks. The critical path example shows why extra effort on one activity doesn't always move the finish by the same amount. Our sequential example deliberately keeps that arithmetic simple.
Put the trade-off into a short change request
A useful request gives the decision-maker enough information to choose. For this pilot, it could read as follows.
The request is a proposal, not an approval. Keep the estimate, assumptions and decision with the revised plan so the next review starts from the same agreement.
PMI's scope-creep discussion describes how small additions can accumulate and calls for impact assessment and agreed handling of changes. The process can be brief when the impact is brief. It still needs a clear owner for the decision.
Update the work people actually use
If the sponsor approves the substitution, remove the daily report from the current scope and add the dashboard's definition and acceptance conditions. Update the schedule, remaining cost forecast and responsibilities together.
Tell the users what has changed. Otherwise one team can expect both outputs while another works to the substituted plan. The RACI guide helps separate who prepares the change, who approves it and who needs to know.
For iterative delivery, the same issue can appear when a new item enters a full release. Reprioritising may be appropriate, but the team still needs to know which other item leaves or which commitment changes. Agree the change process around how the team works.
If the dashboard is deferred, keep it visible for a later investment decision without leaving it on the pilot's completion checklist. The benefits realisation note helps separate the expected benefit from the fact that a feature was delivered.
The next time a useful request arrives, compare the revised work with the people and time available before promising a date. Then record the choice. The team can support the idea and still give an honest answer about its consequences.
Sources and example notes
- Abramovici, A., PMI, 2000. Controlling scope creep. Accumulating additions, impact assessment and handling agreed changes. The barcode example and all calculations here are original.
All work estimates, costs and scope decisions are fictional. The model starts today, after earlier work, and excludes spending already incurred. Its single-specialist sequence is illustrative; it does not calculate a general project network or estimate delivery risk.