Making Roadmaps Work

Building a Strategic Roadmaps

The initiatives ongoing and upcoming are often displayed on a strategic roadmap. The primary information necessary to create one is based on the business case of the initiative (see investment planning) but also is included in the product roadmaps below. The goal of this is to align architects on the working direction of initiatives in terms of their importance and dependencies. The initial strategic roadmap often looks like a set of initiatives (products/projects ) that are lined up on a timeline.

There are two possible approaches to creating strategic roadmaps. In the first, a team of architects uses initiatives either in flight or coming up in the future and structures them according to strategic importance and dependencies, then breaks them down further into product roadmaps. In the other, a broader set of stakeholders is put together to structure objectives and goals into a set of transitions.

Workshop Type 1: Initiatives and Dependencies

This workshop is one of the first that architects use to better understand the relationship between technology work on-going, business drivers, and dependencies between initiatives. The strategic roadmap canvas can be used to create these interdependencies.

Step 1: Preparing the Workshop

To run the strategic roadmap canvas workshop, first, bring all architects (or those involved in this area of business) together. Make sure it includes business, enterprise, solution, and any other types of architects interested but especially business and solution.

Materials Needed for the Workshop:

• Business Cases for Initiatives: The best case would be to have lean business cases for each initiative to be considered. These should be no more than one page if possible. Use the?NABC method ?from the BTABoK or Lean Business Case from agile frameworks if possible.
• Strategic Roadmap Canvas: Have the business cases added to a version of the canvas or use a Sroad mapping tool.
• Sticky Notes and Voting Cards: Using voting dots or sticky notes can radically simplify the process and help time-box the activity.

Make sure each architect has had a chance to read and review the business cases privately before entering or starting step two. This way all architects are aware of the activities and initiatives coming up.

Step 2: Rating and Prioritizing

In this portion of the workshop the initiatives are ranked according to a) their stated value and b) their perceived architectural complexity. While doing this describe any potential governance issues (such as external audits) or risks the initiative might face.

Architectural Complexity Note:

It is easiest to use a number from 1 - 10 with 10 being the most complex initiative the organization could EVER do. A retail company will have a much different level of complexity for things than a nuclear power facility. So this process will get architects used to rating systems and a shared basis for evaluations. If necessary use the checklist items from the Architecturally Significant Requirements card as the categories of complexity then map to a 1-10 figure, but often just letting people free-style creates wonderful conversation.

Every architect in the workshop should have an equal opinion about the rankings and value of the project, no matter their specialization or seniority. This equality makes architect’s opinions matter and empowers people to disagree. The debates should be handled with differing opinions given a timeframe to voice their reasoning and then a shared number declared. It is important not to devolve into getting the same perfect number or solution from everyone but use an averaging system to move the workshop along.

Step 3: Finding Dependencies, Recommending Splinter Initiatives

In the final step of the workshop the architects work together to line up the initiatives on the timeline based on importance and target release dates. From this they should look for shared dependencies and shared capabilities, goals, or enabling technical services. For example, most solutions have an authentication and authorization requirement. This can be identified as a shared dependency and then implemented in the first initiative with the other depending on it. Optionally larger dependencies can be rolled out into a separate initiative or group effort so that the architects are depending on an enablement sprint or activity equally.

** Workshop Type 2: Strategic Goals and Objectives Workshop

The second workshop is more of a business exploration workshop and is very valuable in describing how?capabilities? should be changed and managed. This workshop helps to define the relationship between transitions, the changes needed, and the goals of the transitions.

Continue Reading at: Roadmap | IASA - BTABoK (iasa-global.github.io)

** Stephen Dougall was the original author of the roadmapping article in the BTABoK.