A deadline almost never breaks on the day it breaks. It breaks three weeks earlier, when a client starts taking four days to answer a question instead of one, and nobody writes that down. Project delivery risk is the gap between what your plan assumes and what your week is actually producing, and it is visible long before the date moves — if you are tracking the right things. This article gives you the four signals, the thresholds, the worked example, and the escalation rule. You can run all of it in a blank spreadsheet before lunch.
Why Status Reports Hide Project Delivery Risk
Most small teams track status as a color or a percentage. Both are self-reported opinions, and both lag reality.
Percent complete fails because the remaining effort in a deliverable is not spread evenly. A landing page that is 90% designed is 0% reviewed, 0% approved, and 0% deployed. That last stretch is where the handoffs live, and handoffs are where calendar time disappears.
Red-amber-green fails for a different reason: nobody wants to be the first person to say amber. A task stays green until the person holding it can no longer pretend, and that moment usually arrives after the point where you could have done something cheap about it.
The fix is not more reporting. It is to stop measuring how people feel about the work and start measuring observable facts: how long something has been waiting, how many times it has come back, and how far your honest forecast has drifted from the plan you agreed.
The Four Signals That Move Before the Date Does
Four indicators cover most of what actually kills a delivery date. Track them weekly, per project.
1. Dependency age
Every item blocked on someone outside your team — client feedback, an API key, a legal sign-off, a logo file — gets a date stamp for when you asked. What matters is not that it is open. It is how many business days it has been open.
A working threshold: 3 business days is amber, 5 is red. A red dependency is not a communication problem to be solved with another polite follow-up. It is a schedule problem, and it should be named as one.
2. Milestone drift
The day you agree a delivery date, freeze a baseline date for each internal milestone behind it. Then, every week, write your honest forecast date next to the baseline. The number you care about is the delta in days and its direction.
One milestone two days late is noise. The same milestone drifting one or two days every week for three weeks is a trend, and trends arrive at the delivery date exactly on schedule.
3. Rework rounds
Count how many times each deliverable comes back for changes. Budget two rounds and treat a third as a signal, not an inconvenience. A third round usually means the brief was ambiguous, the acceptance criteria were never written, or the person reviewing is not the person who can approve.
Rework is the cheapest early warning you have, because it shows up in week one or two, long before the schedule math turns ugly.
4. Unbaselined scope
Log every request you accepted after the date was agreed, with an hours estimate, including the small ones. The quick favor that takes forty minutes is not the problem; eleven of them are.
Threshold: once accepted extras pass roughly 5% of the original estimated hours with no change to the date or the fee, you are no longer delivering the plan you quoted.
Build the Register in a Blank Spreadsheet
One sheet, one row per commitment. Ten columns is enough:
- Item — the deliverable or milestone, named the way the client would name it
- Owner — one person, never a team
- Baseline date — frozen at kickoff, never edited
- Forecast date — updated once a week, honestly
- Drift — forecast minus baseline, in days
- Blocked by — who or what you are waiting on, blank if nothing
- Waiting since — the date you asked
- Days waiting — today minus waiting-since, calculated, not typed
- Rework rounds — a counter you increment
- Added hours — scope accepted after baseline
Three calculations do the work. Days waiting subtracts the waiting-since date from today. Drift subtracts baseline from forecast. Status is a nested IF that returns Red when days waiting is 5 or more or drift is 5 or more, Amber at 3, and Green otherwise. The point is that status is computed, not chosen. Nobody gets to feel optimistic in a formula cell.
Sort the sheet by status, then by days waiting, descending. The top five rows are your week.
A Worked Example: A Six-Week Site Rebuild
Say you have agreed a six-week rebuild with a fixed launch date tied to a client event. Milestones: sitemap approved end of week 1, design approved end of week 3, build complete end of week 5, launch end of week 6.
Week 1: sitemap goes out Tuesday. Approval lands Friday. Drift zero, days waiting 3 — amber, but it closed. You note that the client’s turnaround is three days, not one, and adjust every downstream forecast by two days immediately. That single adjustment is the whole discipline.
Week 2: you send homepage design Wednesday. On Friday it is still open. Days waiting 2. Green, no action.
Week 3: the design comes back Tuesday with changes from a stakeholder who was not in the kickoff. Rework round 2. It goes out again Wednesday. By Friday it is still unapproved — days waiting 3, amber — and your design-approved forecast has moved to the middle of week 4. Drift is now 4 days. The client has also asked for a blog template that was not in scope: 6 added hours on an 80-hour estimate, which is 7.5%.
That is two indicators in trouble in the same week. Under the rule below, you escalate now, in week 3, when the remaining schedule still has slack. You do not escalate in week 5, when the only options left are unpaid weekend work or a broken promise.
The message is short: design approval is four days behind, the blog template adds roughly six hours, so build finishes mid-week 6 instead of end of week 5. Here are three options — hold the launch date and drop the blog template to a post-launch phase, keep the template and move launch four working days, or keep both by adding a second developer at a stated cost. Please choose by Tuesday.
The Friday Review and the One Escalation Rule
Twenty minutes, same time every week, before the client’s week ends:
- Update every forecast date. Do not touch baselines.
- Recalculate days waiting and drift, then sort by status.
- For each red row, name the specific person and the specific decision you need from them.
- Increment rework counters and add up scope hours accepted this week.
- Apply the escalation rule.
- Send one short update, even when everything is green — it makes the bad week’s message ordinary rather than alarming.
The rule: escalate when two of the four indicators are red in the same week, or when any single indicator is red two weeks running. No judgment call, no waiting for confirmation. Escalation is not an apology; it is a written decision request with three options — move the date, cut the scope, or add capacity at a stated cost — and a deadline for the answer.
The reason to make it a rule is that the moment you most need to raise your hand is the moment you least want to. If you want more operational checklists in this format, there are others on the Cursiqa blog.
Where a Spreadsheet Stops Being Enough
Be honest about the limits. A sheet is passive — it never pings you, so if nobody owns the Friday review, the sheet is just a tidy record of how you missed the date. No tool fixes an unowned ritual.
You will outgrow a single sheet when more than one person edits it live, when you are running past roughly eight to ten concurrent projects, when dependencies cross teams that do not share your file, or when you need audit history showing who changed a forecast and when. Resource leveling across people and projects is also genuinely painful in a spreadsheet, and that is a fair reason to move to project software.
Until you hit one of those, a sheet wins on speed and on the thing that matters most: you can change the rules on a Friday afternoon without asking anyone’s permission.
If you would rather not build the register from scratch, the Project Delivery Risk & Deadline Control Center packages this same structure — register, drift tracking, thresholds and escalation wording — as a ready workbook, and you can see the rest of the small-team systems in the Cursiqa shop. Either way, start with the four columns above on your next project kickoff; the method matters more than the file.