The Post-Mortem Mistake: Why You Need to Audit Your Project Intake, Not Just Your Execution

Execution received the autopsy. Intake left through a side door.

Some projects fail because delivery went badly. Others were vague, low-value, or impossible before delivery began.

Trace the failure to the first unsupported claim

Review the original request. Was the current problem measurable? Did the affected people confirm it? Was the proposed outcome testable? Which assumptions became scope changes later?

Use how to fix a broken business project intake process for the repair. The post-mortem here has a narrower job: prove which intake decision planted the failure before anybody built it.

Use requirements gathering software to preserve questions and answers so the audit can see what was known when. Keep the first claim on software project intake, or the post-mortem will audit the rewrite instead of the decision.

Audit the decision

Who approved the work? What alternatives lost? Did the estimate include training, policy, data, and rollout? Was an aggressive timeline chosen with the risk recorded?

One post-mortem blaming requirements churn. The original request was one sentence about modernization. The churn was the first time the company had supplied requirements.

Add a pre-mortem

Before approval, ask how the project could fail because the request, owner, evidence, or capacity is wrong. Use the free Project Intake Evaluation Worksheet as the intake side of the review.