Milestone & Deliverable Tracker

What this tool does

CM8-73 is a working milestone and deliverable register for one project or a small portfolio. You record each item with an owner, the date you originally committed to, the date you currently expect, and — once it happens — the date it was actually done. The tool measures the slippage between those dates, flags what is overdue or due soon, works out how often you deliver on time, and prints a progress report you can take to a steering group or a client review.

Everything runs inside this single file. There is no account, no upload and no network request of any kind, so plans, client names and delivery dates never leave the computer you are using.

Milestones vs deliverables

The register holds two kinds of item, and the distinction is worth keeping:

• A milestone is a point in time — a state the project reaches. "Design signed off." "Beta live." It has no duration and nothing is handed over; it is either reached or it is not.
• A deliverable is a thing — a report, a build, an installed room — that is produced and handed to somebody who can accept or reject it.

Give every item a single named owner, not a team. "Owned by the delivery team" means owned by nobody, and it shows the first time a date moves and no one can say why. Use the acceptance criteria field to write down what must be true for the item to count as done — the argument about whether something is "basically finished" is far cheaper to have before the deadline than after it.

The baseline, and why it is sacred

Each item carries two planning dates. The baseline date is the date you originally committed to — set it once, when the plan is agreed, and then leave it alone. The current planned date is the date you now expect, and it moves as often as reality demands.

The distance between the two is the project's honesty. If you re-type the baseline every time the plan changes, every item will always read "on baseline", the average slippage will sit at zero, and the tracker will cheerfully tell you a drifting project is fine. If the scope genuinely changes and a re-baseline is agreed, record it deliberately — note it in the item, tell the people who approved the original date, and accept that the slippage history before that point is reset.

Items without a baseline still work: they are tracked, filtered and counted, but they are left out of every slippage figure rather than being counted as zero, because "we never committed to a date" is not the same as "we are exactly on time".

How slippage is calculated

Slippage is measured in calendar days, per item, and only when both dates are present:

A positive number means the item has slipped; a negative number means it is now expected earlier than originally committed. The register colours slipped items red and early items green. For open items the register also shows the time remaining:

A negative "due in" figure means the planned date has passed and the item is overdue. Open items due within the at-risk window you set on the Settings tab (14 days unless you change it) are flagged amber.

Once an item is complete, one more question is asked — did it beat the original commitment?

Note that this compares the actual date with the baseline, not with the most recent forecast. An item that slipped three times and then hit its fourth forecast was still delivered late against what was promised, and the tool says so.

Status and percent complete

Five statuses cover the life of an item: not started, in progress, at risk, complete, and cancelled. At risk is a deliberate, human judgement — the tool flags dates arithmetically, but only the owner knows that a supplier is wobbling two weeks before the numbers show it. Use it early; it is the cheapest escalation you will ever make.

Marking an item complete requires an actual completion date, and an actual date requires the status to match — the tool refuses the inconsistent combinations, because they are what quietly corrupt the on-time rate. Cancelled items stay in the register as a record but are excluded from every calculation: a plan does not get 10% better because a tenth of it was abandoned.

The % complete field is the owner's estimate of progress on the item. It is useful for spotting the item stuck at 90% for a month, but it is an opinion, not a measurement — the completion figures in this tool count whole items done, and never add percentages together.

The headline figures

Each tile states the population it is calculated from, because the honest denominator is different for each one:

Where a figure has no valid population — no items with baselines, or nothing completed yet — the tile shows a dash rather than a number, because a confident figure computed from nothing is worse than no figure. The same rules are used in the charts and the per-project table, so every view of the data agrees.

Averages hide spread: five items on time and one slipped sixty days average ten days of slippage. Use the average to compare projects and the register's per-item column to find the item that is actually the problem.

Reading the completion curve

The completion curve is the classic delivery S-curve, drawn honestly with what a register can know. The line shows the cumulative number of items actually completed by the end of each month. The figure printed at each point reads, for example, "4 done · 7 planned": the second number is the cumulative count of items whose current planned date falls on or before that month. The dashed line marks the full count of planned items — where the curve must eventually arrive.

Read the gap, not the line. When "done" tracks "planned", delivery is keeping pace with the plan. When the gap widens month on month, the project is quietly accumulating a bow wave of unfinished work that will not fit into the final month, however optimistic the statuses look. Because the planned figures use current planned dates, a re-forecast moves the plan numbers too — which is one more reason the baseline column, not this curve, is where slippage is measured.

The summary tables

Due in the next 30 days lists every open item whose current planned date falls within the next 30 days, soonest first, with its owner, days remaining and % complete. It is the agenda for a weekly review: work down the list from the top and ask each owner one question — is the date still real?

Per-project summary gives one line per project: item count, completed items, overdue count, and average slippage. The slippage cell states how many items it is averaged over, and shows a dash where a project has no baselined items, so a project cannot look healthy merely by never committing to dates. Cancelled items are excluded from every column.

Running a review with it

The tracker is at its best as the single artefact of a short, regular review. A rhythm that works:

• Filter to open items and walk the "due in the next 30 days" table with the owners present.
• Move planned dates the moment they are known to be wrong — a plan that is updated monthly is a history document, not a plan.
• Ask about anything at 80–95% complete for two reviews running. The last tenth of a deliverable is where the surprises live.
• Watch the average slippage per project over time. The absolute number matters less than its direction.

Use the search box and the type and status filters to cut the register down; every screen, the report and the CSV export respect the filter in force.

Printing and sharing

Print Report produces a report from whatever the current filter shows: header, the headline tiles, all four charts, both summary tables, the full register and your closing notes. Print to PDF to circulate it. The scope line under the title states the filter in force — clear the filters before issuing anything described as the whole plan.

Saving your work

Items, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. 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 and includes every filtered record, not only those drawn on screen. Reset asks twice, then erases everything this tool has stored. There is no undo.

Accuracy & disclaimer

This tool calculates from the dates and statuses entered, and cannot tell whether a baseline was quietly moved, whether a status is optimistic, or whether "complete" met the acceptance criteria. Slippage figures are calendar days, not working days, so a two-day slip over a weekend still reads as two days.

It is a record-keeping and calculation aid for internal planning. It is not an earned-value management system, it does not model dependencies between items, and a report from it is not evidence of contractual delivery — keep whatever formal acceptance records your contracts require alongside it.