Every year, hundreds of companies invest in Hoshin Kanri. Leadership teams gather in offsite sessions. Strategic objectives are defined. Initiatives are listed. Owners are named. A planning document is produced, approved, and communicated.
And then very little changes — on the production floor, in the commercial teams, in the support functions. Everywhere that matters.
I have seen this pattern play out across dozens of organisations. The Hoshin process looks rigorous at the top. Ask a line supervisor what the company's top three strategic priorities are and you get a blank stare — or three different answers from three different supervisors.
The failure is not in the strategy. It is in what happens — or does not happen — between strategy definition and daily execution. In my experience, there are three root causes that account for the vast majority of Hoshin Kanri failures: the cascade problem, the capability problem, and the governance problem.
The cascade problem: strategy that stops at the leadership level
Hoshin Kanri was designed as a system for translating corporate strategy vertically through every level of the organisation and horizontally across every function — Operations, Sales, HR, IT, Finance, R&D, Procurement, Engineering. The catchball process — the structured dialogue between levels where targets are negotiated, not simply imposed — is the mechanism that makes this translation happen. The goal is not just to reach the production floor. It is to eliminate silos by ensuring that every department, down to its frontline teams, has objectives designed to support the same strategic priorities at the top.
"Strategy that does not reach the line is not strategy. It is a document."
In practice, most organisations stop the cascade at the second or third level of management. The leadership team has clear strategic objectives. Division heads have annual targets. Plant managers have KPIs. But the connection between those KPIs and the daily work of a maintenance technician or a production operator is invisible.
Toyota, where Hoshin Kanri was developed and refined over decades, never treated the planning phase as the destination. It was the starting point for a process of collaborative deployment that would translate corporate objectives into meaningful, measurable targets for every level and every function of the organisation. A digital transformation objective, for example, requires aligned IT and Digital transformation targets all the way down to their frontline teams — so that their work actively supports what Operations needs to achieve. The same logic applies to R&D, Procurement, Engineering, HR and Commercial. All functions. All levels. One direction.
A genuine Hoshin cascade has five levels: corporate strategic objectives, division or region annual targets, plant-level improvement priorities, departmental KPIs and weekly targets, and team-level daily visual management. At each level, the connection to the level above must be explicit and traceable. A line supervisor should be able to draw a direct line from their daily performance target to the plant's annual objective to the corporate strategic priority. If they cannot, the cascade is incomplete.
Hoshin Kanri vs. traditional Management by Objectives
Most organisations already have some form of objective cascading — annual targets set at the top, broken down by division, by department, by team. It looks like alignment. It rarely is.
The dominant model in European organisations is still Management by Objectives (MBO) — or its more recent variants, OKRs and KPI cascades. The logic is simple and appealing: set the number at the top, break it down, assign ownership, review at year end. The problem is structural, not executional. The model was designed for a world where strategy is stable, functions are independent, and performance is fully measurable by financial outcomes.
Hoshin Kanri was designed for a different problem: how to create genuine alignment across a complex organisation where strategy requires cross-functional coordination, capability development and behavioural change — not just numerical targets.
| Dimension | MBO / Traditional cascade | Hoshin Kanri |
|---|---|---|
| Flow of objectives | Top-down. Targets assigned by hierarchy. | Bidirectional. Catchball — targets negotiated up and down. |
| Ownership | Assigned. People receive their targets. | Co-constructed. People propose and negotiate their targets. |
| Focus | Financial results and lag KPIs. | Results + capability development + leadership behaviours. |
| Review cadence | Annual or semi-annual. Often just the year-end conversation. | Structured monthly, quarterly and annual cycles with defined escalation. |
| Response to gaps | Pressure to recover the number. Root cause rarely addressed. | Structured root cause analysis and corrective action. Gaps are learning opportunities. |
| Cross-functional alignment | Implicit. Each function manages its own KPIs independently. | Explicit. Objectives designed together to eliminate silos and shared dependencies. |
| Capability building | Separate from strategy. Training as an HR initiative. | Integral to deployment. Building the capability to close the gap is part of the plan. |
| Culture generated | Manage the appearance of KPIs. Hide problems to avoid consequences. | Surface problems early. Raising a gap is expected — hiding it is the failure. |
The critical difference is not the tool. It is the direction of information flow and the culture it creates. MBO generates a culture where people manage the appearance of their KPIs. Hoshin Kanri, when implemented properly, generates a culture where surfacing a problem is expected — because the system is designed to respond to it, not to punish the messenger.
The capability problem: deploying targets without building the skills to close gaps
Hoshin Kanri requires people at every level to close strategic gaps. But closing gaps requires capabilities that often do not exist yet — structured problem solving, PDCA thinking, standard work, data analysis, root cause identification. If the organisation deploys Hoshin targets without building these capabilities in parallel, the targets become pressure without tools.
This is one of the most underestimated failure modes. An organisation sets a stretch goal on OEE improvement. The plant manager accepts the target through catchball. But the maintenance team has never been trained in autonomous maintenance. The production supervisors do not have a structured problem-solving method. The team leaders do not know how to use a daily management board to identify and escalate deviations.
The result is predictable: the target is missed, people feel blamed, and Hoshin becomes associated with pressure and failure rather than learning and improvement.
"You cannot deploy Hoshin targets without deploying the capability to close them."
The Hoshin deployment needs to be paired with a structured capability development plan — identifying what skills are required at what level to achieve the breakthrough objectives, and building those skills through training, Gemba practice, and coaching, in parallel with the strategy deployment itself.
Leadership capability matters just as much as technical capability. Managers need to learn how to coach rather than direct, how to surface problems rather than hide them, and how to run a structured review rather than a reporting meeting. These are not natural behaviours — they are learned skills that require deliberate development.
The governance problem: Hoshin without daily management is a once-a-year ritual
Hoshin Kanri is not a planning exercise. It is a management system. The planning phase — defining objectives, running catchball, setting targets — is perhaps 20% of the work. The remaining 80% is governance: the structured review cycles, the escalation mechanisms, the connection to daily operations that keeps the strategy alive between planning rounds.
For Hoshin to work, the daily management system needs to be designed with Hoshin in mind — across all functions, not just Operations. Each team's review routines should show the metrics that connect directly to their Hoshin targets. The cross-functional weekly review should assess alignment between departments and surface the dependencies that need resolution. The monthly management review should evaluate whether the combined trajectory across all functions is on track toward the strategic objective, and trigger corrective action where it is not. This is how silos are broken — not by communication campaigns, but by shared objectives reviewed together, regularly.
Without this governance architecture, Hoshin becomes an annual offsite ritual. The strategy is reviewed once a year, updated once a year, and forgotten in between. The daily management system runs on operational metrics that have no explicit connection to the strategic objectives. The two systems coexist in the same organisation but never actually talk to each other.
Building the governance system requires designing the review cadence, defining what gets reviewed at each level, training leaders to run structured reviews rather than information-sharing meetings, and connecting the Hoshin dashboard to the daily management system so that deviations at the operational level trigger the right escalation at the strategic level.
What a complete Hoshin system looks like
In the deployments I have led — including the global system at Logoplaste across 68 plants and 17 countries — a complete Hoshin system has three interconnected elements:
- Cascade integrity: A five-level cascade from corporate to line, with catchball at each transition, traceable connections between levels, and ownership at every tier
- Capability architecture: A structured development plan that builds the problem-solving, leadership, and operational skills needed to close strategic gaps — delivered in parallel with the deployment, not as an afterthought
- Governance system: A tiered review cadence from daily management in each function's frontline teams to monthly strategic review at leadership level, all connected and designed to surface deviations early and trigger corrective action fast
None of these elements works in isolation. A strong cascade with no capability development produces overwhelmed teams. Strong capability with no governance produces inconsistent execution. Strong governance with an incomplete cascade produces well-managed KPIs that have no connection to strategy.
Vítor Vila Verde is the founder of Capabilium Partners. He led Strategy Deployment & Operational Excellence at Logoplaste across 68 plants in 17 countries, implementing Hoshin Kanri systems based on Toyota's cascading model.