A project review checklist: evidence, decisions, owners, reviewers and deadlines

Start with the decision

Write down what the review is deciding, in one sentence: approve the design, accept the deliverable, open the next phase. If you can’t write it, the review isn’t ready to be scheduled.

List the evidence the decision needs

For each requirement, record what it is, where it is, its status (provided, pending or missing) and the version the reviewer should look at. A link to a file somewhere else is a pointer. It tells a reviewer where to look, but it doesn’t show that the requirement was met or accepted.

Give every item an owner

Each missing or pending item needs one named person who will provide it. “The team” is not an owner. If you can’t name the person, that is the first finding of the review.

Name the reviewers

Write down who has the authority to decide, and whether they have seen the evidence before the meeting. A decision that needs two named people can’t be made by one of them in a corridor.

Set two deadlines

Evidence due is the date by which everything is provided, early enough for reviewers to read it. Decision date is the date the decision is recorded. If evidence arrives on the day of the review, the meeting becomes a reading session.

Say what you don’t know

List what is uncertain or unknown. A review with a confident summary and a hidden gap is worse than a review that says “we don’t know yet”.

Record the outcome and the reason

Write down the decision, who made it, the date and why. The next reviewer should not have to rebuild it from a message thread.

The checklist

Copy this into a spreadsheet, a document or your project tool. Each line is done when the answer after the question is true.

1. What is being decided? One sentence, agreed.
2. What evidence is required? A list with a status for each item.
3. Who owns each missing item? A named person for each.
4. Who decides? Named reviewers, with the evidence in their hands.
5. When is evidence due, and when is the decision? Two dates, evidence first.
6. What is uncertain or unknown? Listed, not hidden.
7. What was decided, and why? Recorded with a name and a date.

A worked example

The project, the people and the dates are invented for this example.

The project is Riverside Depot Extension, a fictional depot extension, and the review is its Initiation stage. The project manager is Marco Manager. The reviewers are Olivia Owner and Priya PMO. Evidence is due on Monday 19 October and the decision is on Wednesday 21 October.

1. The decision. Approve the Initiation stage so the project can move to Planning.
2. The evidence. Twelve requirements apply. Ten are provided, among them the contract and the costing sheet. Two are missing: the risk register has nothing in it, and the stakeholder register has nothing in it.
3. Owners. Marco Manager, the project manager, will add the first risks and the stakeholders by Friday 16 October.
4. Reviewers. Olivia Owner and Priya PMO can decide. They need the risk and stakeholder registers in front of them before the 21st.
5. Deadlines. Evidence due 19 October. Decision 21 October.
6. What we don’t know. Whether two stakeholders on the client side will accept the proposed contact arrangements. Recorded as an open question, not left out.
7. The outcome. If the registers arrive on time: approved on 21 October by Olivia Owner and Priya PMO. If not: the review is postponed, and the reason is written down.

The status of this project could read “On track” the whole time. The review would still be blocked, because two required items are missing. That is the point of checking evidence next to status.

How AEVU helps

AEVU’s stage review shows the requirements for a stage, which are met and which are missing, who can decide, and what is still needed before the stage can be submitted. The checklist above works without it, in any tool.

See how stage-gate evidence and approvals work or take the product tour.