Systems accumulate. A tool gets bought for one team, another for a project, a third because it came with a grant. Nobody planned the estate; it happened. Then something forces the question — a renewal, an incident, a new CEO, a funding requirement — and there’s no basis for deciding what to do first.
A strategy fixes that by producing a shared, evidenced view and an order of operations.
- Current state. Every significant system, what it costs, who owns it, what it’s actually used for, and how healthy it is. This alone usually surfaces duplicated tools and licences being paid for by two departments.
- Gaps and risks — where the estate doesn’t support the operation, and where the real exposures are: single points of failure, unsupported software, no tested backups, key-person dependency.
- A target state proportionate to your size. Not a reference architecture from a large enterprise, which is where a lot of this advice goes wrong.
- A sequenced roadmap over twelve to twenty-four months, ordered by dependency and value, with the foundational work honestly placed before the exciting work.
- Indicative costs — implementation and ongoing — so the plan can go to a board or a funder as a real proposition.
- Governance — who decides, how new tools get approved, and how this gets reviewed so it doesn’t go stale.
Because we don’t resell platforms, the roadmap can recommend keeping what you’ve got. Frequently it does.