Many organisations we work with have some sort of technical roadmap that they’re aiming to achieve. This could be a formal document with board approval or an informal collection of thoughts. In either case we find that some roadmaps are much more robust than others! It’s easy to read through a sensible looking plan and assume that it’s correct. Here we’ll cover four ways that you can scratch beneath the surface and challenge your own technical roadmap to make sure that it’s fit for purpose.
1. Is it the right plan for the business?
The first question to ask about your technology roadmap is whether it aligns with the goals of the business. For some businesses this might raise a different issue: are the goals of the business clearly defined and shared across the company? If not then there’s some prep work to do there! However, assuming the business goals are well defined, you can look at each element on the technical roadmap and question whether it’s helping the company achieve those goals. Anything that isn’t linked to the goals of the company should be thoroughly questioned.
2. Is it feasible?
The second question to ask yourself is whether the roadmap is really feasible, given the time and budget available. In order to answer this question you’ll need to have a tech team that can provide you with realistic ballpark estimates of the timescales and costs involved to achieve each bit of your plan. If you don’t have resource for this in house you can ask an external agency to help you come up with those numbers. Often people fail to account for the time the end users will need before they start using a new bit of technology – roll out plans must be included in a tech roadmap in order to get realistic timescales of the business impact of any change.
3. Is it ordered correctly?
It’s essential to ensure your roadmap prioritises the important things, especially those that may be slightly less urgent. There is tendency to aim for things that deliver the quickest short term return and to neglect longer term projects. It makes sense; there’s no celebration in replacing a nearly defunct system because the old one is about to stop working, or building a back end system that will give business intelligence on future consumer facing sites that are yet to be built. However, the danger of always prioritising the quick wins is that you can end up with a set of disparate systems which become a maintenance headache. Moreover, you may have missed a huge opportunity to have systems that work together to give you better business intelligence and more efficient business processes – something which is much more expensive to put in place retrospectively.
4. What if it all goes wrong?
A final stress test you might want to try on your tech roadmap is a “pre-mortem”. In this exercise you gather key stakeholders in the business and tell them to imagine you’re a year down the line and it’s all gone horribly wrong. Ask them to look at the technical roadmap and tell you why they think it’s gone so badly. This is a great way to reveal people’s hidden concerns about the roadmap and should help identify the perceived most likely points of failure. Even if you don’t change the roadmap as a result, you will have valuable information on how best to communicate the changes you’re making to your colleagues and hopefully mitigate a few risks along the way.
The team at Ghyston has a lot of experience in creating, challenging and implementing technical roadmaps for many different organisations. If you’d like to discuss any of these ideas in more detail we’d be happy to help – just get in touch!
