ImmersaEngineering / Stage gate review
Whether the gate should actually open.
An independent assessment of a plan, estimate, schedule or stage gate before it is approved — and of the risks that are not yet on the register. It states what is ready, what is not, and what would have to be true for the gate to pass.
What it covers
Readiness, tested against what is actually documented.
A gate review asks a narrow question: does the evidence in front of the approver support the decision being asked of them? Most gates that fail late fail because something was assumed to be complete which was only planned.
The basis of the decision
What the gate paper claims, and whether the documents behind it carry the claim.
- Project execution plan and the assumptions it rests on
- Scope definition and the maturity actually achieved against the maturity claimed
- Capital and operating estimate basis, and the class it genuinely qualifies as
- Schedule logic, float and the critical path as built rather than as presented
- Contracting and procurement strategy against the scope it has to deliver
The risks not yet on the register
A risk register records what has been thought of. A gate review is partly an attempt to find what has not.
- Risks carried by assumptions never written down
- Interfaces where two parties each believe the other holds the scope
- Long-lead items whose dates depend on decisions not yet taken
- Estimate allowances that have quietly become commitments
- Dependencies on approvals, permits or utilities outside the project’s control
How it is delivered
A written position, not a workshop summary.
A gate review produces a document an approver can take into the meeting and be questioned on. It states what is ready, what is not, and what would have to be true for the gate to pass.
What arrives
The gate submission and the documents behind it — plan, estimate basis, schedule, risk register, scope definition — together with the decision being sought.
Access to the team for questions, where the programme allows it.
What comes back
A written assessment, findings ranked by consequence to the decision, each stating the evidence it rests on and the assumption it would fall on.
Where the honest answer is that the gate is ready, the assessment says so and explains why.
Typical findings
What a gate review turns up.
Illustrative and non-attributable. Each is invented; no engagement lies behind any of them.
- An estimate presented at a class it did not qualify for. The scope definition behind it supported a wider band than the number carried into the approval paper, and the contingency had been set against the narrower one.
- A critical path that ran through an unmade decision. The schedule assumed an approval date for a permit that had not been applied for.
- An interface both parties believed the other owned. Neither scope of work contained it. It surfaced in the review rather than in construction.
- A risk register that recorded only what had gone wrong before. Comprehensive on familiar failure modes and silent on the two assumptions genuinely novel to this project.
Invented for illustration. Nothing arising from a real engagement is reused, retold or cited as a credential.
See the deliverable
Read one before you commission one.
The specimen is a process design review rather than a gate assessment, so the subject differs from the work on this page. The structure does not: ranked findings, stated assumptions, residual risk, and a revision record that closes each finding against a named response.
It carries the assumptions relied on, a sensitivity table, the items examined and found sound alongside those that were not, the residual risk that remains after the recommended actions, and a passage setting out where the conclusion could be wrong. Every page is marked SPECIMEN; the facility, the client and the findings are invented.
Have a gate tested before it is approved.
A short description of the problem, the document set or the decision is enough to confirm suitability, propose a structure and give an indicative cost. A mutual non-disclosure agreement is executed before technical detail is exchanged.
Discuss a requirement