In this guide
- Why planning software cases get rejected
- Start with an audit of last year’s matrix
- Three claims you can defend
- When finance asks for an ROI number
- Propose a pilot with pass/fail criteria
- Name the risks yourself
- A worked example: from audit to a one-page case
- A one-page structure
- A business case template you can fill in
- Questions this article answers
Key Takeaways
- →“Better alignment” is not a benefit finance can price. Build the case on three claims you can defend from your own records.
- →Last year’s X-matrix is the evidence. Five audit questions, answerable in a day from the review packs.
- →Time recovered is the floor: certain, smallest, presented honestly. Decision latency sits in the middle. Resources redeployed is the largest and needs the most care.
- →Don’t borrow a vendor ROI figure. If finance asks for one, build the software cost benefit analysis from the audit instead.
- →Ask for a three-cycle pilot with pass/fail criteria agreed in advance, not a full rollout.
- →Name your own risks: adoption, parallel processes, method gaps. A case that names them reads as more credible than one that doesn’t.
“Better alignment” won’t get a purchase approved, and an invented ROI figure won’t survive a finance review. The strongest business case for hoshin kanri software uses your own matrix from last year as the evidence.
Why planning software cases get rejected
Business cases for strategy and planning software tend to fail in one of two ways. Some rest on benefits nobody can measure: alignment, visibility, engagement. Finance reads those as costs with adjectives attached. Others borrow a return-on-investment figure from a vendor study or an analyst report. A skeptical approver asks how that number applies here, and nobody can say.
Hoshin kanri has an advantage most planning methods don’t. It produces an explicit record of what the organization bet on and what happened. That record, last year’s X-matrix set against last year’s results, is the best evidence available, because it’s yours.
Start with an audit of last year’s matrix
Take the X-matrix from the start of last year and answer five questions about it. A strategy lead can usually do this in a day with the review packs.
| Question | What it tells you |
|---|---|
| How many priorities reached completion while the KPI they were graded strongest against missed its target? | How many losing bets the program carried |
| For each one, in which month did the data first show the gap, and in which month did a review act on it? | Decision latency: the months a losing bet ran unseen |
| Roughly what people and budget did those priorities consume during the gap? | The cost of that latency |
| How many hours a month went into collecting, formatting and reconciling matrix data? | The cost of upkeep |
| Which targets changed during the year, and can anyone reconstruct why? | Whether the program keeps its own history |
Answer from records, not memory, wherever possible.
Most organizations find at least one priority that finished on schedule and moved nothing, and a gap of several months between when the data could have shown it and when anyone acted. That gap is the core of the case.
Three claims you can defend
1. Time recovered
Upkeep hours from the audit, plus review preparation time across owners, multiplied by loaded cost. This is the most certain claim and usually the smallest. Present it honestly as the floor.
2. Decision latency reduced
The months between a losing bet becoming visible in the data and the review acting on it. With priority and KPI progress compared every month, the target is one review cycle. State the current figure from the audit and the target; don’t promise more.
3. Resources redeployed
The people and budget that, on last year’s evidence, would have been released earlier from priorities that weren’t working. This is the largest number and the one to present most carefully: as an estimate from last year’s actual cases, with the assumptions written out.
Promise less than the audit suggests. A conservative case built on your own data is more persuasive than an aggressive one built on someone else’s.
When finance asks for an ROI number
Refusing to borrow a vendor’s return-on-investment figure is not the same as refusing to produce one. Finance will usually ask, and the three claims above already contain everything a software cost benefit analysis needs. The only thing that changes is where the numbers come from.
| Claim | How it enters the analysis | How to label its confidence |
|---|---|---|
| Time recovered | Upkeep hours plus owner preparation hours, at a loaded rate, over 36 months | Certain. It comes from your own records and the audit |
| Decision latency reduced | Not a cash figure. State the current average in months and the target of one review cycle | Directional. Resist the temptation to monetize it |
| Resources redeployed | Person-months released, at a loaded rate, halved before it goes on the page | Estimate. Assumptions written out and visible |
| Costs | All seven lines of the total cost of ownership model, at year-three headcount | Quoted, except upkeep and parallel running |
| The comparison | Benefits minus costs across the same three years, with the halving shown | A range, never a single point |
Costs come from what drives the cost of hoshin kanri software. Benefits come from your own audit.
Two rules keep a software ROI credible in this category. Show the arithmetic on the page rather than in an appendix nobody opens, because an approver who can follow the sum will argue with the assumption instead of the conclusion, which is the argument you want to have. And present a range, because a single number invites a challenge to that number and a range invites a conversation about the assumption behind it.
There is one figure not to use: any ROI percentage from a vendor case study, including ours. It was measured in an organization that is not yours, with a matrix that is not yours, and the first approver who notices that will be right to discount everything else on the page with it.
Propose a pilot with pass/fail criteria
Approvers are more comfortable funding a bounded test than a full rollout. Propose one: the current matrix, loaded as it stands, run for three monthly review cycles. Agree in advance what has to be true at the end for the full rollout to proceed.
- Owners check in. Most priority and KPI owners have checked in on schedule for all three cycles without chasing.
- The deck is gone. The monthly review runs from the tool, not from slides built the night before.
- Lag is visible. At least one outcome-lag case was identified and discussed in a review, with a decision recorded.
- Upkeep is down. The program lead’s monthly data-collection time has dropped measurably.
Criteria like these protect both sides. If the pilot fails, the organization has spent little. If it passes, the full case is no longer a forecast.
Two words get used interchangeably here and shouldn’t be. Proof of concept vs pilot is a real distinction: a proof of concept asks whether the software can do the thing, and a pilot asks whether your organization will actually run on it. Vendors are glad to demonstrate the first, and most can. The case turns on the second, which is why every criterion above describes a behavior rather than a feature. Ask for the pilot, and make sure the trial or pilot terms give you three full cycles rather than a fortnight.
Name the risks yourself
A case that names its own risks reads as more credible. Three are worth including:
- Adoption. Owners may not check in without a leadership expectation. Mitigation: the executive sponsor runs the review from the tool from the first cycle.
- Parallel processes. The old spreadsheet survives alongside the tool. Mitigation: a date after which the spreadsheet is archived read-only.
- Method gaps. Software won’t create hoshin discipline that doesn’t exist. Mitigation: the pilot tests the practice as well as the tool.
More on these in Why hoshin software rollouts fail (it’s rarely the software).
A worked example: from audit to a one-page case
An illustrative group ran the five audit questions on its 2026 X-matrix. Here is what it found and how the findings became claims.
| Audit finding | Value |
|---|---|
| Priorities on the matrix | 12 |
| Finished on plan while their primary KPI missed | 3 |
| Months between data showing the gap and a review acting | 4, 5 and 3 |
| Average team on each of those priorities | About 2.5 people |
| Monthly hours collecting and formatting matrix data | About 45, plus owner slide preparation |
| Targets changed with a recoverable reason | 2 of 7 |
Illustrative audit.
| Claim | Calculation | Presented as |
|---|---|---|
| Time recovered | 45 hours a month, about 540 a year | The floor; certain |
| Decision latency | Average of 4 months today; target one review cycle | Current figure and target only |
| Resources redeployed | 3 priorities × about 3 months saved × 2.5 people ≈ 22 person-months | Halved to 11 person-months, assumptions shown |
The case asked for a three-cycle pilot, not a full rollout, with the four pass/fail criteria above. The halving on the third claim was deliberate. Finance challenged the first draft’s full figure; the halved one, with its arithmetic visible, went through. The audit’s most persuasive line wasn’t a number at all: five of seven target changes had no recorded reason.
A one-page structure
Keep the final case to one page with an appendix. Problem, using the audit’s headline findings. Proposal, a three-cycle pilot. Benefits, the three claims with their figures and assumptions. Costs, using the drivers in What drives the cost of hoshin kanri software. Risks and mitigations. Decision requested, with the pilot’s pass/fail criteria.
We can help with the audit. In a working session we load your X-matrix into Profit.co, and the gaps between priority progress and KPI progress are usually visible within the hour.
A business case template you can fill in
Advice on how to write a business case usually stops at naming the sections. Rendered as something you can fill in, the structure above gives you seven rows. It is deliberately a lean business case template rather than a corporate one: no benefits realization annex, no five-year horizon, no weighted scoring. Every row names where its content comes from, so the case is assembled from work you have already done rather than written from scratch.
| Section | What goes in it | Where it comes from |
|---|---|---|
| Problem | The priorities that finished while their KPI missed, and the months lost before anyone acted | Audit questions 1 and 2 |
| Proposal | Three monthly review cycles on the current matrix, loaded as it stands | The pilot section |
| Benefits | The three claims, each with its figure, its assumptions and its confidence label | The three claims, and the ROI table |
| Costs | Seven total cost of ownership lines at year-three headcount, not pilot headcount | The cost drivers article |
| Risks | Adoption, parallel processes and method gaps, each with the mitigation beside it | The risks section |
| Decision requested | Approve the pilot, with the four pass/fail criteria agreed now rather than argued later | The pilot section |
| Appendix | The audit table, the arithmetic behind each claim, and the vendor quotes | Everything above |
One page plus the appendix. If the case runs to three pages, the appendix is doing the first page’s job.
Two rows cause most of the trouble. Costs get filled in at pilot headcount, which makes year three a surprise; use the headcount you expect when the program is fully deployed, and get the quotes behind it by running the seven pass/fail tests on a real shortlist first. One scoping question changes that row more than any negotiation will: whether hoshin, OKRs and the scorecard are one subscription or three. In Profit.co they sit together in the Essentials plan, so the Costs row is one line rather than three with integration between them; ask every vendor on the shortlist the same question and write their answer into the row. And the decision requested is often left vague, which invites a deferral rather than a decision. Write the four criteria into the page, with the date the pilot would report back.
A business case that asks for a decision gets one. A business case that asks for agreement gets another meeting.
Free Product Demo
Get the evidence for your case in an hour
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
With three defensible claims: time recovered from data collection and review preparation, decision latency reduced from months to one review cycle, and resources redeployed earlier from priorities that weren’t working, estimated from last year’s actual cases.
That owners check in without being chased, the review runs from the tool instead of slides, at least one outcome-lag case was identified and acted on, and the program lead’s data-collection time fell.
Adoption, if leadership doesn’t review from the tool; parallel processes, if the old spreadsheet stays editable; and method gaps, because software can’t create hoshin discipline that doesn’t exist.
Yes. One page with six sections: problem from the matrix audit, proposal for a three-cycle pilot, the three benefit claims with assumptions, costs across seven lines, risks with mitigations, and the decision requested. Everything else goes in an appendix.
Benefits minus costs over three years, where benefits come from your own matrix audit rather than a vendor study. Monetize time recovered and resources redeployed; leave decision latency as months, not money. Show the arithmetic and present a range.
A proof of concept checks whether the software can do something. A pilot checks whether your organization will actually run on it. For hoshin, the pilot is the useful one, because adoption and review discipline are what the case turns on.
