Why So Many IT Projects Falter—and What We Can Do Differently
Here's something that'll probably sound familiar: Your company just wrapped up another "transformational" IT project. The demos looked amazing. The technical specs were flawless. But six months later, your teams are still fighting the system instead of using it to win.
Sound about right?
You're not alone. After two decades of helping companies navigate digital transformations, I've watched the same pattern play out again and again. Great technology, smart people, solid budgets—and somehow, the wheels still come off.
The Problem Isn't What You Think It Is
Most of us have been conditioned to blame the usual suspects when projects go sideways: scope creep, budget overruns, or that one stakeholder who keeps changing their mind. But here's what I've learned—those are just symptoms.
The real issue? We're still treating IT like it's 1995.
Think about it. Your finance team has been using standardized practices for decades. Your legal department operates with established frameworks that everyone understands. But IT? We're making it up as we go along, project by project, hoping this time will be different.
Here's the uncomfortable truth: technology is no longer just about technology. When you implement a new CRM, you're not just changing software—you're rewiring how your sales team thinks about their day. When you modernize your data infrastructure, you're not just moving databases—you're changing how decisions get made across your entire organization.
Yet somehow, we keep pretending these are "IT projects" that the business will magically adapt to once they're done.
Why Planning Feels Boring (But Changes Everything)
One point made in a recent post by Brian Carlson (CIO, Sodexo) struck a chord: "Spend more time in the planning phase. Don’t rush things."
He's absolutely right. And I get why it happens. Planning doesn't feel like progress. There's no code getting written, no systems going live, no victories to celebrate. Just meetings and documents and more meetings.
But here's what I've learned after watching hundreds of projects: the planning phase isn't where you figure out what to build. It's where you figure out whether you should build it at all.
At ACI, we've treat planning like an investment, not an expense. Before anyone writes a single line of code, we dig into questions that make people squirm:
What happens if we do nothing? Really, what happens?
Who's going to own this thing once IT walks away?
What does success look like to the person who has to use this every Tuesday at 2 PM?
Are we solving a technology problem or a people problem with technology?
These conversations are uncomfortable because they expose the gaps between what we think we're building and what actually needs to get built.
The Art of Building Things People Actually Want to Use
Here's another hard truth: most IT projects fail not because the technology doesn't work, but because nobody wants to use it.
We get so caught up in technical elegance that we forget about human reality. We build systems that require seventeen clicks to do something that used to take three. We create dashboards that show everything except what people actually need to see. We implement "improvements" that make everyone's job harder.
The fix isn't complicated, but it requires discipline. Involve real users—not their managers, not their managers' managers—in the design process. Show them prototypes that barely work instead of demos that look perfect. Let them poke holes in your assumptions before you've spent six months building around them.
And for the love of all that's holy, stop asking people what they want and start watching what they actually do. The gap between those two things is where most projects go to die.
Keeping It Simple in a Complex World
There's a temptation in our industry to build everything from scratch. Custom solutions for custom problems, tailored to exact specifications. It feels important, sophisticated, cutting-edge.
It's also usually a mistake.
The companies that consistently deliver successful projects have figured out something crucial: the goal isn't to build something unique. The goal is to build something that works, that people will use, and that won't break the first time someone tries to do something unexpected.
This doesn't mean settling for generic, off-the-shelf mediocrity. It means being smart about where you customize and where you standardize. Whether we're implementing Salesforce, deploying AI-driven analytics, or modernizing data infrastructure, we've learned to embrace the 80/20 rule: standard solutions for common problems, custom work only where it truly adds value.
The New Rules of Getting IT Right
The companies that consistently nail their technology projects don't just move fast—they move smart. They've figured out a few things the rest of us are still learning:
They start with the end in mind. Not the technical end—the human end. What will be different for real people doing real work once this thing goes live?
They make governance part of the design, not an afterthought. Who makes decisions? How do conflicts get resolved? What happens when requirements change? Figure this out before you need it.
They treat change management like engineering, not marketing. Training isn't about showing people which buttons to click. It's about helping them see how their job gets better.
They measure what matters, not what's easy to measure. User adoption rates matter more than uptime percentages. Time-to-value matters more than feature completeness.
What This Means for You
We're living through a moment when AI, automation, and intelligent systems are becoming part of everything we do. The stakes aren't just higher—they're fundamentally different. These aren't just tools anymore; they're becoming part of how we think, decide, and act.
Which means we can't afford to keep repeating the same patterns that got us here. We can't keep launching technology and hoping people figure it out. We can't keep treating digital transformation like a technical challenge when it's really an organizational one.
The good news? The companies that get this right aren't doing anything magical. They're just being more honest about what success actually looks like, more disciplined about involving the right people at the right time, and more committed to building things that solve real problems instead of impressive problems.
The question isn't whether your next IT project will be successful. The question is whether you're willing to do the unglamorous work that makes success inevitable.
Because here's the thing: in a world where technology is reshaping everything, the companies that win won't be the ones with the best technology. They'll be the ones that are best at making technology work for people.
That's the difference between a project that launches and a project that lasts.
If you're planning a digital transformation and want to avoid the common pitfalls that derail most IT projects, I'd love to hear about what you're working on. Sometimes a quick conversation can save months of headaches down the road. Feel free to reach out—I'm always happy to share what we've learned from helping companies navigate these challenges.
Strategic Partner for Early-Stage Founders | 20+ Years Building Digital Ventures | Sharing What Works & What Doesn't
1moThis is one of the most honest articles I've read on this topic. It cuts right through the noise. Your observation that leaders often focus on "impressive problems instead of real problems" is the core of the issue. There's immense pressure to show progress, which leads to skipping the "uncomfortable conversations" in the planning phase. You've articulated the value of that "pre-build" clarity perfectly.
Great perspective
Driving Business Impact Through MarTech, AI, and Scalable Tech Strategy
1moGreat perspective