From information to insight: Getting more from your data

Most businesses that say they have a data problem do not have one. They have plenty of data. What they have is a disagreement problem: several systems holding different versions of the same fact, and no settled answer about which one wins. No amount of visualisation fixes that.

The dashboard nobody opens

Almost every organisation has one. It was commissioned with enthusiasm, built competently, and is now checked by two people, one of whom built it.

Dashboards fail for a consistent reason: they answer questions nobody was actually asking. They get built from what is easy to measure rather than from what is being argued about in meetings. If a number does not change a decision, presenting it more attractively will not help.

There is a reliable tell for the other failure. If people export the figures into a spreadsheet before deciding anything, or ring somebody to ask for the real number, the problem is not the presentation. They do not trust what is underneath it, and no amount of work on the surface will earn that back.

Decide what a number means before you measure it

Ask three people in a firm what counts as an active client and you will often get three answers. One says anyone billed this quarter. One says anyone with open work. One says anyone who has not formally left.

None of them is wrong. But until you pick one, every report is a negotiation. Definition work is unglamorous, and it is where most of the value in a data project actually sits. It is also the part that cannot be handed to a tool.

One owner per fact

For every fact you care about, one system should own it and everything else should defer to it. The CRM owns the client record, finance owns the invoice value, the delivery system owns the status. Which system it is matters far less than the fact that there is only one.

This is what makes integration tractable. Most integration projects that stall are not stuck on technology. They are stuck because two departments each believe their system is the authoritative one, and nobody has been willing to make the call. Left unmade, that decision has a predictable end: two systems both being corrected by hand, and somebody building a spreadsheet to reconcile them.

Start with the question, not the warehouse

The tempting sequence is to consolidate everything first and work out the questions later. It is expensive, it takes a year, and it usually produces a very tidy repository that still does not answer the thing you wanted to know.

The better sequence is to take one question that genuinely affects a decision, such as which kind of work is actually profitable, where deals stall, which clients take the most effort to serve, or how long a hire really takes, and follow it back through only the data needed to answer it. What does answering it require, where does that live, and which of it can be trusted as it stands? You get something useful in weeks, and the foundations you end up building are the ones you can demonstrate you needed.

The instinct, once data is on the agenda, is to collect more of it. Occasionally that is necessary. More often the answer is already in the building, spread across three systems, defined two ways and awkward to join. Agree the definitions, decide which system owns which fact, and build only what the question needs.

What insight actually looks like

Insight is not a chart. It is a sentence that changes what somebody does on Monday.

“Engagements that start without a scoping call take substantially longer” is insight, because it implies an action. “Revenue by service line” is information. Useful, but not the same thing. When you are deciding what to build, ask what sentence you hope to be able to say at the end of it. If you cannot name that sentence, you are not ready to build yet.