My Simple Data Strategy Framework

I’ve worked for about 10 years in Data Strategy and wrote strategies and mission statements for some of the world’s leading banks, insurance, retail, and consumer goods companies. Every strategy and mission statement, of course, turned out to be different, as they were finetuned to the company and its culture, region, and unique set of challenges. A simple framework can inform the visioning process, to ensure that the resulting strategy is relevant, complete, and cohesive, under a motto of simplicity and relevance before exhaustivity.

Here’s a personal one I used:

It is deliberately shaped as a pyramid. At the top, visible to everyone, the Strategy contains the organization’s mission and vision, which drives the objectives through a set of Use Cases, which is the next layer in the pyramid. These Use Cases are then supported by sets of capabilities across People-Process-Technology, which is therefore the foundational layer at the bottom of the pyramid.

Now, let’s take a closer look at these components.

Data Strategy

Here, we have the concepts that are related to strategy, vision, and mission. This describes what the organization, department, or business unit is all about. What are you trying to achieve? Why do you exist? A high-level mission statement can help to inform future decisioning and drive a sense of purpose across the enterprise.

A good starting point is an overall strategy that already exists within the enterprise, which can be translated into a specific data strategy. What needs to be true from a data perspective for the overall strategy to be successful? What data capabilities are needed?

It is a truism that “you cannot do it all at once.” This is especially applicable in the case of Chief Data Offices and similar teams. Improving data quality, creating master data, documenting data lineage, informing cloud migrations, enabling artificial intelligence and machine leaning use cases, building and operating a data platform — no matter the organization, there is no lack of opportunities. For this reason, you should translate the high-level mission statement into a couple of key objectives — I would say no more than 5–10. If you have fewer, they are likely too long and general to be of any particular use. If you have more, people will not take them all to heart, so you should consolidate some of them.

These objectives can be qualitative, but progress against them should be quantifiable. For example, “Ensuring that all of our critical business processes are provisioned with high-quality data from the right source” can be a stable, multi-year objective. Underlying quantifiable performance metrics could include “number of business processes certified using high-quality data”, “number of trusted sources”, and “percentage of completeness and accuracy of critical data.”

Data Use Cases

Below the high-level strategy come specific data-driven use cases. This component of the framework is the one that is most often forgotten or neglected, even though it is perhaps the most important. Use cases are the specific ways in which the strategy is implemented. They are the channels and instruments to ensure that the overall objectives of the enterprise are achieved. Hence, if you cannot express specifically how your data initiatives are impacting current and future use cases, you cannot explain how you are adding value.

For Chief Data Officers, this is critical. Too many examples exist of CDOs who launched transformations to create master data, map data lineage, or document metadata, only to find out 1–3 years into the journey that leadership and the business side of the organization are questioning the added value. As a result, data is seen as a cost (and not the enabler it can be) and funding dries up.

These use cases should not exclusively be thought up within the data team. The use cases exist in the wider enterprise and they and their relative prioritizations will be different across industries, regions, and even individual organizations. Just a few examples include Customer Engagement, Cross-sell & Up-sell, Profitability Analysis, Fraud Detection & Prevention, and Management Reporting.

Winning organizations have gone a step further. They have not only identified the use cases, but also the data that is required to power them. This allows you to map use cases against data domains and potential data assets, providing the insight what data is used across use cases. This is a great starting point to identify data domains or assets that would be at the heart of your transformation roadmap. Typically, there are 5–10 so-called potential “data assets” that could power 80% or more of the prioritized use cases.

Foundational Capabilities & Operating Model

Now we know what the overall strategy is and the prioritized use cases that should drive its success, we can turn to foundational capabilities. What capabilities are required to enable the identified use cases?

Many thought-leading organizations have created their own capability frameworks, but I usually try to keep it simple, and stick to the trusted People-Process-Technology (“PPT”) concept. If you take a careful look, most of these new, copyrighted frameworks of thought leaders are just a variation on it, adding a dimension or two, and renaming the original ones.

As part of your data strategy, it is critical to emphasize that People, Process, and Technology are not independent of each other. They should be considered highly intertwined and interdependent. It is one of the main objectives of the Chief Data Office to build bridges and cohesiveness between business, technology, and other departments across the PPT-spectrum.

An example can be how a specific strategic data platform is built for business users. If business users (People) are to be able to select, ingest, and connect datasets (Process) themselves, this may require that the platform itself is low-code or no-code (Technology). Or alternatively, if the platform is going to be built through IaaS (Technology), this may require that a central tech team provides infrastructure services (Process) and that the business users have a minimum level of technical skills to be able to interact with the platform (People). Neither option above is necessarily always the right one, but you must consider each of the PPT components together, or you are going to end up with solutions that are not creating value in practice.

The way that People-Process-Technology components are orchestrated can also be referred to as the “Operating Model.” This involves decisions around which capabilities to prioritize and centralize, and which to allow to exist in a federated structure. A framework to help inform an Operating Model will be the topic of a future post.

People

For your data strategy, the People component is exceptionally important. You can have all the machinery in the world, but if you have no-one that can operate it, you will lose. A couple of components include:

• Roles and Responsibilities. What are the main roles that exist in your organization as it relates to data, and what are their high-level responsibilities? The good news is that if you don’t already have these defined, there are some well-known, finetuned roles with descriptions out there, such as data owner, process owner, data stewards, data custodians, data scientist, business analyst, system/app owner, data quality analyst, and data modeler.
• Skills and Expertise. What skills and expertise do your people need to have? It is recommended (possibly working with your HR organization) to execute a simple analysis to list out the required skills and expertise. With this list in hand, you can also build a gap analysis — which skills are missing?
• Data Literacy and Culture. Data is owned by everyone. It is an asset and everyone in the organization needs to play their respective role. Therefore, as part of specific transformation programs as well as at an enterprise level, it is important to drive data literacy and awareness. What is data, and what is my responsibility?
• Talent / Recruiting Strategy. For your respective organization and related objectives, a talent strategy can help to identify which skills and expertise are to be grown through training and recruiting. Some skills that are not critical to the enterprise’s success can be procured or outsourced, where you decide to pay another organization to provide them. This would allow you to focus on those skills that are critical for your organization to own and develop.

Process

The process layer addresses all the critical enabling data processes. A couple of examples:

• Innovation. How are we generating ideas to increase the maturity of data capabilities? How can we ensure that everyone in the enterprise can submit ideas, and how do we subsequently facilitate the analysis, evaluation, and prioritization of innovations? This is important not only to generate the actual ideas, but also to create a sense of shared ownership with the rest of the enterprise.
• Demand Management and Funding. Not every data initiative can be prioritized and funded, so how do we decide which one to pick? A process should be in place that allows for moments of evaluation and ideation, and periods of delivery. It is recommendable to keep a “Book of Work,” which at any time describes what the ongoing efforts and initiatives are. Throughout, a process should be in place that details how funding can be obtained. Some budget line items might be one-off and transformational, whereas others might be recurring and part of “business as usual.”
• Transformation. Once new programs have been prioritized, how can we ensure that data considerations are taken into account in the transformation journey? This is incredibly important — a lot of data programs are historically about “cleaning up the mess of the past.” It is critical to “stop the bleed,” and make sure that critical data principles and standards are incorporated into the organization’s transformation methodology.
• Governance. Data is a big topic with every department in the organization creating, transforming, and using some of it. How do we make sure that the right roles are in place, with the right responsibilities, and how do we track that people are living up to them? Instruments here are policies and standards, compliance and audit processes, performance and risk metrics, and governance forums such as a Data Council.
• Stakeholder Mgmt. Yes, you can have processes to enhance stakeholder management. One mini process could be to update an overview of relevant stakeholders at a periodic basis, to schedule touchpoints with them, and to document key insights. Ensuring that appropriate forums are in place with correct representation across the enterprise is another example.
• Knowledge Management. A lot of experience and expertise is to be democratized across the enterprise. Knowledge Management deals with identifying the content and the channels of dissemination. Some truly critical topics can be fed into a training schedule, and it is almost always a good idea to have some sort of platform where colleagues can find the latest and greatest strategic materials, such as the Data Strategy itself, Policies and Standards, Instruction Manuals, and other viewpoints. This does not need to be complex — in some situations a simple SharePoint can be sufficient.

Technology

The point here is not to create a seemingly endless list of technologies, but rather to identify and manage the capabilities and processes across all relevant data technologies. If they are in place, that should ensure that the right tech capabilities are identified and enabled.

• Architecture and Tech Strategy. Perhaps the most important component is to have an enterprise-level reference (data) architecture. The data architecture can be part of a wider business or technology architecture, but it can also be its own standalone document. It outlines the architectural guidelines that apply to everyone in the enterprise. For example, it may stipulate that AWS is the preferred cloud services storage provider, that Tableau is the preferred visualization tool, and that data should be consumed from a given set of authorized distribution sources. Even more impactful are guidelines on interoperability. This goes hand-in-hand with a (data) technology strategy, including choices on IaaS, PaaS, or SaaS.
• Operations and Maintenance. Across the data tech landscape, the different technologies and environments need to be monitored and where required, fixes and updates need to be applied.
• Security, Reliability, and Continuity. Across all data and related applications, minimum controls need to be in place to protect the data and ensure its continuity in case of issues and disasters. This is typically not owned by the data organization, but there needs to be a strong connection. For example, for data assets that are deemed mission-critical or that contain PII, this should translate to specific data protection and continuity requirements.
• Access Mgmt. and Self-Service Enablement. It is no longer the case that technology is enclosed within the IT organization, as “tech for tech.” A process and capability need to be in place to provide access to business and other users, where appropriate maximizing self-service functionalities.
• Sandboxing and Experimentation. An important component of the overall data technology landscape is to ensure that a user-friendly, secure environment is provisioned to experiment with different sets of data.
• Vendor Management. Across all of the above-listed technology considerations, you do not want every team in the organization to execute their own vendor analysis, negotiation, and contracting — there would be a lot of duplicating and conflicting efforts. A Vendor Management process as it relates to data capabilities (e.g., dashboarding, data quality, data catalogue, lineage capture, etc.) can help drive that a cohesive, rationalized set of tools is identified and promoted.

Applying the Framework

The framework will not be the answer to every data strategy question, but it should help you a long way towards structuring the analysis and to identifying the questions that you want to see answered.

Good luck!