Hoshin Kanri, delivered to your clients
The plan was agreed upstairs. Hoshin Kanri is how it reaches the floor.
Most planning frameworks help a leadership team decide. Hoshin Kanri is about the other problem: getting that decision through every level of the business so the people who have to do the work are carrying an objective that supports the one above it. Loaded as a plan, with owners at each level and progress visible between your sessions.
- Objectives that carry the level above
- A workspace per client, branded as you
- Framework-agnostic, so one client can run this and the next something else
The today line
Every bar is read against it, so late work shows up as a gap rather than a status someone typed.
Filter to the problem
Overdue, off track, on track, started or not started, across every team.
Week to year
Zoom out for the board, in for the quarter, or fit the whole plan on one screen.
A goal and its objectives
Open a goal to see the measures under it and which one is dragging.
What it is
It is a deployment method, not a way of setting goals.
That is the distinction worth getting right before you take it to a client, because it decides which problem you are selling a solution to.
Hoshin Kanri came out of Japanese quality management in the 1960s, built on Deming’s plan-do-check-act cycle, Juran’s work on management and quality, and Drucker’s management by objectives. It got its name in 1965, when Bridgestone Tire published a report analysing how the Deming Prize winning companies planned. By the mid 1970s it was standard practice in Japan, and it reached the United States in the early 1980s through firms including Hewlett-Packard, who called their version hoshin planning. The name is worth knowing: hoshin is a direction or a compass needle, and kanri is management. It is about pointing an organisation the same way, not about writing better objectives.
The method starts with deliberate scarcity. A small number of breakthrough objectives, often one to three, chosen against a three to five year intent, on the argument that an organisation can genuinely change a few things at once and not more. Those objectives are then deployed down through the levels: each level sets objectives that support the level above, so a site manager’s year is legible as part of the company’s year rather than a separate document that happens to exist alongside it.
The part that makes it work, and the part most write-ups skip, is that deployment is a negotiation rather than a cascade. Catchball is the practice of throwing a proposed objective down a level and having it thrown back changed: this is not achievable with the people we have, this is achievable if you move that deadline, this measure will make us do the wrong thing. A cascade that arrives as an instruction produces compliance. Catchball produces commitment, and the difference shows up in month four.
Then a fixed review cadence, usually monthly at the level below and quarterly above, asking the same question each time: is the objective moving, and if not, is the problem the plan or the execution. That question is the one a client cannot answer without somewhere the plan actually lives.
- One to three breakthrough objectives, chosen against a three to five year intent
- Deployed level by level, each one supporting the objective above it
- Catchball: the objective is negotiated downward, not issued
- A fixed review cadence asking whether the plan or the execution is the problem
In the library
Hoshin Kanri is a ready-made plan, not a setting.
The ready-made plan gives a client the deployment shape already built: breakthrough objectives at the top, supporting objectives under them with an owner each, and measures that say whether a level is actually carrying what it agreed to.
3 goals · 6 objectives, loaded into a client’s workspace in one action
What the plan carries
Breakthrough objectives, deliberately few
Three goals rather than ten, because the discipline is the framework. Adding a fourth is a decision somebody has to defend in the room, which is exactly what hoshin is for.
Supporting objectives with an owner each
Each objective names the person accountable and the measure that proves it moved. A supporting objective with no owner is the failure mode hoshin exists to prevent, and it shows up as an unassigned row.
How measures workThe review cadence, as meetings
Build the monthly and quarterly agendas once as templates in myPortal and reuse them across the book. Check-ins arrive before the call, so the review opens on the objective that is behind.
How meetings runOne page, every level
The vision, the values and every goal with its objectives and live progress. What deployment produces has to be readable in one screen or it is not deployed.
Vision
The one sentence everything else has to serve, in front of everyone who works on the plan.
Core values
How the business behaves, kept beside the numbers rather than on a poster.
Live progress on every goal
No one rebuilds this page for a meeting. It is right whenever you open it.
Export to PDF
The same page as a PDF for the offsite or the board pack.
Delivering it
Where a hoshin engagement usually goes wrong, and what to do instead.
The framework survives the workshop. It rarely survives the deployment, because deployment is where the artefact stops being one document and becomes forty.
- One
Set the breakthroughs with the leadership team
Applied into their workspace in the session, so the argument about whether there are three or five is had against a plan rather than a whiteboard.
- Two
Run catchball against the real plan
Each level proposes its supporting objectives in the same system, with an owner and a measure attached. What comes back changed is visible to the level above rather than emailed to you.
- Three
Review on the cadence, not on request
Progress against expected pace at every level, so the monthly asks whether the plan or the execution is the problem, which is the question the method is built around.
Where it does not fit
Three things to know before you take this to a client.
Hoshin Kanri is a strong framework in the wrong place more often than most, and being clear about where it does not fit is part of selling it well.
There is no X-matrix drawing
The X-matrix, the one-page grid tying breakthroughs to annual objectives to improvement priorities to metrics, is not drawn in Empiraa GPS. The relationships it expresses are in the plan as objectives supporting objectives, but if the matrix itself is your deliverable you will keep producing it elsewhere.
Catchball is a human process
Software can hold what was proposed and what came back changed. It cannot make a site manager say "this is not achievable" to somebody two levels above them. That culture is the engagement, and a firm that thinks a tool supplies it is going to be disappointed by any tool.
It assumes an annual rhythm
Hoshin was built where the planning cycle is stable and the horizon is years: manufacturing, operations, large services businesses. For a client whose market resets every quarter it can feel like ceremony, and a shorter-cycle framework will be honestly better.
The client in front of you
Is Hoshin Kanri the right call for this client?
Five questions about them, not about you. The answer is graded rather than yes or no, and it names what to compare against either way.
Yes
On these answers Hoshin Kanri is where I would start.
Hoshin Kanri is worth it here because a deployment method. It gets a decision through every level of a business, which is the problem when a plan dies below the leadership team.
Decided mostly by: the plan dies between the leadership team and the sites
Also worth reading: Balanced Scorecard, because it puts financial results beside the customer, process and people measures that produced them, so cause and effect stops being guesswork.
A starting point, not advice. You know this client and this tool does not, and the useful part is that whichever framework it names has a page with the plan already built.
Who reaches for it
The firms that arrive already selling this.
Each of these is a page in its own right, with the argument written for that profession rather than for a framework.
Strategy consultants
You wrote the plan. Somebody has to run it.
Read their argumentPrivate equity
Fourteen companies, fourteen spreadsheet formats.
Read their argumentOr read a framework that fits better
OKR Framework
For a faster cycle and an outcome focus. OKRs measure whether a result happened; hoshin gets a decision through a hierarchy. A client complaining about alignment often wants the second and asks for the first.
Read itEOS (Traction)
For a smaller client, roughly ten to two hundred and fifty people in one business, where the problem is rhythm rather than deployment across levels.
Read itBalanced Scorecard
If the client can state the direction and the real gap is that financial results are being read without the customer, process and people measures that produced them.
Read itQuestions
Hoshin Kanri, answered.
Is there Hoshin Kanri software in Empiraa?
Yes. Hoshin Kanri is a ready-made plan in the strategy library, carrying three goals and six objectives, and applying it gives a client a plan already shaped for deployment: breakthrough objectives at the top with supporting objectives and owners under them. It is one of fifteen named frameworks rather than the only thing the software runs.
What is the difference between Hoshin Kanri and OKRs?
OKRs are a way of measuring outcomes: an objective with key results that are true or false at the end of the period. Hoshin Kanri is a way of deploying a decision through an organisation: a small number of breakthrough objectives, negotiated down level by level through catchball, reviewed on a fixed cadence. They answer different questions and a business can run both, with hoshin deciding what each level is responsible for and OKRs measuring whether it happened. OKRs in Empiraa GPS.
Does it draw the X-matrix?
No. The X-matrix is not a drawing in Empiraa GPS. The relationships it expresses, breakthrough to annual objective to owner to measure, are in the plan as structure, so the information is there and the one-page grid is not. If the matrix is your client deliverable you will keep producing it in whatever you produce it in now.
What is catchball?
Catchball is the practice of proposing an objective to the level below and having it come back changed, rather than issuing it. The level below says what is not achievable, what would be achievable with a different deadline, or which measure would make them do the wrong thing. It is the difference between compliance and commitment, and it is the part of hoshin that most implementations quietly drop.
Can I run it for a multi-site client?
That is the case it suits best. A plan that dies between the leadership team and the sites is the exact problem hoshin was built for, and each site carrying objectives that support the company objective is visible in one plan rather than in one spreadsheet per site arriving late in a different shape.
Can I change the plan into my own version?
Yes. Open it in the plan builder in myPortal, rename the goals, cut the objectives that never fit your clients, add the ones you always add, and save it as one of your own templates. The next client starts from your version rather than the library’s. Every framework in the library.
Bring one client and see.
Load the framework you already sell into a client's workspace under your own logo, and see whether it survives the eight weeks between your sessions.