Why Most IT Projects Fail: The Foundation Underneath Is Weaker Than Anyone Wants to Admit

Aug 11

6 min read

I've scoped a lot of IT projects. There's one pattern I see almost every time, regardless of industry or company size: the foundation underneath the project is weaker than anyone wants to admit. Networking that was never properly segmented. Identity that grew organically instead of by design. Change management that exists on paper but not in practice. And, more often than companies like to admit, a service provider that's quietly ended up owning the process and the tooling — instead of the company itself.

That last one is easy to miss because it doesn't look like a gap. It looks like things are handled. But the moment a vendor is the one dictating how change requests flow, how identity gets provisioned, or which tools are "supported," the organization has lost something it needs back: the process and the tooling should be owned and dictated by the company running the business, not ruled by whoever happens to be holding the contract.

Point that out, and the answer is almost always the same: we know, but there's no time, no budget, and no fallback plan.

That's the gap I want to talk about here. Not the standards gap — everyone knows what a Zero Trust architecture or ISO 27001 is supposed to look like on paper. The real gap is what happens when you can't meet that standard yet, and nobody has planned for that moment.

The Diagram That Lies by Omission

You've probably seen the chart. Some kind of maturity radar or "current state to future state" roadmap — the sunray diagram everyone puts in a slide deck. It looks great in a boardroom. It's also, almost always, dishonest by omission.

These diagrams jump straight to the aspiration. Someone says "we need microsegmentation" and draws an arrow pointing outward on the chart. But microsegmentation isn't a checkbox. It demands a level of operational maturity behind it — because the moment you add that many firewall rules and that much restrictiveness, you need the team, the monitoring, and the change process to actually absorb the workload that creates. Without that, you're not improving security. You're manufacturing outages.

The diagram shows the destination. It rarely shows the honest starting point, and almost never shows what it actually takes operationally to get there.

Start With the Essentials — Yours Depends on Your Organization's Fingerprint

My starting position, built over years of scoping projects across Microsoft-heavy environments, is that you begin with the essentials: network and identity. Almost everything else in the organization sits on top of those two. If they're not solid, nothing built above them is stable either.

And here's a mistake I've watched cost real money: sophistication is not the same as maturity. I've seen companies invest in expensive, advanced network technology — Cisco ACI, elaborate VRF segmentation — before they've mastered basic, consistent VLAN discipline and firewall rule hygiene. That's buying complexity before earning the fundamentals. It multiplies the mess instead of fixing it.

But I want to be honest about the limits of "start with network" as a rule. Every organization has a unique fingerprint. For one company, network and identity genuinely are the highest-leverage starting point. For another, it's something else entirely — security governance, service management, or increasingly, how AI and large language models are being used by external parties, which is a compliance question almost nobody had five years ago.

The point isn't "always start with network." The point is: find the highest-leverage gap for this organization, and triage from there. Don't try to fix every domain at once.

A Maturity Scale That Accounts for People, Not Just Configuration

Once you know where to look, you need an honest way to measure it. I use a five-level scale:

Minimal — ad hoc, undocumented, reactive only.
Basic — the capability exists but is inconsistently applied. Good intentions, poor enforcement.
Standardized — consistently applied, documented, and monitored. This is your solid, defensible baseline.
Managed — proactively managed with measurable outcomes, automation and integration in place.
Optimized — continuously improved, AI-assisted, business-aligned. Industry-leading — and honestly, a level that should be reserved for strategic priorities, not chased everywhere.

Here's what most scoring exercises miss: these levels aren't purely technical. A network segmentation project can look like a Managed on paper — the firewall rules exist, the VLANs are configured — but if the team behind it has no real ownership, no succession plan, and the whole thing collapses the moment one senior engineer leaves, it isn't actually a four. It just looks like one from the architecture diagram.

The maturity level has to account for the organizational readiness behind the technology — the people, the ownership, the process — not just the technical configuration in front of you.

One more thing about this scale: it doesn't work as a single generic ruler applied uniformly across the company. What "Standardized" means for identity governance isn't what it means for patch management or for vendor risk. Each area — and often each subsection within it — needs its own concrete description of what each level actually looks like in that specific context. That's more work upfront, but it has a useful side effect: writing out what "Basic" versus "Managed" actually means for your backup process, or your change approval flow, forces the team to sit down and genuinely reflect on where they stand, rather than eyeballing a generic five-point scale and rounding up. The exercise of defining the scale becomes part of the diagnosis.

The Missing Middle: Building an Approved Workaround Path

Here's what honest evaluation actually buys you — and where it leaves you stranded. Most frameworks show you two points, current state and target state, and skip the part in between. That's exactly where real projects get stuck.

Take a hypothetical case: your target standard is SMB3 for file shares, or Wi-Fi 7 on the shop floor. But you're running twenty-year-old industrial equipment that has no idea what either of those is, and won't for the rest of its service life. In theory you have two options — push for a hardware refresh, or wait until end-of-life forces one anyway. In practice, that equipment is running production today, and it isn't coming offline because the standard isn't met yet.

So what actually happens — and I'd rather say this plainly than pretend otherwise — is a risk-based judgment call. That's fine, as long as it's done properly, which means three things:

A documented compensating control — extra network isolation, tighter monitoring around the legacy system.
An explicit risk acceptance, signed off by whoever actually owns that risk — not quietly agreed to in a hallway conversation.
A review date, so the interim path doesn't silently become the permanent one.

What's missing from most maturity frameworks isn't more diagnostic rigor at the top — it's a sanctioned, repeatable process for the gap in the middle, so you're not solving the same problem differently every time it comes up. Build that exception-handling process once, and it becomes part of the standard itself, not a workaround you're quietly ashamed of.

Beyond the Technology: The Organizational Layer

One thing gets missed constantly. A lot of projects have clear scope, clear tollgates, clear success criteria on paper — and quietly ignore the organizational layer underneath: naming conventions, identity integration between new tools and existing directory services, how the workflow actually gets adopted by the team running it day to day.

These are leadership and governance issues, not technical ones. A department can't restructure itself from the bottom up — or at least, it's extremely difficult to. That kind of change has to be enabled from management. So when I talk about maturity, I'm not only asking whether the technology is mature. I'm asking whether the organization around that technology — the ownership, the team structure, the process — is mature enough to sustain it.

Final Thoughts

Most organizations don't fail because they lack standards. They fail because there's no honest starting point, no triaged priority list, and no approved path for the moments they can't meet the standard yet.

That's what a proper foundation analysis should give you — not just a map of where you want to go, but an honest diagnosis of where you actually are, a clear sense of what's worth fixing first, and a sanctioned way to handle the gaps you can't close immediately.

If any of this sounds familiar — a roadmap that looks great on a slide but skips the honest starting point — it's worth a conversation. Book a session if you'd like a second opinion on where the real gap in your environment is.