Enterprise DNA

Omni by Enterprise DNA

Enterprise DNA Resources

Thought leadership & research. Practical AI operating-system thinking for owners, operators, and teams doing real work.

220k+

Data professionals

Omni

AI agents and apps

Audit

Map the manual work

Key Findings

Most AI deployments fail because they're built by the wrong team. Here's why operations should drive AI, not IT.

Your IT Team Shouldn't Own Your AI Projects
Insight ai

Your IT Team Shouldn't Own Your AI Projects

Sam McKay

I see this every week in discovery calls: a business owner spent six months and $40K on an AI project that nobody uses. IT built something technically impressive. The system works. But the field team still uses spreadsheets and the ops manager still manually schedules jobs because the AI tool doesn’t fit how work actually flows.

The owner is frustrated. IT is defensive. And everyone’s wondering why the “transformation” didn’t transform anything.

The problem isn’t the technology. It’s who owned the project from day one.

The Real Problem: IT Builds Systems, Operations Runs The Business

Here’s what happens in most small-to-midsize firms when someone says “we should use AI”:

The owner gets excited about efficiency gains. They task IT (or their tech-savvy person, or an external dev shop) with “figuring out AI.” IT does what IT does best: they research tools, evaluate platforms, worry about security and integration, then build or buy something that checks technical boxes.

Three months later, they demo a system that can theoretically automate proposal generation or predict maintenance needs or optimize routing. It’s clever. It’s functional.

And it sits unused.

Why? Because IT doesn’t live in the daily friction. They don’t feel the pain of re-entering customer data three times. They don’t lose sleep over schedule conflicts or miss the revenue impact of a delayed quote. They build to specifications, not to operational reality.

Operations owns the pain. They know which manual tasks actually cost time versus which ones just feel tedious. They understand the exceptions that break neat workflows. They know that the scheduling “system” everyone complains about is actually just Michelle’s Excel file, and Michelle has tribal knowledge about client preferences that no database captures.

When IT owns AI deployment, you get technically sound solutions to problems that don’t matter enough. When operations owns it, you get messy-but-effective tools that people actually adopt because they solve real bottlenecks.

I’ve run audits for 220,000-plus professionals across every operational context you can imagine. The pattern is absolute: AI projects succeed when the person feeling the daily pain drives the requirements, testing, and rollout. IT should enable, not lead.

What Actually Works: Operations-Led, IT-Enabled

The firms getting value from AI right now aren’t doing massive transformations. They’re running small, operations-owned experiments with IT as a supporting player.

Here’s what that looks like in practice:

Operations defines the problem in dollars and hours. Not “we need better data” or “we should automate more.” Specific: “We spend 8 hours a week chasing PO numbers from repeat clients” or “Our estimators waste 3 hours per proposal on boilerplate that’s 80% identical across jobs.”

The ops manager who feels that pain quantifies it. They map the current workflow. They identify where the friction actually costs money or delays revenue. This becomes the project brief, and it’s concrete enough that you’ll know within a month whether the solution worked.

IT evaluates tools and manages infrastructure. Once operations defines the problem, IT’s job is to find or build the simplest technical solution that solves it. Not the most impressive or the most scalable—the one that fits the actual workflow and can be deployed in weeks, not quarters.

IT handles integration with existing systems. They ensure data security. They make sure the solution won’t break when someone’s on vacation. But they’re not deciding what problem to solve or how people will interact with the tool. Operations owns that.

Operations runs the pilot with real work. No sandbox testing with dummy data. The ops manager picks one team, one workflow, one real project and runs it through the new system while keeping the old process as backup. They document what works and what breaks. They gather feedback from the people actually using it.

This is where most IT-led projects fail. IT tests for bugs and performance. Operations tests for adoption and value. You need the latter.

The owner holds operations accountable for ROI. If operations owns the project, they own the results. Did it save the 8 hours? Did proposals go out faster? Did we reduce errors or rework?

The owner’s job is to make sure operations isn’t just experimenting for the sake of trying new tech. There should be a clear before-and-after on time saved, revenue accelerated, or costs reduced. If the pilot doesn’t show measurable improvement in 30-60 days, kill it and try something else.

I worked with a mechanical contractor who spent $30K on an AI-powered dispatch system that IT selected. Technically solid. Operationally useless because it didn’t account for the crew dynamics and client relationship nuances that the dispatch manager juggled daily.

We scrapped it. The dispatch manager spent two weeks testing three simpler tools with one crew. Found one that worked. Rolled it out in a month. Saved 6 hours a week in scheduling conflicts and reduced emergency callouts by 20% because the system caught maintenance windows the old spreadsheet missed. Total cost: $4K annually.

That’s operations-led deployment. Smaller budget, faster results, actual adoption.

What To Do This Quarter

If you’re thinking about AI for your operations, or if you’ve already started and it’s not working, here’s how to reset:

Pick one operational bottleneck and assign an owner. Don’t boil the ocean. Choose the single workflow that wastes the most time or causes the most frustration. Assign your ops manager (or whoever lives closest to that pain) to own the project. Their job is to define the problem in measurable terms and test solutions.

Not IT’s job. Not yours. The person who will use the tool daily should drive it.

Give IT a support role with clear boundaries. Tell your IT person (or vendor) exactly what you need: “Find three tools that can automate PO tracking without requiring us to change how we enter job data.” Or: “Build a simple form that feeds our estimating template and test it with two estimators.”

IT evaluates feasibility and manages implementation. They don’t define success criteria. Operations does.

Run a 30-day pilot with real stakes. Pick one team or one workflow. Use the tool on actual client work with the old system as backup. Track time saved, errors reduced, or revenue accelerated. Get daily feedback from users.

If people aren’t using it by week two, find out why. If it’s not saving time by week four, kill it. Don’t fall into the sunk cost trap of “we’ve invested so much already.”

Measure adoption, not capability. The question isn’t “can this system do X?” It’s “are people actually doing X with this system instead of the old way?” If your AI tool can generate proposals but your estimators still use the Word template, the tool failed regardless of its technical capabilities.

Track usage. Ask your team directly: is this faster or just different? Would you be annoyed if we turned it off? Those answers matter more than feature lists.

Scale only after proving value. Once a pilot works, roll it out to the next team or workflow. Don’t expand until you’ve documented clear ROI from the first deployment. And don’t let IT generalize the solution into something more complex. Keep it as simple as the pilot that worked.

I’ve seen firms rush to enterprise-wide rollouts after a successful pilot, only to discover the pilot worked because of local workarounds that don’t scale. Expand slowly. Let operations lead each new deployment.

Who Owns This In Your Business?

If you’re reading this and thinking “we don’t have separate IT and operations teams, I wear both hats,” the principle still applies. When you’re evaluating AI tools, which hat are you wearing?

If you’re thinking about technical architecture and integration challenges, you’re in IT mode. That’s important, but it’s not where you should start. Begin in operations mode: what specific task wastes time today? What manual process causes errors that cost money? What workflow bottleneck delays revenue?

Answer those first. Then put on the IT hat to figure out how to solve them.

The firms getting real value from AI right now aren’t the ones with the most sophisticated systems. They’re the ones where operations owns the problem and IT enables the solution. The owner holds both accountable for measurable results.

That’s how you avoid spending six months and $40K on something nobody uses.

If you’re not sure where your operational bottlenecks actually are, or if you’ve tried AI projects that didn’t stick, book a 60-minute Omni Audit with me. We’ll map your workflows, identify where you’re losing time or money, and figure out which problems are worth solving first. No sales pitch, just a structured look at where AI can actually help your business.

Book here: https://calendly.com/sam-mckay/discovery-call?utm_source=edna-landing&utm_medium=insights&utm_campaign=insight-ai-for-ops-not-it