Applied Practice and Procedures
This domain tests procedural competence: can you run the routine mechanics that keep delivery controlled and auditable? Procedures exist to create evidence and repeatability, not to satisfy a template.
The procedural spine
- Intake and business case - problem, options, cost, benefit, risk and a clear recommendation.
- Planning - scope, schedule, resources, quality criteria and acceptance thresholds.
- RAID log - Risks, Assumptions, Issues, Dependencies, each with owner, date and status.
- Change control - impact assessment on scope, cost, time, quality and risk before approval.
- Quality review - against defined acceptance criteria, with evidence retained.
- Closure - handover, benefits baseline, lessons learned, records archived.
Worked example
A supplier asks to substitute a component two weeks before delivery. Reasoning: log a change request, assess the impact on testing, warranty and compliance, then route it to the accountable owner within delegated authority. Approve, reject or defer with a recorded rationale. Do not let the team absorb it informally; informal absorption hides cost and risk, and it destroys the audit trail that closure depends on.
Traps
- Starting work before the business case is approved.
- Acceptance criteria written as "user-friendly" rather than as testable statements.
- Change control applied only to scope, not to schedule or quality.
- Lessons learned collected but never assigned actions.
- No baselines, so change cannot be measured.
- Procedures followed only when someone is watching.