Most institutions have one: the person who became the Power BI expert by accident.
They were good at Excel, which in most teams is enough to get you volunteered for anything involving data. Someone needed a dashboard, they had a go, and it worked. Then they had a go at another one, and that worked too. Fast forward a couple of years and a meaningful chunk of your reporting now runs through one person, a set of files only they fully understand, and a quiet collective hope that they don’t hand in their notice or take a fortnight in Spain during returns season.
I don’t say this to knock them. Usually they are among the most capable, most willing people in the building, and they taught themselves a genuinely difficult tool because someone had to. The problem isn’t the person. It’s how they got there, and what nobody checked along the way.
Power BI, and tools like it, have done something quietly remarkable. They have made it possible for almost anyone to produce professional-looking data visualisations without writing a line of code or waiting six weeks for the central team. Drag a few fields around, pick a chart type, choose a colour scheme, and within the hour you have something that looks every bit as polished as the output of a proper analytics function.
That accessibility is a real gain. It is also exactly where the trouble starts.
Because producing a chart that looks right and producing a chart that is right are two completely different skills, and only one of them is obvious. The tool will cheerfully let you build something confident and wrong. It will not stop you joining two tables incorrectly so your student numbers silently double. It will not warn you that the measure you have written is averaging an average, or that your totals quietly stopped reconciling three refreshes ago. It shows you a clean, convincing number either way. The polish is free. The correctness is not, and it is the part that rarely gets taught when someone picks the tool up on the job.
In a lot of settings you can get away with this for a while. A slightly wrong figure on an internal slide is not the end of the world.
Our sector is not most settings. The same tools that produce the departmental dashboard also produce the numbers that feed NSS analysis, access and participation monitoring, board papers, and the figures sitting behind a HESA return or an OfS metric. When a number is going to be submitted to a regulator, or used to decide where the money goes, or quoted in a governance meeting as evidence that something is or isn’t working, “it looks about right” is not a standard anyone should be comfortable with.
And there is a slower, quieter cost too. When a team can’t quite trust its own dashboards, when two reports give different answers to the same question and nobody can say which is correct, people stop using them. They drift back to the spreadsheet they built themselves, the one they trust because they know exactly what’s in it. You end up with the worst of both worlds: an expensive analytics tool nobody quite believes, and a scattering of private spreadsheets that don’t agree with each other or with the dashboard. The technology was meant to give you a single version of the truth. Instead it has quietly added a few more.
None of this is an argument against Power BI. It is genuinely good, and the accessibility that causes the problem is also what makes it valuable. The argument is against treating the skill as something people should simply absorb on their own, in the gaps between their actual job, and hoping it comes out reliable.
The bit that makes the difference is almost never the visuals. It is the unglamorous foundation underneath: how the data is modelled, how tables relate to one another, the difference between a calculated column and a measure and when to reach for which, how to write a calculation that still behaves when the data changes next month. That is the part self-teaching tends to skip, because it isn’t the part that produces an immediate, satisfying chart. It is also the part that decides whether the chart is telling you the truth.
Which is really a case for treating this as a proper skill, learned properly, rather than a happy accident you hope keeps happening. Whether that is structured training, or time set aside for the person who has been quietly holding it all together to actually learn the foundations, or bringing someone in to build things right the first time, the point is the same: make your reporting a deliberate capability, not a single point of failure with good intentions.
It is why we run Power BI training through Sparkline Academy, pitched from beginner to intermediate and built around the kind of reporting HE and FE actually have to produce, rather than generic business examples. But the training matters far less than the mindset behind it, which is simply this. The number on the dashboard is going to be believed, and acted on, by people who weren’t in the room when it was built. It is worth being sure it deserves to be.