If asking costs nothing, request volume stops measuring demand and starts measuring price.
Here is a question worth putting to a delivery leadership team, with the change register closed. Over the last quarter, name every route by which somebody outside this team caused work to be done. Not every route by which they should have — every route by which they actually did.
The list comes back longer than the process document. There is the formal change request, which everyone can describe. Then there is the steering meeting where a director says a thing would be useful and three people write it down as a decision. The email thread that ends "can you just". The corridor conversation with a senior stakeholder. The client-side counterpart who asks the analyst directly, because they have worked together for two years and it is quicker. And the largest channel of all, which is the team noticing something needed doing and doing it.
One of those routes produces a record and a price. The rest produce neither. Work flows down the cheapest available channel, as it does in every system with differential pricing, and the change control system reports faithfully on the only channel that costs anything to use.
The Strategic Context
Asadullah Khan, writing in Cost Engineering in 2006, defines the problem more precisely than the usual formulation. Scope creep, he writes, describes unauthorised scope changes, and unauthorised changes "may creep into project scope as a result of verbal instructions, e-mail instructions, written instructions that have been issued without realizing the magnitude of change". [SOURCE DETAILS REQUIRED]
Read that list carefully. It is not a list of failures of will. It is a list of channels — three of them, each with a different signature. A verbal instruction leaves no artefact. An email leaves an artefact nobody classifies as a change. And the third is the subtle one: a written instruction, properly issued through a legitimate route, whose magnitude nobody recognised at the time. That last channel defeats discipline entirely, because everyone involved followed the process.
The scale claim comes from a different author in the same journal. Nick Lavingia states flatly that the major reason for cost overruns and schedule delays on most projects is scope creep. [SOURCE DETAILS REQUIRED] It is a practitioner's assertion rather than a research finding, and it is offered here as one — but it locates the problem in the intake, not in the estimate, and that relocation is the useful part.
What the Standard Controls Actually Govern
The teaching material's prevention rules are the ones most organisations have. Define who may submit a change. Define who may approve one. Define which elements cannot be changed at all. Require notification when scope changes.
Every one of those is sound, and every one of them operates on the visible channel. They regulate the front door. They say nothing about the side door, and nothing at all about the fifth route in the list above — the team doing work because it needed doing.
The same material is unusually clear about why unmanaged change is expensive, and its list is worth restating because it is more specific than the usual complaint about creep. Rework arrives after the project is already under time pressure, so it is done concurrently rather than sequentially. The activity crosses the boundary between planning and executing, so it is planned while being built. Control is exercised at the point where the team is least able to be proactive. The budget is affected twice — once by implementing the change, and once by the cost of the additional planning the change required. And the project simply gets bigger, which increases the amount of process activity it needs to carry.
The fourth of those is the one that connects to the intake question, and it points at an omission most organisations share.
The Cost of Considering
Hans Robbers, writing on scope in 2009, asks a question that exposes the whole structure. Discussing the impact analysis that a change request triggers, he asks: "How many of you have a separate budget for impact analysis, irrespectively if the change will be approved?" [SOURCE DETAILS REQUIRED] The article is behind a subscription and only its opening is available, so what follows from the question cannot be reported here — but the question stands on its own.
Almost no organisation holds such a budget. Assessment is absorbed by the delivery team, from the delivery team's time, at no charge to the requester. The consequences are not subtle.
Requesting is free, so the volume of requests measures the price of asking rather than the strength of the need. A change register with two hundred entries and eleven approvals is not evidence of good discipline; it is evidence that two hundred requests cost their originators nothing and consumed a great deal of somebody else's capacity.
Rejection is expensive for the team and free for the requester, which inverts the incentive that a control system is supposed to create. The team learns that the cheapest response to a marginal request is to absorb it quietly rather than to assess and refuse it, because absorbing it is quicker than the paperwork.
And the assessment cost is invisible in the accounts, so a team that spends fifteen per cent of its capacity evaluating changes that were never approved shows up as a team running behind schedule.
Robbers adds two channels the standard model does not capture at all. The first is change in the approach rather than the functionality — a different integration pattern, a different testing strategy, a different sequence — which no functional change register is designed to catch. The second is the hardest: the team's own "willingness … to make the project a success and therefore spent time on support activities not foreseen at the start of the project". That is discretionary effort, it is exactly the behaviour every leader says they want, and it is unpriced by construction.
Where the Boundary Is Supposed to Sit — and a Genuine Disagreement
Khan places the boundary in the work breakdown structure and states the convention without qualification: what the structure contains is in scope, and "Anything not shown clearly in a WBS is out of project scope, along with any implied activities." He adds, drily, that many a project manager has come to grief for not preparing a comprehensive enough structure. [FACT CHECK REQUIRED]
That is a clean rule, and it is worth being honest that it is contested. It holds that silence means exclusion. The opposite convention — that a reader encountering an expectation the document does not mention has no way to tell whether it was considered and declined or simply not written down, and therefore reads the silence as a promise not yet detailed — is argued elsewhere in this collection from different evidence, and it describes how expectations actually form. [Related article: Silence Reads as a Promise]
Both can be true at once, and their coexistence is the practical problem. Khan's rule describes what a contract administrator will enforce. The other describes what a stakeholder believes. An enterprise operating on the first while its clients operate on the second will win the argument and lose the relationship, which is a poor trade in any business that expects repeat work.
The Same Channels, Client-Side and In-House
A professional services firm, hypothetically, delivers a fixed-fee advisory engagement. The formal variation process exists and is used twice. Meanwhile the client's project sponsor calls the engagement manager weekly, and each call adds a small analysis — a sensitivity, an extra jurisdiction, one more scenario. None is large enough to raise. The engagement lands at 130 per cent of budgeted effort, and the post-mortem records "scope creep" as though it were weather.
The in-house version is structurally identical and harder to see. An equipment manufacturer's internal engineering group, hypothetically, supports plant improvement requests from operations. There is a request form. There is also a plant manager who walks over. Because the group is a cost centre, nothing it does is priced to anyone, so there is no mechanism anywhere in the system that registers a preference between two competing requests. The group is chronically late on the projects that were formally approved, and chronically praised by the plants it helped informally.
In both cases the fix is not more control over the formal channel, which is already the best-behaved one.
Decision Framework
The channel audit. List every route by which a commitment can enter the team's work. For each, three columns: does it produce a record; does it produce a price; and who is authorised to close it.
The audit is done by the delivery team, not by governance, and it takes about an hour. Its value is that it makes the informal channels enumerable. A route nobody has named cannot be closed, and most organisations discover that the majority of their intake arrives through two or three unnamed routes that everybody uses and nobody has ever described.
The third column is the one that stalls. "Who is authorised to close it" frequently has no answer for the routes that matter, because closing a channel means telling a senior person that a habit of theirs is now out of bounds. That is a decision for the leadership team, and if it is not taken, the audit is a description rather than a control.
The standing impact-assessment budget. A named allowance, held outside the delivery baseline, that pays for assessing changes whether or not they are approved. Two effects follow. The cost of considering becomes visible and can be reported, so a team consuming a sixth of its capacity on evaluation can say so. And refusal becomes affordable, because the assessment that supports a refusal is funded.
Three tests read the result.
The record test. For the last ten additions to scope, which channel did each arrive through? Where more than half arrived through unrecorded routes, the change register is a sample rather than a record, and the reporting built on it is unreliable in a known direction.
The free-work test. What share of the team's week goes to work nobody asked for in writing? Ask the team, not the system; the system does not know.
The price test. What does it cost a requester to ask? If the answer is nothing, the request volume carries no information about priority, and the team's queue is being set by whoever asks most often.
From Strategy to Execution
Immediate. Run the channel audit on one delivery team and read the result at the leadership meeting. Do not accompany it with a policy. The audit is uncomfortable enough on its own, and the discomfort is the mechanism — most of the named channels terminate in someone senior.
Medium-term. Establish the impact-assessment budget and report its consumption alongside delivery performance. Then close the two or three highest-volume informal channels by naming an owner for each, accepting that closing a channel means someone loses a convenience they value. Khan's advice on timing applies: an effective change control mechanism must be in place from the start of scope planning, not introduced once the register starts filling.
Long-term. Decide what the enterprise's posture is on discretionary effort. Absorbing unasked-for work is a genuine strength and it is also the largest unpriced channel in most organisations. The workable position is not to suppress it but to make it visible — to ask teams to record it rather than to stop doing it — so the enterprise can see how much of its capacity is being allocated by goodwill rather than by decision. [Related article: Drivers, Supporters and Observers: Who Is Allowed to Change What Your Program Is For]
Signals to Monitor
- The ratio of change requests raised to changes approved, read as a price signal rather than as evidence of rigour.
- The proportion of scope additions with no corresponding register entry, sampled rather than reported.
- Effort spent assessing changes that were never approved, as a share of team capacity.
- Delivery teams consistently late on formally approved work while receiving informal praise from the parties they helped outside the process.
- Requests arriving directly to individual contributors rather than through a role.
- Post-engagement reviews that name "scope creep" as a cause without naming a channel.
Questions for the Leadership Team
- Name every route by which work enters our delivery teams. How many produce a record, and how many produce a price?
- For our last ten scope additions, which channel did each arrive through?
- What does it cost anyone in this organisation to ask a delivery team for something?
- Who is authorised to close an informal channel, and have they ever done it?
- How much of our capacity is being allocated by goodwill rather than by decision — and would we know?
- When our convention and our client's convention about unstated scope disagree, which do we intend to act on?
Closing Perspective
Scope creep is usually treated as a discipline problem inside the delivery team. The delivery team is the one party in the system with no ability to fix it, because the channels that matter originate outside them and terminate in people they cannot refuse.
The controllable variable is not the team's firmness. It is the price of the routes. An enterprise that leaves one channel priced and every other channel free has already decided how its capacity will be allocated, and it should not be surprised by the outcome. Naming the channels is cheap, funding the cost of considering is nearly cheap, and closing the two or three that carry the most volume is the part that requires a leader to accept the inconvenience personally. [Related article: The Estimate Was Made by the People Who Needed to Win] [Related article: Value Management Is Not Cost Reduction] [Related article: The Clock Starts Before the Project Does] [Related article: The Front End Owns the Outcome] [Related article: Visibility You Cannot Use]
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.