The Professional Services Transformation Paradox #2 – Internal vs. Client Execution

26. März 2026
Kategorien
Newsletter abonnieren

One of the most persistent, and least openly discussed, tensions in professional services firms lies in how they execute their own transformations. It is a tension that does not reveal itself in strategy decks or partner presentations, but in the day-to-day reality of large internal programs that quietly struggle to deliver.

At first glance, the logic seems compelling. Firms that advise clients on ERP implementations, AI transformations, and operating model redesigns should be uniquely equipped to execute similar initiatives internally. They have the frameworks, the methodologies, the talent, and the experience. If transformation is their business, then internal transformation should, in theory, be a natural extension of their core capability.

And yet, the opposite is often true.

When professional services firms turn their advisory capabilities inward, three structural issues tend to emerge with remarkable consistency.

The first is a fundamental gap in operational understanding. Advisory teams are trained to diagnose, structure, and deliver transformation in client environments. They understand frameworks, governance models, and implementation playbooks. But the internal reality of a professional services firm operates under a different set of rules. Audit, tax, and advisory practices each follow distinct economic logics. Partnership structures introduce layers of informal power that rarely appear on organizational charts. Incentives are fragmented, often short-term, and deeply tied to individual or local performance. What looks coherent from the outside becomes far more complex when viewed from within. As a result, internal transformation efforts often start with a model that does not fully reflect the system it is supposed to change.

The second issue is talent allocation, and it is more structural than most firms are willing to admit. Internal programs compete directly with client work for the same pool of high-performing individuals. In a system where revenue generation and utilization remain the dominant metrics, client engagements will always win. The best people are continuously pulled back into billable work, especially when markets tighten or performance pressure increases. What remains on internal programs is not necessarily a lack of capability, but a dilution of focus, continuity, and senior attention. Over time, internal transformation becomes, by design rather than intent, a second-tier priority.

The third issue is accountability. Internal transformation programs are often governed and steered by individuals who are not the long-term owners of the outcomes they shape. Senior sponsors rotate. Program leaders move on to new roles. External advisors complete their mandate and exit. Decisions are made in the context of the program, but the consequences unfold in the operational business long after the program has closed. This creates a structural disconnect between decision-making authority and lived accountability. The people defining the future state are not always the ones required to operate within it.

Taken together, these dynamics create a contradiction that sits at the heart of many failed or underperforming transformations in professional services firms. Organizations that are highly effective at delivering complex change for their clients struggle to replicate the same level of execution internally. Not because they lack expertise, but because their own operating model introduces friction at every critical point of the transformation lifecycle.

This is where the discussion needs to move beyond capability and into governance.

The key question is not whether a firm has the skills to deliver transformation. Most do. The question is how internal transformation is positioned and governed within the firm. Is it treated as a project, structured and executed like a client engagement, with clear scope, timelines, and deliverables? Or is it owned as a long-term operational responsibility, embedded within the business, with accountability that extends beyond program completion?

Many firms attempt to do both, and end up achieving neither.

Running internal transformation like a client engagement creates momentum, structure, and clarity in the short term. But it also introduces artificial endpoints and a bias toward deliverables over adoption. Treating it purely as an operational responsibility ensures continuity, but often lacks the focus, urgency, and resource allocation required to drive meaningful change.

The tension between these two models is not easily resolved. But ignoring it is costly.

And it starts by asking a deceptively simple question:

Who truly owns the outcome of internal transformation — the program, or the business?


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.

Tags

Das könnte Sie auch interessieren

The Project Recovery Process Explained

12. Februar 2018

Projects fail for a variety of reasons. Especially technology projects have a low success rate. Typically more than half of them are considered a failure. But it does not have to end that way. As soon as a project is identified as in trouble you can start thinking about project recovery. This sentence already states a very

Weiterlesen

What Exactly Is a Troubled Project?

11. Februar 2018

Most of my work as a project recovery consultant is with what you can call «troubled projects». But what does this actually mean? Many teams I have worked with seem to be stuck in the PMI view of things. The PMBOK® Guide defines the successful project as a project that meets its objective in terms

Weiterlesen

What is a Project Review?

5. Februar 2018

> You want to know where you are standing with that large, multi-year, strategic project? > You think one of your key projects is in trouble? > Or you know that one of your key projects is in trouble? Then a project review is what you are looking for. When we talk about a project review, there

Weiterlesen

When Is My Project a Success?

22. Januar 2018

Project success and project failure are NOT absolutes.  It may not be possible to be a little bit pregnant, but you can be a little bit successful.  Every project has multiple success criteria related to business results, product/service results, and project delivery results (cost, schedule, scope, and quality). Some criteria are absolute, meaning they must

Weiterlesen

The Only Test Plan You Will Ever Need

3. Januar 2018

Assuming an iteration between two and four weeks: 1) Programmers will write unit tests in the code to ensure product technically behaves. The team will perform QA activities to ensure these are valid tests. 2) In the iteration planning meeting and in the iteration itself, tests cases will be defined as acceptance criteria for each

Weiterlesen

No Validation? No Project!

27. Juli 2017

For large or high-risk projects (what is large depends on your organization) it should be mandatory to do business case validation before you dive head-on in executing the project. In my Project Portfolio Funnel you will see a phase that is called «Validation» after selection of a project has taken place. In this phase you typically have a

Weiterlesen

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