Most projects that disappoint were not badly executed. They were well executed against the wrong problem.
It happens quietly. A request arrives already shaped as a solution – “we need a new system”, “we need to upgrade by spring”, “we need a dashboard”. A team is assembled, a plan is built, a budget is approved. Months later the system is live, the date is met, and the organization is somehow no better off. Nobody did anything wrong. Everyone answered the question they were given.
The request is not the problem
A request is someone’s best guess at a solution. It carries assumptions about the cause, the scope and what “better” looks like – and those assumptions are rarely written down, let alone tested.
When the assumptions are wrong, the plan inherits the error. Scope grows to cover what was missed. Change requests arrive late. Users resist a solution that doesn’t match how they actually work. The project looks like it is failing in execution, but the failure was decided on day one.
Four questions to ask before the plan is signed
Diagnosis doesn’t need to be slow or expensive. It needs to be deliberate. Before scope and dates are committed, get clear answers to four questions:
- What decision is this project meant to enable? Not what will be built – what will the organization be able to decide or do differently once it exists?
- What happens if we do nothing? If the honest answer is “not much”, the urgency is political, not operational – and the plan should reflect that.
- Who can stop this, and what do they need to see? The people with the power to delay or derail a project are rarely the ones in the kickoff meeting.
- What are we assuming is true? List the assumptions behind the scope, timeline and budget. Then pick the riskiest three and test them now.
Why teams skip this step
Diagnosis feels like delay. There is pressure to show progress, and a plan with dates on it looks like progress in a way that questions do not. Sponsors want certainty, and a confident plan provides it – for a while.
But the cost of a week spent diagnosing is small and visible. The cost of solving the wrong problem is large and arrives late, when options are expensive and reputations are on the line.
What good looks like
On projects that go well, the opening weeks feel different. The problem statement is short and specific. The sponsor can explain, in a sentence, what will be different when the work is done. The riskiest assumptions have names and owners. And the plan is built on what is known, with honest room for what is not.
None of this requires a new methodology. It requires someone to slow the start down just enough to ask the right questions – and the discipline to act on the answers.
The most valuable hour on any project is the one spent before the plan is signed.
If you are about to start something important, a Readiness Review is a structured way to make sure you are solving the right problem before you commit to solving it.
18+ years leading complex delivery across public, private and regulated environments. PMP, CSM, M.Sc. Kay helps organizations and the leaders accountable for complex projects get the early decisions right.