Implementation · 9 minutes · Strategy translation · Operating-model design · Implementation architecture
A strategy can be approved, published, presented to staff, and still remain almost entirely theoretical.
Approval confirms a direction. It does not create the financial, organizational, technical, and operational conditions required to deliver it.
This distinction matters because many organizations treat approval as the finish line.
The board endorses the strategy. Leadership announces the priorities. A presentation is shared across the organization. Teams are instructed to "operationalize" the plan.
The difficult work is then handed to program, finance, operations, technology, communications, policy, and delivery teams—each expected to interpret what the strategy means for them.
That is often where strategic coherence begins to weaken.
Different teams make different assumptions. Existing budgets are stretched to absorb new commitments. Responsibilities are added without removing old ones. Technology requirements surface late. Partners receive inconsistent instructions. Implementation activity begins before decision authority, resourcing, or dependencies are clear.
The strategy has been approved. The system required to deliver it has not been built.
A strategy usually answers questions such as:
These are essential questions.
But implementation requires another set:
These questions are not administrative details. They determine whether the strategy is viable.
Organizations often describe the gap between strategy and execution as a failure of communication, project management, or staff commitment.
Sometimes those are factors. But implementation failure is frequently designed into the work from the beginning.
A priority may have no dedicated budget. A team may be accountable for an outcome without authority over the resources required to produce it. A partnership may depend on information-sharing arrangements that do not exist. A transformation may require technology, procurement, legal, or data work that was not reflected in the original timeline. A new service may be approved without a revenue model, staffing structure, or process for managing demand.
The problem is not that people failed to follow the strategy. The problem is that the strategy was never translated into an operating system.
Every strategic priority must be translated into concrete requirements. This includes activities; outputs; capabilities; staffing; technology; information; partnerships; funding; governance; and decisions.
A priority such as "improve service access" is not yet implementable. The organization must determine: which services; for whom; through which channels; with what eligibility rules; supported by which teams; using what data; funded through which mechanism; and measured through which outcomes.
The requirements structure converts strategic language into operating implications.
A strategy is not viable because the organization believes in it. It becomes viable when the financial model explains what implementation will cost, how it will be funded, when cash will be required, and what assumptions must hold.
The financial model should account for more than direct program expenses. It should include staffing; management; technology; professional services; partner payments; training; communications; data; evaluation; administration; contingency; and working capital.
It should also show what happens under different conditions. What if implementation takes six months longer? What if funding arrives later than expected? What if demand is higher? What if participation is lower? What if a partner withdraws?
Financial modelling makes the cost of strategic ambition visible before the organization has to absorb it.
The operating model defines how the organization must work to deliver the strategy. It should clarify required functions; internal and external capabilities; roles; workflows; decision rights; governance; information flows; service standards; and performance responsibilities.
It also determines what should be centralized, distributed, outsourced, automated, or delivered through partners.
An operating model is not an organizational chart. It explains how value is produced and how work moves.
An implementation plan should be more than a timeline. It must connect strategic priorities; workstreams; owners; outputs; resources; dependencies; decision gates; risks; milestones; and measures.
The implementation architecture should show not only what is scheduled, but what must be true before the next stage can begin. For example:
A credible implementation plan makes these dependencies visible.
Implementation requires recurring decisions. Leadership must determine what information will be reviewed; how frequently; by whom; under what authority; and what kinds of issues require escalation.
The governance rhythm should distinguish between routine delivery decisions; cross-functional decisions; financial approvals; strategic trade-offs; risk escalation; and decisions requiring board or funder involvement.
Without this structure, implementation meetings become status updates rather than management forums.
No strategy survives contact with reality unchanged. Implementation will generate new evidence.
Demand may differ from forecasts. Partners may behave differently than expected. Costs may rise. Staff may identify process failures. Users may experience the model in ways that were not anticipated.
The organization must establish what will be monitored; what assumptions are being tested; what signals indicate a problem; who can authorize changes; and when the strategy itself should be reviewed.
Learning should not be postponed until the final evaluation. It should be built into delivery.
A useful test is to take each strategic priority and ask across five lenses—financial, organizational, operational, implementation, and performance. If these questions cannot be answered, the strategy is not yet operational.
Before moving from approval to launch, leadership should ask:
The final question is especially important. A strategy has not been successfully operationalized if the organization remains dependent on undocumented knowledge held by advisors, contractors, or a small number of internal staff.
Approval matters. It creates mandate, legitimacy, and direction. But approval is not implementation.
The work becomes real only when the organization builds the financial logic; the operating model; the implementation architecture; the governance rhythm; the decision system; and the capacity to learn.
The question is not whether the strategy has been approved. It is whether the organization has built the system required to deliver it.
Common Practice translates strategies into financial models, operating structures, implementation systems, and decision tools. We build the operating layer between an approved direction and measurable delivery.
The Post-Approval Checklist — One page: the six layers, the five-lens test, and the eight questions leaders should ask before announcing implementation.