Data Thing Part 5: What shall we call the not technical bit?
I have been doing a bunch of stuff on "data thing" since the last post. A bunch of different stuffs, none of which could be described as done. But rather than wait for something to be concluded I thought I'd write up a bit on what's been going on so far:
The online training
I kept on working through Get started with Microsoft Fabric - Training | Microsoft Learn which is very good. It doesn't take as long as advertised, and you can easily pick and choose which bits to complete. I find working through the labs helps me get how I would apply something in my work.
I also took a little detour into Design a semantic model in Power BI - Training | Microsoft Learn
Coming up with a plan
I booked a meeting with my team next Monday to run through:
- What fabric is
- How it's structured
- What it costs
- How we can / will use it
- What we need to do and decide over the next few weeks
- Training needs - for us and the end users
This means I'll have to have some kind of answers to all of those things by next week or I'll look like a fool. Otherwise, I could fart-arse about with tutorials forever.
Some high level stuff
I kept working on my rough outline of a report that would go to board to get approval to spend on the compute licences. My notes always start all fuzzy and scattered and gradually get rewritten and rewritten until they come into focus.
One element of this project I want to focus on is the importance of the strategic / soft skills / conceptual skills. Except none of those words really made sense for what I wanted to say. Throwback to school when my English teacher wrote in my report I had a limited vocabulary, she said it was from reading too much Calvin and Hobbes.
I'd say I default to plain English mode. 😁
Anyway, I decided to ask my chum Claude for help. It's easy to chat to an AI bot about stuff like that where you don't have to worry about sounding like a tit dumping a garbled misspelt question on them. He came up with some options including Holistic which is for sure the one.
The technical stuff and the holistic stuff
For this project to be a success we need more than just technical skills (both in ICT and for our end users). The holistic stuff I have been thinking about currently looks like:
- At the source end we'll have standards and consistent ways of working.
- The way we structure our data lakehouse / warehouse needs to reflect business priorities not business activities. These might often seem like the same thing but there is an important distinction. It's what you need to achieve vs what you are doing.
- At the user end they will have an understanding of how data could and should be used in a way that provides benefit to their service, how to measure impact etc. They are able to focus their work on delivering improvement in line with organisational goals not "stats" projects that evidence and report work done, with no tangible benefit.
- Projects need to be able to pass the "what is the actual point of it?" test
- Users have the tools to identify areas for change and experimentation e.g. identifying decision points that officers can influence, and that require data.
- Users need to be supported to identify outcomes they want / need to influence, define how they will measure change, then work backwards to design reports or whatever they need to make. If this skill isn't in place the whole thing will be a waste. This is way more important than any Power BI or SQL training or knowing how to write DAX and M.
- I don't mean the project won't be able to complete if we don't do this. All the work could still happen, lots of time would be spent and meetings had and dashboards made and everyone would say 👍. But the end result will be largely decorative reporting that doesn't have any real purpose.
- Too many projects focus on just the data side - tables and access to vast amounts of information, dashboards and reporting, and technical skills, without truly considering what it means to be data-driven. That cannot just be left to use end user to figure out - to deliver actual change the whole process needs strong leadership right to the very end. A good data project is no use if it fails at the final stage where the information actually gets used to do something. This is similar to why I am a grump about chat to your documents
- Specific, Measurable Outcomes 🏆
- Outcome = a real change, a way that things will be different, a different state to before, a real impact that is related to organisational goals.
A description of features or usage is an output, not an outcome (e.g. "we will have dashboards", "users can view reports", "people can use data to make decision X" (although this is kind of specific, it's not measurable and it's describing a process, not a result)).
This bit is still in the middle of the scrappy notes phase, so it may make more sense in a later instalment of blog 😵
Other posts with tag "data thing":