About Us

P2 Consulting was started by a group of award winning consultants who recognised the opportunity to build a global consultancy firm that had clients’ needs at its heart. We understand the challenges clients face – the pace of globalisation, technology change and increasing regulation – and the pressure they are under to respond to these changes rapidly and efficiently.

What We Do

We work on some of the largest transformation programmes in the corporate world and the public sector. Partnering closely with our clients, we help them deliver successful business change. Our reputation as a consultancy is built on excellence in portfolio and programme management, business architecture and design, testing and quality assurance and implementation.

Insights

Understanding the challenges that keep our clients awake at night is essential. In this section we demonstrate our expertise at solving your problems. We have deep insight into the business and technology issues facing all sectors.

Join Us

Are you looking to join a company where a challenge is welcomed, change is anticipated, and expertise is expected? Then have a look at our job listing and please get in touch.

Case Studies

We’ve worked with clients across a range of sectors and gained excellent results – but don’t just take our word for it. Have a browse through some of the work we’ve done.

Story-Telling And The Programme Roadmap

Using narrative techniques to build a compelling roadmap

Adam Skinner, Director of Consulting at P2 Consulting

25.04.19

The client work I do tends to cluster – one quarter the theme is building Agile PMOs, the next I can’t move for PMO Maturity Assessments. Recently it’s been all about building and reviewing Programme and Portfolio Roadmaps so I’ve spent lots of time looking at good and, more usually, bad examples of that thing we call ‘The Roadmap’.

As is often the case it is far easier to say what a ‘roadmap’ isn’t than what it is. And what it isn’t is a perfect reflection of milestones and tasks that deliver the programme.

The Value of a Roadmap

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.

Narratizing the Roadmap

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.

The roadmap: a metaphor for the programme

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….

To talk more about programme roadmaps, strengthening your PMO or to find out how P2 Consulting can help your business today, please contact us:

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

Or