Most hoshin plans that fail mid-year don’t fail on strategy. They fail because the same twenty people were committed to twice the work they could do. A capacity check before the matrix is locked catches this while it can still be fixed.
In this guide
Key Takeaways
- →Names on the matrix are not capacity. The question is whether the people exist, not whose name fits the row.
- →Correct this year’s estimates with last year’s actual-to-planned ratio. Crude beats optimistic.
- →Availability means what is left after operations, customer commitments, regulatory work and maintenance.
- →Check individuals as well as teams. No person should own more than two priorities on the group matrix.
- →Four resolutions, in order: stop, sequence, cut, add resources. “Stretch” is not one of them.
- →An overload resolved in planning costs a conversation. Found in March, it costs a priority you didn’t choose.
The plan is staffed on paper
The right-hand side of the classic X-matrix lists the people and teams who own each priority. It’s meant to answer a simple question: do we have the people to do this? In most planning seasons it answers a different one: whose name should go next to this row?
Names are easy to add. Capacity isn’t. The same senior people end up against most priorities, each priority is estimated optimistically, and nobody adds up the totals. The overload shows up in March, when priorities start slipping in an order nobody chose.
Step 1: estimate effort honestly
For each candidate priority, estimate the effort it needs by team, in person-months or a similar unit. Then correct the estimates with last year’s evidence.
The reflection should show how much effort last year’s priorities actually consumed compared with plan. If priorities typically took half as much again as estimated, apply that multiplier to this year’s estimates. It’s crude, and far more accurate than assuming this year’s estimates are the first ever to be right.
Step 2: find real availability
For each team, estimate the capacity left after the work that has to continue regardless: operations, customer commitments, regulatory work, maintenance. Planning often treats teams as fully available for priorities, when in practice most of their time is already committed.
A quick way to get a realistic figure is to ask each team lead what share of their team’s time went to priority work last year, rather than what share they hope to give this year.
Step 3: compare and find the overloads
| Team | Available (person-months) | Demanded by priorities | Status |
|---|---|---|---|
| Service operations | 24 | 41 | Overloaded |
| Pricing and commercial | 18 | 15 | Within capacity |
| Site engineering | 30 | 33 | At the limit |
| Procurement | 12 | 8 | Within capacity |
Illustrative capacity check after applying a reality multiplier.
Also check individuals. If one person owns or leads work on four priorities, that person is the plan’s bottleneck regardless of what the team totals say. A useful rule is that no person owns more than two priorities on the group matrix.
Step 4: resolve before locking
Overloads have four possible resolutions, in rough order of preference:
- Stop something. Free capacity through the stop-doing list.
- Sequence. Start some priorities in the second half, after others finish.
- Cut. Remove the lowest-ranked priority that uses the overloaded team.
- Add resources. Hire, contract or reassign, with the time needed to do so built into the plan.
“Ask the team to stretch” isn’t on the list. It’s what happens by default when the check isn’t done, and it’s the reason priorities slip in an order nobody chose.
An overload you resolve in planning costs a hard conversation. One you discover in March costs a priority, and you don’t get to choose which.
What the capacity check needs from the software
Each of the first three steps asks for a number that the organization already generated and usually threw away. Step 1 wants last year’s actual effort against plan. Step 2 wants the share of each team’s time that went to priority work rather than to operations. Step 3 wants every row’s owner, totalled by person.
None of that is hard to produce from a system that tracked the year. All of it is guesswork from a system that tracked only the current quarter, and guesswork here defeats the whole exercise, because the optimistic estimate is exactly what the check exists to correct.
| Step | What the tool has to supply | How to test it in a demo |
|---|---|---|
| 1. Effort estimates | Planned versus actual effort per priority, last year | Show me a priority that took more than it was given |
| 1. Multiplier | The ratio across all priorities, not one example | What did priorities cost against plan on average? |
| 2. Availability | Priority work visible beside the projects and operations it competes with | Show me everything this team is committed to |
| 3. Team totals | Demand summed by team across all candidate priorities | Total the effort demanded of service operations |
| 3. Individuals | A filter for people owning more than two rows | Show me everyone named against four priorities |
| 4. Sequence | Priorities with start dates, not just a year | Move this priority to a second-half start |
| 4. Add resources | The hiring lead time visible in the plan, as a dependency | Record that this priority waits on two hires |
Row 5 is a one-click answer or a manual audit, and it decides whether individuals get checked at all.
Row 5 is worth pressing on. The individual check is the one most often skipped, not because anyone disagrees with it but because reconstructing who owns what across a matrix, a project list and several team plans takes an afternoon nobody has in week five. Where ownership is a field on every row, it is a filter. The same structure is what makes the planning room easy to fill correctly.
Row 3 is the one that separates a planning tool from a platform. A team’s availability depends on what else it is committed to, and most of that is projects and operational work rather than matrix priorities. Where hoshin and the project portfolio are separate systems, step 2 is a survey; where they aren’t, it is a report.
What an overload costs in March
Take the example table at face value. Service operations is short by seventeen person-months, roughly a year and a half of one person’s time. That shortfall does not announce itself; it arrives as two priorities drifting, a third quietly deprioritized by whoever was most overloaded, and a reflection next October marking those bets “not tested”. The organization spent the year and learned nothing about whether the ideas worked, which is the second cost and the larger one.
Licensing shapes how well you can see this coming. 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. Steps 2 and 3 need the delivery teams and their work inside the system, not just the planning group, so a per-seat model prices exactly the visibility the check depends on.
Profit.co publishes two plans, Essentials and Enterprise, and quotes against modules and scale rather than a public seat rate. Because hoshin kanri runs alongside project portfolios and OKRs and Goals on one platform, with Balanced Scorecard and Strategy Roadmap in the same Essentials plan, step 2 can read what a team is already committed to rather than asking it. What drives the cost of hoshin kanri software covers the rest of what to total, and the seven pass/fail tests the questions to ask in an evaluation.
The 30-day free trial is long enough to load this year’s priorities and owners and run step 3 on them, which usually finds the bottleneck before the planning room does.
Capacity in Profit.co
In Profit.co, every priority and KPI on the X-matrix shows its owners, so people who appear against too many rows are visible from the matrix itself. Last year’s objectives keep their check-in histories, which helps the reflection estimate how much priorities actually took. Because hoshin runs alongside project portfolios on the same platform, the work already committed to projects can be seen alongside the plan. More on the planning software page.
Against the four resolutions, that gives each one somewhere to land. A stop recorded on the stop-doing list names the priority its freed capacity goes to. A sequencing decision becomes a start date on the row rather than an intention. A cut removes the demand from the team total immediately, so the room can see whether the overload actually cleared. And where resources are added, the lead time sits in the plan as a dependency, which is what stops a priority being counted as staffed from January when its people arrive in April.
Free Product Demo
Check whether next year’s plan is staffed
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
Estimate effort per priority by team, apply a reality multiplier from last year, compare with each team’s real availability after essential work, and check for individuals named against too many priorities.
A useful rule is no more than two on the group matrix. More than that usually makes the person the plan’s bottleneck.
In order of preference: stop other work, sequence priorities across the year, cut the lowest-ranked priority, or add resources with the hiring time built into the plan.
The ratio of actual to planned effort from last year’s priorities, applied to this year’s estimates. If priorities typically took half as much again as estimated, multiply by 1.5.
Planned versus actual effort from last year, demand summed by team across candidate priorities, a filter for individuals owning several rows, and what each team is already committed to in projects and operations.
On day two of the offsite, after the stop-doing list and before the matrix is locked. Resolving an overload needs the room that chose the priorities still in session.
