In this guide
Key Takeaways
- →Two ways to get it wrong: copy-paste, where no site owns its matrix, and fragmentation, where nothing rolls up.
- →Nest instead. A group priority becomes a site objective, and the site builds its own plan to deliver it.
- →Standardize KPI definitions, the calendar, correlation grading and the planning gate. Let priorities, countermeasures and phasing vary.
- →Multi-site organizations have a built-in experiment. Sites running a priority and sites not running it are evidence about whether the correlation holds.
- →Group first for three cycles, then one or two pilot sites, then waves. Connecting everything at once is the most expensive mistake available.
- →Seats are the commercial question here. How viewers at eight sites are licensed changes the total more than the rate does.
Multi-site hoshin tends to fail in one of two directions. Either every site receives a copy of the corporate matrix and owns none of it, or every site builds its own and nothing rolls up. The method already contains the answer: one level’s “how” becomes the next level’s “what”.
Two ways to get it wrong
| Pattern | What it looks like | What goes wrong |
|---|---|---|
| Copy-paste | Each site receives the corporate matrix with its own name on it | No local ownership; site priorities that don’t fit local reality; catchball skipped |
| Fragmentation | Each site builds its own matrix from scratch | Nothing rolls up; corporate can’t see whether sites add up to the breakthrough |
Both are understandable. Copy-paste is fast and looks aligned. Fragmentation respects local knowledge and looks empowering. Neither deploys strategy, which is the whole point of hoshin kanri.
Nesting: the how becomes the what
Classic hoshin deployment links levels through their priorities. A corporate priority, the “how” at group level, becomes an objective, the “what”, at site level. The site then builds its own priorities, KPIs and correlations to deliver it, and negotiates targets with the group through catchball.
In practice, a group priority such as “bring eight sites to operational maturity level 2” becomes, at each site, an objective like “this site to level 2”. Each site’s plan for getting there is its own. Progress at the sites rolls up to the group priority, and the group can see which sites are carrying it and which aren’t.
Sites should own how they deliver. The group should own what is delivered and how it is measured.
Standardize these, let these vary
| Standardize across sites | Let vary by site |
|---|---|
| KPI definitions, units and calculation | Site priorities and how they’re sequenced |
| The review calendar and check-in cadence | Countermeasures and local problem-solving |
| Correlation grading rules | Which local KPIs supplement the common ones |
| The planning gate for new priorities | Phasing of plan rows, by local seasonality |
The most important item is the first. If “on-time delivery” is calculated differently at each site, the group roll-up is meaningless and comparisons between sites start arguments rather than ending them.
Sites as a natural comparison
Multi-site organizations have an advantage single sites don’t: a built-in comparison. When a priority runs at some sites and not others, or starts at different times, the KPI at each site becomes evidence about whether the correlation holds.
That’s the most practical way to answer the swamping question in an outcome-lag diagnosis. If the KPI is flat everywhere, including where the priority runs, the market may be swamping the effect. If it’s flat only where the priority runs, the mechanism is the problem. Record partial correlations by site so this comparison is possible.
Rollout order
- Group first. Run three review cycles on the group matrix before connecting any site.
- One or two pilot sites. Choose sites with strong local leadership and some hoshin practice already.
- Site reviews before group reviews. Each site’s monthly review runs a few days before the group review, so the group sees current site data.
- Extend in waves. Add sites a few at a time, once the pilots have run three cycles.
Different sites will be at different levels of maturity, and that’s fine. Expect pilot sites to run full catchball and countermeasures while later sites start with check-ins and the bowler.
A worked example: one priority across four sites
An illustrative group priority, “bring eight sites to operational maturity level 2”, becomes an objective at each site. Here is the picture at mid-year for four of them.
| Site | Site objective | Progress | Status |
|---|---|---|---|
| Site A | Reach level 3 (already at 2) | 75% | On track |
| Site B | Reach level 2 | 63% | At risk |
| Site C | Reach level 2 | 31% | Off track |
| Site D | Reach level 2 | 50% | At risk |
Illustrative.
Because each site objective contributes to the group priority, the group sees not just an average but who is carrying it. Site C is the outlier, and its owner’s check-in comment explains why: an audit failed on maintenance records and a countermeasure is under way.
The sites also give the group a comparison. On-time delivery improved by six points at the sites that reached level 2 last year and by one point at the others. That’s evidence, not proof, that the correlation between site maturity and on-time delivery holds, and it’s exactly the evidence the group needs when deciding whether to fund the next wave.
What multi-site deployment needs from the software
Nesting is easy to describe and hard to retrofit. Most strategy deployment software models one matrix well and treats a second level as a reporting problem, which works until a site wants to run catchball on its own targets. Six things decide whether the model above is possible at all.
| What multi-site needs | Why it matters | How to test it in a demo |
|---|---|---|
| A site objective that contributes upward | The roll-up has to be structural, not a report someone assembles | Ask to see a group priority with four sites contributing at different weights |
| Central KPI definitions | If each site can redefine on-time delivery, the roll-up means nothing | Ask who can change a KPI definition, and what happens to sites using it |
| Catchball at every level | Group-to-site negotiation is the whole method; without it you have copy-paste | Ask to see a catchball thread between a group and a site owner |
| Correlations recorded per site | The natural comparison above only works if site-level evidence is kept separately | Ask how the same correlation can be graded differently at two sites |
| Site-level permissions | Sites need to run their own plan without seeing or editing each other’s | Ask what a site lead sees when they log in |
| Adding sites in waves | Wave two should not be a reconfiguration project | Ask what adding three more sites in month six actually involves |
The third row is the one specialists usually win and platforms sometimes miss.
Seats are the commercial question here
Multi-site is where seat licensing stops being a detail. A group matrix might need thirty contributors; the same program across eight sites can need several hundred people who need to see the matrix and a few dozen who own rows on it. Which of those counts as a licensed user changes the three-year total far more than the headline rate does.
The temptation is to buy fewer seats than the program needs and give site teams a monthly export instead. That is the fragmentation failure arriving through the finance door: sites stop seeing their own plan between reviews, local ownership decays, and within two cycles the matrix is something head office maintains. Model the cost at the deployment you expect in year three, with viewers included, which is the arithmetic what drives the cost of hoshin kanri software sets out line by line.
Worth asking every vendor the same two questions before a shortlist narrows: how are view-only users at a site licensed, and what does the price look like at three times today’s user count? RFP questions that separate matrix storage from strategy execution puts both in writing.
Multi-site hoshin in Profit.co
In Profit.co, site objectives can contribute to group objectives as key results, so each site’s progress rolls up with its own owner, weighting and status visible on the group objective. The group can see which sites are on track against a priority and which aren’t, and catchball sessions run on each objective at each level, with a balance constraint so site targets add up. More on the hoshin kanri software overview.
Because Hoshin Kanri sits in the Essentials plan with OKRs and Goals, Balanced Scorecard and Strategy Roadmap, a site running team OKRs beneath its own matrix is on the same subscription and the same check-in engine as the group matrix above it, rather than a second tool to license per site. That matters more at eight sites than at one: licensing OKR software and balanced scorecard software per site as well turns one seat question into three. The 30-day free trial is long enough to connect one pilot site to a group priority and watch the roll-up behave before any wave is planned.
Free Product Demo
See your group and site matrices connected
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
Turn each relevant group priority into a site objective, let each site build its own priorities and plan to deliver it, negotiate targets through catchball, standardize KPI definitions, and roll site results up to the group.
KPI definitions and calculations, the review calendar and check-in cadence, correlation grading rules and the planning gate. Site priorities, countermeasures and phasing can vary.
One or two pilot sites with strong local leadership, after the group matrix has run for three review cycles, then further sites in waves.
Site objectives that contribute upward structurally, centrally controlled KPI definitions, catchball at every level, correlations graded per site, site-level permissions, and adding sites in waves without reconfiguration.
More than the rate does. A thirty-person group matrix can become several hundred viewers across eight sites. Ask how view-only site users are licensed and what the price looks like at three times today’s count.
It works for a cycle or two, then fails. Sites stop seeing their own plan between reviews, local ownership decays, and the matrix becomes something head office maintains, which is the fragmentation failure arriving through the finance door.
