There’s a pattern we see all the time. An organisation invests in an AI initiative, the pilots look promising, and then it quietly stalls. The results are inconsistent. The model behaves unexpectedly. The business case falls apart. People blame the technology, but in our experience, the technology is rarely the problem.

The problem is the data underneath it.

The Numbers Are Hard to Ignore

Gartner predicts that through 2026, 60% of AI projects unsupported by AI-ready data will be abandoned. A RAND Corporation study found that over 80% of AI projects fail altogether, roughly twice the failure rate of standard IT projects.

And the trend is accelerating. In 2024, just 19% of organisations said data quality was a top challenge. By 2025, that number had jumped to 44%. As AI adoption has grown, so has the reckoning with the data problems that were always lurking beneath the surface.

What “AI-Ready Data” Actually Means

When people talk about AI-ready data, they don’t mean perfect data (no one has that). They mean data that is consistent: the same thing recorded the same way, across systems and over time. Accessible: it can be found, joined, and used without heroic effort from your data team. And trusted: the people using it believe in it enough to make decisions from it.

A lot of organisations have data that falls short on all three. Duplicates, gaps, conflicting definitions, siloed systems that don’t talk to each other. These aren’t new problems, but AI amplifies them dramatically. A model trained on bad data doesn’t just give bad answers. It gives confidently wrong answers.

Why Good AI Models Go Wrong

We’ve helped clients debug AI outputs that looked plausible but were systematically off. In almost every case, the culprit wasn’t the model. It was something upstream: a field that meant different things in different systems, historical data that captured an old process no longer in use, or key information simply missing.

AI learns from patterns. If your historical data reflects broken processes, your AI will faithfully replicate those broken processes at scale. That’s not a technology problem. That’s a data governance problem.

Where to Start

You don’t need to boil the ocean before you can benefit from AI. What you do need is a clear-eyed view of your data and a willingness to fix the foundations in parallel with your AI ambitions. Here’s a practical starting point:

Map your critical data domains. For the use case you’re targeting with AI, identify what data it needs. Where does that data live? Who owns it? How is it collected?

Assess quality honestly. Run some simple profiling: How complete is it? Are there duplicates? Do values make sense? You may be surprised what you find.

Fix governance, not just data. Often it’s not the data itself that’s broken, it’s the process for creating and maintaining it. Fixing that process has lasting value far beyond any single AI project.

Build incrementally. Start with a narrow AI use case where the data is relatively clean. Get a win, learn what worked, and build from there.

The Competitive Advantage Nobody Talks About

Here’s the flip side. Organisations that have invested in data quality and governance are now pulling ahead quickly. They can deploy AI faster, trust the outputs more, and scale without the rework that’s slowing their competitors down. That investment doesn’t make headlines, but it makes all the difference.

We work with organisations across a range of industries who are at various stages of this journey. Some are just starting to audit their data. Others are deploying AI at scale having done the groundwork. The pattern is consistent: the groundwork matters.

If you’re finding that your AI ambitions keep running into data problems, we’d love to have a conversation.

The IT team wants to move. The CTO has the roadmap. But in the boardroom, the mood is cautious. If that sounds familiar, you’re not alone. In our experience, the board isn’t saying no to the cloud. They’re saying: “Show us this won’t go wrong.”

That’s a fair ask, and one worth answering properly.

Why Boards Are Right to Ask Hard Questions

Cloud migration carries real risk if it’s rushed. Research from Flexera shows 84% of organisations struggle to manage cloud spend, and nearly 40% of enterprises waste more than 30% of what they invest in cloud infrastructure. Cost overruns, data security incidents, compliance gaps: these are the kinds of stories that end up in board minutes.

A cautious board isn’t obstructing progress. They’re doing their job.

What “Risk” Actually Means in This Context

When board members raise concerns about cloud migration, they typically circle around a few core issues: data sovereignty, regulatory compliance, vendor dependency, and the fear of runaway costs.

These aren’t unreasonable. Financial services firms worry about GDPR and data residency. Healthcare organisations want to know who has access to sensitive records. Manufacturers with legacy systems wonder whether anything will still work after the switch.

The good news is that each of these concerns has a practical answer. The less good news is that those answers require genuine homework, not a slide deck full of reassurances.

Start Small: The Case for a Phased Approach

One of the most effective things we’ve seen is what might be called a “low-stakes first” approach. Rather than a big-bang migration, you begin by moving a workload that’s important enough to be meaningful, but not so critical that failure would be catastrophic.

This does two things. First, it builds institutional confidence. When the board can see a real system running well in the cloud, the conversation shifts from hypothetical risk to demonstrated capability. Second, it surfaces the real complications early, before they become expensive.

We’ve helped clients take this phased approach and it consistently reduces both the technical risk and the boardroom anxiety.

Security and Compliance: The Honest Version

Here’s something worth saying plainly: cloud environments, when properly configured, can be more secure than most on-premise setups. The major cloud providers invest more in security infrastructure than almost any individual organisation can match.

The risk isn’t the cloud itself. It’s misconfiguration, inadequate access controls, or moving sensitive data without a proper classification exercise first.

For regulated industries, the key is understanding exactly where your data will live and ensuring your chosen provider meets the relevant compliance standards, whether that’s ISO 27001, GDPR, or sector-specific frameworks. This isn’t glamorous work, but it’s the work that turns a board’s “we’re not sure” into “we’re satisfied.”

Making the Business Case They’ll Actually Trust

Boards don’t respond well to technology-first arguments. They respond to numbers: cost reduction, risk reduction, competitive positioning.

Cloud migration, done right, can reduce infrastructure costs, improve system resilience, and make it far easier to scale when business demand increases. But these benefits need to be quantified honestly, based on your actual workloads and current costs, not vendor benchmarks.

It also helps to be transparent about what won’t go smoothly. Every migration has surprises. Boards that were told to expect challenges tend to trust the team more when those challenges arise, rather than feeling misled.

If this sounds like the conversation you’re navigating, we’d love to chat.

There’s a lot to like about automation in public services. Faster processing, reduced backlogs, lower costs, more consistent outcomes. These aren’t abstract promises. Local councils have used automated triage to cut waiting times on housing queries. Benefits agencies have streamlined routine eligibility checks to free up staff for more complex cases. The efficiency gains are real.

But so are the stakes.

When automation makes decisions that affect people’s access to housing, healthcare, welfare, or education, the ethical responsibilities are enormous. And, as a number of high-profile cases globally have shown, getting it wrong can cause serious harm to the people who can least afford it.

The Bias Problem Nobody Likes to Talk About

Automated systems learn from data, and data reflects the world as it has been, not necessarily as it should be. If historical decisions were discriminatory, an algorithm trained on that data will likely reproduce those patterns at scale, and much faster than any human could.

Research has consistently shown that automated decision-making systems in public services can disadvantage people from lower-income backgrounds, ethnic minorities, and those with complex circumstances. AI fraud-detection tools used in welfare systems have flagged disproportionate numbers of legitimate claimants. Predictive policing tools have raised serious questions about racial bias. The problem isn’t the technology itself. It’s deploying it without properly understanding what it has learned, and who it might harm.

The Transparency Gap

One of the most pressing questions in public sector automation is deceptively simple: can citizens understand the decisions being made about them?

In many cases, the answer is no. “Black box” systems, where even the operators can’t fully explain why a particular outcome was reached, are deeply problematic in public services. People have a right to know why a benefit was denied or why they’ve been flagged as a risk. Regulation is catching up: the EU AI Act and the UK’s Algorithmic Transparency Recording Standard are both important steps, but implementation is still uneven.

Transparency isn’t just a legal obligation. It’s a practical safeguard. When decision logic can be audited and explained, errors get caught. When it can’t, they compound quietly.

Keeping Humans in the Loop

Automation should never fully replace human judgement in high-stakes public sector decisions. That’s not a rejection of technology. It’s a recognition of what technology is and isn’t good at.

Machines excel at processing large volumes of structured data consistently. They’re not well-suited to understanding context, nuance, or the full complexity of someone’s circumstances. A person applying for disability support isn’t a data point. Neither is someone appealing a school placement or contesting a benefits decision.

The best practice we see emerging is using automation to assist human decision-makers, not to replace them. Flag the cases that need attention. Streamline paperwork. Surface relevant information quickly. But keep qualified people accountable for the final call where it significantly affects someone’s life.

What Getting It Right Looks Like

The organisations doing this well tend to share a few things in common. They document the purpose and limitations of every automated system they deploy. They run regular audits for bias and accuracy. They make appeals processes clear and accessible. And they invest in training so that staff understand what the system is doing and can challenge it when something doesn’t look right.

None of this is technically complicated. It’s mostly about governance, discipline, and a genuine commitment to treating the people these systems serve with respect.

We work with public and private sector organisations to build data and analytics capabilities that are both effective and responsible. In our experience, the organisations that approach automation thoughtfully, asking the hard questions before deployment rather than after something goes wrong, are the ones that earn lasting trust.

If you’re thinking through how to introduce automation ethically in your organisation, we’d love to have that conversation.

Most organisations we speak with have spent significant time and money implementing IBM Maximo and Oracle ERP. And yet, when we dig into how those systems are actually being used, the same pattern emerges: mountains of data, precious little insight.

The Expensive Filing Cabinet Problem

Maximo and Oracle are typically deployed to manage compliance, track assets, and keep the finance team happy. They do those jobs well. But they’re rarely used as strategic tools, sources of intelligence that can genuinely shape business decisions. Most organisations are using a fraction of what’s available to them.

We see this constantly with our clients. The data to answer their most pressing operational questions is already sitting in these systems. It just hasn’t been connected, cleaned, or surfaced in a way that makes it useful.

What’s Really Sitting in These Systems

Think about what Maximo holds: years of asset performance data, maintenance history, work order patterns, failure records, and parts consumption. Oracle, meanwhile, holds the financial picture: costs, procurement trends, supplier performance, and budget actuals. Together, these systems tell a rich story about where money is being lost and where operational risk is hiding.

According to McKinsey, organisations that properly leverage digital work order management can reduce planned downtime costs by 15-30%. IBM research shows that companies achieving full integration of asset management and financial data can reduce total maintenance spend by up to 28%. That’s not marginal improvement. That’s a meaningful shift in operational economics.

A Well-Timed Opportunity

IBM and Oracle recently announced an expanded partnership, including a new connector between Oracle Fusion Cloud ERP and the IBM Maximo Application Suite. This integration allows organisations to use built-in AI and analytics across finance, procurement, assets, and facilities in a joined-up way. It’s a signal that the market is moving, and a good prompt to ask whether you’re getting full value from what you already have.

Where We See the Biggest Wins

In our experience, there are three areas where unlocking Maximo and Oracle data delivers fast, visible returns:

Predictive maintenance: Rather than running scheduled maintenance on a calendar, organisations can use Maximo’s asset data to predict failures before they happen. Industry research suggests this approach can reduce unplanned downtime by 23-37%, which, depending on the operation, can be worth millions.

Spend and procurement intelligence: Oracle holds the financial story of your asset base. Connecting that to Maximo’s operational picture often reveals patterns not visible from either system alone: duplicate supplier relationships, inefficient parts procurement, or spend categories that look fine on a ledger but are masking operational waste.

Asset investment planning: Knowing when to repair versus replace is one of the most consequential decisions in asset-heavy industries. With the right data, that decision can be made on evidence rather than gut feel.

You Don’t Need a Transformation Programme

One thing we’re always clear about with clients: you don’t need a massive, multi-year project to start getting value from what you already have. The better approach is to pick one high-value question, such as “why is our maintenance spend rising?” or “which assets are costing us disproportionately?”, and use that as the lens to unlock the data already in Maximo and Oracle.

Start small, show the value, and build from there. In our experience, the first insight often pays for the whole programme.

If you’re running Maximo or Oracle and wondering whether you’re getting full value from the investment, we’d love to have that conversation.

If you work in financial services, healthcare, insurance, or the public sector, you’ve probably watched the AI conversation from a cautious distance. The benefits are obvious. But so are the risks: client data, regulatory obligations, GDPR, and a legal team that asks a lot of hard questions.

That hesitation is understandable. But we’re seeing more and more regulated organisations move past it, and Azure OpenAI is often the reason why.

What Makes Azure OpenAI Different

Azure OpenAI gives you access to the same powerful models as public ChatGPT, including GPT-4o and others from OpenAI’s family. The critical difference is where and how those models run.

With Azure OpenAI, your data stays in your chosen Azure region. Microsoft doesn’t use your prompts or outputs to train or improve their models. That’s a contractual guarantee, not just a privacy policy. For organisations dealing with sensitive client data, that distinction matters enormously.

You also get the compliance certifications that regulated industries rely on: ISO 27001, SOC 2, GDPR alignment, and more. Azure holds over 100 compliance certifications globally, covering financial services regulators, healthcare standards, and data protection frameworks across the EU and UK.

The Data Residency Question

One of the first questions we hear from clients in regulated sectors is: “Where does our data actually go?”

It’s the right question. With public AI tools, the honest answer is often unclear. Data may be processed in multiple regions, retained for varying periods, or used to improve future models.

Azure OpenAI is different. You choose your region (such as UK South or West Europe), and your data is processed and stored there. Microsoft offers zero data retention options for high-sensitivity use cases, meaning prompts and responses aren’t logged at all after processing. That’s the kind of control that lets a legal or compliance team say yes.

What You Can Actually Do With It

The use cases for regulated organisations are broader than most people realise. We’ve helped clients use Azure OpenAI to:

• Summarise lengthy regulatory documents and flag relevant changes
• Draft client communications in a consistent, compliant tone
• Extract and structure information from unstructured documents such as contracts, forms, and emails
• Build internal knowledge assistants that answer staff questions using approved company content

None of this involves feeding client data to a public model. Everything runs within a controlled, auditable environment.

The Governance Layer

Azure OpenAI doesn’t just provide the model; it wraps it in enterprise-grade governance. You can apply content filters, set usage policies, and connect it to your existing identity and access management through Azure Active Directory. Every API call is logged. You have full audit trails.

That’s not just reassuring for regulators. It’s what good AI governance looks like in practice.

Getting Started Doesn’t Have to Be Complex

A common misconception is that deploying Azure OpenAI is a major IT project. It doesn’t have to be. Many organisations start small, perhaps automating one internal process or building a pilot tool for a specific team, and expand from there once the value is clear and the governance model is established.

In our experience, the organisations that get the most from Azure OpenAI are those that start with a clear business problem rather than a technology goal. The question isn’t “how do we use AI?” It’s “where are we spending time on tasks that AI could handle safely?”

A Word on Responsibility

AI in regulated industries comes with real responsibilities. Azure OpenAI helps you meet the technical and legal requirements, but it doesn’t replace good judgement. Outputs should be reviewed, models should be monitored, and governance frameworks should be in place before you scale.

We believe that done properly, AI in regulated organisations doesn’t increase risk. It reduces it: fewer manual errors, better consistency, and more time for people to focus on complex decisions that genuinely need a human.

If you’re in a regulated sector and wondering whether AI can work within your constraints, the short answer is yes. It’s worth a conversation.

If this sounds like familiar territory, we’d love to chat.

Most organisations we work with have more data than they know what to do with. The tricky part isn’t usually collecting it. It’s knowing what they already have, where it lives, who owns it, and whether any of it can actually be trusted. That’s what data estate blueprinting is about, and it’s one of the most valuable things a business can do before investing in AI, analytics, or any kind of digital transformation.

What Is a Data Estate, Exactly?

Your data estate is the full picture of everything your organisation holds in terms of data: the systems that generate it, the places it’s stored, the tools that process it, and the people responsible for it. That might include a CRM, a data warehouse, spreadsheets on shared drives, cloud platforms, third-party data feeds, and everything in between.

A data estate blueprint is simply a structured map of all of this. Think of it as a floor plan for your data. Just as you wouldn’t renovate a building without understanding its layout, you shouldn’t build data products or AI models without understanding what data you’re working with.

Why Most Organisations Skip This Step

Blueprinting isn’t glamorous. It doesn’t come with a slick demo or a flashy dashboard. So it often gets deprioritised in favour of shinier projects. In our experience, this is one of the most common reasons analytics initiatives stall. Teams spend months building models on data they don’t fully understand, only to find the outputs can’t be trusted or can’t be explained to stakeholders.

We see this regularly with clients who’ve invested heavily in technology but haven’t taken stock of what data they actually have. The tools are there, but the foundation isn’t solid.

The Four Things a Good Blueprint Covers

When we help clients map their data estate, we focus on four areas:

Sources: Where does your data come from? This includes internal systems, external providers, manual inputs, and automated feeds. Many organisations are surprised by how many sources exist when they actually count them.

Storage: Where does data live once it’s collected? On-premise servers, cloud storage, SaaS platforms, local machines? Understanding the landscape here is critical for both governance and cost management.

Ownership and accountability: Who is responsible for each data set? Without clear ownership, quality tends to drift. Someone needs to be accountable for whether the data is accurate, up to date, and fit for purpose.

Quality and lineage: How reliable is the data, and where has it come from? Can you trace a figure in a report back to its original source? If you can’t, your data probably can’t support the kind of decisions you want to make.

Start with Business Questions, Not Technology

A common mistake is approaching this as a pure IT exercise. Data estate blueprinting should be driven by business questions: What decisions do we need to make? What do we wish we knew? Where are we flying blind?

Once you know what you’re trying to achieve, you can map backwards to the data that matters most. That keeps the process focused and avoids the trap of cataloguing everything for its own sake, which quickly becomes an expensive, never-ending project.

Why This Matters Even More Now

With so many organisations exploring AI, the pressure to understand your data has never been higher. AI models are only as good as the data they’re trained on. If you don’t know what’s in your data estate, you can’t responsibly build on top of it. Blueprinting isn’t just a governance exercise; it’s the foundation for everything that comes next.

Beyond AI, there are very real compliance and cost implications. Holding data you don’t know about creates risk. Storing data in the wrong places drives unnecessary cost. A clear blueprint helps you make smarter decisions about what to keep, what to retire, and what to invest in.

Where to Begin

You don’t need to map your entire estate in one go. Start with the data that matters most to your key business decisions. Pick one or two domains, like customer data or operational reporting, and build from there. A pragmatic, iterative approach almost always beats a big-bang programme that runs out of steam before it delivers value.

If this is something your team is wrestling with, we’d love to have a conversation. We’ve helped a number of organisations get clarity on what they have and build a practical path forward.

There’s a tempting belief in the data world: if your AI model isn’t working as well as you’d hoped, you just need a smarter algorithm. Train longer. Add more layers. Try the latest architecture from the research papers.

In our experience, that’s almost never the real problem.

We’ve worked with a lot of organisations on data and AI projects, and the pattern we see again and again is this: the algorithm is fine. What’s failing is everything around it. The plumbing, the structure, the way the system is put together. In short, the architecture.

The Uncomfortable Truth About AI Failure Rates

A 2023 survey by Rexer Analytics found that only 32% of machine learning projects actually make it to production. That’s a sobering number when you consider the time, budget, and enthusiasm poured into these initiatives.

The reasons? They’re rarely about the model itself. They’re about data pipelines that break silently, deployment environments that look nothing like the training environment, monitoring that doesn’t exist, and teams that built a great notebook but couldn’t turn it into a reliable product.

Google’s AI research team famously published a diagram showing how ML code typically represents a tiny sliver of a real production system. The vast majority is infrastructure: data validation, serving systems, monitoring, configuration, and process management. Clever algorithms without solid architecture around them don’t survive contact with reality.

What “Clean Architecture” Actually Means in Practice

We’re not talking about abstract software theory here. Clean architecture, in practical terms, means building AI systems that are modular, maintainable, and observable.

It means separating your business logic from your data pipelines from your model serving. It means having monitoring in place from day one, not bolted on afterwards. It means your model can be retrained, swapped, or updated without the whole system collapsing. And it means the people who eventually own and maintain the system can actually understand what’s going on.

When these things are in place, AI projects tend to work. When they’re not, even the most sophisticated model will underperform or fail entirely.

The Silent Failure Problem

One of the trickiest aspects of poorly architected AI systems is what practitioners call “silent failure.” Unlike a traditional application that crashes and throws an error, a poorly monitored model just starts giving worse predictions over time. Nobody notices until the damage is done.

This happens because the world changes. Customer behaviour shifts. Data sources evolve. A fraud detection model trained two years ago is looking at a very different landscape today. Without proper monitoring baked into the architecture, drift goes undetected until someone complains.

We see this with clients who’ve built technically impressive models but have no systematic way of knowing when those models stop being accurate. The fix isn’t a better algorithm. It’s building the observability infrastructure that should have been there from the start.

Starting Simple, Building Solid

A principle we return to often: build end-to-end early, and start simpler than you think you need to.

We’ve seen projects spend months perfecting a model in isolation, only to discover that integrating it into the real system surfaces a dozen new problems. Getting a basic version into production quickly, even if it’s not yet optimised, forces you to confront architectural challenges before they become expensive.

Once you have a working end-to-end system, you can iterate and improve. The architecture gives you a stable foundation to build on. Without it, you’re optimising in a vacuum.

Where This Leaves AI Strategy

For business leaders investing in AI, this has a practical implication: don’t evaluate your data science team by how sophisticated their algorithms are. Evaluate them by how reliably their systems perform in production, how quickly they can iterate, and how well the solution holds up six months after launch.

A well-architected system with a straightforward model will almost always outperform a brilliantly complex model sitting on shaky foundations.

This is something we think about a lot when we’re helping clients build out their AI capabilities. The goal isn’t to build the cleverest thing in the room. It’s to build something that works, keeps working, and can grow with the business.

If your AI projects aren’t delivering the results you expected, there’s a good chance the answer lies in the architecture rather than the algorithm. We’d love to chat about what that might look like for your organisation.

The dashboard looks beautiful. Green arrows, rising lines, a satisfying row of KPIs glowing on the screen. Leadership sees it, nods approvingly, and moves on. But six months later, sales are down, customers are leaving, and someone quietly asks: “Were we even looking at the right numbers?”

This happens more than most organisations care to admit. Dashboards can mislead without anyone intending them to. Not through fraud or bad faith, but through a combination of poor design, weak data foundations, and measuring what’s easy rather than what matters. We’ve seen it with clients across industries, and it’s one of the most costly blind spots in analytics today.

Measuring Activity Instead of Outcomes

One of the most common traps is filling dashboards with activity metrics. Calls made. Emails sent. Reports generated. These numbers are easy to count, so they end up front and centre. But activity doesn’t equal progress.

A sales team can be incredibly busy and still miss every meaningful target. A marketing team can send thousands of emails to the wrong audience. When dashboards reward activity, people optimise for activity. The real question, “Are we moving the business forward?”, goes unanswered.

Numbers Without Context

A metric on its own tells you very little. Conversion rate up 15% sounds like cause for celebration. But compared to what? Last month? Last year? The industry average? If your conversion rate rose while your competitor’s doubled, you may actually be falling behind.

Context transforms data into insight. Without it, dashboards show you a number and let you fill in the story yourself. And people tend to fill in the story they want to hear. We often help clients layer in benchmarks, trends, and targets, not because the raw data is wrong, but because data without context is easy to misread.

The Problem Starts Upstream

A dashboard is only as honest as the data feeding it. If records are incomplete, duplicated, or entered inconsistently at source, your charts will faithfully visualise a lie. This is especially common in organisations that have grown quickly or merged systems over the years.

We’ve worked with businesses whose customer counts were significantly inflated because the same person appeared in the system multiple times under slightly different names. Their dashboard said one thing. Reality said another. No amount of clever visualisation fixes a data quality problem. It has to be addressed at the root.

When Design Misleads

Sometimes the dashboard data is fine, but the design creates a false impression. A bar chart that doesn’t start at zero makes a small change look dramatic. A line graph covering only three months can look like a long-term trend. Colour choices that use red and green without explanation can imply danger or safety where none exists.

None of this is usually intentional. Analysts build what they’re asked for, stakeholders get used to seeing it a certain way, and nobody questions whether the visual is actually accurate. A good dashboard design should make the truth obvious, not require careful reading to uncover it.

Building Dashboards You Can Trust

The fix isn’t to abandon dashboards. They’re genuinely useful when built with care. The key is to start with the question, not the data. What decision does this dashboard need to support? What would it look like if things were going well, and what would it look like if they weren’t?

From there, you work backwards to the right metrics, ensure the underlying data is clean and consistent, and design visualisations that reflect reality plainly. In our experience, the best dashboards show fewer things, more clearly, with enough context to act on.

If you’ve got dashboards that look impressive but don’t quite get used, or that your team has quietly stopped trusting, that’s usually a signal worth investigating. We’d love to have that conversation.

Most businesses we speak to know their data stack needs work. Reports take too long. Analysts spend more time wrangling spreadsheets than finding insights. The warehouse hasn’t been touched in years. And whenever someone suggests a proper overhaul, the conversation quietly dies because it feels too big, too risky, and too disruptive.

The good news? You don’t need a multi-year transformation programme to make real progress. In our experience, a focused 90-day plan can unlock genuine value, build momentum, and set you up for sustainable modernisation, without grinding the business to a halt.

Here’s how we think about it.

Days 1 to 30: Understand What You Actually Have

The biggest mistake organisations make is jumping straight into solutions before they understand the problem. The first month is all about honest assessment.

Map your current data flows: where data comes in, where it lives, where it goes, and where it gets stuck. Talk to the people who use the data every day, not just IT. They’ll tell you what’s really broken. A data scientist who spends three hours every Monday manually reconciling two reports is your canary in the coal mine.

During this phase, document your pain points and, crucially, quantify them. How many analyst hours are lost to manual prep each week? How long does it take to answer a straightforward business question? These numbers will become your baseline for measuring success later, and your business case for investment.

Don’t try to fix anything yet. Just listen, map, and understand.

Days 31 to 60: Pick One Thing and Prove the Value

With a clear picture of your landscape, choose one high-impact area to modernise first. Not everything, not even the most complex problem. Pick something where the pain is real, the scope is manageable, and a quick win is visible to stakeholders.

That might be moving a creaking on-premise data warehouse to a cloud platform. It might be replacing a fragile, manually-maintained pipeline with something automated and reliable. It might simply be getting a clean, trusted data model in place for one business function.

Run this as a focused pilot. Set clear success criteria upfront. Is it faster reporting? Fewer errors? Analyst time saved? Build it, validate it, and measure it against your baseline. By the end of this phase, you should have something tangible to show, something that makes people think “why didn’t we do this sooner?”

We’ve helped clients navigate exactly this kind of pilot, and the reaction from business stakeholders is almost always the same: the results speak for themselves far more persuasively than any slide deck.

Days 61 to 90: Build the Roadmap for What Comes Next

A successful pilot changes the conversation entirely. It shifts modernisation from “a nice idea we’ll get to eventually” into something the business actively wants. Use that momentum.

In the final phase, take stock of what you learned. What worked? What surprised you? What dependencies appeared that weren’t visible at the start? Use these insights to design a realistic, prioritised roadmap for the next 12 to 18 months.

This isn’t about planning everything in detail. It’s about knowing which problems to tackle next, in what order, and roughly what it will take. Think of it as a living plan that you’ll refine as you go, not a rigid blueprint.

One thing we’d emphasise: keep the roadmap business-led, not IT-led. Every initiative should connect clearly to an outcome the business measures and cares about.

A Few Things to Keep in Mind

The temptation with data modernisation is always to go too big too fast. Ripping out everything and replacing it wholesale is high-risk, high-cost, and almost always takes longer than anyone expects. The incremental approach, done well, is less glamorous but far more likely to deliver lasting results.

Equally, don’t let perfect be the enemy of good. A data stack that’s 80% modern and delivering real value today beats a theoretically perfect one that’s still 18 months away.

And make sure someone senior owns this. Not just IT. Modernisation touches every part of the business, and without clear executive ownership, even the best plans stall.

Where to Start

If the idea of a 90-day plan sounds appealing but you’re not sure where to begin, we’d love to help. At Idiro, we work with clients across all stages of the data journey, from initial assessments through to full modernisation programmes. Sometimes an outside perspective is exactly what’s needed to cut through the noise and find the right starting point.

Feel free to get in touch, we’re always happy to have that first conversation.

There’s a pattern we see again and again with organisations embarking on their AI journey. They invest in the tools, brief the team, and wait for the transformation to arrive. Then, a few months in, the results are disappointing. The model isn’t behaving as expected. The outputs feel unreliable. The project quietly stalls.

The problem isn’t AI. The problem is almost always the data underneath it.

The Uncomfortable Numbers

Recent research from BARC, which surveyed over 400 organisations on their AI experiences, found that data quality issues more than doubled as the top obstacle to AI success, jumping from 19% of organisations in 2024 to 44% in 2025. That’s not a small uptick. That’s a signal.

Gartner found that at least half of all generative AI projects were abandoned after the proof-of-concept stage. And according to the same BARC research, only 20% of organisations have actually built the proper foundations needed to support AI in production.

These numbers are striking, but they shouldn’t be surprising. AI doesn’t create insight from thin air. It finds patterns in the data it’s given. If that data is inconsistent, incomplete, or siloed across a dozen different systems, the model will faithfully reflect that mess right back at you.

Garbage In, Garbage Out. At Scale.

We’ve worked with clients who came to us excited about AI, only to discover that their biggest challenge wasn’t which model to use. It was that their customer data lived in three separate systems with no common key, or that the same metric was being calculated differently across departments, or that nobody quite knew which version of a dataset was the authoritative one.

These aren’t exotic problems. They’re the everyday reality of most data environments. And while they might be manageable when a human analyst is doing the work, AI amplifies them. A model trained on messy data doesn’t produce mediocre outputs. It produces confidently wrong ones.

So What Does “Discipline” Actually Mean?

It means treating data as infrastructure, not an afterthought. Here’s what we see separating organisations that succeed with AI from those that struggle:

Data governance that’s actually practised. Not a policy document that lives in a shared drive, but agreed definitions, clear ownership, and processes that people follow day to day.

Data quality monitoring. Knowing when something has gone wrong before a model makes a decision based on it. This means checks, alerts, and accountability.

Connected data. AI works best when it can draw on a full picture. That means investing in integration, whether through a data warehouse, a lakehouse, or well-managed pipelines, so models aren’t working from a partial view.

A clear business question. The most disciplined AI projects start with “what decision are we trying to improve?” not “what can AI do for us?” Starting with the use case keeps data work focused and makes it easier to measure success.

The Organisations Getting This Right

The BARC research found that organisations with mature data and AI foundations were nearly twice as likely to have five or more AI projects running in production compared to those without. The discipline compounds. Once the foundations are in place, deploying AI for new use cases becomes faster and cheaper.

This is the virtuous cycle we try to help our clients build. It’s not glamorous work. Getting data governance right rarely makes headlines. But it’s the difference between AI that actually changes how your business operates and AI that stays stuck in a pilot forever.

Where to Start

If you’re wondering whether your data is AI-ready, a good first question is: can your team agree on the definition of your top five business metrics? If the answer is “it depends who you ask,” that’s your starting point.

The good news is that building these foundations doesn’t have to take years. With the right focus, organisations can make meaningful progress quickly, and the payoff extends well beyond AI.

If this resonates with where your organisation is right now, we’d love to have a conversation. At Idiro, we help businesses get their data in shape for the future. Sometimes that means AI. Always, it means better decisions.