"We want to be data-driven". Where are you today?
READ TIME - 4 minutes ⏳
Email formatting looks broken? click here to view in browser.
"We want to be data-driven."
I have heard that sentence in almost every organisation I have worked with, and I have started answering it with a question. Where are you today? Not where do you want to be. Where are you right now, on the path to being data-driven.
The answer is almost always silence. Not because the people in the room lack intelligence, but because they have no way to answer. Every other discipline has a thermometer.
- Security has NIST.
- Quality has ISO.
- Project delivery has a dozen maturity models.
Data has almost nothing a normal company can pick up and use on a Monday morning. That missing thermometer is the reason most data strategy conversations go in circles.
This is the story of a project where we built the missing thermometer. It did not begin as a strategy project at all. It began as a request for a Power BI template & a .json theme file...
The template that wasn't about templates
The original scope was small and clearly bounded. Build a Power BI template. A theme file, a design system, a set of reusable components. A design deliverable with clean edges.
Then the first pieces landed, and the client came back wanting to extend the scope. Not more design work, but something bigger. They wanted guidance on a five to ten year data vision, periodic advice at executive level, and outside perspective they could not source internally.
That line is the whole lesson of the early phase. When a client asks for a template, they are often describing a symptom. The template was the visible artifact of an invisible problem. Nobody had defined what good looked like, so every report was a negotiation, settled by whoever argued hardest that day. You cannot template your way out of that. The real work sat upstream of the template, in a place nobody had named yet.
The reframing that changed the engagement
The proposal went up to the CEO, and his response contained one line that reshaped everything. I wrote it down word for word.
"Il ne fournit pas la direction. Il nous alimente à une réflexion qui va vous amener à définir la direction."
He does not provide the direction. He feeds a reflection that will lead them to define it themselves.
That is a small sentence with a large consequence. I had positioned myself as the expert with answers, the consultant who hands over a direction. He wanted something different. A sparring partner who builds capability and then leaves. Not consultant leading to a decision, but coaching leading to autonomy.
He described a model that already worked inside their walls, borrowed from how they run cybersecurity. An external expert feeds an internal pilot. The internal pilot drives the steering committee. The committee drives the organisation. The pilot stays the one who proposes, because he is the only one who understands the fit between what the business needs, what the budget allows, and how mature the organisation actually is. The external expert brings material, expertise and teaching. The pilot translates it into their reality.
Then he asked the question that launched the real project. Is there a referential to evaluate this maturity? He pointed straight at the NIST Cybersecurity Framework, which they had already adopted internally and loved. He wanted the data equivalent.
Why there is no NIST for data?
There is a reason he could not simply go and find one.
In security, NIST gives you five functions, categories, subcategories, and a shared vocabulary almost everyone in the field understands. In quality, ISO plays that role. In data, the shelf is not empty exactly. There is DCAM, there is DAMA, there are various maturity models descended from older capability frameworks. They are all interesting, and none of them is something a mid-sized manufacturer in the middle of an SAP migration, with international expansion plans and a two-person BI team, can pick up and use on Monday morning. They are too heavy, too abstract, or too far from the daily reality of the people who would have to run them.
So we made a decision. Rather than force-fit an existing framework, we would build a custom one. We would borrow NIST's structure, which they already knew and trusted, and fill it with data content, which they actually needed. This is the part worth taking away even if you never build one of these yourself. The value of a framework like this is not its content. It is the shared language.
The evidence, before the build
We did not start by writing questions. We started by gathering evidence, because a maturity model that is not grounded in the organisation's own reality is just another consultant slide. Three sources fed it.
First, an audit against six pillars, presented in steering committee and validated by the CEO.
- Organisation and collaboration,
- Data infrastructure,
- Ownership and control,
- Analytical design,
- The decision system,
- and adoption and upskilling.
The findings were honest. The technical foundation was solid, with semantic models rolling out. Almost everything else was informal or missing. No business glossary, no dataset certification, no naming conventions. Requirements were rarely challenged, and the table was still the default answer to every question. Real usage existed in management reviews and one to ones, but there was no process to escalate anything, and usage statistics sat unexploited with no measure of success.
Second, interviews with three actual Power BI key users, and three clear profiles emerged.
There was the operational explorer, a production director who knew exactly what he wanted and knew his data, blocked only by access and structure, not by willingness. His line stuck with me:
"tons of data, and we do not use it".
There was the frustrated ambassador in management accounting, who believed in the tool and understood the adoption problem better than anyone. Her issue was not technical at all. It was convincing colleagues to go and fetch the information themselves instead of asking her for it. The symptom showed up in a single recurring phrase: thank you for your analysis. Management receives the insight, but the users never learn to seek it.
And there was the frustrated expert in quality methods, with deep domain knowledge who could not industrialise anything without depending on one specific colleague. He wanted to run proofs of concept and could not.
Five themes ran through all of it. Adoption is the real problem, because the tools exist but the reflexes do not. The data exists but goes unexploited. Dependency on single individuals creates constant frustration. Trust in the data is not established. And underneath, a set of very concrete unmet needs, from year to date calculations to outlier handling to automated distribution.
Third, and most powerfully, their own numbers. We connected to their Power BI governance data, five years of report metadata, creation and deletion dates only, no business data. The cadence of report creation told a story by itself. Twenty-five reports in 2021, one roughly every two weeks. By 2024, one every week. By 2025, ninety-four reports, one every three working days. And a second signal that mattered even more. Report deletions appeared for the first time in 2025 and accelerated in 2026. For the first time, the teams were not just creating reports, they were managing their lifecycle. Thirty-two were decommissioned.
Read together, those numbers say something the organisation could not see about itself. Production had tripled in pace, and the teams had started, on their own, to prune what no longer served. The organisation was maturing. It simply had no way to see it, measure it, or steer it. No slide I could have made would land the way their own data did.
The build
With the evidence in hand, the referential almost designed itself, because we let their existing habits dictate its form.
The security tracker they already used had a dead simple structure. A domain, a category, and a subcategory phrased as a question. We adopted exactly that. Same columns, same question phrasing, so there's zero learning curve. The data version came out as six domains, the validated pillars, eighteen categories, and fifty-one evaluation questions, every one of them phrased as a plain "is it the case that" question anyone could answer.
Each question is scored from zero to five. Zero means not yet assessed. One is absent, nothing in place. Two is initiated, isolated and informal. Three is in place on a partial scope. Four is generalised across the full scope. Five is piloted, meaning measured, reviewed and continuously improved. On top of the questions sit five maturity levels, from fragmented, to emerging, to structured, to integrated, to optimised.
And here is the improvement the client asked for, which turned out to be the most important edit in the whole project. The first version described the levels but did not say how to move between them. So I added a column. To reach the next level, do these specific things. Adopt a tool and name an internal pilot to leave level one. Stand up governance, a first glossary, a steering committee and formal templates to leave level two. That single column turned a descriptive tool, one that tells you where you are, into an actionable one that tells you what to do next. A thermometer became a map.
The tool nobody needed training for
I built it in Excel. Deliberately. No platform, no licence, no six-month implementation. A tool that requires a project to adopt is a tool that quietly undermines the autonomy the CEO asked for in the first place.
A few of the design decisions are worth stealing. The dropdowns show full labels, not numbers, so a user selects "3 - in place" and a formula quietly extracts the score behind it. Nobody has to memorise what three means. There is exactly one column to fill in each period. Everything else calculates itself: the previous score, the objective pulled from a roadmap sheet, the gap between ambition and reality, and the priority pulled from a MoSCoW sheet. That prioritisation evolves over time, because what is a must-have this quarter can become a should-have next, and explicitly declaring something a will-not-have is a decision rather than an omission. A synthesis sheet ranks the eighteen categories into a top five and a bottom five for any period you select, so the steering committee sees where to look in seconds.
One last principle, which applies far beyond this project. No formatting until the content is validated.
Formatting is the final touch, never the starting point.
What actually changed
The mechanics matter less than the shift they produced. Before, a conversation about data strategy was a contest of opinions, won by the most confident voice in the room. After, there was a score, a trajectory and a shared language.
"Are we good at data" became "we are at level two on ownership, we were at level one last quarter, and here is what level three requires."
That is a completely different conversation, and it is one an organisation can hold with itself, without a consultant in the room!
The first score is the hard one
If you take one thing from this, let it be the uncomfortable part. The hardest moment in the whole exercise is accepting that you are at level two when you believed you were at level four. That gap, the distance between how mature you feel and how mature you are, is the single most useful number the referential produces. Everything good downstream depends on being honest about it.
"We want to be data-driven" is a fine ambition. It is not a plan until you can answer the question that follows it. Where are you today?
Now, before your next strategy meeting, one thing worth sitting with. If someone asked you where your organisation sits today, on a scale you actually trusted, could you answer it out loud? And would the honest answer match the one you have been telling yourself?
Would you like me to audit your organization ? If so, hit the button below and let's talk!
See you in two weeks,
Julien
