{"id":430,"date":"2026-09-19T05:58:07","date_gmt":"2026-09-19T03:58:07","guid":{"rendered":"https:\/\/cursiqa.com\/en\/blog\/project-delivery-risk-deadline\/"},"modified":"2026-09-19T05:58:07","modified_gmt":"2026-09-19T03:58:07","slug":"project-delivery-risk-deadline","status":"publish","type":"post","link":"https:\/\/cursiqa.com\/en\/blog\/project-delivery-risk-deadline\/","title":{"rendered":"How to Spot Project Delivery Risk Before a Deadline Slips"},"content":{"rendered":"

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<\/strong> is the gap between what your plan assumes and what your week is actually producing, and it is visible long before the date moves \u2014 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.<\/p>\n

Why Status Reports Hide Project Delivery Risk<\/h2>\n

Most small teams track status as a color or a percentage. Both are self-reported opinions, and both lag reality.<\/p>\n

Percent complete<\/em> 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

The Four Signals That Move Before the Date Does<\/h2>\n

Four indicators cover most of what actually kills a delivery date. Track them weekly, per project.<\/p>\n

1. Dependency age<\/h3>\n

Every item blocked on someone outside your team \u2014 client feedback, an API key, a legal sign-off, a logo file \u2014 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.<\/p>\n

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.<\/p>\n

2. Milestone drift<\/h3>\n

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.<\/p>\n

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.<\/p>\n

3. Rework rounds<\/h3>\n

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.<\/p>\n

Rework is the cheapest early warning you have, because it shows up in week one or two, long before the schedule math turns ugly.<\/p>\n

4. Unbaselined scope<\/h3>\n

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.<\/p>\n

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.<\/p>\n

Build the Register in a Blank Spreadsheet<\/h2>\n

One sheet, one row per commitment. Ten columns is enough:<\/p>\n