In this guide
- Don’t wait for the next planning cycle
- What to settle before day one
- Days 1 to 15: load
- Days 16 to 45: first review
- Days 46 to 75: second review and repair
- Days 76 to 90: third review and extend
- A worked example: what the 90 days can look like
- Three roles that make it work
- Questions this article answers
Key Takeaways
- →Don’t wait for the next planning cycle. Load the matrix you have, imperfect as it is, and start running reviews from it.
- →Four phases with exit gates: load, first review, repair, extend one level. Don’t move on until the gate passes.
- →Three roles decide it: a sponsor who chairs from live data, a program lead who owns the cadence, and owners who check in themselves.
- →The test isn’t whether the tool is configured perfectly. It’s whether one real decision happened earlier because of it.
- →Settle who loads the matrix before signing. A software implementation plan that starts with a blank tenant has already lost two weeks.
- →Write the day-90 gates into the agreement, not just the project plan. They are the only objective test of whether this worked.
The most common implementation mistake is trying to design the perfect configuration before running a single review. The first 90 days should be three monthly review cycles on the matrix you already have, each with a gate to pass before moving on.
Don’t wait for the next planning cycle
Many organizations buy hoshin software and then wait for the annual planning cycle to start using it, so the first matrix in the tool can be “done properly”. The wait is usually several months. During that time, the old process continues, enthusiasm fades and the tool becomes associated with a future event rather than current work.
A better approach is to load the current matrix as it stands, whatever month it is, and start running reviews from it. The matrix will be imperfect. That’s fine. Running real reviews on it shows faster than any design workshop what needs to change before the next planning cycle.
What to settle before day one
The 90 days below assume a few things are already agreed. They are cheap to settle during the buying conversation and expensive to discover afterwards, because each one can quietly consume a fortnight of the first phase.
| Settle before signing | Why it decides the first 30 days | What good looks like |
|---|---|---|
| Who loads the matrix | A blank tenant on day one means the load phase starts with data entry, not with reviews | The vendor loads it with you, from your existing file |
| Whether loading is included | A separately priced services line changes the total and often the timeline | Named in the quote either way, not discovered at kickoff |
| How many weeks to the first review | This is the only implementation number that matters | Weeks, with a date; not “typically a quarter” |
| Trial or pilot length | A fortnight cannot contain a monthly cycle, so it cannot test the thing you are buying | Long enough for one full review cycle, at minimum |
| Integrations needed on day one | KPI values living in an ERP or BI system decide whether check-ins are realistic | Agreed scope, with who maintains them |
| The day-90 gates themselves | Shared success criteria prevent a renewal conversation built on impressions | The gates below, written into the agreement |
Six rows. Most software implementation checklists cover the first two and none of the rest.
The last row is the one most often skipped and the most useful. A software implementation plan that lives only in a project tracker gets judged on whether tasks closed. Gates written into the agreement get judged on whether three reviews ran and one decision moved earlier, which is the thing you actually bought. Pricing and what the plan includes are on the plans page, and RFP questions that separate matrix storage from strategy execution covers how to ask about implementation before a shortlist narrows.
Days 1 to 15: load
- Load the current X-matrix: objectives, priorities, KPIs, perspectives and correlations as they are today.
- Give every row exactly one owner. Shared ownership is the first thing to fix, and the tool makes it visible.
- Enter actuals for the months already passed, at least for primary KPIs, so the first bowler has a history.
- Set the check-in cadence and tell owners when the first one is due.
- Matrix loaded. Every objective, priority and KPI from the current matrix is in the tool.
- Owners named. Every row has one owner who has logged in at least once.
- Cadence set. Owners know when their first check-in is due.
Days 16 to 45: first review
- Owners complete their first check-ins, with a comment on every red or amber.
- Wire up the primary correlations first, so the outcome-lag view has something to show.
- Run the first monthly review from the tool. The chair opens the live matrix, not a deck.
- Record every gap you find: missing KPI definitions, unclear owners, correlations nobody can explain.
- Check-ins in. Most owners checked in before the review without being chased individually.
- No deck. The review ran from the tool.
- Gaps listed. There’s a written list of data and structure problems to fix.
Days 46 to 75: second review and repair
- Fix the gap list: KPI definitions with baseline, target and unit; adoption-type key results on priorities measured only by completion.
- Run the second review, opening with exceptions rather than walking every row.
- Apply the countermeasure rule: red rows without a cause and action are sent back before the meeting.
- Archive the old spreadsheet as read-only, with a date on it.
- Exceptions first. The second review opened with outcome-lag cases and repeated reds.
- Spreadsheet retired. The old file is read-only, and nobody has asked for it back.
Days 76 to 90: third review and extend
- Run the third review. By now it should be shorter than the first.
- Extend one level: connect one site, region or function, or one set of team OKRs, to the matrix.
- Hold a short retrospective: what changed, what still doesn’t work, what to fix before the next planning cycle.
- Three cycles. Three monthly reviews have run from the tool.
- One decision changed. At least one decision was made earlier than the old process would have made it.
- One level connected. A second level is checking in and visible on the matrix.
The test of the first 90 days isn’t whether the tool is configured perfectly. It’s whether one real decision happened earlier because of it.
A worked example: what the 90 days can look like
| Day | What happened | Gate |
|---|---|---|
| 8 | Matrix loaded: 5 annual objectives, 11 priorities, 9 KPIs. Three rows had shared owners; each was assigned one person | Passed |
| 30 | First review from the tool. About 70% of owners checked in unprompted. Gap list: 14 items, mostly KPI baselines | Passed, with gaps listed |
| 45 | Two activity KPIs replaced with adoption measures; baselines added for four KPIs | |
| 60 | Second review opened with exceptions. Old spreadsheet archived read-only | Passed |
| 75 | Pricing priority found in outcome lag: tool launched, low use. Measure changed; status reset to amber | |
| 90 | Third review took 70 minutes instead of 2 hours. Two pilot sites connected | Passed |
Illustrative timeline.
The decision on day 75 is the one that matters. Under the old process, the pricing priority would have stayed green until the quarterly review, since the launch had happened on time. The first 90 days paid for themselves the moment one decision moved earlier.
Three roles that make it work
- Executive sponsor. Chairs the review from the live data. This one behavior determines adoption more than any other.
- Program lead. Owns the cadence and the gap list. Explicitly not the person who enters other people’s data.
- Owners. Check in on their own rows, with comments. Nobody does it for them.
If the program lead starts entering data on owners’ behalf to keep the matrix complete, the matrix keeper has returned. It’s better to show an honest gap in the review and let the chair ask about it. (See Why Hoshin Software Rollouts Fail (It’s Rarely the Software).)
Profit.co’s team runs the loading step with you in the first working session, so the 90 days start with your matrix already in the tool. More on the hoshin kanri software overview.
Hoshin Kanri sits in the Essentials plan with OKRs and Goals, Balanced Scorecard and Strategy Roadmap, which matters at day 76: extending one level usually means connecting team OKRs, and on one plan that is a configuration step rather than a second purchase mid-rollout. Buying OKR software separately at day 76, or balanced scorecard software when the board asks in month four, turns a configuration into a procurement cycle. The 30-day free trial covers the load phase and the first review, so the first gate can be tested before anything is signed.
Free Product Demo
Start day one in the working session
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
Running the first monthly review from the tool should take a few weeks, not months. A 90-day plan covers loading the matrix, three review cycles, fixing data gaps and extending to one more level.
No. Waiting usually costs months of momentum. Loading the current matrix and running real reviews shows faster what needs to change before the next planning cycle.
An executive sponsor who chairs the review from the live data, a program lead who owns the cadence but doesn’t enter others’ data, and owners who check in on their own rows.
Four phases with exit gates over 90 days: load the current matrix, run the first review from the tool, repair the gap list and run the second, then run a third and extend one level. Gates, not task lists.
Who loads the matrix, whether loading is priced separately, how many weeks to the first review, how long the trial runs, which integrations are in scope, and the day-90 gates themselves written into the agreement.
No. A fortnight cannot contain a monthly review cycle, so it cannot test check-in behavior, the exception queue or whether the review runs from the tool. Ask for long enough to run one full cycle.
