SKIL90004 Chap.8 Quality Planning and Root Cause Analysis
Quality Planning and Root Cause Analysis
Quality planning defines requirements and verification, assurance examines the process and control checks results. This chapter connects those layers with containment, correction, root-cause testing, corrective action and effectiveness review. Cause diagrams and repeated why questions organise hypotheses, but observations and tests are still required before a team claims that a cause is established.
A narrow problem statement identifies the affected population, location, timing and pattern so affected and unaffected cases can be compared. Containment protects current outputs, while corrective action changes a supported mechanism and must be reviewed for effectiveness. Requirements, thresholds, records and decision owners make acceptance reproducible.
Quality action also needs integration with scope, schedule, cost and risk when the proposed control changes another commitment.
What this chapter covers
- 01
Quality requirements
- 02
Acceptance evidence
- 03
Quality assurance
- 04
Quality control
- 05
Nonconformance containment
- 06
Cause-and-effect analysis
- 07
Corrective action
- 08
Effectiveness review
Worked example · free
Investigate repeated label mismatches
- 1Contain affected records and verify identity.
- 1Describe when and where the mismatch occurs.
- 1Map candidate causes across the workflow system.
- 1Test which conditions predict the mismatch.
- 1Change the verified mechanism and review recurrence.
Key terms
- Quality planning
- Quality planning defines requirements, measures, methods, owners and acceptance evidence before execution.
- Quality assurance
- Quality assurance examines whether the selected process is capable and operating as intended.
- Quality control
- Quality control checks results against requirements and supports action on detected variation.
- Containment
- Containment protects current outputs or users while deeper analysis continues.
- Root cause
- A Root cause is a supported underlying condition whose change can reduce recurrence of the problem.
- Effectiveness review
- An Effectiveness review tests whether the approved action produced the intended improvement without unacceptable side effects.
Quality Planning and Root Cause Analysis FAQ
What is the difference between assurance and control?
Assurance examines whether the process is capable and being followed. Control checks results against requirements. Both support quality, but they ask different questions about process and output.
Why is correcting a defect not enough?
Correction protects the current output. If the underlying mechanism remains, the event can recur. Corrective action addresses a supported cause and then checks whether performance actually improves.
Does a fishbone diagram prove a root cause?
No. It organises candidate explanations across categories. The team still needs observations, records or tests that show which conditions are connected to the failure and change when the action is applied.
Exam move
For every quality scenario, separate requirement, evidence, containment, correction, candidate causes, testing, corrective action and effectiveness. Rewrite broad branches such as people or method into testable statements. Finish by checking whether the action changes scope, schedule, cost or risk and therefore needs wider control.
Start by translating a vague quality goal into a requirement, measure, verification method, owner and acceptance decision. Use examples involving traceability, completeness, method performance and documentation. Classify each planned activity as planning, assurance or control and explain why.
Design the nonconformance route before failure: who may quarantine an output, who judges technical significance, who approves rework and what records preserve traceability. For root-cause practice, describe the effect with population, location, time and pattern. Compare affected and unaffected cases instead of asking only why the failure happened.
Build a cause-and-effect map across method, people, equipment, material, environment and measurement, adapting the categories where the project demands it. Turn every broad branch into a condition that evidence could confirm or refute. Separate creation of the defect from failure to detect it. Assign observations and protect original records.
Choose candidate causes by plausibility and consequence, but do not use a vote as proof. Test the relationship where feasible and keep contradictory evidence visible. Write immediate correction separately from corrective action. Relabelling a record protects the current output; redesigning a verified hand-off weakness changes recurrence.
Before implementation, define the effectiveness measure, observation period, sample and review owner. Preserve the pre-action baseline and watch for displacement into another quality failure. If results do not improve, reopen the analysis rather than treating completed training as success. Connect approved actions with scope, schedule, cost and risk controls.
Finish the record with requirement, event, containment, evidence, supported cause, action, owner and effectiveness result. This chain makes the quality conclusion reproducible. Alternate between two kinds of drill. In the first, receive a completed cause map and write the tests needed for each branch. In the second, receive mixed observations and construct the map without discarding anomalies.
Compare how each approach changes your confidence. End by writing a closure criterion that another reviewer could apply without knowing your preferred explanation.
Working through Quality Planning and Root Cause Analysis in SKIL90004? Sia is AskSia’s AI Project Management tutor — ask any SKIL90004 Quality Planning and Root Cause Analysis question and get a clear, step-by-step explanation grounded in how SKIL90004 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
