Roadmaps challenged

In my previous post I asked some questions about the validity of producing detailed strategic road maps for organisations at the end of the supply chain. I ended by saying that when I found the answers I would share them.

After publishing the post I picked up The Design of Design by Frederick P Brooks and started reading it from where I had previously left off (like a lot of people I have several books on the go at the same time). Brooks is famous amongst computer science students for writing a book of essays on software engineering, The Mythical Man Month which, in my day at least, formed the core of any course on the subject. His later book covers the essence of Design, not just in software but in the wider world and some of his essays can be taken to be a touch contentious and thought provoking. Either way both books make for excellent reading & I cannot recommend them enough for anyone dealing in architecture or software production as they contain many useful lessons applicable to either field

The essence of my previous post centred around the fact that as strategists we’re expected to produce road maps giving detailed guidance to the next steps to be taken to deliver our strategic intent. I don’t disagree with the intention at all, but when the future hangs on a number of different factors over which you have no control then providing instructions on whether to code the next project in C# or Java, and which method classes to use can be a bit difficult. My questions centred around being able to deliver strategic direction almost on demand to reflect the current view of the future, and then having effective & continual communication so everyone knew what to do and why.

Enter Mr Brooks. In an essay entitled The Divorce of Design he writes about how designers need to understand their products from a user viewpoint, and how cross training users in design techniques; and conversely training designers in the user domain provides a shared language that enables richer and faster communication with reduced ambiguity.  I’d suggest that the same lesson can be applied between strategists and the designers, and developers, downstream in the overall delivery process. By sharing knowledge of each others domains, then it is possible to enable the quicker communication medium that supports the flow of information in both directions.

Later on in his book, Mr Brooks writes about the process of documenting design rationale. He refers to two companies in the same industry, one with a culture of formally documenting how designs evolve and the second where this doesn’t happen; and then looks at the long term effect it has had on the designs of their products. Again,  I’d suggest that this too should apply to strategy planning & road mapping. A couple of years back, I produced a strategic roadmap detailing how we could develop a comprehensive online managed services capability, but subsequently my company changed how it delivers a fair portion of this capability. The detail of my original roadmap in terms of release levels of products is now irrelevant; and yet the strategic intent of what we are trying to do is the still the same and the rationale for selecting each step along the roadmap remains as valid now as it was then.

I only wish I had recorded the rationale for those steps so that the people using the documents had a clearer understanding of what we were aiming to achieve. So I haven’t answered all of the questions, but I’ve made start


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s