Getting IT Road Mapping Right - part 2

Roadmaps come in all shapes and sizes

This is part 2 of our series on roadmapping in enterprise architecture, IT planning and portfolio management.

Roadmaps come in all shapes and sizes

As we can see in the following examples, there is no one way to create a roadmap. The form a roadmap takes - or should take - is highly dependent on who will be using it and for what purpose. For example, a CIO in a situation like a strategic consolidation or M&A will want to understand when an organizational entity will be rolling over application support for a capability such as “Customer Management” from an old solution to a new one.

Figure 1: Roadmap of the support of the Business Capability (Domain) ”Customer Management” by applications across locations - differentiated by actually approved applications (blue) and proposed tactical plans (yellow).

The investment board will want to understand the progress made on projects: what are the different initiatives we‘ve kicked off? What is the state of affairs regarding milestones, budget and scope?

Figure 2: Roadmap of the projects that affect an application domain (Back Office) showing the project lengths (in blue) and the application lifecycles.

The roadmap is an extremely versatile planning tool. With the right underlying technology, it is highly configurable in form and content to be able to address virtually any communication or information need regarding the IT plan. Following are a few examples:

• If the goal is better business collaboration, the roadmap should link business strategy and need for capability improvement to IT deliverables.
• If cost reduction has the highest priority, the roadmap should help disentangle the current project portfolio by identifying overlapping, redundant or outright conflicting projects.
• As discussed previously, a consolidation initiative will need roadmaps to be able to link the technology portfolio to application usage, identify rationalization roadmaps for the technology portfolio and translate these into application changes.
• To promote agility, roadmaps will harmonize context processes and the IT solutions supporting those across the organization resulting in faster time-to-market for changes requested by business.
• For clear instructions to the Operations and Infrastructure group as to the precise timing of technology changes, migration roadmaps clearly show the plan.

Figure 3: Roadmap which shows a three-step mitigation of various CRM systems to salesforce.com. The previous screenshot compares projects that are addressing the same business activity in order to decide on the roadmap for each project.

The above-given roadmaps all demonstrate the three main principles for creating effective roadmaps:

1. Be consumer-centric. If the planning tool used has the right supporting capabilities, it presides over a wealth of detailed information on all relevant enterprise architecture artifacts and the associated planning information. A good tool also has the ability to aggregate information to subsuming topics and figures familiar to the roadmap‘s target consumer. Use this ability to cater to the audience you want to address. If you‘re unsure if you have the right input on what to map, it‘s best to look at the domain you‘re working in, find out who the actors are and simply ask.
2. Keep the presentation simple. A roadmap should be comprehensible in an instant. It should include only the information required to answer the question at hand. Besides the elements and the timeline that are at the core of the discussion, little else in the form of objects and text should be on the roadmap. For qualitative information that will provide additional insight to enhance the discussion, colors and element sizes can be used and should be properly annotated in a legend. Too much information will only confuse the reader and dilute the message.
3. Interrelate roadmaps into a network of dependencies. Simple roadmaps in such a complex enterprise? It doesn‘t seem possible but it is. Keep the individual roadmap simple. But interrelate several with elements they have in common. For example, interrelate a roadmap for application consolidation with technology lifecycle roadmaps to show compliancy of new or consolidated applications with IT standards. Use this information to synchronize both application and technology rollouts. This is an example of why it is important to be able to drill-down into individual elements on a roadmap and from there navigate to other related roadmaps.

Stay tuned for our next episode on technology requirements for effective IT road mapping.