Success Factor #3 - Roadmap
Mapping the journey
With a clear vision and a blueprint for the target operating model, the time has come to plan, in more detail, the journey from the current state to the future operating model.
You may get away with a simple project schedule (Gantt for sequential waterfall project) or a project backlog for a small Salesforce project. Whatever the size of your project, to get full value from Salesforce, it is important to engage the business users right from the beginning to ensure you bring them along on the journey.
A large project or programme scope is typically divided into manageable ‘chunks’. This is where a roadmap helps to communicate how these will deliver new capabilities over the course of the programme. As I mentioned in the first chapter, a Salesforce solution is likely to cut across several business functions and these must be involved as you move from blueprint to roadmap.
When engaging a new client, I often start by evaluating their roadmap as this quickly shows me where they are and the rationale behind their plans. If they do not have a roadmap as such, I quickly create a roadmap to play back what they are telling me. I start by drawing a one page roadmap with the key capabilities, by quarter or by phase. The capabilities are grouped logically to make the roadmap quick and easy to understand.
Here is an example roadmap organised by programme phases and Salesforce releases. The capabilities are further grouped by programme workstream:
This roadmap has an additional row for the main business benefits to be realised with each release. Some organisations like to see the investment for each phase, as shown in the second example below:
With a roadmap agreed with the key stakeholders, it is much easier to explain the programme to other stakeholders, and to surface potential concerns they may have. It helps to address questions such as:
What will the programme deliver?
What results are expected and how will this be measured?
When will we see the benefits?
Who is impacted and when?
How much are we investing (and when)?
Why is capability X being delivered before capability Y?
Note: The last question is very useful to discuss and agree priorities with stakeholders.
Let’s look at where you would place an organisation on the Roadmap dimension in the Salesforce 8-Factor Scorecard.
At Company A, they have a project to deliver the new Salesforce solution and manage the data migration from the old system. The project plan covers technical deliverables leading to one or more releases of new capabilities. At level 1, the project is very much a standalone initiative. In contrast, at level 3 the standalone Salesforce project would be one of many projects in a portfolio of projects that combined would deliver a set of new capabilities.
At Company B, the Salesforce project (or projects) will be delivered in stages, starting with a basic solution, for example, to replace a legacy system, and then expand the basic Salesforce solution to provide more complex capabilities. At level 4, I expect to find a project or programme plan arranged around the delivery of new capabilities. The project or programme team has a clear understanding of how the organisation will use each new capability. At level 6, there should also be a supporting capability map to connect the solution features to business capabilities. I would also expect a business representative to drive the priorities for the capabilities being developed.
At Company C: There is a programme of work to deliver Salesforce capabilities according to business priorities, starting with the main capabilities for which Salesforce was chosen. Each capability will deliver a fully working solution to support the business transformation. At level 7 or 8, the organisation has a phased programme plan and a backlog of epics in priority order. For level 9, there would be a simple roadmap showing the capabilities in each delivery phase. The programme stakeholders talk in terms of ‘roadmap and business priorities’. The initiative is owned by the business and the programme is seen as a collaboration between business and technical leads.
At Company D: The Product Owner has agreed a roadmap of capabilities that supports the strategic objectives and delivers benefits with each release. The roadmap shows how new capabilities are stacked and evolves as the organisation gains familiarity with the Salesforce solution and the new operating model is settling in. For a score of 10, the stakeholders are committed to their roadmap and the programme team is actively supported by the sponsor and the heads of departments. As you move towards level 12, the focus is on delivering and embracing new capabilities to achieve the programme benefits. The use of roadmaps for planning and communication is part of the way this organisation operates, and they would not undertake a Salesforce project without developing a clear roadmap first.
There is a lot more I could go into about roadmaps, for example, how to overlay the POTI model, how to evaluate competing requests for new capabilities, how to prioritise using a scoring system, how to manage multiple roadmaps, and so forth. But the aim of this book is helping you become more successful with Salesforce, not to teach you everything about roadmaps!
You have seen a few working examples and we have discussed what the different levels represent. You are now in a good position to ascertain where your Salesforce project or programme fits on the 1 to 12 scale. And by doing this exercise in your own organisation, it will show you what to focus on next to advance your success with Salesforce.
If you are ready to have a go at creating a roadmap, start by asking ‘what are you wanting to achieve’ followed by ‘what capabilities do you need to achieve that’. Plot the capabilities across quarterly columns in one row. Then add the key benefits expected in each quarter on a separate row, like this: