The Steering Committee Didn't Kill Your Agile Transformation. The Vendor Did.

#softwareinsidenontechindu

When enterprises whose core business is cement, insurance, or freight hire a consulting firm to "go Agile," they've already handed the wheel to the wrong driver.

Picture this: a quarterly steering committee at a mid-size logistics firm somewhere in the industrial Midwest. Twelve people in a conference room, half of them dialing in, one of them opening the meeting with a RAG status slide that is, inexplicably, all green. The vendor — a major consulting house three years into a SAP S/4HANA migration — presents a Gantt chart that has been re-baselined four times. Someone in the room calls it "Agile." Nobody corrects them.

This is not a hypothetical. It is the operating reality inside hundreds of large enterprises whose core business is emphatically not software — logistics firms, insurers, hospital networks, chemical manufacturers — but who have spent the last several years enthusiastically adopting the vocabulary of Agile delivery without much of the substance. When the transformation eventually stalls or quietly collapses, blame lands on the usual suspects: resistant middle managers, underfunded training programs, culture. What gets a pass, far too often, is the vendor.

Here is the claim worth arguing: the dominant reason Agile fails in non-tech enterprises is not the PMO. It is the vendor-led implementation model that the PMO was built to manage — and the two have formed an unholy alliance that is near-impossible to dislodge from the inside.

The PMO Gets Too Much Credit for the Problem

There is a readable, comfortable critique of the traditional PMO: that when a directive for "Agile transformation" lands on its desk, the PMO's instinct is to water it down as far as possible, thoroughly vested as it is in the established project culture. That critique is accurate. Fixed structures, entrenched hierarchies, and command-and-control habits are genuine barriers to Agile ways of working. But pointing at the PMO as the primary culprit is too easy, and it lets a much larger actor off the hook.

More recent State of Agile data points to leadership, culture, and alignment as the current barriers — the sticking points at the top, where executives are not fully on board and business and IT are not aligned. What that data rarely surfaces, because surveys tend not to name vendors by name, is how often those cultural barriers are structurally enforced by the way the engagement contract is written in the first place.

In 2024, hybrid is the new normal for Agile ways of working, with enterprises using home-grown frameworks or something inspired by an industry-standard framework — and some still carrying traditional PMO teams reminiscent of the waterfall days. The honest reading of "hybrid" in most non-tech enterprise contexts is this: waterfall planning at the front, some Scrum ceremonies in the middle, and a hard delivery gate at the end. The industry has a name for it. Forrester's Dave West called this "Water-Scrum-Fall" years ago and raised the uncomfortable question of whether anyone is really doing pure Scrum at all. The answer, inside a chemical distributor running a three-year Oracle implementation managed by an external systems integrator, is obviously not.

What Vendor-Led Actually Means

The mechanics here are worth being specific about, because "vendor-led implementation" gets used so loosely it has become meaningless.

SAP Activate — the methodology most large SAP implementations follow — emphasizes phase-based execution with clear deliverables such as FIT/GAP analyses, WRICEF objects, blueprint documents, testing, and transport management. These are legitimate, well-reasoned artifacts for large ERP rollouts. The problem is not that they exist. The problem is that aligning SAP's structured methodology with modern Agile practices is genuinely challenging, and spreadsheets, manual trackers, and siloed communication routinely produce limited visibility and misaligned priorities between functional and technical teams.

Into that gap walks the steering committee — monthly, armed with a RAG report it didn't build and doesn't fully understand, ratifying decisions the vendor team made three weeks earlier. Large SAP projects using SAP Activate and SAFe together involve heavy upfront planning and design, with most sprint deliverables being process designs and documentation rather than working software. Sprints full of documentation are not Agile; they are waterfall with a two-week heartbeat. And the steering committee, composed of a CFO, a supply chain VP, and three rotating business unit heads, has no particular reason to flag this. Their job is governance, not method purity.

From 2022 to 2024, digital transformation spending in Western markets was projected to reach $6.3 trillion. Failure rates hover around 84%. The scale of that failure deserves a more precise explanation than "culture change is hard."

The Framework Alibi

There is a particular pattern that emerges when non-tech enterprises adopt scaling frameworks. About 59% of organizations report using frameworks like SAFe or LeSS, with larger enterprises especially reliant on them — yet 61% of large organizations are dissatisfied with the results of their Agile transformations. Reliance on scaling frameworks appears correlated with the billions wasted on transformation efforts that don't meet expectations.

Why? The polite answer is that organizations adopt frameworks without adapting them, producing rigid processes that can't keep pace with internal and external change. Technically true. Also somewhat beside the point.

Here is what that framing misses: in a vendor-led engagement, the vendor has a strong financial interest in keeping the framework rigid. A SAFe Program Increment planning event with 200 attendees is billable. Fifteen consultants running Agile Release Train ceremonies for a manufacturing company that moves steel coils is billable. There is a real risk in implementing SAFe as an Agile-novice organization, because the different levels make it possible to generate big initiatives where smaller pieces of value would be possible — and organizations end up busy creating documents with requirements while a waterfall is essentially recreated inside the framework.

The vendor gets paid either way. The org chart absorbs the friction, and the steering committee calls it on-track.

The Counterargument Deserves a Hearing

None of this means the PMO is innocent, or that vendor-led implementations are inherently doomed. Agile is considerably easier to practice in a software company than in a hardware or physical-product company — when you're working with abstract products, the constraints are different than when physical materials and regulated processes are involved. A pharmaceutical company running a GxP-validated system genuinely cannot iterate its way out of regulatory requirements. An insurer mid-way through a claims system migration has contractual commitments to counterparties that a two-week sprint cannot simply defer.

Agile is best suited for projects of an experimental nature, incorporating new or untried technology, where change or refinement of requirements is expected. Using Agile for bridge construction makes little sense, since the requirements are clear and the prerequisites are needed from the outset — last-minute changes simply aren't in the plan. The same logic applies to a pipeline of warehouse automation systems for a 3PL operator with contractual SLAs: you cannot pivot the racking configuration in sprint 14.

There is a real disconnect between how Agilists think about Agile and how business people think about business. That disconnect is not purely the vendor's fault, nor purely the PMO's. For less successful Agile transformations, two factors recur: difficulty changing corporate culture, and difficulty transforming middle management. Both are internal problems. Vendors can make them worse, but they rarely create them from scratch.

And there are cases where the external shock of a vendor pushing Agile discipline is precisely what unlocks change. A documented turnaround of a failing enterprise-scale Oracle COTS implementation in a public agency involved a hard reset from waterfall to Agile methodology, with a delivery approach implemented at enterprise, program, and team levels. It worked there. Context matters.

The Thing Nobody Says in the Steering Committee Meeting

What actually happens in most non-tech enterprise Agile programs is this: the consulting firm lands a multi-year engagement priced against scope defined during a waterfall-style requirements phase. Then it installs Agile ceremonies as a delivery layer on top of that fixed scope. Then it trains the PMO to report on sprint velocity and calls the dashboard "transparency." Modified Agile methodologies end up being used in these hybrid approaches, but their benefits are never fully unlocked — because hybrid approaches still require rigorous upfront analysis that sharply limits whatever agility was supposed to follow.

"Hybrid" is not inherently bad. But there is a version of hybrid that is just waterfall with better marketing, and it tends to live inside the kind of engagement where the vendor sets the methodology, the PMO enforces compliance, and the steering committee applauds the green RAG.

A coach can advise, but ownership of change cannot be the coach's responsibility — ultimately it is the organization's officers who carry the can for the success or failure of a transformation. That is precisely right. And the organization's officers, most of whom did not come up through software delivery, need to stop outsourcing their methodology decisions to the firms who are billing them to implement that methodology. The conflict of interest is obvious. The fact that it rarely gets named in a steering committee meeting is the real problem.

The next time a non-tech enterprise declares its SAP rollout "fully Agile," it might be worth asking one simple question: who decided it was Agile, and what were they being paid to say so? That question alone won't fix the steering committee, the org chart, or the culture. But it might at least make the RAG report a little more honest.

DEV Community