Roadmapping basics

Over the years I’ve helped numerous groups create technology, capability, product, platform and strategy roadmaps.  Most of these used a format similar to one popularized by Bob Galvin during his tenure at the helm of Motorola.  Such roadmaps depict the evolution of a technology, product, etc. through a series of states (releases, maturity/performance levels).    Even though roadmaps and project plans look very similar (each displays a series of “bars” on a timeline), they differ greatly in their meaning and usage.  The bars on a roadmap represent states; the start of the bar is when the technology or product achieves a specified release or performance level and will be available to create value in the real world.   The end of the bar is the end-of-life or retirement point for this state, i.e. when the technology, capability or product becomes obsolete and should be replaced with something better (lest value attrition occur).

The bars on a project plan represent tasks, work that is planned and will consume resources.  The start of a task bar represents the start of work; its end point signifies that it has created a set of deliverables, its intended work products.

Of course, technologies, capabilities, products or strategies don’t automatically advance to a higher state with the passage of time; the step-function improvement that is implied by the start of a roadmap bar is the result of investment and effort.  It is triggered by one or more projects and the completion of tasks within these project plans.  As a result, there will typically be multiple finish-to-start dependencies between a set of projects or project tasks and a specific roadmap bar.

Delay of a prerequisite task will push out the release date for a roadmap bar; if roadmap bars are delayed too much they collapse, i.e. they won’t have enough time to create value in the real world to justify their development cost.  Roadmap bars are easily compressible, but such compression is bad; task bars resist compression, but such compression is good.

Strategic roadmapping requires a higher level of project management than most organizations have mastered.  There is a project of projects that must be coordinated to time-align all of the new states that will come together to produce a big bang of business results.  However, rather than start with the project plans and then wire them together to “push” the roadmap, it’s better to build the desired state model (lots of aligned releases of technologies, capabilities, products and strategic advancements) and then define the project of projects plan to support it.

Look for more roadmapping basics in coming blog entries! And start a trial of the Decision Driven® Solutions Framework (DDSF) today by contacting the Decision Driven® Solutions team at trial@decisiondriven.com or solutions@decisiondriven.com.

About decisiondriven

Innovator in Decision Management, Systems Thinking and System Engineering methods and tools
This entry was posted in Decision Concepts, Decision Driven Innovation, Decision Driven Product Development, Decision Driven Strategy and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s