Issue #58 – Building a Data Strategy (The Execution)
From direction to a plan people actually follow
Read time: 11 minutes
Everybody loves the direction setting part of the Data Strategy process. I mean who doesn’t like to go shopping for cool data science, analytics and AI tools saying “I want that one and that one.”
But then you get to the checkout…
And suddenly everyone thinks back to their day jobs, and realizes they didn’t have time to build those things.
Sound familiar?
This is where most data strategies go to die. Not because the direction was wrong; not because the use cases were bad; not even because people weren’t bought in.
But because the executional machinery wasn’t established or just collapsed under the weight of competing organizational priorities.
Execution is where the rubber hits the road. Often, people mistake that for “Let’s just do shit now.” That is where teams become ticket takers, keep putting out fires, and don’t really get much done, even though they are always busy.
The beauty of a data strategy is that it allows you to frame up the execution in a strategic way where the work you’re doing actually means something and isn’t just for the sake of it.
And today, we’ll walk through how to build on the direction setting that we’ve already covered to understand what actions need to be done and how we do that in a way that adds value rather than just creates work.
Going from Data Direction to Delivery
We covered the direction setting in the last article, but it is still important to provide a brief framing of how to move from direction to delivery.
At the outset, the goal of any data strategy is to understand the perspectives of those business and data stakeholders in the organization. This includes what they need to do their job, their biggest problems/challenges, the organizational strategy/ways of working, what data and products exist, the technical foundations you are building on, where the organization wants to go, etc.
These are things everybody knows, but aren’t often articulated well, leading to different perspectives in everyone’s heads. This lack of consistency is what kills progress.
Therefore, the direction setting portion of any Data Strategy is to bring everybody onto the same page:
The first artifact you build—the Data Vision—is an inspiring statement about how data will help the organization that people truly believe in
The Strategic Pillars under that act as the bridge, breaking down that vision into something more tangible and connected to the overall organizational goals and day-to-day activities
Then the direction needs to be made tangible with use cases, outlining the specific initiatives to translate the strategy into outputs and outcomes.
The back half of the process is about cementing these direction-setting artifacts that everybody has bought into and aligned around into how the organization moves forward. The hardest thing to do in a corporate environment is change management—getting everybody bought into the change that needs to happen. And this is exceptionally hard with data & AI because people don’t fully understand it (especially now…).
So that is where the Capability Assessment and Executional Roadmap come into play. By looking at your organizational maturity and what exists today, you know your starting point and what gaps you have to fill to deliver against the vision/ use cases that have been set out. That allows you to build a proper plan—the Executional Roadmap—which establishes the path to success with clear ownership, timelines, and next step actions.
A real strategy has all four components (Vision/ Strategic Pillars, Use Cases, Capability Assessment and Roadmap) flowing into one another. If you don’t take a holistic, action-oriented perspective to each step, your data strategy won’t succeed. And from my experience, the gap between a data strategy that delivers and one that dies is almost entirely down to how seriously the team treats these last two components which bring your direction to reality.
So let’s get into them.
The Capability Assessment
You can’t build a roadmap if you don’t know where you’re starting from.
This sounds obvious. But it’s not what most data strategies do.
Instead, most pure strategy consultants skip this step. A lack of technical and data knowledge makes it impossible to properly assess different data domains and map them against what needs to be done. And that is why those data strategies fail.
On the other hand, technical consultants spend too much time at this step. They get into the weeds and focus on individual solutions by domain. In the end, there is no link between the data maturity and the strategic direction.
Honestly, this kind of exercise is where my tagline—bridging the gap between data and strategy—comes to life. It is about understanding the specific data domain and assessing its maturity in delivering against the organizational needs.
When going into an organization, I usually break the capability assessment into five large categories, each with individual data domains. Each domain gets scored against where people believe the organization is at (keeping it simple with a 1-5 or Red, Amber, Green rating system) and why. After doing that, you follow up by assessing the initial scores against what the strategy requires to succeed, given the vision, strategic pillars, and prioritized use cases. This goes beyond the typical Gartner “best-in-class” framework and actually adds colour to the assessment about what needs to be done.
Here’s how the structure breaks down at a glance:
Business & Data Foundations — The structural components that set the direction and operational cadence for data to succeed. This includes the data & AI strategy, the operating model, and the org structure. On new maturity assessments, I will be adding a context layer to this bucket
Data Engineering & Architecture — The technical bucket around how the data and technical platform are architected, modelled, ingested (engineered), and surfaced to analytical resources. Platform and software engineering also fit into this bucket. The new addition is whether you are doing these things in an AI-enabling way
Data Management & Governance — This focuses on how the data is governed, managed, secured (data privacy & security), and mastered. With AI, this bucket becomes so much more important, as the script has flipped on how to actually deliver against these domains
Value Realization & Adoption — This bucket includes BI & analytics, data science and AI. But it also includes data & AI literacy, culture, and business decisioning. It comes down to whether the data is being surfaced in an insightful way and does the business actually understand and use it in the intended way
By going into detail in each area, you develop an understanding of where the holes are and, more importantly, how different domains are dependent on one another. For example, you see the throughlines of a poorly architected data platform having direct implications for the bandwidth of your engineering team, which in turn affects the reliability of your dashboards.
This is essential if you want to actually get something from your data strategy because every roadmap will have use cases and initiatives that span across multiple data domains. So don’t sell this part short when you are evaluating what exists!
In addition to evaluating your data capability domains, it is also worth examining your data architecture. Now this can mean many things, but from a strategic and evaluation perspective, I tend to focus on these three areas:
Existing technologies – Start with what tools exist in the stack and where they are. You’d think this would be easy because every data person loves talking about their stack, but when you take an enterprise view of this, you often get random tech involved, or source data coming from tools that people didn’t even know existed
Current and target state dataflow diagrams – A high-level view of where data is produced, where it lands, how it moves, and where it’s served. This includes the technology stack from above, but gets a bit more explicit in how the data travels and where and how it gets processed. Honestly, given that this often happens in 20 different ways for each organization, this helps simplify how things work
Data modelling approach – If there is one, great. If there isn’t (most of the time), then this is where to begin recommending an approach to modelling the data against the prioritized use cases within the existing (or target) tech architecture and data flows. Most people just default to Medallion, which is fine but there should be some strategic and technical rigour behind it rather than just saying bronze, silver, and gold over and over again…
When this high-level architecture view is done properly, three key things emerge.
First, the organization gets a clearer picture of something people think is too technical to simplify.
Secondly, you start to add technical rigour that can be applied to the use cases. By assessing the platform more technically, you can better see how to build on it.
Finally, you surface and map out some of the dependencies within the dataflows and platform that will be essential when building the roadmap.
Speaking of, let’s move to that final step of a Data Strategy.
The Executional Roadmap
Finally, the roadmap. Now this seems like an obvious last step, and to be fair, most people will build this artifact. But the problem is, most roadmaps don’t have the context, accountability and buy-in necessary to be delivered on.
Because a roadmap isn’t a list of high-level, ambitious initiatives with dates next to them.
A real roadmap is a sequenced, owned, funded plan with clear accountability for each workstream.
At this point, you have already prioritized the use cases. Ideally, you have a 2×2 prioritization map with delivery effort (technical effort, data availability, and team capacity) on one axis and business value (cost savings, revenue growth, risk mitigation, enablement of other use cases, etc.) on the other. This should give you four clusters of prioritization that helps you build your roadmap:
Quick Wins — High value, low effort. These are essential to build credibility and create the political capital for the data team/ roadmap
Strategic Investments — High value, high effort. These are strategically important use cases that are usually phased across multiple steps with clear dependency chains.
Two Low Value Clusters — Honestly, you rarely get to these, so I’m grouping them together. Plus once you talk to stakeholders things always end up being higher value and people don’t like to see their use cases mapped in these two quadrants…
Once you’ve mapped those, then it is about figuring out the workstreams. The use case categories from your prioritization exercise will help. Within each you might have foundational initiatives (e.g., KPI standardization, data quality improvement, data ownership, etc.) and value-generating use cases (e.g., dashboards, machine learning models, AI tools, etc.). You can list these two tracks separately, but I prefer approaching it from a logical manner; thinking like an engineer, what needs to be done before the other, and how do they flow into each other. This is where the dependency thinking comes to play.
Now that you’ve developed the workstreams, you can start to sequence the action plan. Who is leading each workstream, what are the initiatives/ use cases under each, and what are the next step actions based on the logical plan. For each step or action, you should have an owner (ideally a business and data), dependencies, timing, required process changes, data sources needed, desired outcome, and next steps. Getting these on a page and people aligned to them (especially the owner) is crucial if you want to make this roadmap work.
Other bits you should think about, which I won’t go into are:
Delivery model
Executive sponsorship
Forums and checkpoints
Escalation points
Investment/ business case
Metrics & ROI calculations
Realistically, this all falls into change management and delivery principles, which is a whole other article on its own.
The key things to look for when building a roadmap are:
Building it collaboratively – Both the data team and the business teams need to be in the workshops where this is shaped and they need to see themselves in it (both benefits and execution)
Executive ownership – There needs to be visible support from a both data and non-data leaders. They need to have skin in the game, which it is because they are funding it or they are very invested in the use case outcome
Anchor the roadmap in transformational delivery – Everybody hates change management or transformation, but the roadmap needs that type of project management/ governance structure to ensure accountability
Realistic timelines – Choose what needs to get done based on capacity and priority. Don’t be overly optimistic, things will fall through the cracks and the whole execution will follow
Dependencies are defined – A lack of communication between teams usually halts any strategic priorities in data. With stakeholders aligned to different tasks by dependency, it makes it easier to get the right people in the room to make things happen
Clear storyline – An underrated element. After you set the roadmap, you need to sell it in to the exec team (for funding) and to the business (for the execution). Have that concise and impactful story to do that
Keep these six things in mind: when you do them right, that is when a roadmap turns into reality.
Moving From the Data to AI Strategy
So there you have it, my secret sauce. I’ve billed hundreds of thousands of dollars in Data Strategy work, and now you have my standard approach for free.
That said, building one of these is not easy. It takes a lot of coordination, stakeholder management, and getting buy-in from across teams. It also requires commitment and ownership from people who are already extremely busy. Finally, you have to string it all together, which few organizations do well.
If you ever need help with that, just give me a ring.
Well, now that we’ve gone through the Data Strategy, it only fits that we cover off the AI Strategy! And in the past 6 months, this idea has shifted significantly. A year ago, I would have viewed the AI Strategy as an extension of the Data one, done in a similar way. Now, I have different views…
… It has to be a lot more action-oriented and involves re-engineering how the organization works.
… Moreover, AI use cases need to be implemented today, not tomorrow.
… Plus, there is a level of flexibility and agility that needs to be baked into it.
Overall, next week’s article will be focused on an AI Strategy for this brave new world, not a 60-page slide deck of AI use cases and platitudes. Until then, have a great Sunday!
Thanks for the read! Comment below and share the newsletter if you think it’s relevant! Feel free to also follow me on Substack, LinkedIn, and Medium, or reach out if you are looking for some top-notch freelance consulting input! See you amazing folks next week!