Scope and change control

Scope does not explode by one large decision. It explodes through forty small requests, each of which got “sure, that’s easy”.

Every one of them really was easy. The forty together are a second project that was never priced and never scheduled.

Change control is not refusing change. It is pricing change before accepting it. The difference between the two is the difference between a project that is delivered and one that is cancelled.

The baseline

Nothing can be controlled without a written baseline, or every discussion becomes an argument about whether the request is a change at all.

The baseline is four lists.

List	What is in it
Processes	Every in-scope process by name: “purchasing with three-way matching”
Entities and sites	Which company, which branch, which warehouse
Integrations	Every external system by name and the direction of data
Reports and documents	Every report and printed document, counted as a number

The last list is the one that always explodes. The statement of work says “standard reports plus custom reports as required”. “As required” means forty reports by month five.

So write a number: twelve custom reports, and anything beyond that is a change request. The number is negotiated calmly today, and under pressure in month five.

The four questions before “yes”

Every request, however small, passes four questions. In writing, on a half-page form.

1. What problem does it solve? — not what screen is wanted. A third of requests die here, because the problem has a standard solution that already exists.
2. What does it cost? In days: design, build, test, document. Testing and documentation are half the cost and are always forgotten.
3. What does it do to the schedule? Every change delays something — and the question is what, specifically?
4. What is its permanent cost? Every customisation is retested at every upgrade, forever. This is the item that makes management refuse what they were about to accept.

Question four is your strongest instrument. A request costing three days looks cheap; the same request costed at two test-days per upgrade over seven years looks like something else entirely.

Classifying requests

Three classifications, and no fourth.

Classification	Definition	Route
Clarification	Inside the baseline, disputed interpretation	Settled in the working team, 48 hours
Change	Outside the baseline, needed now	Priced and approved before work starts
Phase two	Outside the baseline, deferrable	Logged rather than refused

The third row is the most important relationship instrument you have.

“No” produces conflict. “Yes” produces delay. “Logged for phase two” produces a relationship. A written phase-two list shows the customer their request was not dismissed, and shows management the size of what has been deferred — usually the basis of a later contract.

Nothing is refused on this project; it is deferred or priced.

One request, read through the four questions

Take the commonest request on any project: “we want an extra field on the printed invoice.”

The question	The answer
What problem?	The customer wants their PO number on the invoice to match their payment
Is there a standard solution?	Yes — the field exists on the document and was never enabled in the template
What does it cost?	Two hours of configuration, not three days of development
Permanent cost?	Zero — because it is configuration rather than customisation

The result is that the request was delivered the same day, and would not have been had it been accepted as it arrived.

It arrived phrased as a solution — “add a field” — rather than as a problem. The first question returned it to its problem, and the solution turned out to already exist.

That is the real return on the four questions: not refusing requests, but discovering that a third of them need nothing built. A project applying them from week one delivers more requests rather than fewer, because it does not spend days on what was a setting.

The economics of the small request

Three numbers make the conversation possible without conflict.

• How many requests have been raised to date.
• Their total in days if all were built.
• How many days of contingency remain in the plan.

Present all three together at the steering committee monthly. When the sponsor sees that the accumulated requests total thirty-six days against fourteen days of contingency in the plan, the choice becomes their decision rather than your battle.

That is the difference between a project manager who says no and one who presents numbers.

What you actually do in this station

• Write the baseline in its four lists, with numbers in the report list.
• Design the change request form on a half page with the four questions.
• Open the phase-two list on day one, rather than when it fills up.
• Compute the three numbers monthly and present them at the steering committee.
• Go back to the assumptions register: every assumption disproved is a pre-justified change request.

The three commonest mistakes

One: a baseline without numbers. “Reports as required” becomes forty reports.

Two: accepting small requests verbally. They appear in no calculation, and their total is discovered in month six.

Three: refusing instead of deferring. Conflict gets built around a request that could have been logged.

The acceptance test for this station

1. Show the baseline in its four lists, with numbers.
2. Show the change request form and one completed request.
3. Explain how question four changes a management decision, with a worked example.
4. Show the phase-two list and its total in days.
5. Show this month’s three numbers.

What comes next

Scope is protected. The next station runs into the real constraint: the plan and the team — and why the customer’s staff time, rather than money or technology, sets your go-live date.