Techn@gerial

Product and service roadmaps are notoriously hot topics in most software or technology businesses.  They are there to represent the aspirations and communicable plans a business wants to surface and use to keep their customers and partners engaged.  There is no doubt that they are an essential aspect of demonstrating and evaluating your delivery capability but getting them right and keeping them meaningful is a challenge.

Let’s assume that it is a given that IT and software projects are notoriously difficult to plan and deliver within original bounds.  Let’s also assume that your roadmaps are communicated to customers and partners as statements of corporate intent and used to seal deals and retain customers. When a project fails or slides, corporate credibility is suddenly at serious risk if your roadmap is ill conceived and based on expectation or desire rather than fact.

This diagram illustrates a series of projects on a background that shows an increasing level of knowledge as the planning and delivery lifecycle is executed.  Projects in Zone A may be in high demand but they are too young to be firmly positioned in terms of delivery as the requisite level of understanding about them just hasn’t been arrived at.  Zone A is the place for strategising and scenrio planning using rudimentary sizing and forecasting tools to provide a level of context and business foresight of what the size and shape of these projects might be.  The urge to communicate delivery dates for these projects should be firmly resisted.  If their priority is high enough then invest in learning more before committing to delivering them and then failing to do so.

The projects in Zone B are the most dangerous ones, it is so tempting to take the detail that has come out of the planning and investigations that have been going on and hand out that information as committed dates.  Obviously, there will be times when you’ll get it right or score a delivery within an acceptable tolerance.  But equally, you will probably have missed something and the net result will be the same as going with a date from Zone A dissapointed and frustrated customers and missed targets.

As projects cross from Zone B into Zone C the level of confidence, consensus and clarity about the project should be at a level where forthright project management techniques will ensure an acceptable delivery.  These are the projects that you should be telling your customers you will be delivering.  They are the confirmed initiatives, supporting the business strategy, that have been planned to the right level and are resourced correctly.

Your roadmap/s should reflect your lifecycle.  If you only want to publish dates you can meet, then use projects only when they get into Zone C.  If you want to take risks then publish dates from the borderland  in Zone B, but monitor carefully and expect delays.

Don’t publish dates anywhere to the left of the midpoint of this diagram.  Talk about them, validate them, socialise them with your customers and sales forums to get your priorities right but let the lifecycle run before you committ.  If the pressure on a certain project increases, reprioritse to service that project.

My preference is to seperate projects onto staged roadmaps so there are no illusions about the quality of the information each roadmap is offering and therefore the level of surety in the dates that are being stated.

Tweet This Post