So the first part of this topic focused mostly around identifying the IT areas that were applicable to your businesses and then assessing your maturity within those areas. Next up is the more interesting bit, where you document where those improvements can be made and how to put a plan of action (or roadmap) of when to implement the new solution, or process improvement.
So you now understand how mature your business is in the various subject areas, whether that be Data & Analystics, Internet of Things, Identity, or the one I’ll use today – Cloud & Infrastructure. Its very difficult to understand how mature you are as a business in each of these areas, because that can cover a particular technology you are moving to, whether processes are put in place, whether there is a strong relationship with your customer, etc – the list goes on. But its at this stage you need to try and document your findings – NOT an easy thing to do.
Your document needs to ensure it stays true to your findings, but also needs to be accessible by all various levels within IT. That means it doesn’t contain detail around how you will configure your automation script, or which particular vendor or product you will work with, but will simply draw a map, or a plan to how you will get there and why you need to get there. So its needs to be a very high level view.
I find the simple way to display this is using Microsoft Powerpoint as it tends to make me stop killing people with walls of text… I have a habit of doing that. Powerpoint keeps things brief, and alongside some visual aides, such as icons, or graphics, it breaks this up and allows you to talk people through it.
A roadmap should try and tell a bit of a story, of where you as a business are right now, to where you want to get. This could be a complex process of many steps, or could be super simple. Either way, you need to find an easy way to get this across to your audience. I’ve seen a few ways of providing visuals for this, I’ve put a few screenshots of templates I’ve seen before which could help.
Personally, I find the first one quite engaging, easy to follow and limits the amount of blurb I can write. The second, although very pretty, I find tough to follow – but its each to their own.
If I use IT Operations as the example, this can be broken down into a few subsections:
- Monitoring, Alerting & Application Performance Management
- Systems Management
- Backup & Disaster Recovery
- Automation, Compliance & Configuration Management
For each of these sections you should be able to describe an ‘As-is’ for both product, capability and process. From there, you should then be able to describe a ‘To-be’ and how to get there – essentially what the end of your roadmap looks like.
For example, for Automation, Compliance & Configuration Management, your roadmap could look like this:
- As-is state:
- No cloud, infrastructure or OS automation in place
- VMs built from golden image, but configuration can ‘drift’ leading to inconsistent builds over time
- No compliance toolset to manage cloud infrastructure
- To-be state:
- All infrastructure conforms to compliance policies
- No drift in configuration over time
- Builds of environments are automated, either via schedule or based on ‘load’
Once you’ve put this in to place, its best to try and understand how long it will take to put these kind of processes or technologies into your environment and to educate the team on how to use them. This is where the dreaded project manager folk could help – they love a good gannt chart. However, if you’re like me, and avoid anything that involves Microsoft Project, draw something super simple like this:
This should allow you to demonstate how long it would take to implement a particular technology, or process. Its always a idea to put some ‘fat’ into the plan – things commonly over-run, so build some contingency into this.
I’ve seen people try to describe particular products and even quotes into roadmaps and timelines in the past. Bad idea. You’re solutionising (probably not a word, but gonna use it anyway!) – so stop it.
You need to put proper planning in place, and that means understanding your requirements, going out to market to see what matches those requirements, and then scoring the various products against each other. Only then should you be getting pricing.
As I’ve said a few times, this is the way I work my way through planning, not neccessarily the right way, but I find it logical and maybe my thoughts can help others.
I’ve included a few of the example template powerpoint slides below. If they help someone, then so be it. Happy roadmapping!
Leave a Reply