Order IT roadmaps by outcomes and dependencies

An early IT roadmap should show which work needs to improve and what must be clarified first. Product names can follow. Naming them too early can make an open choice look like an approved purchase.

The practical result is familiar: a new CRM can be introduced while customer addresses remain inconsistent. A portal can be finished while the authoritative price source remains unclear. Buying the product does not resolve that preceding rule.

Three products, two unresolved prerequisites

A fictional business writes “CRM, customer portal, dashboard” into its plan. Its business goals are easier ordering and visibility into which enquiries become proposals. Before product comparison is useful, two decisions are missing: which system is authoritative for customer and price data, and which processing statuses define an enquiry?

The plan can turn these into concrete next outcomes:

• The source of valid customer addresses and prices is defined; discrepancies are resolved using a sample transaction.

• A test customer can complete an entire order with that data; missing ERP acknowledgement stays visible.

• A report connects distinct enquiries with reviewed processing statuses and proposals.

These outcomes suggest a sequence: data responsibility before binding ordering, shared statuses before useful reporting. They do not specify which suppliers must be bought from. Some capabilities may already exist in the current system.

Different steps can have different certainty

A near-term step can have a defined outcome and known prerequisites. Later steps can still have an open solution and uncertain effort. State which investigation enables the next decision. An early product choice will then not appear falsely settled.

The GOV.UK guide describes roadmaps as adaptable plans with clear objectives, priorities and intent. A detailed backlog organises smaller implementation tasks. For the example business, “customer data authority agreed” is an outcome; individual field checks belong in delivery work.

When product names help

After a reasoned selection, a procurement view with products, costs and responsibilities is useful. A confirmed shutdown date or unavoidable technical dependency can also determine the sequence. The roadmap should make that constraint explicit.

The standard remains the required outcome. If investigation shows the existing CRM can support the workflow with an adjustment, a new purchase may disappear. If it reveals an unavoidable integration gap, the necessary change becomes a concrete planned item.

For an investment discussion, examine every entry: what observable outcome is required, what is missing beforehand and what finding could change the decision? If only a supplier name remains, the next planning question is unresolved. A complete purchasing decision also needs scope, recurring costs and future switching options.

Sources

• GOV.UK: Developing a roadmap