2.4. Executing Planned Strategies and Frameworks
💡 First Principle: A plan or framework (a communication plan, a risk response plan) is only useful if the team actually follows it when the moment it was designed for arrives. This section tests recognizing the correct, planned response to a situation — not improvising a new one.
Responding to a planned strategy or framework. If a scenario describes a risk materializing that the risk register already has a documented response for, the correct action is to execute that planned response — not brainstorm a new solution from scratch, and not escalate past the level the plan already specifies. The same logic applies to communication plans: if the communication plan says a status update goes to a specific stakeholder group weekly, following that plan is the default correct answer over inventing an ad hoc update path.
⚠️ Exam Trap: A "clever" answer choice that solves the immediate problem in a new way is usually a trap if a documented plan already covers the situation. Associate-level judgment favors executing the existing framework correctly over improvising, unless the scenario explicitly says the plan doesn't cover this case.
Project initiation and benefit planning. Initiation is where a project formally starts — where the business case and expected benefits get documented before detailed planning begins. Benefit planning means being explicit, from day one, about what value the project is expected to produce and how that value will be measured once delivered. A project that skips this step can still get built, but the team loses the ability to later prove the project was worth doing.
A worked example. Suppose a risk register already documents this response: "If the vendor's delivery slips past the contracted date, invoke the backup vendor clause within 5 business days." The vendor slips. A scenario might offer several tempting alternatives — negotiate a discount, escalate to the sponsor for a decision, quietly extend the internal deadline. All three ignore that the plan already answered this exact situation. The correct action is to invoke the backup vendor clause, on the timeline the plan specifies, because that's what "executing a planned strategy" means in practice: following the documented response instead of re-deciding it under pressure.
When improvising is actually correct. This doesn't mean plans are followed blindly forever. If a scenario explicitly states the situation falls outside what any documented plan or framework anticipated, escalation or a new response becomes appropriate. The skill being tested is telling the two situations apart — "the plan covers this, use it" versus "the plan genuinely doesn't cover this, escalate or adapt" — rather than always assuming one or the other.
Why a benefit gap doesn't announce itself. A project can be technically well-executed — the deliverable gets built, on schedule, meeting every stated requirement — and still represent a planning failure if no one ever documented what business value it was supposed to produce. This gap is easy to miss because nothing about the deliverable itself looks wrong; the problem only surfaces later, when someone asks the team to justify the project's existence and there's no benefit statement to point to. That's precisely why benefit planning belongs at initiation, before any detailed work begins, rather than something to backfill once questions start arriving.
A change that "seems small" still needs the full response. A feature request that looks minor to the person raising it — "can we also add an export button" — still belongs in whatever planned intake process the project uses for scope changes, not handled informally because it seems too small to bother with formal process. Redirecting even a small request to the correct planning conversation is itself an example of executing the planned framework correctly, not an overreaction to what might genuinely seem like a minor ask.
