Most organisations do not lack ideas about technology. They lack an agreed picture of what they have, what it costs them, and which changes would make a measurable difference. A technology assessment produces that picture. A roadmap turns it into a sequence of decisions with owners and dates.
This article sets out how we structure both, and the mistakes that most often make assessments expensive and roadmaps ignored.
Start from the business, not the inventory
An assessment that starts by cataloguing servers and licences produces a long document and few decisions. Start instead with the questions the leadership team needs answered. Typical examples:
- Which processes are slowed down or made error-prone by the systems that support them?
- Where is information re-entered by hand because systems do not exchange it?
- Which systems would stop the business if they failed, and how quickly could they be restored?
- What are we paying for capability we do not use, or for risk we have not priced?
Each question points to the parts of the estate that matter. The inventory is still needed, but it becomes evidence for an argument rather than the deliverable itself.
Talk to the people who run the process
Requirements gathered from managers alone describe how a process is supposed to work. Requirements gathered from the people who run it describe how it actually works, including the spreadsheets, workarounds and informal approvals that never appear in a process diagram.
We run short, structured workshops with the operators of each in-scope process, and we ask them to show us rather than tell us. The gap between the documented process and the observed one is usually where the value of any change is hiding.
Assess the estate along four dimensions
For each system in scope we record four things:
- Business fit. How well it supports the process today, and what it cannot do that the business needs.
- Technical condition. Version and support status, known defects, integration approach, security posture, and how the system is deployed and backed up.
- Operational dependency. Who maintains it, whether that knowledge is documented, and what happens when the maintainer is unavailable.
- Cost and contract. Licence and hosting cost, contract term and notice period, and any renewal dates that constrain the roadmap.
Scoring each dimension on a simple scale is useful for comparison, but the written observations are what the decision makers will rely on. Keep both.
Map the information flows
Integration problems rarely appear in system inventories, because they live between systems. Draw the flows: which system is the source of truth for customers, products, orders, employees and contracts; where copies exist; and how they are kept in step. Mark every manual step, every scheduled export and every point where the same record is entered twice.
This map does more than expose problems. It defines data ownership, which every later architecture decision depends on.
Present options, not a single answer
A useful assessment gives decision makers a small number of genuinely different options, with the trade-offs written down. For a finance system that no longer fits, the options might be to extend it with integrations, to replace it with a platform product, or to rebuild the specific capabilities that differentiate the business. Each has a different cost profile, risk profile and demand on the organisation.
Record why each option was or was not recommended. Six months later, when circumstances change or a supplier makes a new proposal, that record prevents the same debate from starting again from nothing.
Turn the recommendation into a roadmap
A roadmap is a sequence, not a list. Order the work by dependency first: identity and access, data ownership and integration foundations usually have to come before the applications that rely on them. Then order by value and risk, and check the sequence against the contract dates found in the assessment.
For each phase we define:
- The outcome, in business terms, and how it will be measured.
- The systems and interfaces that change.
- The budget range, with the assumptions behind it.
- The operational changes required: training, new procedures, new responsibilities.
- The decision the leadership team needs to take before the phase can start.
Budget ranges are more honest than point estimates at this stage. A range with stated assumptions invites a conversation; a single figure invites a negotiation.
Plan the operating model alongside the technology
Roadmaps fail most often after go-live, when nobody has agreed who runs the new capability. Each phase should state who will operate the result, under which procedures and with what response times. If the answer is an external provider, the roadmap should include the transition. If the answer is an internal team, it should include the hiring or training that makes that realistic.
Common mistakes
- Too much scope. An assessment that covers everything finishes late and recommends nothing specific. Scope it to the questions that matter, and note what was excluded.
- Vendor-led options. If the only options assessed are the ones a supplier proposed, the assessment is a sales process. Include at least one option the incumbent would not suggest.
- No owner for the roadmap. A roadmap is a living document. Name the person who updates it when a phase completes or an assumption changes.
- Skipping the people. Training, documentation and change management are line items, not afterthoughts. Leave them out of the budget and they will be cut from the delivery.
What a good result looks like
At the end of an assessment the leadership team should be able to say, in their own words, what the estate looks like today, which three or four changes would make the most difference, roughly what each would cost, and what they have to decide next. The roadmap should be short enough to fit on one page and detailed enough in its appendices to brief a delivery team.
That combination, a clear argument backed by evidence, is what allows technology decisions to be made once and carried through.