140 Pages, Four Days, One Five-Hour Meeting
A 140-page business requirements specification for a pension-transfer system must be baselined in four working days. The project manager proposes a single five-hour review meeting on day four with eight attendees: the author, two developers, two business analysts, one architect, the test manager and you. No preparation time is planned, and none of the reviewers has seen the document. The author says she will 'walk everyone through it page by page'. The requirements are subject to regulatory audit, and the last two releases each produced more than 40 requirement-related defects in system test. Two of the eight attendees will be on leave for part of day four.
1. What review type does this situation justify, and what is wrong with the proposed plan?
Read the worked answer
Type. The regulatory exposure and the two releases of 40+ requirement-related defects are exactly the conditions that justify a formal review - an inspection: defined roles, documented process, entry criteria, recorded findings and follow-up. That is the answer to 'how much formality', and it is a judgement about cost of failure, not a preference.
The plan, however, is not an inspection - it is a walkthrough wearing an inspection's clothes. Problems:
- No individual preparation. Without preparation the meeting becomes a presentation, and the document's defects are discovered by the author, on the day, in front of everyone. The 40+ downstream defects are the predictable result.
- Five hours in one sitting. Reviewer attention collapses well before that; defect detection in the last two hours will be near zero while still consuming the most expensive people in the room.
- Eight attendees reading 140 pages together. Large meetings have a well-known free-rider problem and a low logging rate; 35 pages per hour in a group setting is not a review, it is a reading.
- Roles are undefined. There is no moderator distinct from the author, no scribe, no assigned sections.
- No entry criteria. The document has not been checked for stability or readability, and no checklist exists.
- No follow-up defined. Findings with no owner and no verification date are a workshop, not a review.
2. Propose a plan that fits the four days. Be concrete about preparation rates, meeting shape and roles.
Read the worked answer
Day 1 - planning and kick-off (60 minutes)
- Assign a moderator who is not the author; the author's job is to answer questions and rework, not to chair or defend.
- Name a scribe and 4–5 reviewers; drop the attendance to people who will actually read and have a stake.
- Send the document, the glossary, the review checklist and the section assignments.
Days 1–3 - individual preparation
- A formal inspection preparation rate is in the order of 1–2 pages per hour, so 140 pages × 5 reviewers is roughly 100+ reviewer-hours. That does not fit four days alongside other work, and pretending it does is how reviews fail.
- So prioritise by risk. Split the document: the ~60 pages covering transfer calculation, eligibility and regulatory reporting get full inspection; the remaining 80 pages get a lighter technical review against a checklist.
- Reviewers log findings before the meeting, in writing, with location and defect type - this is the single biggest determinant of the outcome.
Day 4 - logging meetings, not one long one
- Three sessions of at most 90 minutes, each on a section, roughly 15–20 pages per session.
- The meeting's job is to confirm, classify and consolidate prepared findings - not to read the document aloud.
- Handle the leave by scheduling the sections those two attendees cover in the morning, or reassigning their sections during preparation.
Follow-up
- Every finding gets an id, a severity and an owner. The author reworks. The moderator verifies closure before baseline. Baselining an unverified rework defeats the point.
3. How would you know the review worked, beyond 'we did a review'?
Read the worked answer
Two sets of measures, and the second matters more.
Review-process measures (available same week)
- Preparation effort per reviewer and pages per hour - to confirm the review actually happened rather than being declared.
- Defects found per page, split by defect class (ambiguity, missing requirement, inconsistency, untestable statement, incorrect rule). A class breakdown tells you which checklist item is earning its keep.
- Defect severity distribution - a review that finds only typographical issues across 140 pages of regulatory requirements has probably not found the interesting ones.
- Coverage: percentage of pages actually reviewed at inspection depth, stated honestly.
- Rework effort and closure rate before baseline.
Downstream measures (the real test)
- Requirement-related defects escaping to system test, compared with the 40+ of the last two releases. That is the number the review exists to move, and it should be tracked against the same measurement basis as before.
- Review effectiveness: defects caught in review ÷ (defects caught in review + requirement defects found later). If the ratio does not improve, the checklist or the preparation rate needs changing.
One caution: a large defect count in the review is not automatically success - it may mean the document was poor, or that review effort was spent on the wrong sections. Report the count alongside the class mix and the escape rate, and it becomes actionable.