6.4 Common Traps in Management Products
Key Takeaways
- Do not confuse the Project Brief with the PID: the Brief is created in Starting up; the PID expands it in Initiating.
- Reports are fixed once issued; a new instance is created each period, unlike registers which are updated in place.
- The Daily Log is for informal notes; formal items belong in the Risk, Issue, or Quality Register.
- An Exception Report responds to a forecast breach; an Issue Report documents one specific raised issue.
- A management product's purpose is fixed, but its format can be tailored, merged, or held in a tool.
High-Frequency Confusions
Foundation questions cluster around a handful of look-alike products. Learn each boundary precisely.
Project Brief vs PID
The Project Brief is lightweight and created in Starting up a Project to justify initiating the project. The PID is the comprehensive baseline created in Initiating a Project to manage the whole project. The Brief feeds into the PID; they are not interchangeable. A trap answer treats the Brief as the document the board uses to authorise the project — in fact the board uses it to authorise initiation, and authorises the project against the PID.
Report vs Record
Reports are point-in-time snapshots: once an instance is issued it is fixed forever, and the next period produces a new instance (Highlight Report week 1, week 2, and so on). Records (registers and logs) are living documents updated in place throughout the project. A question that says a document is "updated continuously" points to a record; one that says it is "issued at a frequency" points to a report.
| Pair | The distinguishing fact |
|---|---|
| Project Brief vs PID | Brief = SU, justifies initiation; PID = IP, success baseline |
| Report vs Register | Report = fixed snapshot; Register = updated in place |
| Daily Log vs Registers | Daily Log = informal notes; Registers = formal tracked items |
| Issue Report vs Exception Report | Issue Report = one specific issue; Exception Report = forecast tolerance breach |
| Highlight vs Checkpoint | Highlight = PM to board; Checkpoint = team to PM |
More Traps to Avoid
Daily Log vs the Registers
The Daily Log is the project manager's informal diary — notes, observations, reminders, and minor actions that do not warrant a formal register entry. Significant risks go in the Risk Register, formal issues, changes, and off-specifications go in the Issue Register, and quality activities go in the Quality Register. A trap answer files a formal risk in the Daily Log; the correct answer escalates it to the Risk Register.
Issue Report vs Exception Report
An Issue Report captures the details of one specific issue that has been raised and needs analysis or a decision. An Exception Report is produced only when a stage or the project is forecast to breach tolerance. Many issues never become exceptions; an exception is a forecast that something will go out of the agreed limits. Reading the trigger word — "a problem was raised" versus "forecast to exceed tolerance" — decides the answer.
Tailoring traps
A recurring distractor insists a management product must always be a separate formal document. PRINCE2 7 explicitly allows products to be merged, split, or held in a tool, provided the purpose is met. On a small project the Business Case may sit inside the Project Brief; the registers may be tabs in one spreadsheet. The correct answer respects the purpose, not a fixed format.
Removed products
Because PRINCE2 7 dropped several 6th-edition products, a trap may name a product that no longer exists as a standalone item, such as Configuration Item Records or the Product Status Account. The current artefact is the Product Register. If an option cites a removed product as the right answer, treat it as a distractor.
Ownership traps
Finally, watch ownership: the project manager maintains the Business Case but the Executive owns it; team managers produce Checkpoint Reports, not the project manager. Matching the product to the wrong role is one of the most common ways an otherwise-correct-looking option is wrong.
Worked Trap Examples
Seeing the trap in action fixes the boundary better than memorising it. Work through these.
Trap: "The board authorises the project using the Project Brief."
Tempting, because the Brief is presented to the board early. But the board authorises initiation from the Brief and authorises the project from the PID. The Brief is too lightweight to be the success baseline. The correct answer names the PID.
Trap: "A forecast slip means the project manager updates the Issue Register and waits."
Logging the issue is correct as far as it goes, but a forecast tolerance breach obliges the project manager to escalate by raising an Exception Report to the board. Stopping at the register understates the action required.
Trap: "The Lessons Report is only produced at project closure."
Lessons are captured in the Lessons Log throughout, and a Lessons Report can be produced at any stage boundary as well as at closure, so that learning is shared while the project is still running. An answer that confines it to closure is too narrow.
Quick-reference disambiguation table
| If the stem says... | The product is... |
|---|---|
| "informal note the PM jotted down" | Daily Log |
| "forecast to exceed tolerance" | Exception Report |
| "routine progress to the board" | Highlight Report |
| "team reports progress on its work" | Checkpoint Report |
| "master document used to manage the project" | PID |
| "early definition to justify initiation" | Project Brief |
| "tracks every product and its status" | Product Register |
Keep this table in working memory. Most trap questions in this domain are simply one row of it disguised in a paragraph of context, and recognising the row strips the disguise away.
Which statement correctly distinguishes a PRINCE2 report from a register?
A team member identifies a significant new risk to the project. Where should it be formally recorded?
What is the key difference between an Issue Report and an Exception Report?