Scope, and what happens when it changes

Your requirements document says what you need. The scope says what is being built, for this price, in this project. They are not the same document, and confusing them is expensive.

The fit-gap matrix

This is the bridge between the two, and the most valuable page in the whole project. Every requirement gets a row, and every row gets a verdict.

ID	Requirement	Verdict	How	Days	Priority
SAL-003	Approve orders above a limit	Configuration	Standard approval rule	0.5	Must
INV-011	Track stock by branch	Standard	Multi-warehouse	0	Must
FIN-014	Block duplicate vendor bills	Standard	Built-in duplicate check	0	Must
SAL-021	Commission by product family	Custom	Custom module	6	Should
REP-004	Margin per shipment	Configuration	Analytic accounting	2	Must
HR-007	Shift roster feeding payroll	Custom	Custom module	12	Must
SAL-030	Rebuild our old quote layout exactly	Process change	Use standard layout	0	Could

Four verdicts are enough:

• Standard — Odoo already does it. No cost.
• Configuration — settings and setup, no code.
• Custom — code must be written. Has a day count and an upgrade cost forever.
• Process change — the system will not do it that way, and the recommendation is to work differently.

Read the custom rows carefully. Each one is a permanent cost: it must be retested at every upgrade and explained to every new developer. A project with thirty custom rows is a different animal from one with three, whatever the total price says.

Also read the process change rows, because they are the ones that fail politically. Somebody in your company is going to be told to work differently. Find out now whether they will accept it.

What “scope” actually is

The signed scope should be short and contain:

1. The fit-gap matrix, agreed line by line.
2. The list of apps being implemented, and the edition.
3. Which legal entities, branches and locations are included.
4. How much data is migrated, and how much history.
5. Who is trained, in what, and how.
6. The phases, their deliverables and their sign-off.
7. Out of scope — repeated from your requirements document and expanded with anything found during fit-gap.
8. Assumptions, and what happens if one is false.

If the scope is a paragraph in a proposal, you do not have one.

Change requests

Scope will change. Every project discovers something in month two that nobody knew in month zero. That is normal, and it is not a failure. What matters is that changes are visible and priced instead of absorbed silently.

A change request needs five things, and fits on one page:

CR NUMBER ........ CR-007
RAISED BY ........ name, date
WHAT ............. the new or changed requirement
WHY .............. what happens if we do not do it
IMPACT ........... days ......  cost ......
                   effect on the go-live date ......
                   requirements affected: ......
DECISION ......... approved / rejected / deferred
                   by ...... on ......

Three rules make it work:

• Nothing is built without one. Not even a small thing, especially not a small thing. Untracked small things are how projects lose a month.
• The decision owner signs. One person, named in the readiness checklist.
• Every change shows its date impact. Cost is easy to see; a slipped go-live is what actually hurts.

Keep a visible register of every CR, approved or not. At the end it explains exactly why the project cost what it cost, and it settles every argument about it.

Without a change process 7 steps

1. A manager mentions it to the consultant in a corridor.
2. The consultant agrees, because it sounds small and the meeting is nearly over.
3. It is built, and it takes six days rather than the two it looked like.
4. Two other requirements slip, and nobody connects the two facts.
5. Go-live moves by three weeks. No single decision caused it.
6. The final invoice is higher than the quotation and nobody can explain the difference.
7. The relationship ends badly over a sum neither side can account for.

Not the money. The fact that at the end, neither side can reconstruct where it went.

With one 4 steps

1. The request is written on one page: what, why, and who asked.
2. The partner prices it — six days, and one week on the go-live date.
3. The decision owner sees the price and the date together, and decides.
4. Approved or rejected, it goes on the register with the date and the name.

Every change is a decision somebody made with the price in front of them.

Contingency

Reserve about 10–15% of the budget and a few weeks of time for changes you cannot predict. Not padding — a decision you make in advance so the first real change does not become a crisis.

If it goes unused, you finish under budget. It never goes unused.

Warning signs

• Work being done that is not in the matrix and has no CR.
• “We will just add that quickly.” Nothing is quick, and quick things are never documented.
• Requirements being agreed verbally in meetings without reaching the register.
• The custom list growing while the standard list stays the same size.
• A new department asking to be included after the scope was signed.

The last one is the most dangerous, because it is usually reasonable. Handle it as a second project or a formal change, never as goodwill.

What to do when it slips

Something will. When it does, you have exactly three levers and you must pick one:

• Move the date. Cheapest, if your deadline is genuinely flexible.
• Cut scope. Drop Shoulds and Coulds to a later phase. This is what MoSCoW priorities were for.
• Add money. More people rarely makes a late project faster, but it sometimes helps early.

What does not work is agreeing to the original date and hoping. That is how systems go live half-tested, which costs more than every other option combined.