So what's in a roadmap, anyway?

  • Article

Microsoft is an odd bird.  It is a dynamic place, with different business units moving at their own rate, not hindered by much of a 'central authority.'  It's an approach designed to foster innovation, and it works pretty well.

Where this doesn't work is in IT and business process simplicity.  Every different team will approach mostly the same problems over and over, but because no one wants to rely on anyone else to deliver for their business, or be responsible for a mistake, then everyone develops their own solution to the common problems.  Finance and HR are the exceptions.  These well-run teams created simplified processes long ago because the company would never have been able to survive at the size and speed it moves without them.

Different processes and tools cost a lot of money and slow the company down.  They need to be streamlined, simplified, and removed. 

That's where a roadmap comes in.  This is a single document that includes the information that everyone AGREES upon with respect to tools, processes, and timelines for bringing all interested parties to a single 'reasonable' answer.  The roadmap has to be updated every year, and there has to be a way to making sure that different roadmaps don't overlap one another or leave big gaps.  In other words, every key business capability that has to be automated or addressed with a process should have one and only one roadmap where it is included in scope.  (that's harder than it sounds.  different blog... different day).

We have a roadmap for every solution platform.  A platform is a business grouping of applications that solve similar needs.  (Don't think OS or SQL Server... think ERP or CRM).

The end result is one document for each platform.  Here's what I have in the template for that document:

  • Purpose of this Document  - why write the doc
  • Stakeholder Chart - whose needs are being met with the solution
  • Signoff Chart - timestamp and id of person who signs off.
  • High Level Platform Capabilities - the solution capabilities demanded by the business
  • Business Drivers for the Capabilities - the list of business programs or business teams that will use the system
  • Capability Demand - which business are asking for which capabilities.  An interesting grid.
  • Technical Interdependencies - what other systems rely on this solution.  What other systems does this solution rely on?
  • Enterprise Architecture Concerns - what agreements have been made with EA to get alignment of the solution to EA standards.
  • Architectural Context - one or more diagrams showing how the solution platform will evolve over time.
  • Methodology - how this document and concensus was created.  What meetings were held.  Who was in the room.  (it matters)
  • Roadmap schedule - what timelines everything thinks are reasonable for delivering the needs to different business customers
  • System Quality Attributes - what quality attributes will be stressed in each of the iterations.
  • Alternatives considered - what alternatives to this roadmap were considered and why this one was chosen.
  • Roadmap Risks - what could go wrong and who is assigned to watch for it
  • Platform Historical Narrative - previous decisions and narrative so that we can always answer the question: how did we ever get in a bind like this?

So if you find yourself in the position of having to create a roadmap, and getting your businesses to sign off on developing one platform well, rather than 4 competing applications with competing data streams and incompatible processes, use the list above.  It is simple, doable, and a good starting point to keep your customers from 'going off the rails' and stomping on another's needs.