The Hidden Costs of Internal Client Relationships

What Research Reveals
April 6, 2025 by
Alain Vanderbeke
| No comments yet


Introduction: The Illusion of Internal Efficiency

We often assume that internal client relationships are simpler and smoother than external ones—after all, we work in the same organization, right?

But research reveals a more complex story.

According to a study published in the Journal of Business Research, internal clients prioritize two things above all: efficiency and durability of the delivered product or service (Matthing et al., 2004). Surprisingly, they rarely care about the expertise level of the delivery team—they just want results they can rely on.

And yet, many organizations have adopted internal structures that unintentionally sabotage this reliability. By modeling internal teams as independent suppliers or mini-enterprises, they create fragmented, competitive environments that undermine collaboration, ownership, and long-term quality.



When Teams Compete Instead of Collaborate

The trend of internal supplier logic comes from an old corporate philosophy: “What gets measured gets managed.” Unfortunately, that logic often leads to teams being pitted against each other to deliver “efficient” results within budget.

In such environments, teams tend to:

  • Optimize for short-term budget goals.
  • Avoid innovation that might delay delivery.
  • Deliver products that meet specifications—but not client needs.

As noted in Total Quality Management & Business Excellence, internal competition leads to fragmented accountability and declining product consistency (Oakland & Tanner, 2007).

Even worse, when departments are treated like vendors, feedback loops shrink or disappear altogether. Instead of learning and improving together, teams shield themselves from blame and feedback. This destroys the potential for cross-functional learning—one of the core promises of agility.



Why Agile Is Not What You Think

Agile methods were created to address exactly this kind of dysfunction. Agile isn’t just a framework—it’s a philosophy of collaborative development and customer co-creation.

The Project Management Institute (PMI) found that Agile organizations achieve project success 71% of the time, compared to 62% for traditional methods (PMI Pulse of the Profession, 2020).

Agile promotes:

  • Constant feedback between business and delivery teams.
  • Shared responsibility for outcomes.
  • Adaptation over rigid contracts.

However, many companies today have adopted Agile theatre—keeping the rituals but ditching the spirit. The result? Teams are once again treated as service providers, and the old “client is always right” mindset creeps back in.

This reintroduces hierarchy and control where there should be trust and exploration.



Estimation, Uncertainty, and the Myth of Control

Let’s talk about estimation—one of the most misunderstood elements in project delivery.

Traditional estimations assume a level of predictability that simply doesn’t exist. A joint study by Bent Flyvbjerg and Alexander Budzier from Oxford University (2011) showed that IT projects on average run 27% over budget, with 1 in 6 exceeding by 200% or more. The root cause? Underestimated complexity, dependencies, and unknowns.


So how do we make estimation useful without pretending it's precise?


 Tool 1: The T-Shirt Estimation Model

This is a popular Agile tool because it helps people detach from exact numbers while still expressing effort. Here's how it works:

T-Shirt Size Relative Effort Time Band (approximate)
XS Very Low 1–2 hours
S Low 1 day
M Medium 2–3 days
L High 1 week
XL Very High 1–2 weeks
XXL Massive Requires breakdown

The key benefit? It helps teams stay grounded in time without being fixated on precision. Plus, it's easy to discuss and align quickly across stakeholders.

But what if we want to go a step further—beyond perception, into systemic reasoning?



 Tool 2: The Estimation Equation – 4 Variables That Define Complexity

To support teams in building more shared understanding of work complexity, I created a tool based on four core variables:

🔢 The Estimation Equation:

Each task or feature is assessed using four dimensions:

  • Time (T) – the estimated duration to complete the task
  • Complexity (C) – how technically or structurally complex it is
  • Uncertainty (U) – the level of unknowns, ambiguity, or assumptions
  • Dependencies (D) – reliance on other teams, systems, or sequences

Each is scored between 0 (minimal) and 3 (high), or marked as "X" if unknown or unmanageable.

🧮 Estimation Score = T + C + U + D

⚠️ Rule:

If even one variable is "X", estimation must be paused and:

  • Broken down further
  • Investigated for missing info
  • Re-scoped

Otherwise, if all variables are between 0 and 3, their sum gives you an effort score—which you can then match to T-shirt sizes or story points.

This tool encourages deep thinking while remaining lightweight. It’s especially effective in cross-functional teams where ambiguity is high and alignment is critical.



 Tool 3: Impact vs Effort Matrix

To improve decision-making during backlog refinement, consider pairing estimation with an Impact-Effort Matrix:

Rate each feature on:

  • Impact – how much value it brings
  • Effort – derived from the Estimation Equation above
  • Confidence – how sure are you of the first two?

Use these values to calculate ICE Score:

ICE Score = (Impact × Confidence) / Effort

This tool helps prioritize features not just by how big they are—but by how worthwhile they are.



Conclusion: From Silos to Shared Ownership

The hidden cost of internal client relationships isn't budget or time—it’s the loss of shared purpose.

When teams become vendors and internal clients become demanding customers, we lose the trust, transparency, and iterative learning that make great products possible.

Instead of relying on rigid estimates and performance contracts, we must build systems that:

  • Encourage collaborative sense-making
  • Use estimation tools to spark dialogue, not dictate timelines
  • Prioritize prototypes and MVPs for faster feedback
  • Respect that dependencies and uncertainty are part of the game, not exceptions

Because at the end of the day, we’re not solving internal problems—we’re building shared solutions.

Alain Vanderbeke April 6, 2025
Share this post
Archive
Sign in to leave a comment