Give fifty teams a planning tool and you get fifty plans. Whether that is decentralised strategy or just fragmentation depends entirely on whether those plans are connected.
Connecting is not mainly a matter of structure. It is about the four things below: making sure the choices teams make point the same way, that they work on the same goals and indicators rather than on private copies of them, that the work is divided rather than duplicated, and that somebody can actually see how the strategy is going across the whole organization.
Strategic choices that point the same way
The most valuable connection in a set of plans is the least mechanical one: a team can see which choice higher up its own plan serves, and the level above can see how its choice was picked up.
In OGSM.online a strategy is a first-class element with its own owner, KPIs and actions, and it can be linked between plans. So the line runs both ways. A team leader opening their plan can see where their Objective came from. A director can open a company strategy and see the team plans standing behind it.
That matters most when a choice changes. A strategy that is quietly rewritten in the company plan usually leaves five team plans still executing the old one. When the link is there, the change is visible on both sides in the same week rather than at next year’s planning session.
Shared goals and indicators, not private copies
Some things are genuinely shared. Customer satisfaction, a safety figure, a margin, a delivery time: several teams contribute to them and no single team owns them alone.
The wrong answer is for each team to put its own version in its own plan. Two copies of a number immediately start reporting different things, and the argument about whose figure is right takes up the review that should have been about what to do.
So a goal, KPI or strategy can appear in more than one OGSM: the same measure, not a second copy of it. One definition, one target value, one set of measurements, visible in every plan it belongs to.
This also solves the quieter failure. Two teams building the same capability without either noticing is common, and expensive. Making the overlap visible is usually all it takes to have the conversation.
Work divided, not duplicated
The same applies to the actions.
- Actions shown in several plans. One action, one owner, one status, visible everywhere it is relevant
- Sub-actions distributed across plans. A large piece of work split up so each team owns its part, with the whole still readable as one thing
- The multi-OGSM action overview. Everything in flight across the organization, gathered in one place, for a programme office or a management team that needs to know what is actually happening rather than what one corner of it is doing
The point of dividing rather than copying is that the split is honest. If nobody will take a piece of the work, that shows up now instead of in month seven.
Insight into how strategy is actually going
Once plans are connected, the useful questions stop being about one team.
On Pro, cross-OGSM reports take a cross-section of the reports from several plans. That is what a board usually wants: not fifty dashboards, but one view of where the whole thing stands and which parts need a decision. The process status dashboard answers the other half of it, which is whether the rhythm is actually being kept: who has filed a report and who has not, while there is still time to ask.
Between them, those two answer a question most organizations cannot answer at all. Not “is our plan good” but “is our strategy being executed, and where is it stuck.”
One format, filled in by each team
Every plan in OGSM.online has the same shape, because it is an OGSM. That is deliberate, and it is most of what makes the rest of this page possible: you can read plans side by side, roll status up, and report in one way across the organization.
It is also the thing spreadsheets never manage. Hand out a template in Excel and within two quarters every team has added its own columns and rows, and no two plans can be compared. One format is not bureaucracy; it is what lets a team’s plan be read by anyone else.
What goes in the format is another matter entirely. Our advice there is consistent: prescribe the results that matter to you, and leave the how to the team. They are closest to the work and usually best placed to decide it. And it makes the plan theirs, which is most of what determines whether it gets executed rather than filed.
Cascading, when the content really is nested
Cascading is the tightest form of connection, and worth being precise about because it is used less often than its prominence in the literature suggests.
A strategy in the organization’s OGSM becomes the Objective of the plan below it. Its KPIs become that plan’s goals; its actions become that plan’s strategies. The link is live: change something at one level and it is visible at the other, instead of the two quietly diverging over a year.
That works well for programmes and projects, where the structure of the content genuinely matches the structure of the work. A sustainability programme spanning several departments becomes the Objective of a programme team’s plan, and everyone can see where it came from.
For ordinary departments and teams, the looser connection above usually fits better: the team writes its own plan informed by the level above, with coherence maintained by conversation and by shared goals rather than by mechanism. Both are supported, and choosing between them matters more than most organizations realise.
Structure that grows with you
The organization structure (teams, who is in them, what they can see and change) is managed centrally.
Roles per team decide what someone can do: a viewer reads the plan, a responder can comment, a participant edits, an administrator has full control of that team’s OGSM. User groups let you assign those permissions to a group rather than to one person at a time, which is what makes onboarding a new department a five-minute job rather than an afternoon. Someone who holds both an individual and a group role gets whichever grants more.
That matters at scale for a reason people underestimate: the reason large rollouts stall is rarely the plan. It is that nobody can face setting up the permissions.
Rolling this out across more than a handful of teams? A demo is usually faster than a trial.
Book a demo