9.2 Issues 5-Step Technique & Supporting Techniques

The 5-Step Issues Technique

Every issue, once identified, is worked through the same five steps. This consistency is what makes the practice auditable and repeatable.

Assess: the business-case test

The assess step is the analytical heart of the technique. v7 frames it as: balance the advantage gained through a change against the impact of implementing it. The single most important question is whether the change keeps the business case valid. A change that delivers a small benefit but undermines the project's justification should be rejected or escalated, not absorbed.

Assessment typically considers impact on:

• Benefits — does the change add, erode, or leave unchanged the expected benefits?
• Scope — does it alter what the project will deliver?
• Risk — does it raise or lower the project's risk exposure?
• Quality — does it affect the level of quality required?
• Time — does it move the schedule?
• Cost — does it change the budget or the cost of delivering the benefits?

Recommend vs Decide

A common exam trap is to merge recommend and decide. They are deliberately separate. The Project Manager recommends; the appropriate authority decides. This separation prevents the PM from both proposing and approving their own proposal on items outside their tolerance. The recommendation is forwarded to whoever holds authority for that tolerance band.

Supporting Techniques New in v7

v7 adds two supporting techniques that strengthen the assess step:

• Root cause analysis — instead of treating only the symptom, investigate why the issue arose. If a product keeps failing quality checks, root cause analysis asks whether the specification, the build method, or the supplier is the real source. Fixing the root cause prevents recurrence; fixing only the symptom guarantees the issue returns.
• Pareto analysis — the 80/20 rule: roughly 80% of issues often stem from 20% of causes. By ranking issue causes by frequency, the project can focus its finite management effort on the few causes that generate most of the disruption. The output is typically a ranked bar chart (a Pareto chart) showing where to act first.

These techniques do not replace the 5-step flow; they inform the assess step so that recommendations address causes, not just symptoms.

Decision Authority

Who decides depends on the tolerance framework:

• The Project Manager decides on routine issues that sit within their delegated tolerance — for example, a minor problem/concern that can be resolved without breaching stage or project tolerances.
• Requests for change and off-specifications that breach tolerance, or that affect the project baseline, go to the Project Board. The board may delegate some of this authority to a Change Authority for changes within agreed limits (often used when there is a change budget).

A useful rule of thumb: if the issue can be handled inside the current plan and tolerances, the PM decides; if it moves a baseline or breaches a tolerance, it is escalated.

Sequencing in scenarios

Practitioner questions often test the order of the five steps. Be ready to identify that assess comes before recommend, and recommend before decide — never the other way around. A frequent distractor offers "decide then assess" or collapses assess and recommend into a single step; both are wrong.

Applying Pareto analysis concretely

Suppose a stage produces 50 issues over its life. Tallying the root causes shows that 40 of them — 80% — trace back to just two causes: ambiguous Product Descriptions and late SME availability. Pareto analysis says focus management effort on those two causes first, because addressing them removes the bulk of the disruption. The remaining causes, individually small in frequency, can be handled as they arise.

Applying root cause analysis concretely

If an off-specification recurs on the same product, root cause analysis asks a chain of "why?" questions. Why did the product fail its quality check? Because the build step skipped a test. Why was the test skipped? Because the build instructions did not mention it. Why did the instructions omit it? Because the Product Description's quality criteria were vague. The root cause is the vague quality criterion, not the skipped test — and the fix is to revise the Product Description, not just to re-run the test.

Why these supporting techniques were added

v7 added root cause and Pareto analysis because earlier versions were criticized for treating each issue in isolation. Projects that only fix symptoms find the same issues returning stage after stage, eroding the business case. The two supporting techniques push the project to learn from patterns, not just to process individual items. This connects the Issues practice to the wider v7 emphasis on organizational alignment and sustainability — recurring issues are a sign of a deeper misalignment that no amount of per-issue processing will fix.