The three terms are used interchangeably, and that blurs a useful distinction. Planning makes the choices; execution does the work; deployment is the connection between them. Most strategic failures happen in the connection.
In this guide
Key Takeaways
- →Planning asks what we should do, deployment asks whether the choices are working, execution asks whether the work is getting done.
- →Planning has a visible event and execution has visible activity. Deployment has neither, which is why it gets skipped.
- →Deployment hands planning evidence about which choices are working. That handover makes it a loop, not a pipeline.
- →Organizations diagnose every miss as an execution failure, because execution is what their tools measure.
- →When the work was done and the result still didn’t move, the problem is almost always deployment.
Three activities, one chain
| Aspect | Strategic planning | Strategy deployment | Strategy execution |
|---|---|---|---|
| Question | What should we do? | How do our choices reach every level, and are they working? | Are we doing the work? |
| Who | Leadership, strategy office | Strategy office, objective owners, every level | Teams and project owners |
| Cadence | Annual, with periodic refresh | Continuous: planning season, monthly, quarterly | Daily and weekly |
| Output | Choices and objectives | Agreed targets, evidence, decisions to adjust | Delivered work |
| Fails as | Vague or unchosen strategy | Targets nobody owns; evidence nobody sees | Missed deadlines, poor quality |
The definition behind the middle column, with its three directions, is in What Is Strategy Deployment? A Definition Without the Jargon.
The rest of this article is about the middle column, because that is the one with no budget line, no software category of its own in most organizations, and the highest failure rate of the three.
Why the middle gets neglected
Planning has a visible event, the strategy offsite. Execution has visible activity, projects and deadlines. Deployment has neither. It happens in the negotiations over targets, the monthly comparison of work against results, and the conversations between functions, none of which feel like a distinct activity.
So organizations invest in planning (consultants, offsites) and execution (project tools, delivery teams), and leave deployment to a cascade and a quarterly slide pack. Then they’re surprised when a well-made strategy and well-run projects add up to a missed result.
Good planning and good execution don’t add up to a delivered strategy. The connection between them has to be built too.
Where each ends and the next begins
- Planning hands deployment a set of choices and objectives.
- Deployment hands execution agreed targets, priorities and owners.
- Execution hands deployment progress and results.
- Deployment hands planning evidence about which choices are working, which is the input the next planning cycle most needs and least often gets.
The last handover is what makes deployment a loop rather than a pipeline. Without it, each planning cycle starts from opinion instead of evidence. The planning side is covered in depth in Hansei: Reviewing Last Year’s X-Matrix Before Planning the Next.
A worked example: one miss, three diagnoses
An illustrative group misses its services target by three points. Depending on which activity failed, the fix is completely different.
| If the failure was in | You’d see | The fix |
|---|---|---|
| Planning | Services growth was never a real choice: no resources moved, nothing stopped | Make the choice, or drop the target |
| Execution | Service centers opened late; contract model never launched | Delivery: capacity, project management |
| Deployment | Centers opened on time, contracts launched, but attach rates didn’t move and nobody saw it until year end | Evidence up: connect work to results monthly |
Organizations tend to diagnose every miss as an execution failure, because execution is what their tools measure. When the work was done and the result still didn’t move, the problem is almost always in deployment.
That specific pattern has a name and a diagnosis of its own: Outcome Lag: When Priorities Are Green and KPIs Don’t Move.
What the middle costs to run
The deployment layer is the one organizations most often run on unpaid labor: a strategy analyst rebuilding a pack each month from systems that don’t talk to each other. A week a month of one person’s time is the usual figure, and it buys a view that is already three weeks old by the time anyone reads it.
Among published alternatives, OnStrategy lists $200 per month for unlimited users. i-nexus publishes a free Starter tier for up to five users and $28 per user per month at its Standard tier. Both are worth testing against one question: when execution reports progress, does the tool show the result that progress was meant to move?
Profit.co publishes two plans, Essentials and Enterprise, quoting against modules and scale rather than a public seat rate. The deployment layer sits in Essentials with OKRs and Goals, Balanced Scorecard, Hoshin Kanri and Strategy Roadmap on one data model, so planning output and execution progress land in the same place. Building the Business Case for Hoshin Kanri Software sets out how to total it, and the 30-day free trial covers a full monthly review.
Software for each activity
Planning is mostly thinking and documents. Execution has mature tools: project and portfolio management, task tracking. Deployment is the category that connects them, which is why it needs to integrate with both: objectives from planning, work from execution tools, and evidence moving between them.
Profit.co runs the deployment layer, connecting objectives, OKRs, scorecards and hoshin plans, with project portfolios and performance management on the same platform. See the Hoshin Kanri software page.
In practice that means three things:
- Objectives arrive from planning as records with owners, targets and the reasoning behind them, not as slides.
- Work arrives from execution through project and task integrations, so progress is reported once rather than re-entered.
- Evidence moves back through check-ins that show a result beside the work meant to move it, and an exception queue for the cases where they disagree.
How this category differs from the execution tools next to it is set out in Purpose-Built Hoshin Kanri Tools vs Strategy Execution Platforms.
Free Product Demo
Find where your strategy chain breaks
A 30-minute walkthrough, tailored to your team.
Book a free demo
What happens in the call
How your teams set goals, track progress and review results.
Strategy, performance, projects and engagement on one platform, with AI.
A practical path to align teams, execute faster and drive results.
Questions this article answers
Execution is the work that carries out the strategy. Deployment connects strategic choices to that work, agreeing targets with each level and bringing back evidence of whether the work is moving the results.
No. Planning makes the choices; deployment makes them operational and tests them. The two connect at the start of each cycle, when deployment’s evidence should inform the next plan.
Because the connection between them, deployment, is neglected: targets aren’t owned, evidence of effect isn’t seen, and dependencies between functions aren’t agreed.
Look at whether the work was delivered. If initiatives slipped, that is execution. If they finished on time and the result still didn’t move, and nobody noticed until year end, that is deployment.
Not separate, but connected. Deployment software has to integrate with both sides: objectives from planning and work from execution tools, with evidence moving between them. Profit.co runs that layer alongside project portfolios and performance management on one platform.
