You can’t outsource accountability

There’s something oddly reassuring about blaming the vendor.

• The timeline slipped? Must be their fault.
• The app doesn’t work on tablets? Scope misunderstanding.
• We spent $32 million and still don’t have a working product? Clearly a delivery issue.

But behind every disaster labeled vendor failure, there’s usually a deeper truth: someone on the client side stopped paying attention. Or was never really involved in the first place. Let me tell you a true story!

A multi-million-dollar website that never launched

A major brand in the travel sector decided it was time for a full digital overhaul. New website, mobile apps, content platform, modern user experience — the works. They hired one of the biggest names in global consulting to make it happen. They paid tens of millions over the course of the project. What they got:

• A desktop website that didn’t adapt to tablets (no, seriously)
• Code that was so poorly structured it had to be rewritten entirely
• Missed deadlines, broken features, and a system that never went live

After nearly two years and multiple extensions, they fired the consultancy and brought in someone else to rebuild the whole thing. Was the vendor bad? Honestly, I don’t know. But the client wasn’t present. Yes, the consultancy messed up. They missed the mark on critical requirements. They misunderstood scope. They delivered incomplete and, in some places, insecure code. But the client let it happen. No strong internal product ownership. No meaningful validation of deliverables. No feedback loop that kept the work aligned to actual business outcomes. They thought writing a check would buy them transformation. Instead, it bought them frustration.

What actually went wrong

Key features were assumed, not defined. The client thought responsive design obviously included tablets. The vendor delivered desktop and mobile — and then asked for more money to add tablet layouts. Reusability across brands was a goal, not a requirement. The client wanted a single platform for multiple brands and regions. The vendor built something that only worked for one. Technically correct; strategically useless. The front-end code was riddled with issues. Performance, maintainability, and even basic logic were subpar. It didn’t follow the standards of the platform it was supposed to be built on. Testing was superficial. Some code was allegedly commented out to make it pass. The testing process looked good on paper — but failed to catch serious problems. Documentation and handover were incomplete. The client expected an interactive design system. The vendor sent PDFs and a bill for the rest. After terminating the contract, the client had to pay another firm to rebuild almost everything from scratch. Of course, there was a big lawsuit as well.

Lesson learned: No one will care about the outcome as much as you do

You can hire the biggest name in the business, but if you don’t stay engaged — if no one on your side owns the outcomes, asks the hard questions, and keeps the team honest — you’re not managing a transformation. You’re just spending money and hoping it works. I like to remind people of three things to remember for your next strategic project:

1. Vendors build what you tell them. Not what you wish for. If you want extensibility, accessibility, or scalability, write it down. Get it into the contract. Assume nothing.

2. Outcomes need owners. There must be someone on your side whose job is to understand the vision and the delivery. Not just approve invoices.

3. Working software beats perfect plans. Progress is not a slide deck. Test everything early. Look at real functionality. If you’re surprised at go-live, you weren’t looking closely enough.

Enter AI

Now why is all of that important to you? Because everywhere, organizations feel the pressure to implement AI, to digitally transform and to finally get all of that right. So organizations commit on buying new tools or explore ways to extend and integrate AI with existing systems. But if no one in your org understands how it’s being built, what it’s trained on, or why it matters, you’re just repeating that same IT failure, only faster and with more hallucinations.

Here’s how to not repeat the past

1. Start with the job, not the model. What work are you trying to improve? Who does it today? What’s painful about it? If you can’t answer that in plain language, you don’t need AI, you need clarity.

2. Own the decision-making. Don’t let external partners dictate what AI looks like for your business. Use them to build, not to decide. Your leadership team should define success and call the shots on what’s acceptable, usable, and scalable.

3. Don’t skip the governance conversation. It’s not just about data privacy. It’s about explainability, auditability, and long-term cost. Who’s updating this thing next quarter? What happens when the model drifts? If you don’t know, you’re not ready to ship.

4. Build internal muscle, even if you’re not coding. You don’t need a team of PhDs. But you do need product managers, domain experts, and data-literate leaders who can ask smart questions. If every AI decision is outsourced, you’re not transforming, you’re just renting tech theater.

5. The very inconvenient truth: the tools are better, but the habits are the same. We have better infrastructure, smarter models, and easier integrations than ever before. But if we approach AI with the same mindset that failed digital projects a decade ago, we’ll get the same result:

🚨 High spend 🚨 Little value 🚨 Lots of finger-pointing

AI is not a shortcut to strategic clarity.

It’s an amplifier. Of whatever culture and structure you already have. AI won’t save you, but ownership might. The lesson from that $32 million disaster wasn’t don’t trust vendors. It was: Don’t abdicate leadership.

If you’re serious about AI, don’t start with the pitch deck. Start with the problem. Start with the users. Start with someone internally who is accountable for every step from vision to deployment. And if you don’t have that person? Congratulations. You’ve just launched a very expensive experiment in disappointment.

If this hits close to home, let’s talk. Not about the vendor. About the part you can control: How to lead a project that actually delivers.