The update says the project is on track. Everyone is busy, the meetings happen and nobody has raised a major issue. Yet the demonstration keeps moving to next week and the same decision appears on every agenda.
Early warning signs of project trouble include milestones without acceptance evidence, ageing decisions, unclear ownership, unconfirmed dependencies and a forecast that ignores changes in scope or capacity. Check these signals together. One late update needs investigation; a repeated pattern needs a delivery decision.
Photo by Jakub Żerdzicki on Unsplash.
1. Milestones describe activity rather than results
“Configuration underway” tells you someone is working. It does not tell you whether the configured system meets the agreed need. Ask what evidence proves the next milestone: an accepted test, an approved design or a completed handover.
If the answer changes each week, the team may not share a clear completion condition. Agree it before treating the milestone as achieved.
2. Decisions stay open while work continues
A team can make progress around an unresolved decision for a while. Eventually the assumptions become rework. Look for questions about scope, supplier responsibilities, data access or approval that repeatedly return.
Give each decision an owner, a required-by date and the consequence of waiting. If nobody has authority to decide, escalate that gap to the sponsor rather than asking the delivery team to keep guessing.
3. Ownership becomes collective
“We are looking into it” can conceal three people waiting for each other. For the next few deliverables, ask who is responsible for finishing the work and who accepts it.
Ownership is also a capacity question. The named person may be covering client delivery, leave and two other projects. A name in a plan is not evidence that the time exists.
4. Dependencies are treated as background detail
A supplier response, a data export or a client approval can control the delivery date. Record the expected input, responsible party and last safe date. Check whether the rest of the plan assumes it will arrive on time.
A practical warning sign is work reported as nearly complete while the dependency needed to finish it has no confirmed owner or date.
5. The forecast never changes, but the work does
Compare the current scope and remaining tasks with the plan that produced the deadline. New requests, failed tests and lost capacity should lead to a fresh forecast or an explicit trade-off.
Confidence without an updated estimate is a reason to ask for evidence. It is not a reason to blame the person reporting it.
A short sponsor review
Use these questions at your next check-in:
What has been accepted since the last review?
What is the next deliverable, its owner and its completion evidence?
Which decision is oldest, and what work depends on it?
Which dependency could change the forecast?
What changed in scope or capacity, and has the plan absorbed it?
In an illustrative software rollout, configuration may be complete while training and data checks remain unplanned. The useful response is to expose those tasks and agree the delivery trade-off, rather than rename configuration as “almost launched”.
Act while the choices are still manageable
Start with the most consequential uncertainty. Assign the decision, verify the remaining work and agree the next checkpoint. If the deadline is no longer credible, make that visible with options for scope, capacity or timing.
When should a sponsor intervene?
Escalate when a blocked decision or missing dependency threatens an agreed milestone and the project lead cannot resolve it within their authority. State the decision required, the last useful decision date and the delivery effect of waiting. Give the sponsor options with consequences so the review produces a choice rather than another request for reassurance.
Our small-team project-planning guide can help rebuild the basic structure. If the updates no longer give you a reliable view, discuss a project review with Hili Consulting. Bring the current plan and the decisions that keep returning.
