To create a roadmap, we need to know what it is supposed to accomplish

I’ve been involved in a number of meetings recently as our IT teams try to come to consensus on answering this question: What is a Roadmap?  It’s been a fascinating series of discussions.  One thing that strikes me is that most of the internal discussions, and many of the discussions I’ve seen online, are only seeing part of the business process where a roadmap is used. 

If we don’t see all the process interactions, we can’t get the requirements right.  And if we don’t get the requirements right, the solution (the design of the roadmap) will not be as useful as it could be.

[Terminology Note: I don’t have any great love of the word “roadmap” to refer to the EA artifact.  I like “action plan” as a term, but I have no strong preference.  In keeping with prior posts on the subject, I’ll keep using the word “roadmap” unless and until we can get some consensus on an alternative word.]

Picking the correct approach

There are two different business processes where a roadmap is useful: deciding on the order of efforts, and tracking the efforts against that decided order.  IT folks tend to focus on the second.  I will focus on the first.

When we look at the notion of strategic planning from an EA perspective, we are trying to reduce unnecessary effort.  Just as a downhill skier in the Olympic games will surely lose if they are off course by a few degrees, adding a few extra meters to the length of their run, commercial enterprises are not asking for “any path down the hill” to win the race.  They are asking for “the best possible path down the hill.”  (If your company is run by a salesman, they may shout the words “win the race.” :-)

The business has created their strategy and we have assisted with creating the measurable scorecard to track our progress towards achieving it.  That is step one (most Enterprise Architects have NO idea that this is part of their job).

The first process that uses Roadmaps starts here (colored in brown above).  Enterprise Architecture collect information to produce a series of alternative approaches (“candidate roadmaps” in the diagram above).  The input information includes other roadmaps, as well as business rules, political needs, dependencies, parallel initiatives, resource constraints, technology standards, fiscal constraints, regulatory constraints, and business drivers.  Each approach allows the business to deliver on that strategy in a way that is feasible, fiscal, and forward looking.  We allow ideas that may require us to change big things (merge, split, and repurpose teams, systems, processes, assets, etc.). 

Why have many candidates?  Because there is nearly always more than one path.  Each path will have tradeoffs.  One may be quicker to see results, another less expensive, and another less disruptive to existing product plans.  We need the business to pick the path that they want to follow.  Moreover, we want them to debate the tradeoffs in front of their peers, and come to a resolution about which path they will collectively select.  Because the only thing worse than having no roadmaps is having many competing roadmaps.  It is tempting to come to the business with only one roadmap. “Here’s your solution, sir.” On occasion, that works. Depends on the organizational politics. Personally, I think that is not a good recipe for buy-in. Your mileage may vary.

At the end of this two-step process, we walk out of the room with something powerful: buy-in.  We come away with a clear decision: beyond “get this done,” we now have “go do these projects, in this order, to get it done.” 

The candidate roadmaps fuel the debate.  It is the tinder to which we strike a match.  Each one explains all of the information that a stakeholder needs to debate the pros and cons, and the collection of information is sufficient to allow business leaders to pick one with their eyes open to the tradeoffs. 

Delivering on the approach selected

In the second part of the process (in purple above), we bring up the roadmap on a regular basis as we review, with our business stakeholders, the status of our projects and whether there are dependencies that may be driving our decisions.  In other words, if two projects are on time and a third project is late, but the fourth project cannot kick off....  You get the picture.

This is a kind of decision-rich governance activity.  The “roadmap” in this context is used for expectation management.  While this is a very valuable activity, you do NOT need all the same data for this activity as you do for the previous one.   Whether you need one diagram or two will depend on your business and how it handles project governance.

Conclusion

I went to such trouble to explain the distinction between these two parts of the process because the first part (using a roadmap as a high-level decision making tool) is often misunderstood by EA stakeholders who only view EA from an IT context.  As such, much of the debate on “what belongs in a roadmap” is centered around delivery needs and not enough on the decision needs described above. 

To build a better roadmap, it helps to know where it will be used.

Comments

• Anonymous
  November 14, 2011
  I found this to be very valuable in guiding my teams through the same roadmapping discussions, which initially started out as 'developing a business case for expanded efforts aligned with Product Development'. On the whole, there is not a lot of focus within the EA community for moving from Architectural models to Product Realization strategies. This is an area that I think will mature considerably in the coming months and years. en.wikipedia.org/.../Technology_roadmap