I’ve come to some interesting conclusions regarding Roadmaps that I thought might be interesting to others. About two years ago, I was given responsibility on behalf of the Enterprise Architecture team to provide Roadmaps on behalf of MSFT’s CIO that address 3 CIO concerns to all of Microsoft and they are; IT’s alignment to the business, Gaps and Overlaps in our portfolios, and Key Technology Investments. This responsibility came to our Enterprise Architecture team as a result of a less-than-successful attempt of an ask by our CIO to all groups of our IT organization for their roadmaps. The plan was to simply collect them all together and have an aggregated Roadmap that addresses the 3 CIO concerns. Unfortunately, the roadmaps returned from our IT organization were a collection of documents that no system or human could rationalize together to claim “across MSIT, here is how we are aligned to the business, here is where our gaps and overlaps are, and here are our key technologies to invest in”. When I looked at the roadmaps I learned that each of them were correct to varying levels but only the author could explain how it address the 3 concerns noted above – they didn’t stand on their own nor could they be aggregated to represent all of IT’s view. I discovered that the root cause was based on these problems:
Six months later I gained support to build a team with tool support to be the official provider of Roadmaps called Enterprise Strategic Planning (ESP) that has the mission statement “Enterprise Strategic Planning is a ‘Service’ provided by the Enterprise Architecture team. We provide a consistent, unified, rational, and collaborative planning capability within MSIT via Service Offerings based on people, process and tools.” The scope of our first release was to provide the foundational processes, role definitions and data to generate roadmaps that illustrate how IT addresses each of the three CIO concerns.
My ESP team built a data model that supports the 3 CIO concerns and we addressed each of the 7 problems above over the course of a about a year. We made major headway to delivering Roadmaps that address the 3 CIO concerns. I can generate roadmaps that show how IT things like IT Projects, Applications, Managed Information, etc associate to business things like Business Strategy, Business Process, Business People/Role, etc over time. I can generate roadmaps that show gaps and overlaps exist in our IT Project portfolio, Process portfolio and Application and Platform portfolios over time. I can show roadmaps that show which Technologies we will migrate to over time too. I wanted to share my learnings regarding roadmaps with you all about a year ago but I didn’t feel I could speak with confidence on them at the time because although I’ve addressed the 7 problems listed above, I discovered more challenges with the roadmaps that made me fear I might propose ideas that produce more bad ideas to the industry. (For those of you that follow my writing and presentations, I maintain an important principle in that I only share my experience and stay away from communicating theory. This is because the Enterprise Architecture discipline is so immature I think too much theory actually causes more damage than good sometimes.)
After producing those roadmaps I learned that they weren’t particularly effective in driving change, which I think is the purpose of Enterprise Architect’s existence…which is to drive change across the enterprise to help accelerate the company to achieve its strategy. This was both disappointing and ironic. The roadmaps communicated current state well but the future state was treated as more speculative rather than course-setting. So change, as it turns out in my experience, wasn’t driven by these roadmaps. This caused me to rethink how to drive change and then how should I position roadmaps to contribute to driving change.
In Microsoft, change happens via programs/projects/initiatives. Therefore, to drive change as an Enterprise Architect, we must influence decisions which projects to fund as well as set the scope of the project. The challenge is to know what influence should an Enterprise Architect provide to project portfolio managers so that they fund the right projects and define the scope to hold the projects accountable for. And on top of that, how to monitor change to track progress. So, to make the roadmaps more effective at driving change, we need roadmaps to have two fundamental principles:
We will generate several types of roadmaps this year including Program Roadmap, Strategy Roadmaps, Application and Platform Roadmaps. One that is relatively new is the Program Roadmap and is based on the two principals above. That is, the information on the Program Roadmap is mostly the ‘affect’ of the Program rather than traditional stuff like features or functions delivered, or showing program milestone dates. Instead, it includes specifics like which business strategies will be enabled and when, which organizations will be supported and when, which processes will be automated and when, which applications and platforms will be created, modified, or retired and when, which corporate risks and issues will be addressed and when, which business information facets will be created/updated/deleted/used/published and when, etc.
The Program Roadmap is a bold step in a new genre of roadmaps referred to as ‘affected architecture’ (the good people from alfabet.com coined this I think.) What I really like about the concept of ‘affected architecture’ is that it incents the right behavior. It holds projects accountable to make certain changes. Therefore, it’s not about releasing code, delivering features, spending time and money. To track change at the enterprise level, it’s entirely about tracking changes to the enterprise architecture.
Thanks, great post, Gabriel. I've seen and built a lot of roadmaps as well, and have often been less than satisfied with the final product - largely due to the fact that they fail on one of the 7 points you list above. I've certainly had the experience (and I'd bet that you have too) of digging up an old roadmap only to be amused/discouraged at how little it reflects the reality of where it predicted we would be today. This “drift” is bound to occur – and usually is magnified on roadmaps with long time horizons. Business goals change, leadership has turnover, market conditions affect budgets, etc. But to your point, many old, ignored, inaccurate roadmaps probably ended up this way because the author threw in a little too much wishful thinking, and didn’t construct the roadmap as a tool to actually affect the change he/she wanted to see.
The other conundrum I often face is the “one size fits all” dream. I can’t say that I’ve seen a single view of a roadmap that pleases every stakeholder. Some stakeholders (think PMO, Ops) want to see start dates/end dates, role impact, milestones, etc. Leadership usually wants a high-level abstraction that points to business capabilities enabled/improved by certain timeframes. At Microsoft, the customer-facing Consultants, Account Managers, Engagement Managers usually only want to pivot on the “what’s-in-it-for-me” view. And IT obviously needs an added overlay of technology, platforms, etc. For now, I’m okay with authoring separate roadmaps for separate audiences, but would love your thoughts on how to deal with the diverse set of stakeholders any given roadmap has.
Thanks for your comments. I'm of like-mind that there are near-infinite roadmaps. The roadmap, in my view is our enterprise architecture information repository associated to investments. With this, we can view the model from various perspectives how our investements are currently and will make change to our enterprise architecture (eg Business Strategy, Process, Information, Application, Technolgies, etc). Each of these views are roadmaps in my opinion.
So, to your question of making a roadmap relevant to all stakeholders, I suppose it depends on the stakeholder's concerns. That is, depending on the questions your stakeholders have drives what information you include from the repository on the roadmap for them. Sorry for the 'it depends' answer. I know this can be frustrating, however, I do think it is correct.
Great post, Gabriel!