The Professional Services Transformation Paradox #4 – Accountability vs. Alignment

1. April 2026
Kategorien
Newsletter abonnieren

In large transformation programs, accountability is rarely missing. It is distributed. It sits with executive sponsors, steering committees, transformation offices, service line leaders, and partner groups, each with a defined role and a legitimate claim to involvement. On paper, this creates alignment. In practice, it often removes ownership, because when accountability is spread across too many actors, it becomes increasingly difficult to identify who is ultimately responsible for the outcome. Decisions are made collectively, risks are reviewed collectively, and progress is monitored collectively, but when a transformation underdelivers, ownership becomes blurred.

Who actually owns the result?

The CEO, CIO, or COO who sponsors the program, the transformation office coordinating execution, the steering committee governing decisions, the service line leaders affected by the change, or the partner group that approved the investment?

The honest answer is often uncomfortable.

No one, clearly.

That is the gap.

Professional services firms are highly disciplined when it comes to accountability in their core business. Revenue, utilization, and client delivery are measured with precision, performance is transparent, and consequences are explicit. There is no ambiguity in who owns a missed revenue target and no committee responsible for utilization, because ownership is individual, visible, and enforced. But for internal transformation, the same discipline does not apply. Ownership becomes collective, and collective ownership is often just a polite way of describing diluted accountability.

This becomes more problematic as the scale of transformation increases. These programs involve tens or hundreds of millions, reshape operating models, and cut across service lines, geographies, and partner groups, which inevitably expands governance and increases the number of stakeholders involved. What emerges is a structure designed to ensure that everyone is heard, but not a structure that ensures that someone is accountable. This is the tension. Alignment requires distribution, accountability requires concentration, and the two do not scale together. As governance expands to maintain alignment, accountability becomes diluted, decisions slow down, trade-offs become harder, and risks are escalated rather than owned. From the inside, this feels like good governance. From the outside, it often looks like drift.

When transformation programs underdeliver, the explanation usually focuses on execution, on complexity, technology, scope, or change management. These factors matter, but they rarely explain the full picture, because they assume that the primary challenge lies in delivery. In many cases, the deeper issue lies in governance. If no single person is clearly accountable for the outcome, the organisation will not optimise for results, but for alignment, risk distribution, and internal consensus. The program may appear well-managed and well-governed, while still failing to achieve its intended impact. This is not a failure of execution alone. It is a failure of accountability.

The paradox is not that professional services firms lack accountability. It is that they apply it selectively, enforcing it rigorously in client-facing work while relaxing it in internal transformation, where outcomes are more complex and politically sensitive. The result is predictable. When accountability is clear, performance follows. When accountability is shared, performance becomes optional. Alignment is necessary, but alignment without ownership does not deliver transformation.

For boards, the question is simple but uncomfortable. Who is personally accountable for the success or failure of this transformation, not in theory but in practice? If the answer is unclear, the outcome will be too.


This article is part of a series exploring the tensions at the heart of the Professional Services Transformation Paradox.

The paradox is simple. Firms that excel at transforming their clients often struggle to transform themselves. Deeply embedded incentives, partnership structures, and legacy operating models create internal resistance to the very change they advocate externally.

Each article in this series focuses on a specific contradiction. Structural, economic, or cultural. These tensions are not side effects. They sit at the core of how decisions are made, how transformation is executed, and why many programs underdeliver.


Most transformation failures do not start with strategy, technology, or vendors. They start with governance, incentives, and blind spots at board level.

If you are currently overseeing a critical transformation, I offer a focused board-level diagnostic to identify where your program is at risk before those risks become visible in financials and delivery.

If this is relevant, get in touch.

Das könnte Sie auch interessieren

When is your Project Backlog Item "Ready" for selection?

26. Juli 2017

As defined in the Simple Portfolio Management Framework, the Project Backlog is an ordered list of all projects that might be needed in the organization and is the single source of projects for any changes to be made in the organization. The Portfolio Owner is responsible for the Project Backlog, including its content, availability, and

Weiterlesen

The Project Portfolio Funnel

24. Juli 2017

When you look at the project portfolio funnel of the Simple Portfolio Management Framework (SPMF) it looks like the diagram below. Like I explained in previous articles, this is not greatly different from how PMI defines the project portfolio funnel. What is greatly different, is how you manage your funnel. SPMF is a framework within which

Weiterlesen

No More User Stories! There Are Jobs to Be Done

13. Juli 2017

Creating new and better products that thousands or millions of customers actually love is a top priority for almost every company. Agile frameworks and techniques have been hailed as a solution for exactly this problem. It started with eXtreme Programming (XP), where a conversation between the development team and the customer is the base for all requirements. And

Weiterlesen

The Reverse Triple Constraint of Troubled Projects

25. April 2017

Assuming you suspect or know that one of your projects is in trouble the first step is always an extensive project review. After such a review you hopefully have the necessary information for decision-making as well as the team’s support for the recovery of the project. It may be highly unlikely that the original requirements

Weiterlesen

8 Signs of troubled projects for project sponsors

19. April 2017

When you’re dealing with a troubled project, there are usually a number of red flags surrounding you. This article is written from the perspective of senior management (for instance the project sponsor, members of the Steering Committee, or the executive management). All of us have endured troubled projects that didn’t accomplish their intended business goals. Such watermelon projects,

Weiterlesen

Building Is the Easy Part…

6. März 2017

Agile Frameworks and books tell us how to build a product–that’s the easy part… What we are not told are equally important things like maintaining, operating, fixing and extending the built product. When your agile philosophies fail to cover these areas, it greatly reduces agile’s benefits. This is where DevOps comes into play. DevOps is the combination

Weiterlesen

Paying Technical Debt

15. Januar 2017

The metaphor of technical debt in code and design can be defined as follows: You start at an optimal level of code. In the next release, you are adding a new feature. This would take an effort E. This, of course, assuming that estimations are somewhere near reality. If the level of code was less

Weiterlesen

Outsourcing Technical Competence Is a Very Bad Idea

2. Dezember 2016

I have written about technical competence in the context of Software Engineering Practices. This article will shed some light on a different aspect of technical competency. Outsourcing it. A number of companies I have worked for have started a large project based on a technology they are not competent in, or even completely unfamiliar with.

Weiterlesen

Estimating with Wideband Delphi and Monte Carlo Simulation

18. Oktober 2015

During the LeSS training in Berlin last week with Craig Larman he mentioned the best estimating method he knows for any big software project. Wideband Delphi with Monte Carlo Simulation. I agree with him on this one hundred percent. This article will explain what Wideband Delphi and Monte Carlo Simulation is (Part 1 & 2),

Weiterlesen
Previous