Do you need a data strategy?
A good Data Strategy is an invaluable artefact for any organisation that is serious about building out their data capabilities. However, it’s also one of the least well-defined artefacts. Often organisations will skim over this step because they think it will “take too long to create” or “be too high level” to add any value. Unfortunately, these criticisms are oftentimes warranted. We have seen organisations spend 6 or 12 months and sometimes even longer crafting a data strategy whilst holding up other work until it is completed. We have also seen organisations that have created a strategy that is so high level it is never referenced and adds very limited value.
However, a practical data strategy that focuses on bringing together your stakeholders and defining guidelines for the overall direction of your data program is an extremely important artefact. Creating such a strategy is a really worthwhile exercise and it will pay dividends time and time again as you move forward with your data initiatives.
Why do we need a data strategy?
We might sometimes think the work we do to improve data capabilities at our organisations is part of a single program of work or a series of projects and delivery milestones that run as a linear plan. We might kick off with a broad goal. Something like ‘becoming a data driven organisation’. We then plan and start executing a series of data related activities. Our initial projects might deliver some form of data warehouse or analytics platform uplift. At the same time, we might setup our first Data Governance Councils and start appointing Data Stewards. We continue running more initiatives and investing in data related projects. The expectation is that all the big and little things we do along the way will come together to form a complete capability. The organisation is making the “right investments in data” and as such we can be confident that it will only be a matter of time before “data becomes the lifeblood of our organisation”.
In practice things rarely work out that way. In a complex organisation all the different projects and use cases will not line up. The business environment and priorities will change. Some of the things we set out to do won’t start. Some of the things we tried to do will fail. We will be forced to build new capabilities we hadn’t thought about along the way as the market, industry and technology evolve.
If we want to be successful in bringing about a sustained uplift in our data capabilities and deliver projects that build upon each-other to drive our organisation forward, then we need to accept a few things:
There is no “finish line”; unless we believe the business and technology world are going to stand still. Therefore, we need a long-term direction as well as a short to medium-term plan. We may only plan at a detailed level for the initial Use Cases, but we need a North Star - big picture thinking; what are we working to achieve.
If we want to move fast and deliver value quickly, then we can’t constrain ourselves to an overarching linear plan. We need the flexibility to adapt as we learn. We need to empower our people, teams and business functions to progress independently without the constraints of a large slow-moving program.
For these reasons; we believe it is very difficult to succeed without an overarching data strategy. The strategy gives us that 50,000-foot big picture view. It allows us to get on with delivering value whilst knowing that all the small and big things we do are lining up to a bigger picture and moving the organisation in the right direction.
What is a data strategy?
At its simplest level a data strategy is a document. However, the document is the output of a process and it’s this process that is important rather than the document itself. A Data Strategy is about bringing together our stakeholders to collaborate and to describe where we are, where we want to get to and the broad steps we are going to take to get there. Our data strategy should cover the following items.
1. Current State: What are our biggest problems? What strengths can we build on? What existing infrastructure can we keep? What are the data skillsets that we already have? What’s our culture around data and is this a culture that we want to foster or something that we need to change?
2. Use Cases: What are the key uses cases we want to enable? These should not be exhaustive or detailed, but we should document 4-5 key business use cases at a high level.
3. Dependencies: What are our key dependencies? What big projects are planned that we may depend on or need to align our strategy with? What regulatory changes are coming up?
4. Goals: What are our goals? Avoid broad statements that aren’t measurable and don’t be afraid to have modest goals that may reflect our low level of maturity today. In this area we should not constrain ourselves to narrow time horizons– this is the time to think about how our business will change in the long term and what that might mean for the capability we invest in today.
5. Technology & Architecture: What tools and infrastructure do we need to deliver our use cases and how will these tools be architected to work together. We don’t need to define specific vendors but should think about the overall technology capability we need. Do we need a Master Data Management (MDM) capability? Do our use cases depend on high volumes of streaming datasets?
6. Skillsets: What skills do we need in our data organisation? This includes technical, architecture and data skills as well as softer skills such as project management. Its important that our investment in skillset match up with our investment in technology. There is no point in building extensive data science infrastructure if we don’t have people with (real) data science skills. Similarly, we don’t want to go out and hire a team of Data Scientists if we don’t have funding to build out the infrastructure they need.
7. Organizational Structure: What does our Data Organization look like? Which capabilities are centralized in an Enterprise Function? Which capabilities are federated to the Business Units? How much should we bring inhouse vs outsourcing to vendors? What is the right level of governance to ensure we deliver an operating model that we can sustain?
8. Principles and Guidelines: This is where we can start describing some of the architecture principles and broader rules that will guide our overall program. The intention here is to write a set of very clear and unambiguous statements that set some boundaries around the work we will be doing. These principles may be extended in your data architecture principles and data policies later but for now its important to capture the broad strokes.
9. Short Term Wins: We are most likely asking our organization to sign up to a multi-year journey. That can often be a tough ask. It’s always good to think about how we can add value near term. Are there things we can do quickly that will solve some real business problems? How can we leverage these to build rapport and trust with our stakeholders?
10. Roadmap: Finally, our data strategy should include a high-level roadmap. This isn’t a detailed project plan but should describe the key things we will be doing on a monthly or quarterly timeline. The closer the deliverable then the more detail we expect the roadmap to have.
How do we create a good data strategy?
There is no magic formula that you can follow to create a data strategy that will be genuinely valuable for your organisation. With that said there are some guidelines you can follow:
1. Process over Documentation: Focus on the process and not the document. The data strategy document is just a by-product of the things you learn and the decisions you make as a team whilst collaborating on the areas covered above.
2. Business Science over Data Science: Our business goals need to drive our data goals. For example, we should focus our data projects on products, services and channels that we believe are growth areas for the company. We also need to build solutions that fit the business needs; for example, a major investment in real time analytics to support product placement is a bad investment if our business practice is to review product placement on a monthly basis. Finally, remember that you cannot sustain a data capability just because it produces interesting data or beautiful dashboards. You need to create information that people can directly act on and make business decisions from.
3. People over Data: More data and more complex technology is not necessarily better. A simpler solution designed with the end users in mind will win out 100% of the time. The fact is that it’s not really about the data. It’s about the people that need to understand and trust the tools and information so that they can make better decisions in a timely manner
4. Capability over Technology: Focus on capability and skillset over technology. Technology will enable people with the right skills to do great things, but it will not compensate for them. Plenty of organisations have bought the latest and greatest tools and delivered nothing with them. The fact is that unless you are at the cutting edge (chances are you are not) most of the vendor tools are quite similar. The differentiator is in knowing how to use them and how to make them work together.
5. Agility over Certainty: The big bang approach to delivering a data capability is a surefire way to burn money. You need to develop the simplest solution you can and then make it better if it adds value. You need to build for the future but since you don’t know the future the best thing you can do is be able to adapt. Your data strategy should define a culture where you test things first, see what works and then do more of that.
How much time should it take to develop a data strategy?
So how long should it take to create our data strategy? Well, as with many things the answer is that it depends. How detailed do we want to be? How quickly can we get time with the people that need to have input? How complex is our landscape? How much work has already been done over that last few months or years that we can leverage as a starting point?
As a general guideline we recommend that 6-12 weeks is an appropriate timeframe. This doesn’t mean that we will know or cover everything in that timeframe but it’s important that perfection not get in the way of progress. 6-12 weeks is a reasonable timeframe to develop a data strategy and you can extend the depth of the strategy as you learn more.
Infornite is a boutique Data Management consultancy. We help our clients to develop their data strategy and to successfully build data management, data delivery and analytics capabilities. Reach out to us via our contact page or connect to our slack group if you’d like to discuss how we can help your organisation.