Companies today are confronted with the complexity of multi-vendor hardware and software solutions, accelerated business and organizational change, and a growing number of heterogeneous technology alternatives. Because of this, they face significant challenges planning and managing their IT programs and making informed investment decisions.
Many enterprises build a model of the current and desired future state architecture, but fail miserably in providing support to realize the myriad intermediate states that one must transition to from here to get to there. The lack of this ability is the reason IT plans and reality never seem to converge.
Business models, too, are becoming more complex with mergers, acquisitions, partnerships and globalization playing an increasing role. The challenge for organizations is to align IT plans to the business strategy, which means that both camps need to communicate and collaborate with each other effectively.
Road-mapping enables organizations to collaboratively plan and manage the numerous and nontrivial steps along the way, such as strategic demands, projects, scenarios, application lifecycles and instances of technology to be adopted or retired to lead them to the always-evolving target landscape.
What Are Road Maps?
In a nutshell, road maps are time-sequenced initiatives within a strategy to guide decision making and help realize the strategy. Road maps are not strategies or project plans; rather, they indicate velocity of change, decision points, event sequencing, dependencies and future risks. They answer questions such as: What is the scope of this initiative? How long will this initiative take? Where are we in terms of goal attainment? How do we measure progress? What is our next step?
Road maps are used as part of the strategic planning process to coordinate change between interconnected portfolios.
A road map has only limited value if it is published as a picture. Road-mapping can only be effective if it's embedded into the strategic IT planning process. This entails the following:
- Maintaining a central repository of all architecture objects
- Creating time tags for each object and object lifecycle phases to monitor and maintain vendors' technology life cycles
- Creating road maps on different status levels, such as operational, in roll out and planned
- Basing application plans on dependencies between enterprise architecture planning elements
Only then can the information remain updated and meaningful.
Building a Road Map
There are a number of steps involved in the process of building a road map. First, you need to identify the strategic targets of the organization. Where do you want to go? The outcome is integrated with your strategic agenda so that each stakeholder is aware of where he fits into the plan. You then should communicate this with all employees who need to know about your agenda.
The next step is to define your road map context document. In the context document, the following aspects should be considered:
- Current environment
- Industry trends
- Future vision - target state
- Significant changes/major programs
- Dependencies and interconnections
- Road maps at various levels
- Implications of action and consequences of inaction
- Business implications
- Detailed steps for the next planning period
Once you have determined what you want to communicate in your road map context document, you should decide the format in which to show it. Finally, you should publish multiple views to connect with your audience.
Road Map Best Practices
Before you embark on a road map, consider these eight best practices:
1. Standardize the forms which business and IT use for collaboration.
Define the "language" used in the forms. This means describing what various shapes, words and design elements represents. Consider the confusion if elements such as circles, blue lines and red lines mean something different throughout a plan? Thus, if an arrow represents a business process in one form, it should mean the same in all. Do this for all reports you need to standardize. By doing so, stakeholders will understand the "language" used for all.
2. Use a central inventory of plans to re-use the current architecture information, such as applications, support, processes. etc., reduce efforts needed to consolidate plans, and see potential conflicts in planning.
A central repository serves many benefits. While it would be convenient if plans didn't change, they generally do. By maintaining a central inventory, you'll reduce the amount of effort required to revise the plan by reusing much of the current information. In addition, it is easy to compare plans, since you've already collected the elements represented in them. Doing so will reduce the time required to consolidate them when necessary. And finally, by having all information stored in the same place, you'll be able to identify conflicts should they arise. For example, consider the organization that is replacing an ERP system. The initial plan likely included running the new an old system in parallel for a time period. But if the new system is delayed, that organization wouldn't be able to switch off the legacy ERP system according to the original timeline. With a central repository, it would be easy to identify the potential issue by examining the road map and then adjust the date for turning off the old system.
3. Train business users to create planned (desired) IT support with a desired life-cycle
If you are to obtain good results from using a repository, you'll need to have knowledgeable people do the work. This may not be an issue when drawing from IT staff, but the whole point of the exercise is to get business and IT people to work together. Thus, training for business people is critical. Consider developing webinars or incorporate integrated HELP capabilities into their road map environment in order to help them generate plans. In addition, designate an internal support group to assist road map users.
4. Use road maps as mandatory documents for planning meetings and input for detailed IT delivery plans
We all know of cases where newly introduced applications have failed because employees didn't use them some or all of the time. Likewise, road maps must be used for planning purposes or, like the old adage, garbage in will equal garbage out. Management planning meetings are a perfect example. Recently a CIO at a major auto firm sought approval for an IT initiative at a management meeting. In the past, obtaining such approvals was time consuming and difficult. This time, he brought in a printed road map, complete with visual representations of the plan. Using this, he was able to explain to management over the course of the next few meetings what he sought. As a result, he was able to get them to understand the issues and then obtain buy-in into the plan. Everything he needed to communicate was in the road map, saving him and the organization the time and effort that would have been required to go back and obtain answers from his staff.
5. Establish guidelines for changing road maps
Invariably, road maps will change due to new corporate strategies or unavoidable external factors. The best way to handle these situations is to establish in advance what is to be done in such cases. Establish how changes are communicated, who is to be involved, when to introduce operational teams, etc. Essentially, you want your entire team to know if things change, here is what each individual is responsible for.
6. Apply rules to road maps for governance (e.g. govern component migration stages)
What happens when your department introduces a new application that requires Microsoft Windows 7, but you're organization is running Vista? Establish rules so you know which road maps affect each other, ensuring that component and project road maps are linked. Doing so will prevent surprises that could cripple your organization.
7. Make project approval dependent on inclusion in the master plan road map
New projects should not be considered unless they have been included in the master plan road map. Ensure that all project deliverables are integrated into the plan so you can see the effect of each project and know how it fits with the IT strategy and your business needs.
8. Use blueprints to create consistent and standardized guidelines across separate organizations; e.g., in setting up a new manufacturing plant or sales organization.
Road maps enable you to define blueprints for similar plans in other parts of your organization. For example, a large utility recently put together a road map for meeting new environmental requirements for several existing plants. When it built a new plant, it searched its plans and found that it could use 80% of the road map blueprint. Leveraging such efforts can save you an enormous amount of time and money and ensure a successful project.
It's easy to say you have a vision, but it's hard to get people to take the right action unless they have a path to get there. Road maps ensure that IT and business are aligned properly for the benefit of the organization. Using them, for example, business managers gain an insight into where they have an operating model that is not really working to their best advantage and IT managers can identify where they have application redundancies and overlap. Both parties can collaborate on the basis of the shared information base so that when they analyze the business architecture, they are all talking the same language and can drive programs forward much more effectively and faster. And when change comes -- as it invariably does -- they can act quickly regardless of circumstances to set them back on course.
Dr. Bostjan Praprotnik is director of consulting for alfabet, a strategic IT planning and management software provider. Since 1999 he has supported multinational organizations in designing and realizing their IT strategies. He can be reached at Bostjan.Praprotnik@alfabet.com.