Skip to main content

A project can be on schedule and still be heading in the wrong direction

Two leaders review a project timeline and a route toward the intended outcome.

A project can hit every milestone on time and still fail to solve the problem it was started to address.

That is because a plan is built on assumptions: about the problem, the people affected, the systems involved, and the value a change will create. Some assumptions remain true as work progresses. Others do not. A status report can show that tasks are complete without answering the more important question: does the original decision still make sense?

Progress and direction are different questions

Delivery teams need to understand whether work is progressing against the agreed plan. Leaders need that view too. But a green status is a statement about execution against a plan; it is not, by itself, evidence that the plan remains the right one.

Consider a hypothetical internal service project. The team is building the agreed replacement system on schedule. During the work, staff discover that the main delay comes from an approval step outside the system. The replacement may still be useful, but the original expectation of faster service now needs to be tested. Continuing without revisiting that assumption can produce a technically complete result with less business value than expected.

This is not a reason to change direction whenever new information appears. It is a reason to make the decision visible and deliberate.

Review the case, not just the calendar

A useful project review connects four things:

  • The outcome: What should be different for customers, colleagues or the organisation when this work is complete?
  • The assumptions: What must be true for that outcome to happen?
  • The evidence: What have we learned from users, operations, data or technical discovery?
  • The decision: Given what we know now, should we continue, adjust the scope, change the approach or stop?

These questions keep a review grounded in the purpose of the work. They also help distinguish a genuine change in direction from ordinary delivery friction. A delayed task may need help or a revised sequence. New evidence that invalidates the expected outcome may require a larger decision.

Make assumptions testable early

At the start of a project, write down the few assumptions that matter most. Keep them specific enough to check. “Users will adopt the new process” is too broad to guide a decision. “The people who handle these requests can complete the core task in the proposed workflow” gives the team something to investigate.

Then decide what evidence would strengthen or weaken each assumption, who will gather it, and when it will be reviewed. Evidence might come from observing the current process, testing a prototype, validating an integration, or checking operational data. The right method depends on the work; the aim is to learn before a large commitment makes change harder.

This does not require a heavy governance process. A short, regular checkpoint can be enough if it brings the right decision-makers together and records the decision, its owner and the reason behind it.

Give the review room to change something

A review is only useful if people can raise concerns without being treated as though they are resisting progress. Teams should be able to report when evidence conflicts with the plan. Sponsors should be prepared to make trade-offs: protect the outcome by changing the scope, preserve a deadline by reducing what is delivered, or stop work when the case no longer holds.

Clear ownership matters here. The delivery lead can surface what has changed and explain the available options. The business owner should be accountable for whether the expected outcome is still worth pursuing. Technical and operational specialists can explain the consequences of each option. When those responsibilities are unclear, the project can keep moving while the decision itself remains unmade.

Use a simple decision record

After each meaningful review, record four points: what changed, what evidence informed the discussion, what decision was made, and who owns the next step. This gives people a shared reference and makes it easier to revisit the reasoning when conditions change again.

The record should not become a substitute for conversation. Its purpose is to preserve the reasoning, especially when a project spans teams or leadership changes.

Keep the plan accountable to the outcome

A strong delivery plan creates focus, sequencing and ownership. It should also remain open to evidence. Checking whether work is on schedule tells us how execution is going. Checking whether the work still points toward a valuable outcome tells us whether to keep investing in it.

For leaders, the practical habit is simple: at each important checkpoint, ask not only what has been completed, but what the organisation has learned. Then make an explicit decision about what that learning means for the work ahead.

That is how a project stays accountable to its purpose, even when the original plan needs to change.