Alexis
Hi, everyone. Welcome to another episode of Talk Tech with Data Dave. I am Alexis, your host, and I’m here today with none other than Data Dave. Dave, how are you today?
Data Dave
I’m very well, Alexis. How are you?
Alexis
I’m good. It’s a Friday here on recording day. The day’s almost over. We’re going to record a podcast. It should be a fun end of our week.
Data Dave
Excellent. Yes, I’m excited. Let’s do it.
Alexis
So the question today. I know I say this all the time, but it’s right up your alley. The question I actually think might have been inspired by something you said or, advice from you. So, this is good. Why are data projects so complicated?
And I think it kind of spurred from this idea of data projects fail all the time. They’re very difficult to get going. They’re here, they’re there, they’re everywhere. They’re not just technology projects; they are human projects. They’re change management projects, their data projects, their everything projects. And that is the big picture here. So, that’s what I want to talk about.
Data Dave
I think this is a very short podcast, actually.
Alexis
Did I just answer the question?
Data Dave
I think you’ve just answered the question.
Alexis
Yes. Go Alexis!
Data Dave
To be honest with you.
So, the question you’re asking is why do data projects fail? Or why are data projects particularly troublesome? Or why are they challenging? Why do people have issues with them? Why don’t they always deliver the level of return that people expect them to, especially in the time frame that they want them to?
Alexis
Yes, that’s a great way of putting it.
Data Dave
And I think you are absolutely right. It’s because they turn into essentially everything projects. If we diagnose some technology projects for a minute. Right? Or decompose some technology projects. If we look at an implementation of an application, whether it’s a CRM or an ERP or whatever, customer relationship management or resource planning or whatever it might be, these projects are usually put in place pretty siloed for a defined team. And once you’ve loaded the data, they take on a little bit of a life of their own, but they just move forward. You start using them, and they move on.
Alexis
Hopefully. Yeah.
Data Dave
So, a lot of these projects are, you come in, you do it. Once it’s done, it’s done, and it moves forward. There is some maintenance and some management and some evolution, but once it’s done, it’s done, and it just moves forward.
And they have the data that they have, they own it, they do it, they use it, and they do the job for which they were hired. Let’s use that term. That’s a good term for an application. I’ve hired this application to do a job.
So, the problem with data projects, two things.
A data project is not only a technical implementation, but also, if you think of the data project, think of an MDM or a big data project. The data itself is one of the outcomes.
Well, of course, all the data is a moving target. What data is the content? Is it the data of yesterday or the data of tomorrow? So, I’ve got not only the technology that I’m delivering; I’m also delivering a data set that is based off of something that either exists or will exist.
Okay, does that make sense?
So, there’s another dimension of complexity in that, because the data itself has meaning.
Alexis
Give me an example of that. Help me understand that a little bit more.
Data Dave
I’m doing a data project around “customer”. The output of that is actually the data that describes my customer base.
So, the product is not static. The product isn’t a system. The product is the customer base. And the customer base continues to evolve from yesterday to today to tomorrow.
Alexis
Okay? Okay.
Data Dave
So it’s never finished.
Alexis
Right.
Data Dave
So what does complete look like? What does good look like?
Alexis
Good question.
Data Dave
Right? Unlike saying, I’m going to build a shed and when I’ve got a shed, the shed is finished.
What you’re actually saying is, I’m going to make some grain, and the grain is grain every year, right? I’m going to put it in my shed. How much is in my shed?
Alexis
Well, it keeps changing every day.
Data Dave
It changes every day. So how do you measure good?
Well, is the grain good quality, low quality, whatever?
You’ve got different measures of success which are actually tied up with your business process.
I’m going to use the grain analogy again. My data product is more like a shed full of grain, but the value is not in the shed. The value is in the grain. I don’t want the shed. I only have the shed because I’ve got the grain, and I’ve got to keep the grain dry.
Does that make sense?
Alexis
Yeah.
Data Dave
But the value of the shed is actually tied up with the quality of the grain or the value of the grain, not with the value of the shed. So, often we put in the data product thinking about the shed, and we forget about the grain.
Alexis
But really, the grain is what’s so important.
Data Dave
The grain is what is most important. So, that’s one part of that analogy. It’s the grain that’s important. But we’re measuring the project on the value of the shed.
Alexis
Right.
Data Dave
And we don’t know how to measure the quality of the grain because that isn’t an IT project; that’s a business project.
Alexis
Yeah, that’s a human project.
Data Dave
That’s a human project. That’s a change management project that says, the only person who can tell me how good my grain is, is the baker who’s going to use the flour.
So, that’s a really late indicator for when I built the shed, because I’m building the shed, because I’m an IT guy. So, I’m building my shed, and it’s a great shed. It’s a great shed. Fabulous shed. I love my shed. But I don’t know how good my shed is until the baker has picked up the grain and made a loaf of bread. And is the grain any good?
But that’s not necessarily dependent upon the shed. The shed can make it bad. And if my shed leaks, then it makes the grain bad.
But if the grain was bad when it came into the shed, the shed’s not going to make any better.
So why do data projects often fail? Why are they challenging? Because there’s this dimension of the contents of the data, the contents of the project that can’t be measured until it’s a much later indicator. And it often can’t be measured until after the shed project is finished.
So, I’ve built my shed, I sent all the contractors home, and then my baker says my grain is no good.
Who fixes it?
Alexis
Yeah.
Data Dave
How does it get fixed?
Alexis
That’s the perfect question.
Data Dave
Is the shed to blame?
Alexis
Yeah. What did they do to the shed to make the grain bad?
Data Dave
Or was it the guy who drove the combine harvester that picked up the grain that put it in the shed?
I’m stretching my analogy a little bit, but you get the picture.
So, that’s why with data projects, we find it beneficial to look at them as a change management project and de-emphasize the shed.
We’re technologists. We always want to solve everything with technology. But a data project, while it is a technical project…
Alexis
It has to be a business project first. It has to be a human project first.
Data Dave
Exactly. It must be a human project first.
Alexis
Yeah.
Data Dave
And you must be ready to measure it as a business transformation project rather than a technical project.
Now, the technical indicators can be pointers towards success, if that makes sense.
Alexis
Those are going to have to be your early indicators. I don’t know what other early indicators you’re going to have.
Data Dave
There are early indicators. Data quality coming out of applications. Data quality of what is going into my shed is a good indicator as well. Measure it as it comes in, measure it as it goes out, and measure the quality of the shed. Does my shed leak? Does it have a good front door? Can I lock it? Can people get in and steal stuff? All of those are good indicators that my shed isn’t going to be part of the problem.
But that doesn’t mean the shed is the solution. If you’ve got bad grain, you have to do more work. You have to change the way you manage your field. You have to clean the trailer that you put the grain in. There’s all these other things that might impact the quality of the grain before it gets to the shed.
Alexis
Yeah, well, that’s a perfect wrap-up there. Dave, thank you for answering that question for me today. I appreciate it. I appreciate everyone joining us for another episode of Talk Tech with Data Dave. If you have a question for Data Dave, please reach out to us by sending us an email at talktech@d3clarity.com or you can reach out to Dave or myself on LinkedIn.
Dave, it has been a pleasure podcasting with you today, and I hope you have a great one.
Data Dave
Yep, thank you. Thank you, Alexis. Always a pleasure.
