Bijuraj Sarangi

The reasoning for going in-house is seductive.

“We know our business better than any partner”

“Our IT can manage it; it will be cheaper”

“We can live without a lot of things”

“We stay in control and we retain the knowledge”

“We will build internal capability”

Interestingly, all the above can be true, albeit under the right conditions. But, the right conditions are rarer than many of us realize.

Transformation is not a technology problem with a business wrapper. It’s a structural change problem with a business or a technology trigger.

The capabilities usually required for transformation; business analysis, enterprise architecture, technology solutioning, change management, agile delivery, DevSecOps, data governance and integration design, are scarce individually. Bringing them together in one team, with sufficient depth and ready to execute from day one, is something few organizations can realistically do.

And yet they decide to run it in-house.

What usually goes wrong?

Timelines slip in ways nobody anticipated: The team that looks capable in week one quickly discovers that internal decision cycles, competing business priorities, and the absence of dedicated, ring-fenced capacity make every phase longer than planned. A program scoped for 18 months quietly becomes 30. Then 36. Nobody announces this. The date just keeps moving. Add 20-25% extra cost on TCO.

The skill gaps reveal themselves late: Technical debt decisions that require deep architecture experience get made by people who are good but not experienced in this class of problem or even sufficiently experienced. Integration layers that a seasoned team would have handled cleanly become sources of rework months down the track. These skill gaps either go unnoticed or consciously ignored, until the gap starts costing something significant. Add 15-20% extra cost on TCO on account of specialist hiring, additional payout to partners to cover the gaps.

Simple things get complex: This is the one that surprises leaders most. A data migration that a team with the right experience would complete in eight weeks turns into a six-month exercise involving multiple vendors, a rebuilt data dictionary, and three rounds of UAT. It all happened, not because the problem was hard, but because the team didn’t know what they didn’t know. Add 10-15% extra cost on TCO.

Knowledge concentration becomes a single point of failure: One or two senior people carry most of the program understanding. When one of them leaves and in competitive talent markets, they often do, institutional knowledge walks out the door, and the program effectively restarts. Add 5-10% extra cost on TCO.

The opportunity cost is invisible: The direct costs of in-house delivery are visible. What’s not visible is the cost of being twelve months late to market. When a competitor launches a capability, you could have had operational a year earlier, the impact is not usually measured against the transformation budget, but it gets visible in terms of the business and operation KPIs and subsequently in the market share. Add a few times to the TCO on account of business loss and it usually is the biggest number of all.

Here is a scenario that’s worth running numbers on

Let’s say a mid-size financial services company decides to run a core platform modernization in-house.

Initial scope: $15M, 18 months.

This is what we usually see in such programs (in most cases)

Year 1: The team is assembled. Six months in, they realize the integration complexity is significantly higher than scoped. Two senior architects are hired at a premium. Timeline extends to 24 months. Budget creep to $19M.

Year 2: A key technical lead resigns midway through the delivery. Three months of knowledge recovery and onboarding cost $800K and delay go-live by four months. The board is told the program is “on track with minor adjustments.”

By delivery (Month 28): Total direct spend: $24M. Original budget: $15M. Overrun: 60%.

But here’s what doesn’t get reported in the program review:

• A competitor launched a comparable capability in Month 18. The 10-month head start gave them meaningful customer acquisition advantage.
• Internal staff distraction across IT and operations over 28 months, conservatively costed, adds $3-4M in productivity drag.
• Technical debt baked into the hastily-finished solution will cost $5-7M to remediate over the next three years.
• Opportunity cost of delayed revenue from new product capabilities: $8-12M (conservative, based on peer benchmarks).

Real TCO: $40-45M against a original $15M budget. It turns out, the in-house saving was not a saving, but a deferral of cost with compounding interest.

Various research find, only 30-35% of banks that attempt a digital transformation report successfully implementing their digital strategy. More than 50% of banking transformation programs exceed their initial timelines and budgets, with challenges driven by underestimated IT architecture complexity, misaligned stakeholders, and insufficient change management capacity. Research also shows that 70-80% of digital transformations go over budget.

Forrester’s 2024 State of Digital Transformation report found that governance breakdowns account for 58% of transformation failures, far above technical issues at 22%. When in-house teams don’t have the experience to establish strong governance frameworks from the outset, they are starting with the single biggest risk factor already in the red.

Think of the Flip Side: using partners to build

One interesting question is whether a transformation program can be structured in a way that external capability accelerates, and simultaneously builds internal capability. The answer is yes, but only if that’s a design principle from day one.

Partner brings the depth, the pace, the methodology, and the pattern recognition from having done this before. The client brings domain knowledge, business context, and people who are learning by doing, embedded in the work, not observing from the side. At the end, the client owns the capability. The partner leaves having built something.

This requires a different kind of partner conversation and a different kind of statement of work. It requires clients to define what capability they want to own in three years and work backwards from that. It requires partners to be honest about what they are transferring, not just what they’re delivering.

What this means for your decisions

If you’re looking at a transformation program and considering whether to do it in-house, run a TCO model and consider the following:

• The realistic timeline, consider 25-30% time extension in a best case at least and the corresponding budget overrun
• The cost of delays measured in market opportunity
• The talent risk: what happens if two key people leave at month X
• The technical debt your team will create through inexperience, and what it costs to resolve later
• The productivity drag on the business during a longer-than-planned program

Then compare that to the cost of bringing in a partner with real depth, not a tier 3 provider that gives just bodies, but an experienced partner who brings pattern recognition, delivery rigour, and a genuine commitment to transferring capability.

The math will look different than the initial instinct suggested.

In-house can work. But “can work” and “is the right call” are two different things. The cost of getting that wrong doesn’t land on the transformation budget, rather It lands on the business.

I have written at length about what happens when companies chase low-cost, tier 3 or tier 4 partners to run their transformation programs; “Cost of buying low cost”. The reality is, you get what you pay for, and usually a bit less – read more here.