This post continues a series on taking your cloud journey from strategic vision to practical reality.
In recent posts, I’ve discussed the process of establishing an organizational vision and strategy for cloud technology. Once you’ve established a solid, supported, long-term strategy it’s time to get tactical and the bridge between strategy and tactical implementation is your roadmap.
Everyone gets roadmaps as a metaphor and that a roadmap is a detailed guide to the stages of an organizational evolution. But I find that people often aren’t sure what this kind of IT transformation roadmap should really look like. Let’s dive in.
The roadmap documents the transformation goals and the timeline to get your organization from where it is today to where it wants to be. It also notes the value delivered in each phase.
Fitting between high level strategy and day-to-day tactics of project management, the roadmap gives you a sense of the logical sequence of steps needed to move from your present state (say, all on-premises IT) to the desired future state (say, 80 percent cloud-based with a cloud-first bias for any new technologies in three years).
Sample high-level cloud roadmap approach
Informatica Professional Services does workshops around roadmapping that go into considerable detail. The above sample diagram gives you some idea of what a roadmap looks like at the high level. This is just one viable format— roadmaps come in many forms and there’s not a single universal template to hunt for. What’s important is that your roadmap covers the right bases for both the business and the technical aspects of your plan:
Each milestone or rollout on your roadmap requires some mid-level detail. The roadmap might note the following for each specific goal:
Truly granular detail, such as step-by-step time tables, training schedules and project staffing don’t fit here— that’s at the project management level. Here, you’re accounting for everything that needs to be done, so your project manager knows what to accomplish via a more detailed project plan.
The roadmap is a tool with three important uses. The first, most obviously, is planning. As we just discussed, it lays out the stages of work toward achieving the desired future state and for doing it in a way that keeps the business readiness and IT capabilities in sync.
Secondly, it’s a tool for maintaining buy-in. IT transformation is slow and often expensive and most multiyear visions are held hostage by annual budget cycles. The roadmap is a statement of commitment that helps you keep business stakeholders literally on the same page.
And thirdly, it serves a related function to help maintain priorities. Any long plan will face challenges when business leaders discover a new urgent need. Sometimes there’s a valid reason to rewrite a roadmap, sometimes there’s a route to compromise and sometimes long-term priorities must defeat the “shiny new object.” But it’s up to the roadmap to show how all the pieces fit together and the value delivered at each stage and by the full transformation.
Because a roadmap is a living document never carved in stone, it’s important to review it every six months or so. Huge business/industry changes or new technology shifts might prompt changes to better maximize results.
A common question in the roadmapping process is how to determine the “ideal state” and adapt it to your organization and needs. But that’s a bigger discussion around architectural planning—which I’ll discuss in my next post.