Most businesses agree that it is worth looking back at a significant job, project or failure once it is finished. A meeting is held, people talk openly about what went well and what did not, a list of improvements is agreed and the matter is closed. Everyone leaves feeling the review was worthwhile. Yet months later, the same problems appear on the next job.
The reason is often not that the review was badly run. It is that the review never actually diagnosed anything. It described what happened, debated who or what was responsible, and jumped to remedies, without ever establishing why the problem occurred. A remedy without a diagnosis is a guess, and guesses rarely fix recurring problems.
This article explains why reviews so often fail to ask about causes, how a well-intentioned workplace rule can block diagnosis, the difference between correcting execution and questioning the assumptions behind it, and a practical way to run reviews that change what the business does next.
What one study found
In research published in Project Management Journal in 1999, J. S. Busby of Cranfield University observed four post-project review meetings at three companies, about twelve hours of discussion among experienced people, and analysed what was said. By his account, nobody asked a diagnostic question in all that time. Many questions began with “why”, but they were requests for clarification (“why was it poor?” meaning “in what way was it poor?”) rather than questions about cause.
Busby was careful about the limits of his study. He could not claim the pattern would appear everywhere, he strongly supported holding reviews and several of the companies were running them for the first time. But the pattern he described is easy to recognise in many businesses.
Why reviews drift away from causes
Reasoning forward is easier than reasoning backward
The meetings were not lazy. People argued competing explanations, reconstructed what happened in what order, and imagined what would have followed if different choices had been made. But much of that thinking ran forward, from a possible cause to its effects, or from a remedy to its likely results. Reasoning backward, from an outcome to the chain of causes that produced it, is harder. So people tend to skip straight to solutions and imagine how they would work.
Responsibility drifts outward
Busby found a strong tendency to explain problems by pointing to other parties: the supplier, the customer, another department. Only rarely did anyone say “I got this wrong” or “I need to work differently”. He noted a useful counterweight: successful businesses tend to believe events are largely within their control, which is why it is worth asking what could have been done differently even when causes look external.
Remedies are proposed but not examined
At the end of the meetings, remedies were suggested and briefly debated, but not examined: no one tested their side effects or planned how they would be carried out. When participants were interviewed later, many were sceptical that the reviews would change anything, partly because of long experience of management exercises that produced no visible improvement, and partly because the remedies themselves were unconvincing. That creates a loop: people expect reviews to change nothing, the review produces unexamined remedies that quietly fail, and the expectation is confirmed.
The rule that blocks diagnosis
Busby identified a cultural force that deserves attention. Many workplaces, rightly, encourage people to be constructive and to bring solutions rather than problems. In day-to-day work, this is a good rule. It reduces complaining and pushes responsibility to where it belongs.
Inside a review, the same rule does something different. People hold back from exploring causes unless they already have a solution to offer, because raising a problem without a remedy looks negative. A rule requiring a solution with every problem becomes, in a review, a rule against diagnosis. And it is often enforced most strongly by leaders who believe they encourage candour.
The fix is simple to state: for the diagnostic part of a review, explicitly suspend the rule. People may describe a cause without having a remedy. Say this out loud at the start, because a rule suspended on paper but not in the room is not suspended.
Correcting execution or questioning the plan
When results disappoint, the natural response is to improve execution: more monitoring, tighter deadlines, more effort. Sometimes that is right. Sometimes it makes a flawed approach more efficient.
Management writers describe two kinds of learning:
- Single-loop learning improves how something is done within the existing approach: did we carry out the plan properly?
- Double-loop learning questions the assumptions, goals or methods behind the approach: was this the right plan, and what did we believe that may not be true?
Both matter. Single-loop learning builds reliability. Double-loop learning allows adaptation. The skill is knowing when to switch. A useful rule: move to questioning the assumptions when repeated execution fixes have not improved the result, when conditions have changed significantly, or when new evidence challenges a core belief.
This takes some self-awareness. Owners and managers can become attached to decisions they made or ideas they championed, and may dismiss evidence that threatens them. Persisting with a failing approach is not resilience.
A two-level review
Structure the review in two levels:
| Level | Questions |
|---|---|
| Execution | Did we do what we planned? Were people, resources and skills adequate? Were decisions made in time? Did handoffs work? |
| Assumptions | What did we believe about customers, suppliers, technology, cost, time or risk? What evidence supported those beliefs? What evidence now challenges them? Is the goal itself still right? |
Many reviews stop at the first level. The second level is where the larger lessons usually sit.
Categories are not causes
Reviews often conclude with a category: “communication problems”, “poor requirements”, “not enough resources”. These feel like answers but are really the start of a diagnosis. A diagnosis asks how the requirements came to be poor, who was in a position to notice, and why nobody did. Almost anything can be described as a communication problem; saying so explains little.
A simple discipline helps: for each finding, ask “why?” again until you reach something the business can actually change, such as a process, a decision rule, a skill, an incentive or a missing check.
A practical approach
Before the review, the person who commissions it writes a short diagnosis brief:
- The question the review should answer: a specific causal question, such as “why did the installation take twice as long as quoted?”, not “how did it go?”.
- Who will be asked about causes, so that questions are expected rather than felt as accusations.
- A clear statement that, during diagnosis, people may describe causes without offering solutions.
- A requirement that every proposed remedy is examined for side effects, cost and who will carry it out, either before the meeting ends or at a second meeting.
It often works better to hold diagnosis and remedies in separate sessions, because the pressure to produce answers undermines the willingness to explore causes.
Afterwards, three questions test whether the review worked:
- Was at least one genuinely causal question asked, and what did it reveal?
- Did anyone accept a share of the cause, and what happened to them afterwards?
- Were the remedies examined, and are they actually being carried out?
The second question matters most over time. People watch what happens to colleagues who admit mistakes, and they adjust accordingly.
A worked example
This is an illustration. A commercial fit-out business finishes a café fit-out three weeks late and $18,000 over its estimate. The review meeting is friendly and thorough. The team reconstructs the timeline, agrees the joinery supplier was slow and the client changed the layout twice, and resolves to “communicate better with suppliers” and “lock in client changes earlier”. The meeting closes in an hour.
The owner is uneasy, because the same two explanations appeared in the last review. She runs a second session with a diagnosis brief: “Why did joinery arrive two weeks after the date we planned around?” She states at the start that people can describe causes without having solutions.
The diagnosis goes further this time:
- The joinery supplier was not late against its own quoted lead time. The business had planned around a lead time from a quote six months old.
- Nobody rechecked lead times at order, because the estimator assumed the project manager would, and the project manager assumed the estimator had.
- The client’s layout changes came after the business sent drawings for approval with a five-day turnaround, while the client’s decision-maker was travelling. The approval process did not check who would actually approve.
- At the assumption level, the business’s standard programme assumed suppliers’ lead times were stable, which had stopped being true over the past year.
The remedies are then examined. A rule that lead times are confirmed in writing at the time of order is assigned to the project manager, with the estimator providing current figures. Approval requests now name the client’s decision-maker and confirm their availability. The standard programme template is updated to include a check of supplier lead times at three points. Each remedy has an owner and a review date, and the next two jobs are checked against them.
Neither of the original conclusions, “the supplier was slow” and “communicate better”, would have produced these changes.
Review successes too
Reviews usually follow failures, which makes them feel like inquiries into blame. Occasionally reviewing a job that went unusually well changes the tone and teaches something different: what made it work, and whether that can be repeated deliberately. A job that finished early, delighted a customer or came in under budget often contains a method, a supplier arrangement or a way of communicating that the business does not yet use consistently. Asking why it worked is as useful as asking why something failed, and it helps people see reviews as learning rather than judgement.
Keep a short record
Record each review in a single page: the causal question, the causes found, the assumptions that proved wrong, the remedies with their owners and dates, and the result when they were checked. Over time, these pages show which causes keep recurring across jobs. A cause that appears in several reviews is a system problem, and deserves a deliberate fix rather than another resolution to try harder. The when good teams make poor decisions and plans that detect rather than predict articles cover related habits.
How this applies to a small Australian business
Small businesses often review jobs informally, if at all, and the same problems recur. Practical steps:
- Write a specific causal question before reviewing a significant job.
- Suspend the “bring solutions” rule during diagnosis, and say so.
- Keep asking why until you reach something you can change.
- Review assumptions as well as execution.
- Separate diagnosis from remedies where possible.
- Examine every remedy for side effects, cost and ownership.
- Respond well when someone admits a mistake.
- Check later whether remedies were carried out and worked.
The what your projects know that your plan doesn’t article covers how lessons from delivery should reach decisions about direction.
Signals worth watching
- Review findings that are categories rather than causes.
- The same findings appearing in review after review.
- Problems explained mainly by other parties.
- Remedies agreed in minutes with no owner or plan.
- People privately doubting that reviews change anything.
- Nobody ever admitting a share of the cause.
Common mistakes
- Describing what happened without asking why.
- Jumping to remedies before diagnosis.
- Requiring a solution with every problem raised in a review.
- Correcting execution when the assumptions were wrong.
- Accepting categories such as “communication” as conclusions.
- Never checking whether remedies were implemented.
Frequently asked questions
Which jobs deserve a review? Those with significant cost, delay, quality problems or surprises, and occasionally successful ones, to understand what made them work. Choose them for what they can teach, not just because they were painful.
How long should a review take? A focused diagnosis session often takes an hour or two. Remedies may need a second session.
What if the review points at a senior person or the owner? That is when the process matters most. If the owner can say “I think I contributed to this” and the conversation continues, others will learn that honesty is safe.
Should customers or suppliers be involved? Sometimes. Their view of what happened can reveal causes the business cannot see on its own, especially at handoffs.
How do we keep remedies from being forgotten? Give each one an owner and a date, and check it at the next relevant job or management meeting.
Questions to ask
- In our last review, was a genuinely causal question asked?
- What happens in practice when someone admits a mistake?
- Do we require solutions with problems, and how does that affect our reviews?
- Which remedies from past reviews were actually carried out?
- Are we fixing execution when the assumptions were wrong?
- Which recurring problem has never been properly diagnosed?
Bringing it together
A review that cannot ask why is a discussion, not a diagnosis. Start with a specific causal question, suspend the rule that every problem needs a solution while you explore causes, keep asking why until you reach something you can change, review assumptions as well as execution and examine every remedy before relying on it. Respond well to honesty, and check later whether things changed. The goal is not a better meeting, but a business that stops repeating the same mistakes.
Source: KEVOS notes, drawing on J. S. Busby, “An assessment of post-project reviews”, Project Management Journal (1999), and teaching material on single-loop and double-loop learning. Examples and figures in this article are illustrations.
