Execution and Operations
From plan to steady state
Execution is coordination under change. Operations is sustained performance under constraint. Questions in this domain usually test whether you can distinguish an issue being managed from a change being approved, and whether a handover is genuinely complete.
Concepts to hold
- Change control. A change request alters an approved baseline; a defect is a failure to meet an agreed requirement. Different routes, different authorities. Mixing them is a classic trap.
- RACI. Responsible does the work, Accountable owns the outcome (exactly one per activity), Consulted gives input before, Informed is told after. Two "A"s means no accountability.
- Standard operating procedures. Written steps, roles, inputs, outputs and exception paths. A procedure nobody follows signals a design or ownership fault, not a discipline problem.
- Capacity versus demand. Work in progress above capacity lengthens lead time without increasing throughput. Limit work in progress before adding people.
- Transition and acceptance. Handover needs agreed acceptance criteria, named operational owner, trained users, documented support model and a defined hypercare period.
- Quality gates. Predefined checks at defined points; a gate without exit criteria is a meeting.
Traps
Declaring handover complete when the build team is still answering routine queries. Treating a service level target as a guarantee rather than a threshold with remedies. Escalating a routine decision because it is unpopular.
Rule of thumb: the "who owns it Monday?" test
At handover, ask who is accountable for the process on the first working day after transition, what they will do when it fails, and where that is written. If any of the three is unanswered, transition is incomplete.
Worked illustration
Users request an extra approval step post-launch. That is a change request (alters the approved design), routed through change control with impact assessment - not a defect fix, and not something a team lead can authorise informally.