How to Build a Data Strategy - Part 3: The roadmap

The previous article in this series focused on the Assessment phase, which describes where you are today and how you will deliver each element to get to your data vision end state. The assessment yields an assortment of solutions or initiatives that need to be synchronized to deliver your data strategy. The focus of this article is the last part of the overarching data strategy: the roadmap.

Why Do You Need a Data Strategy Roadmap?

The data strategy roadmap shows how and when to implement your data vision and mission. It is a valuable change management tool, but equally important, it ensures alignment to your organization’s vision, mission, and strategic goals.

A vital tenet of the data strategy is keeping the individual solutions small and simple, which leads to having many solutions that need to be delivered to successfully implement your strategy. The roadmap takes your organization’s priorities and constraints and defines the best time to deliver each element. A successful roadmap aligns all the individual solutions to ensure you build a strong foundation while providing the best time to value. During the roadmapping process, one of the objectives is to find “quick wins”, or smaller, yet impactful solutions, that will build positive momentum for your data strategy.

Finding quick wins helps build the momentum but finding the balance of building a solid foundation while ensuring you are delivering value quickly is the art of putting together a successful roadmap. One of the first questions coming out of the assessment is, “How solid is our data foundation?” Common foundational elements of your data strategy include:

• Data
  • Master Data (quality, attributes, and hierarchies)
  • Metadata (business and IT)
  • Operational Data (quality and security)
• People
  • Maturity
  • Ownership
  • Change
• Process
  • Data Management
  • Data Governance
• Technology
  • Data ingestion, integration, and storage
  • Data access/security 

Let’s revisit the sample data assessment from our previous article. I have highlighted the key attributes used for the roadmap. One of the benefits of doing a detailed assessment before the roadmap is that it becomes much easier to group your solutions by the different attributes and better understand your common foundational needs.

Table 1: Data Assessment Elements

Question: Can a “quick win” be a temporary solution? Yes – there are times that you may implement a “quick win” prior to the long-term foundation being in place. The “quick win” is replaced with a more robust solution as the rest of the program is implemented. One caution: be careful that the maintenance of the “quick win” does not impede the delivery of the rest of the program.

How Roadmaps Work

A well-implemented roadmap shows you true dependencies so that you can adjust as priorities shift. You can also understand all the dependencies and impacts for each change. The assessment gives you any identified predecessors and successor solutions along with known constraints.

Roadmaps are living documents. Business priorities may change or external events may demand change. One of the key benefits of doing the detailed assessment and the roadmap is the ability to quickly assess any needed changes and know how it impacts all the other moving parts. For example, suppose you need to prioritize self-service for your customers due to a change in your ability to support them as you have in the past. In that case, you already know the data and infrastructure that is needed. You simply have to determine if you have enough resources (in-house or outsourced) to make the shift (across each area – people, process, technology, and data) or if you need to deprioritize other parts of your data strategy.

As you work through the road mapping process, it is common for resources constraints to change. You may identify resource gaps that can be filled or outsourced.

What Does a Roadmap Look Like?

Let’s discuss three primary levels of roadmaps. Each one has a different level of granularity and purpose. There are also different views that can be created for each level of roadmap. The first one is the strategic roadmap that focuses on investment priorities and change management. The second is the program roadmap that focuses on key deliverables, high-level resources, high-level dependencies, constraints, groupings, and change management. The final roadmap is the working roadmap with all the deliverables, dependencies, and resource needs at a very detailed level. The working roadmap is used as a framework to build out your project plans for your individual solutions. Secondary roadmaps can be done for each of the element streams (people, process, technology, and data) as well as one for change management.

PRIMARY

• Strategic roadmap – high level – execs and change management (how and when)
  • High level
  • Communicates How and When the data strategy will deliver the vision
  • Strategic investment
  • Change Management tool
  • Helps to keep alignment with the organizations overall vision, mission, and strategy
  • Presented in a graphic format

Let’s look at some examples of a strategic roadmap. First, we will look at our first view which is a simplified strategic roadmap. This roadmap is very good at communicating the organization’s data strategy priorities and when they will get delivered over time. It also shows some quick wins and building blocks that enable those priorities. However, it doesn’t show the foundational work and some of the complexities that it will take to for delivery.

FIGURE 1: Strategic Roadmap (Simplified)

The second example below is a view of a more detailed strategic roadmap. It shows the same priorities and building blocks, but it also shows the foundational layers broken out and the complexities and dependencies that it takes to deliver the building blocks and priorities. However, it can be overwhelming to look for many people. It is a good roadmap to use in working sessions and as a back up to the simplified roadmap answering the question of “how did we get here?”

FIGURE 2: Strategic Roadmap (Detailed)

Now let’s take two of the sample priorities from the initial data strategy article. They are a customer self-serve of their accounts, and publishing the top 4 KPI’s for all employees. We use these different priorities to show a breakout of what it takes to deliver both of these priorities as well as the higher level of foundational work needed for the KPI priority. Combined these samples show you the native fit for delivery sequencing based on effort and dependencies.

The customer self-serve priority below has limited foundational work since its data subject area is limited. However, as you can see in the picture there is an option to bring in more integrated data which would either increase the resource needs or shift the delivery until the required foundational elements are delivered. As an option, you could provide an initial release with some data and functionality and then a second release with more data and functionality as long as you communicate what they get and when they get it.

FIGURE 3: Strategic Roadmap (Customer 360 view example)

The final example is the KPI roadmap below. Many of the foundational, building blocks and quick wins are needed to deliver this priority. This naturally makes it a good fit for a later delivery than the customer 360 delivery. This also shows why some of the quick wins are important. For example, the analytics dashboard quick win could be enhanced to bring some of the KPI’s to key stakeholders over time so they aren’t waiting three years to get the value they expect.

FIGURE 4: Strategic Roadmap (KPI example)

• Program roadmap –
  • Mid-level
  • Communicates what is getting delivered and when at a more detailed level
  • Key deliverables and enablers
  • Proof of concept activities with alternate options
  • Tracking significant projects and program
  • High-level resource (people, tech, data) needs
  • Duration by solution
  • Dependencies by solution (predecessor and successor)
  • Groupings (like deliverables – helpful for foundational work)
  • Quick wins
  • External constraints (to the strategy and not necessarily outside the organization)
  • Investments
  • Key change management efforts
  • Presented in a graphical format
  
  
  
• Working roadmap (higher level of granularity)
  • Detailed level based on program roadmap
  • Communicates the detailed level of effort and intricacies that are required to be successful
  • Every deliverable (enabler) with all known dependencies
  • All resource needs across the elements (people, process, technology, and data)
  • Duration by individual deliverable
  • Framework or structure for project management of each solution
  • Presented in a graphical format or a spreadsheet/project management tool – this is dependent on the volume or complexity of the roadmap

SECONDARY

• Roadmap by element – people, process, technology, and data
  • Different view of the data defined by the working roadmap
  • Helps highlight resource constraints and can be rolled up to the program or strategic level for communication or investment needs
  • Presented in a graphical format
    
    
• Change management roadmap
  • Impact over time (by stakeholders or business unit)
  • Data maturity and enablement
  • Resource changes
  • Skills changes
  • Presented in a graphical format
    
    

How to get started

Building a roadmap is an art. Many variables with different dependencies cause cascading impacts. However, this process can help you get started, ensure that your roadmap can be implemented, and can positively impact your organization.

1. Build your team to create the roadmap and ensure you have the right leadership and key stakeholders involved. These generally include process owners, data owners, technology owners, and HR leadership.
2. Rank your priorities for the strategic level of the roadmap. These may be individual solutions or a group of solutions that work together. The way to rank the priorities is different for each organization. Most find a balance of strategic alignment, ROI, and customer impact works well. However, do not overlook visibility or political needs.
3. Once your priorities are set, start the program level of the roadmap. Understand that the strategic level roadmap may need to be tweaked based on the upcoming work.
4. Add in quick wins based on the strategic priorities – try to make these early and often to gain momentum.
5. Layer in foundational efforts to support the priorities.
6. Add in any internal or external constraints (quiet periods such as end of year or busy season, etc.), including other systems going live.
7. Evaluate technology roadmaps to see if some of your needs will be met with (realistic) future releases.
8. Identify solutions that can be done in parallel with current constraints or if some constraints are removed.
9. Identify all dependencies and do an initial draft for sequencing.
10. Identify resource constraints from the initial draft.
    • Can the resources be changed? (Internal retraining or hires and outsourcing)
    • Do a buy vs. build analysis if that is an option
11. Evaluate your organization’s ability to absorb the changes from the initial draft.
    • Is your organization change-resistant?
    • Is it better to have incremental change or will that feel like death by a thousand cuts?
    • Is it better to roll out big changes with the appropriate support?
    • Are there other changes that are happening in the organization simultaneously that would be beneficial or a distraction?
12. Revise roadmap based on constraint changes and change management input
    • There are times when having more than one version of the roadmap with varying investments or different timelines can be useful.
    • Ensure that any changes in constraints are validated with the appropriate stakeholders
13. Document the decisions that were made when you created the roadmap so that it is easier to communicate, and if (when) changes are needed later, the original logic can help guide the changes, and you aren’t recreating the wheel.
14. Build out the different views of the roadmap as needed – Strategic, Program, Working, Element, and Change Management.
15. Once your draft roadmap is set, socialize it with key stakeholders and influencers.
    
    

One important note. Many of the foundational pieces take time. However, their delivery can be segmented by process or subject areas. The common foundational elements are:

                Metadata alignment – business users and IT lineage

                Master Data Management including data governance

                Data ingestion, integration, storage, and secured access

Setting up your data strategy implementation for success           

Here are some of the key points to remember during your road mapping:             

• Know what must be done – ensure your assessments and priorities are clear.
• Identify your quick wins and ensure they are both quick and deliver the right value as “wins.”
• Know the dependencies – this cannot be stressed enough.
• Know your constraints – ensure they are real constraints and not holdover or legacy issues.
• Focus on value over time for the entire organization – find a way to be inclusive so there is support from the whole organization.

A great roadmap has flexibility so when circumstances or priorities change, the roadmap can be quickly adapted, and the strategy is not derailed.

The road mapping effort does not have to be onerous. It should go smoothly if you have done a good assessment and documented your resources, constraints, and dependencies. If you have to go back and revalidate data from the assessment, it will be more cumbersome and frustrating.

Finalizing the roadmap leads to our next article on change management and ensuring that you are ready to implement your data strategy.