Does the end justify the means, or does the means seek an end? In most IT consolidation programs and data strategies, the answer is clear: the means prevail. The choice of platform is set in stone before anyone has even voiced the underlying problem.
Where does it really hurt in your company?
That question is usually missing from these kinds of initiatives, whether they involve IT consolidation, an AI application, or data-driven work. The issues that bother people in the organization—and that they keep talking about—usually affect the bottom line. That’s where the benefit of “Business First” lies: you naturally focus on the business and data strategy that’s actually needed.
The Wishful Thinking Behind the Little Tool
Buying a tool feels like progress. A contract is signed, a project is given an inspiring name, and a dashboard appears.
The tool only solves the problem you feed into it. Software processes the data you enter and does nothing to address the reason why that data was inaccurate in the first place.
Those who start with technology turn a blind eye to the real problems.
IT consolidation is not a strategy
IT consolidation is the clearest example of this. Systems are merged, processes are standardized, and teams are forced into agile methodologies.
Such a process usually starts with good intentions: a truth, a platform, a process. Along the way, the original question fades from view, and the program itself becomes the goal.
The focus shifts to the operational level: sprints, backlogs, and speed of delivery. The business must adapt to this mode. Product owners plan releases, stakeholders join refinement sessions, and the question of what data matters to the company gets lost amid the question of what will be delivered in this sprint.
Change for the sake of change is costly. The organization ultimately pays twice: first for the consolidation, then for the correction that ultimately proves necessary.
Pain is a signal, not noise
The recurring complaints within an organization are rarely coincidental. A report that’s always inaccurate, a team that manually corrects figures, a process that regularly runs behind schedule—these signals point to wasted time and money.
Pain is the best indicator there is. Follow it, and the question of which data gets priority answers itself.
Prioritizing means being in control
A vendor pushes its own agenda. Anyone who bases their priorities on that agenda relinquishes control.
Initiatives that address pain the organization is already experiencing almost automatically gain support, because no one needs to be convinced that the problem exists. The reverse approach—setting up a project and then looking for a problem to fit it—rarely sells itself so easily.
Focus emerges naturally when you start your business
This naturally leads to prioritization. The data underlying the biggest bottlenecks is also the data that must be addressed first for data-driven work.
That same data contributes most to successful AI applications. It makes sense: AI doesn’t feel the pain. We do.
Reversing that order has been counterproductive for years. Building an application around a tool rather than a problem does not contribute to reliable data.
From Pain to Priority
A comprehensive approach starts with a concrete question: Which problem impacts the bottom line the most, and what data underlies it?
That requires conversations with the people who feel the pain every day, and a willingness to draw consequences from it. Purchasing a tool is more tempting. Just like saying “yes” to the big consultants’ flashy slide deck. Those options profit primarily from the tool itself.
The “Business First” approach takes a little longer to get started, but more than makes up for it during implementation. Architects have known this for decades: time invested in the design phase pays off during execution.
Executives who take their business and data strategy seriously start with the business: where are the pain points, what do they cost, and what data is needed to address them. The form—whether that’s IT consolidation, AI, or something else—follows naturally.
At MAD-Quality, we call this “Business First,” the foundation of our Go-Mad approach: first the problem, then the strategy, and only then the form.
Data doesn’t have to be perfect. It just has to be adequate.
Want to learn more about data quality? Follow Ruud on LinkedIn for updates on data. Be sure to check out our other blogs on MAD-Quality.
