Scope & Change Tracker

What this tool does

CM8-297 holds two things in one register: the scope you agreed at the start, and every change raised against it since. Each row is a baseline item or a change, with its effort, cost and schedule impact, who asked for it, who decided it and when. The tool sums the baseline, nets the approved changes against it, expresses the difference as a percentage, and shows what happens if everything still pending is approved as it stands.

Everything runs inside this single file — no account, no upload, no network request — so costs, rejected requests and internal reasoning stay on your computer.

What scope control actually is

Scope control is not saying no. Plenty of changes should be approved: requirements are discovered, the world moves, and a project that cannot absorb anything new delivers exactly what somebody guessed at the start. Control means something narrower and harder — that every change is visible, costed and decided by somebody with the authority, so the project ends where everyone expects it to.

The failure mode is rarely a dramatic argument. It is a series of small, individually reasonable extras, each absorbed by somebody helpful, none of them written down. Nobody ever decided the project would take fifteen per cent longer. It simply does, and the conversation about why happens at the end, when it is a post-mortem rather than a decision.

The baseline is the thing changes are measured against

A change is only a change relative to something. Enter your agreed scope as baseline rows — one per deliverable block, with its effort — and the tool sums them into the baseline every percentage is measured from. If you would rather not itemise, put a single figure in the settings instead; summed rows win where both exist, because rows can be read and a number cannot.

Here is the uncomfortable observation. Most projects have no written baseline. There is a proposal, a plan, a set of workshop notes and a shared sense of what was meant — and when someone asks late on whether the work grew, nobody can answer, because there is nothing to compare against. That is why creep is usually invisible rather than absent. An hour spent writing five baseline rows at the start is the single highest return in this tool, and it is worth doing even if the numbers are rough: an approximate baseline still catches a fifteen per cent movement.

The five entry types

• Baseline — agreed starting scope. Effort only: a baseline item has no cost or schedule impact, because it is not a change to anything. The tool refuses that combination.
• Addition — new work. Effort is always positive; the sign is handled by the type.
• Removal — work taken out. Enter the effort as a positive number and the tracker subtracts it.
• Clarification — the wording was ambiguous, this settles it, and nothing moves. Worth recording precisely because it stops the same ambiguity being re-litigated as an addition later.
• Exclusion — something explicitly not in scope.

Exclusions deserve their own paragraph, because they are the type people leave out. The cheapest scope argument you will ever have is the one you had in writing at the start. Writing down "integration with the customer's own portal is excluded" costs one line and settles a question that would otherwise surface in week nine, framed as an assumption rather than a request, at the worst possible moment. Anything raised in a requirements workshop and consciously left out belongs here.

Justification protects both sides

Every addition needs a justification, and the tool will not save one without it. This is not paperwork for its own sake. It protects whoever is delivering, because a change with a written reason cannot later be described as gold-plating. And it protects whoever is asking, because a request with a reason attached gets decided on its merits rather than on who asked most recently.

Write the reason as fact and consequence: what changed, and what happens if the change is not made. "Because the customer wants it" is not a justification; "the carrier withdrew its manual tracking portal, so from March there is no way to answer a tracking call without a separate login" is one, and it survives the meeting where somebody asks why the project grew.

Measuring creep

Creep is expressed as a percentage of baseline effort, so it is comparable across projects of different sizes:

Only approved changes count towards creep — pending ones have not happened yet, which is what the third bar on the creep chart is for. Effort is the honest denominator: cost and schedule follow from work content, but they also move with rates, contingency and who happens to be available, so a cost-based creep figure mixes two different stories. The tool reports cost separately.

There is no universal acceptable figure. Ten per cent on a well-specified replacement project is a lot; ten per cent on an exploratory build is nothing. Set the alert threshold to whatever your contingency actually is, and treat crossing it as a prompt to talk to the sponsor rather than a failure.

Pending decisions are the hidden risk

The number that surprises people is the longest pending decision. A change sitting unanswered for three weeks looks harmless in a register, and it is anything but, because work rarely waits. Somebody starts designing it. Somebody stops ordering the consumable it replaces. Somebody promises a customer. By the time the decision is taken it is not a decision at all — it is a ratification, and rejecting it costs more than approving it would have three weeks earlier.

A long pending queue means the baseline is already fiction, whatever the approved figure says. The tool flags anything waiting more than a fortnight and sorts the pending table by wait, longest first. That table is the agenda for the next change board, in order.

Rejected and deferred entries are the evidence

A register where every change is approved is not evidence of a well-run project; it is evidence of a queue with a rubber stamp. Rejections and deferrals are what prove the process has teeth, and they are worth keeping visible for two reasons. They show the sponsor that the discipline is real, and they preserve the reasoning — a rejected change with its justification intact is the first thing you reach for when the same request comes back next quarter. Deferred is the honest middle answer for a good idea in the wrong phase: it keeps the request alive without letting it into this one.

This is not a contract variation register

This tool is internal: it tracks what the work is, against what was agreed, in effort and money you can see. Where the change is a contractual variation to be issued to and priced with a customer — quoted, instructed, signed and invoiced — that is a different document with different obligations, and the Change Order & Variation Register handles it. Many projects run both, and the two are not duplicates: a change can be real work here and never touch the contract, and a variation can be issued for work that was always in scope but was priced separately.

The spreadsheet workflow

Baselines usually already exist in a plan or a proposal, and retyping them is wasted effort.

• Spreadsheet template saves a CSV whose headings are exactly this tool's column names, with a guidance row giving the date format and the accepted values for the entry type and decision lists.
• Fill it in — baseline rows first, then changes — then delete the guidance row and save as CSV.
• Import spreadsheet reads it back. Columns match by heading, so order does not matter and extra columns are ignored. Rows failing validation — an addition with no justification, an approved change with nobody named — are skipped and reported by row number.

The file is read in your browser: nothing is uploaded, and importing adds to what is here.

FAQ

How small is too small to log? If it changes what gets delivered, log it, however small. Creep is made almost entirely of items that were individually too small to bother with. If it takes less time to do than to write down and changes nothing about the deliverable, do it.

Effort or cost — which is the real measure? Effort. It is the work content and it moves the end date. Cost is what effort is worth this month, and it can be flattered by rates or absorbed by contingency without the work getting any smaller.

A change nobody will approve or reject — what do I do? Leave it pending and let it age in the table. The wait is the finding, and the number is more persuasive at a steering meeting than the request ever was.

Should rejected changes be deleted? Never. The rejection and its reason are the most valuable rows in the register when the request returns.

Saving your work

Scope items, settings and the report header are written to this browser's local storage as you type. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work, including every filtered record rather than only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

The arithmetic is sums and percentages on the numbers you enter, and the tool does it faithfully. The limitation is what never gets entered. Scope that grew quietly — work absorbed into an existing task, a helpful extra nobody wrote down, a requirement re-interpreted in a workshop — leaves no row here, and that is exactly the scope that hurts. A register showing two per cent creep on a project that everybody knows grew is telling you about the register, not the project.

Creep figures are only as sound as the baseline. A baseline reconstructed after the work started will quietly absorb the early changes and understate everything that follows. This is a record-keeping and control aid, not a contractual instrument: nothing here creates, varies or evidences an agreement between parties.