13 years, 4 months ago

How to build a Roadmap

Link: http://pragmaticarchitect.wordpress.com/2011/03/05/how-to-build-a-roadmap/

Roadmap Image (Pins)How many of us in the profession can truly say we have been taught to develop, refine, and deliver a professional roadmap based on a sound method with consistent repeatable results?  Have been at this crazy business for years, and still astonished at the wide variety of quality in the results I have experienced over the years – and it’s not getting any better. Not sure I can identify why this is so, maybe it’s the consolidation and changes in the traditional consulting business (big eight to what? two, maybe) or the depreciation of the craft itself among our peers. And then again, maybe sound planning went out of style and I didn’t get the memo. No matter what the root cause(s) is I want to take a little time and share some (not all) of what has worked for me with great success over the years and may make your next roadmap better.

I’m no genius, just believe I have been blessed to come into the industry at a time when the large management consulting firms actually invested in intellectual property and shared this with the “new hires” and up-and-coming staff like me. Investing in structured thinking, communication skills, or just plain good old analytic skills makes sense.  Why there is not more of this kind of investment is truly troubling.

What I’m going to share works well across most transformation programs. You will struggle to find this in textbooks, class rooms, or in your local book store (I have looked, maybe not hard enough). This method I will share is based loosely on the SEI-CM IDEAL model used to guide development of longe-range integrated planning for managing software process improvement programs. You will most likely find something similar to this in the best and brightest organizations who have adopted an optimized way to think about how to guide their organizations to perform as expected (some of us call this experience). Now on to the summary of what I want to share, the balance will be revealed in an upcoming series using the adoption of Master Data Management as an example.

The Overall Pattern

At the risk of over-simplifying things, here is the overall pattern ALL roadmaps follow:

Click to enlarge

1) Develop a clear and unambiguous understanding of the current state

– Business Objectives (not just strategy or goals, real quantifiable objectives)
– Functional needs
– High impact business processes or cycles
– Organization (current operating model)
– Cost and complexity drivers
– Business and technical assets (some call these artifacts)

2) Define desired end state
First, (know this is obvious) what are trying to accomplish? Is there an existing goal-driven strategy clearly articulated into quantifiable objectives? Sounds silly doesn’t it, and if this exists and a no one knows about it or cannot clearly communicate what the end game is we have a problem. This could be a well guarded secret. Or, what is more common the line of sight from executive leadership down to the mail room is broken, where no one knows what the true goals are or cares (it’s just a job after all) becomes a annual charade of MBO objectives with no real understanding.  Some better examples I would expect include:

– Performance targets (Cash flow, Profitability, Velocity (cycle or PCE), Growth, Customer intimacy)
– Operating Model Improvements
– Guiding principals

3) Conduct Gap Analysis
Okay, now this is where the true fun starts. Once here we can begin to evaluate the DELTA between who we really are, and what we truly want to become.  Armed with a clear understanding of where we are and where we want to be, the actionable activities begin to fall out and become evident. Gap closure strategies can then begin to be discussed, shared, and resolved into any number of possibilities usually involving the following initiatives:

– Organizational
– Functional
– Architectural (technology)
– Process
– Reward or economic incentives

For the enterprise architect the following diagram illustrates a sample index or collection of your findings to this point focused across the four architecture domains (Business, Information, Application, and Technology) related to the architecture.  Note how this is aligned into the enterprise architecture meta-model you can see over at the Essential project. The DELTA in this case represents the recommended Gap Closure Strategy between current and desired end states. Or put simply, the actionable things we need to do to close the gap between where are, and where we want to be.

EA Document Index

Click to enlarge

4) Prioritize
Now that we have the list of actionable items it is time to prioritize what is front of us. This is usually driven (in a technology road map) by evaluating the relative business value AND the technical complexity, plotting the results in a quadrant graph of some kind. It is critical here that the stakeholders are engaged in the collection of the data points and they are keenly aware of what they are scoring. At the end of the day, what we are doing here is IDENTIFYING what is feasible and what has the highest business value. I know, I know this sounds obvious, and you would be astonished by how often this does not occur.

5) Discover the Optimum Sequence
Okay, now we have the initiatives, the prioritization, how about sequence? In other words are there things we have to get accomplished first, before others? Are there dependencies we have identified that need to be satisfied before moving forward? This sounds foolish as well, and we sometimes we need to learn how to crawl, walk, run, ride a bike, and then drive a motor vehicle. And what about the capacity for any organization to absorb change? Hmmm… Not to be overlooked, this is where a clear understanding of the organizational dynamics is critical (see step number 1, this is why we need to truly understand where we are).

6) Develop and Publish the Road Map
Now we are ready to develop the road map. Armed with the DELTA (current vs. desired end state), the prioritization effort (what should be done), and the optimum sequence (in what order) we can begin to assemble a sensible, defensible road map describing what should be done in what order.  How this is communicated is critical now. We have the facts, we have the path outlined, and we have a defensible position to share with our peers. We have the details readily available to support our position. Now the really difficult exercise rears its ugly head. Somehow, we need to distill and simply our message to what I call the “Duckies and Goats” view of the world.  In other words we need to distill all of this work into a simplified yet compelling vision of how we transform an organization, or enabling technology to accomplish what is needed.  Do not underestimate this task, after all the hard work put into an exercise like this, the last thing we need to do is to confuse our stakeholders with mind-numbing detail. Yes, we need this for ourselves to exhaust any possibility we have missed something. And to ensure we haven’t overlooked the obvious – not sure who said this but “when something is obvious, it may be obviously wrong”.  Here is another example of a visual diagram depicting an adoption of Master Data Management platform in its first year.

MDM Roadmap

Click to enlarge

So, this is the basic pattern describing how a robust roadmap should be developed for any organization across any discipline (business or technology) to ensure an effective planning effort. Wanted to share this with you to help you with your own work, this is usually not an exercise to be taken lightly. We are after all discussing some real world impacts to many, all the while understanding the laws of unintended consequences, to come up with a set of actionable steps to take along the way that just make sense. This method has worked for me time after time. I think this may just work for you as well. More on this later…

Tagged: Enterprise Architecture, Master Data Management, Methodology, Roadmap development