But what is a Roadmap? Well, before we get to that perhaps we should answer the question of what the Roadmap is for – what purpose does it serve? I believe there are 2:

1) Building the mental framework: When we process a piece of information we try and position it within a mental framework to both make sense of it and, more critically, to understand how that bit of information relates to us and all the other bits of information we need to do our job. If your mental framework is significantly different to the person sitting next to you then the same bit of information could have very different meanings and implications. Clearly a critical part of managing any programme (indeed any organisation) is trying to ensure everyone is signing up to and working off similar mental frameworks. The roadmap, if done right, provides a massive part of that mental framework to help people understand the programme, the journey it needs to take the organisation on and, critically, how their activities fit within it.

2) Filling the information void: change is scary. There’s a growing body of evidence about how change threatens people and that, when threatened, people will fill any information gap with worst case scenarios. If done well the Roadmap fills that void and is a powerful tool in managing the ‘threat’ of change for all stakeholders.

So if we understand what the roadmap needs to do then perhaps we can begin to answer what it needs to be to perform those key functions. Based on the above goals I’d suggest the roadmap needs to tick a number of boxes. It needs to be:

· Holistic – To be a framework it needs to ‘encompass everything’. A stakeholder needs to look at it and consider it sufficient to tell the whole story whilst accepting that all the information within is connected/related.

· Informative – It must say something useful about either current or future state. The information contained within it must be both truthful and value adding. However there is not a direct link between how informative something is and how much ‘information’ it contains (as anyone who has used early web-search engines can testify to). Being informative is about optimising the average level of information across all data points rather than having as many data points as possible.

· Engaging – It must be aesthetically pleasing – the viewer should feel drawn to the image rather than repelled by it. It must must must be pleasing to the eye.

· Accessible – It must give up its story willingly, rather than requiring the viewer to wrestle the information out of it. And remember information never lives in isolation – accessibility is both about the ease with which an individual data point gives up its information, and the ease with which the viewer can see how that data point relates to the ones around it.

· Relatable – the Stakeholder must be able to see how it relates to them, how they fit into the framework. Without that it’s a map without a ‘you are here’ sign.

So how on earth do we take a complex programme plan, a detailed business case and a group of senior stakeholders and make something that meets all those criteria? And this is where I think we need to turn our approach to roadmapping on its head – to stop thinking of it as a planning exercise and realise that it is far closer to story-telling: building a narrative around how we believe the programme will move from inception, through the challenges of the delivery, to its triumphant conclusion in a way that can be accessed by a wide group of stakeholders both informed and otherwise. And the good news is that there is an absolute wealth of guidance around telling stories which I’ve found incredibly relevant to helping me improve my roadmapping skills.

So how do we tell a story? I’ve found 6 rules of thumb that fit nicely:

1) Focus on plot not story: The golden rule of narrative roadmapping – E.M. Foster defined “story” as the chronological sequence of events, and “plot” as the causal sequence of events. As he puts it, “The king died and then the queen died” is a story. “The king died and then the queen died of grief” is a plot. For me the absolute golden rule of roadmapping is to focus on plot – the causal flow of events – rather than story – the chronological sequence of events. In practice this means avoiding starting with a timeline and then splattering it with ‘key milestones’ instead focusing on the relationships between those major milestones and how they build to an outcome. I’d go so far as to say the timeline is one of the very last things you need to overlay over any roadmap – an engaging story trumps a linear timeline every time.

2) Start with the ending: A man walks into a pet shop, asks to buy a hamster. Pet shop owner says “you can have this brown hamster for £5 or this grey hamster for £500”. Man says “£500! Why so expensive!”. Pet shop owner: “The grey hamster writes award winning detective fiction.”. “Your joking” says the man “How on earth does he do that?”. Pet shop owner “He starts with the ending and works backwards”. Much like the expensive hamster our Roadmaps should always start with the ending. Begin by articulating how the organisation will be different on completion of the programme – without this you’re instantly excluding all business stakeholders from engaging with the message. You’re also missing the ‘target’ the narrative flow needs to take the story to.

3) Identify main characters and show how the story transforms those characters: Stories have characters – heroes and villains that you can relate to and enjoy experiencing their inner and outer journey and, critically, their transformation through the course of the story. The roadmap is no different – the characters might be customer groups or organisational entities or KPIs but either way you need to decide what the main entities you will represent within your roadmap are and ensure it articulates their journey to achieve the end-point you’ve already identified. If you can’t identify that golden thread, that character journey, then neither will your stakeholders – you need to articulate the flow better or, more likely, revisit whether that entity really is a value-adding part of the story. As a word of caution if you approach road-mapping from a planning perspective you’ll treat the projects or workstreams as the ‘characters’ – as a rule of thumb this usually makes for a very disjointed ‘narrative flow’ from project to outcome. You may be better thinking about who benefits from the programme and treating those groupings as the ‘characters’ the story is being told about.

4) Make it relatable: If the reader doesn’t relate to – even like – the characters in a novel they will not believe the journey and they simply won’t enjoy the novel. This is all about relatability – can I see myself in these people, can I relate to their actions and the journey they are going through. The point stands for roadmapping – can the key stakeholders who need to engage with this roadmap ‘see’ themselves in it? Can they understand how it relates to them and how it will impact their world? If they cannot – they will struggle to engage with it and, critically, hold onto the mental framework it provides.

5) Avoid excessive exposition – Dr Johnston once wrote to a friend ‘I apologies for the length of this letter, I did not have time to make it shorter’. There’s a deep truth in those words – it takes time and effort to take a complex story and refine it down to its essence therefore improving its clarity without losing the essence of the message. The same goes double for roadmapping where the urge is always to put more detail on it in the fake hope that this will somehow increase its value and clarity. Fight that urge – clarity of the narrative must always come before excessive data.

6) Proof-read! – If plot not story is the golden-rule of road-mapping then ‘proof-read’ runs it a close second. You will spend many hours shaping your roadmap and will know it back to front by the time you believe it is ready for public consumption. It is not… the very act of creating the roadmap means you will have a privileged relationship with it that will not be shared by stakeholders. In short – it will tell a far clearer story to you than to anyone seeing it for the first time. Ensure it is reviewed by a number of different stakeholder groups who have not yet seen it – listen to their feedback, take it seriously and act on it. It may feel like dumbing down your masterwork but I guarantee their advice will improve the final roadmap.

So there you have it, my 6 rules for narratizing your roadmap:

1) Understand the plot, not the story of your programme

2) Start with the ending

3) Identify the main characters and the transformation they will go through

4) Make it relatable to your stakeholders

5) Avoid excessive exposition – simple, clear and flowing

6) Get stakeholders to proof-read it!

A colleague of mine refers to building a roadmap as creating a metaphor for the programme which I rather like and captures the spirit of what we’re trying to do with the above rather nicely. We’re trying to create an artefact that is less a perfect mirror of the programme and more an artistic reflection of the preferred future-state and how we get there. So why not try unleashing your inner Enid Blyton and narratizing your roadmap – or you might end up with a Grimm’s fairy tale….

adam@p2consulting.com
+44 (0) 7803 260508