Every Role on Your Project Has a Different Definition of Success. That’s Not a Problem — Until Nobody Knows It.

When a technology program stalls — when timelines stretch, when the steering committee starts hearing contradictory updates, when the sponsor starts losing confidence in what they’re being told — the instinct is to look at the plan, the vendor, or the budget.

Rarely does anyone look at the room.

Specifically: at who is in the room, what each of them is optimising for, and whether those things are pointed in the same direction.

Every major technology program — ERP, infrastructure, digital transformation — assembles a cast of roles that each carry a fundamentally different viewpoint. Not a different opinion. A different definition of what success looks like from where they sit.

This is not a design flaw. It is actually the design. The problem is when no one makes that explicit.

The Viewpoints in the Room

The Product Manager sees the program through the customer. Their question, consciously or not, is: does this serve the people we exist to serve? They are the voice pulling the project back toward organisational purpose when technical decisions start drifting inward.

The Architect sees the whole. Their lens is structural — how does this fit into what we already have, and what we’re likely to need? They are not optimising for this project. They are optimising for the system that will outlast it. When Architects are ignored or overruled on implementation timelines, the cost arrives later, quietly, in integrations that break and data that won’t reconcile.

The Technical Lead is there to build. Their viewpoint is delivery — I win by making things work. This is an asset. It is also a risk if their definition of “working” diverges from what the business actually needs the system to do. Technical success and business success are not the same thing, and confusing them is one of the most common failure modes in ERP programs.

The Project Manager operates inside constraints — time, cost, scope. Their job is to deliver the project as defined, within the parameters they’ve been given. They are not responsible for whether the project was worth doing. They are responsible for whether it gets done. Executives sometimes confuse these two things and hold the PM accountable for outcomes that were actually determined at the direction stage, long before delivery began.

The Test Manager is the issue catcher. Their entire function is to find what’s wrong before it reaches the live environment. A good Test Manager is, by definition, delivering bad news regularly. Organisations that treat testing as a box to tick — rather than a critical quality gate — discover the problems later, at a cost that is orders of magnitude higher.

The Trainer is the bridge between the system and the people who have to use it. Their viewpoint is adoption — do the people who need to use this product actually know how to? In ERP programs, training is routinely underfunded and back-loaded. The result is a technically successful go-live followed by months of operational chaos, because the system works but the organisation doesn’t know how to use it.

The Change Manager is the navigator. They are not managing a document. They are responsible for bringing every stakeholder — from the executive table to the frontline — on the journey, and arriving at the other end with them. Their viewpoint is alignment across the human dimension of the program. When Change Managers are brought in late, or treated as communicators rather than strategists, you get adoption failure dressed up as a technology problem.

The Project Sponsor carries accountability for the whole endeavour. Their viewpoint must be the most balanced of all: Is this worth the investment? Am I getting a clear picture? Are there surprises I should already know about? The Sponsor is not there to be the program’s champion. They are there to be its steward — which sometimes means asking uncomfortable questions of the very team they are sponsoring.

Hierarchy Is About Decisions, Not Importance

Here is something that is rarely said clearly enough in the room where these programs are discussed.

The hierarchy on a project exists for decision-making escalation, not to rank the importance of roles. The Sponsor earns more. The Project Manager may earn more than the Trainer. But the program does not succeed because the high-paid roles performed well. It succeeds — or fails — because of what happens when all of these roles are working together.

A technically perfect system that no one was trained to use is a failure. A project delivered on time to a scope that was never right is a failure. An issue-free go-live that collapsed under integration problems six months later because the Architect was overruled is a failure.

None of those outcomes belong to one role. They belong to the system of roles — and to what happened, or didn’t happen, between them.

What Actually Produces a Successful Outcome

After two decades inside programs of every shape and scale, the pattern is consistent. Projects that succeed are not distinguished by having better technology, bigger budgets, or more experienced individual contributors. They are distinguished by five things:

Alignment — Everyone understands the destination and agrees it is the right one. Not consensus for the sake of harmony. Genuine clarity about what this program is supposed to achieve and why.

Cohesion — The roles hold together under pressure. When timelines compress and trade-offs are forced, cohesive teams make decisions that serve the program. Fragmented teams make decisions that serve their own corner of it.

Cooperation — The viewpoints talk to each other. The Architect and the Technical Lead are in the same conversation. The Change Manager and the Trainer are not working in parallel silos. The Test Manager’s findings actually reach the Sponsor.

Balance — No single viewpoint dominates. Technically-led programs that ignore the human dimension fail at adoption. Business-led programs that ignore technical constraints fail at integration. The balance is not automatic. It requires active executive stewardship.

Synchronous effort — The program moves as a unit, not as a collection of individual performances. This is the most common gap. Individual roles performing excellently, in isolation, while the program drifts. Synchronous effort is what turns individual competence into collective outcome.

What This Means for You as Sponsor

Your role is not to understand every technical decision. It is to create the conditions under which these eight viewpoints can function together.

That means knowing who is in the room and what each of them is actually optimising for. It means asking whether the roles are talking to each other — not just reporting upward. It means treating your Test Manager’s bad news as signal, not problem. It means not letting the loudest viewpoint crowd out the quietest one.

And it means recognising, before the program goes live, that the hierarchy you see on the org chart is a decision-making structure — not a ranking of whose contribution matters most.

The programs that drift do so quietly. Not because the roles were wrong. Because nobody made the viewpoints explicit, held the balance, or asked the questions that kept them synchronised.