Hard Truths

The 18% Problem: Why Most Project Professionals Are Trained to Execute, Not to Lead

The PMI Pulse of the Profession 2025 report landed a stat that should be uncomfortable reading for anyone who runs project teams: only 18% of project professionals demonstrate high business acumen — a structural failure in how the profession develops talent.

And here's what makes it worse. That 18% pulls well ahead: they hit business goals at a higher rate (83% vs. 78%), fail less often (8% project failure rate vs. 11%), and use 50% more performance measurement factors than their peers.

The industry has the knowledge. It just hasn't made business acumen a training priority.

Why the Gap Exists

The project management profession has spent decades building expertise in execution. Methodologies, frameworks, certification pathways — almost all of it is oriented around the question: how do we deliver this well?

That's a legitimate question. But it's the wrong starting point.

The right starting point is different: what value does this need to create, and how do we make decisions that protect it? That's a fundamentally different orientation, and it requires understanding business mechanics, financial models, and organisational strategy. In the context of digital transformation programs, where investment is high and tolerance for ambiguity is low, that gap is costly.

PMI defines business acumen as "understanding business mechanics, models, financial aspects and making decisions aligned with organisational mission." By that definition, 82% of project professionals are operating without it.

And yet — financial acumen ranks dead last (23%) among the qualities senior leaders look for when hiring project managers. Which tells you exactly how this gap got so wide: we don't hire for it, we don't train for it, and then we're surprised when it's missing.

Above the Line vs. Below the Line

At Softwired, I use a framework called the Four Languages to describe the fluency required for effective digital transformation leadership. The four languages are Boardroom, Delivery, Process, and Code — each representing a distinct domain, each with its own logic, vocabulary, and priorities.

The framework also draws a line through each language: above it and below it.

Below the line is where most project work lives. Budget tracking, status reporting, RAID logs, requirements documentation, agile delivery ceremonies. This work is necessary. It's not unimportant. But it's tactical, and it's visible — so it tends to fill the space available to it.

Above the line is where value is created or destroyed. In Boardroom language: business cases, investment framing, commercial accountability. In Delivery language: outcome-based steering, risk-based escalation, decision rights. In Process language: operating model design, process strategy. In Code language: platform strategy, build vs. buy decisions, vendor governance.

The 18% PMI identifies as high-acumen? They're operating above the line. The other 82% are mostly below it, undertrained for anything else despite having the capability.

The translation failures are everywhere once you know to look for them. A PM presents velocity charts to a steering committee that asked about ROI. A developer quotes "3 sprints" to a CEO who hears "three months and I don't understand why." A business analyst identifies a "process gap" and a developer hears "scope creep." These are language problems, and they cost organisations real money.

Why This Matters More Than Ever

The argument for business acumen has existed for years. What's new is the urgency.

AI is automating below-the-line work faster than most organisations are ready for. Status reports, RAID log maintenance, requirements documentation, sprint tracking — these are exactly the kinds of structured, repeatable tasks that AI handles well. The tactical execution layer of project management is shrinking.

That leaves above-the-line work as the only defensible position for human project professionals. And if 82% of the profession isn't operating there today, the window to close that skills gap is narrowing.

As Mike Boutel of PM Partners Australia put it: "Good business acumen means constantly focusing on benefits and asking the right questions, like 'what's the value this brings?'"

That's not a soft skill. It's the skill. It's the thing AI can't replicate — because it requires contextual judgment, stakeholder engagement, organisational knowledge, and the willingness to challenge a bad investment before it gets approved. That last one, in particular, is underrated. The project professionals who prevent bad projects from starting create more value than those who execute them well.

What This Means for Building Project Teams

If you're building or hiring project capability for digital transformation and organisational change programs, the PMI data suggests a few things worth acting on.

First, stop treating business acumen as a nice-to-have. It's the highest-leverage capability in the profession, and it's the most underdeveloped. If your project training investment is split 46% technical, 25% business acumen, you're almost certainly building the wrong capability mix for the next five years.

Second, look above the line when assessing talent. Technical delivery skills are easier to assess and easier to develop. Business acumen — the ability to frame investment decisions, challenge scope in terms of value, and hold a conversation with a CFO about why this change management program matters — is rarer and harder to build. Screen for it earlier.

Third, consider what language your project leadership is actually speaking. As Fola F. Alabi put it: "Project management skills help you deliver, strategic thinking helps you align with objectives, and business knowledge helps you drive value." Most teams are strong on the first, adequate on the second, and weak on the third.

The 18% who get this right hold the same job everyone else does. They just start from value and work backwards to delivery, instead of the reverse.

That orientation is learnable. But only if it's treated as a priority — and built into your capability-building strategy from the start.

I built the Four Languages framework around above-the-line fluency across Boardroom, Delivery, Process, and Code. If you're thinking about how your organisation develops project and digital capability, that's the conversation worth having.

References