Your Information Technology Roadmap

John Eccles, 05 October 2020

Magnetism provides specialist input to the IT roadmaps of our partner-clients. We advise about the new technology expected from Microsoft and how they might utilise it for greater value. We look at the broader IT systems and advise on how D365, Azure and the Power Platform might integrate with other systems for greatest benefit.

It’s helpful for us to step back and reflect on the IT road-mapping process - to get clearer context - so we can do the job better. This blog is such a reflection.

Why have an IT roadmap?

Here are some of the reasons why organisations have IT roadmaps:

1. Executive alignment. When the IT roadmap aligns with the strategic vision and priorities of the organisation, the organisation’s leaders can readily collaborate and support the plans, projects and investments involved.

2. Prioritisation of improvement opportunities. The process of formulating the IT roadmap involves consideration of all the IT improvement opportunities. They must be weighed against each other in terms of both ROI and precedence and dependencies. Trade-offs need to be made and validated.

3. Timeline for projects. A timeline is a key step towards execution. The roadmap will help to anticipate resourcing needs, plan assignments, select software and vendors, budget and start visioning and planning with the functional project owners well in advance.

Outputs – What should an IT roadmap include?

There are a multitude of charts and diagrams used to summarise and visualise the IT roadmap. See for example https://roadmunk.com/guides/3-technology-roadmap-examples/

Every organisation will want to develop its own roadmap documentation, and this will depend on the size of the organisation and the complexity of the IT architecture.

My preference is for the outputs to line up with the reasons for the IT roadmaps, so I suggest the following outputs.

1. Strategy vs IT opportunity matrix

This chart shows how projects contribute to the key strategies of the organisation. As the strategies change over time, this chart should be reviewed and updated.

2. Opportunity evaluations

This is not a full business case, rather a summary of the strategic fit, the costs and benefits of an opportunity. You might add some financial measures if these will be helpful in prioritising projects.

The purpose is to aid the prioritisation process by clearly showing why an opportunity might be worthwhile.

3. Projects timeline

This chart is clearly very high level and more detailed project plans will be required. But this is probably enough detail as an output of the road-mapping process. It shows the order of the projects which will take into accounts any dependencies. (In this case the self-service portal is dependent on the CRM system.) It should also take into account the constraints associated with staffing and financing the projects.

Roadmap Development

I’m not going to outline a process for developing the IT roadmap as the process should fit the size, culture and IT complexity of your organisation. But I will venture a few pointers:

1. Roadmap development is an opportunity to get buy-in from key leaders throughout the organisation, so make sure the key people are consulted and involved in a meaningful way.

2. Some ‘vision-casting’ may be helpful. You cannot assume the leadership team is completely up to date with IT systems that might add value. Show them some of what is available. Expose them to new ideas and new functionality from existing applications.

3. Involve experts. Your IT applications partners can provide ideas on how to get more value from existing applications and about integration with other systems. They should know what new functionality is coming. An independent consultant may be able to bring broader IT systems experience to the table.

4. Re-visit the roadmap regularly – at least annually, but preferably every 6 months. The IT world is changing rapidly, and your IT roadmap needs to change with it.

John Eccles, Magnetism

September 2020