Implementation and Execution
The Implementation and Execution domain tests whether work is authorized, coordinated, controlled, and accepted. It is less about activity and more about disciplined execution within baselines.
Core rules
- Authorize work against an approved baseline; do not let informal requests become delivered scope.
- Use a change control process for scope, schedule, cost, quality, or benefit-impacting changes: log, assess, decide, communicate, update.
- Clarify roles with RACI or equivalent; one accountable owner per decision.
- Separate quality assurance (process-focused, preventive) from quality control (deliverable-focused, detective).
- Manage interfaces, dependencies, and escalation paths; late escalation is a delivery risk.
- Record acceptance evidence and configuration status so delivered work is verifiable.
Worked example
A developer adds an unrequested reporting feature because it is small. The correct path is to log a change request, assess effort, risk, and benefit impact, have the accountable owner decide, and update the baseline only if approved. Delivering it silently is scope creep even if the feature is useful; refusing to consider it without analysis is also poor practice.
Traps that cost marks
Skipping change control for small changes; treating quality control as testing only at the end; confusing communication with stakeholder engagement; and escalating problems without options. Good escalation states the issue, impact, options, recommendation, and decision needed.
Exam habit
When a scenario shows an unexpected request, ask: Is it authorized? What baseline does it affect? Who decides? What evidence will show acceptance? Execution marks are often won by controlling change, not by doing more work.