In our experience, there are five mistakes telcos can make at the outset that impede or even sink the transformation. (See the exhibit.) By understanding these “recipes for failure,” telcos can start on the right foot—and be better poised for success.

Not Looking at the Big Picture

Many telcos go into a transformation with a specific goal. Modernizing the tech stack, for instance, can lower IT costs. But such a change can have a ripple effect across the business. If the aim is to create IT savings, rigid standardization makes a lot of sense. But beyond IT, that choice has a price, as it can limit the company’s ability to offer customized products.

In many transformations, this critical wider perspective is missing. As telcos get deeper into the project and unanticipated issues arise, the inevitable response is to add more to the mix: more changes, more complexity, more tasks for the teams leading the effort. A once-realistic timeline becomes overly ambitious, and invariably, deadlines pass and frustration grows.

It also becomes harder to sustain the funding and momentum for the journey. IT transformations typically take two to four years. During that time, the company will be building and operating the new IT stack while still running legacy systems. That’s two to four years of extra burden on business and technology resources—most notably, the budget. While transformation partners such as system integrators can reduce the pain by lowering upfront fees and recouping the difference through maintenance and operating contracts down the road, an IT transformation remains a significant long-term investment. To support the continuing expense, telcos need a business case that covers the big picture, one that considers how the contemplated transformation can reshape how the telco operates—and how it serves its customers, creates value, and accelerates growth.

This means focusing on more than IT changes. The self-funded journey—IT changes paying for themselves, and then some—doesn’t exist. Simplified processes, revamped product portfolios and contract structures, a culture that’s responsive and receptive to change: all are elements of a successful transformation.

Waiting Too Long to Bring in the Business Side

Many transformations are IT-led—and it’s not hard to see why. A large part of the effort will involve designing, selecting, and implementing new software. Furthermore, IT often has a positive track record, having steered shifts to new market solutions in areas like large-enterprise sales or workforce management. Indeed, it’s often this past success that sparks excitement for a larger-scale transformation. Yet almost all IT-led transformations fail.

Why don’t the dots connect? To put it simply: scale counts. Modernizing an entire BSS or OSS is a whole different game than replacing an application for a specific function or business line. Telcos need to have clarity around the project scope, sourcing strategy and operating model, and business impact. And they need it from the start. The business side is the natural source for this insight, but it often enters the picture too late to help shape the project. Telcos wind up working out the details as they go, which all but guarantees failure. In our experience, companies see better results when transformation is a business-led effort with strong engagement of IT. This approach creates clarity and alignment at the outset.

Going Half-In on Agile

More collaborative than traditional ways of working, agile accelerates innovation and responsiveness, helping companies move and adapt to change faster and more precisely. Not surprisingly, agile-run transformations are increasingly the norm. Yet many telcos adopt agile without truly empowering it.

Getting the most out of agile requires a shift in mindset and culture, along with a high—and for most telcos, unprecedented—level of coordination across IT, the business, support functions, and system integrators. The heart of agile is the cross-functional team: product owners from the business side collaborating with IT experts to tackle and share accountability for a specific capability, feature, or function. Companies must also put in place the infrastructure and processes, such as automated software lifecycle management, to support the effort. And to make it all stick, they’ll need robust coaching, training, and change management.

That’s a lot to get right. Depending on a telco’s starting point, it may be a year or more before an agile-fueled “transformation engine” is running at full steam. This ramping up often comes as a surprise to telcos, as does its impact on the overall transformation timeline and budget. But only by unleashing agile’s full potential can telcos realize a successful transformation.

Forgetting to Align Incentives

Different stakeholders in a transformation are bound to have different priorities. The business side typically looks to increase revenue, enhance the customer experience, and lower operating costs. IT commonly seeks to simplify the application landscape, retire costly legacy systems, and create a future-proof, easy-to-maintain IT architecture. The network side often looks to increase automation.

Now add system integrators to the mix. They’ll want to optimize their resource management; for example, by spreading their best employees over multiple clients instead of concentrating them on any one project. And it’s often in their financial interest to customize solutions instead of implementing out-of-the-box functionality.

These varying goals and the choices they trigger can complicate, or even doom, a transformation. Consider, for example, an IT department looking to reduce IT costs or complexity. To meet this goal, it prunes the number of applications. Meanwhile, to increase automation, the network department builds up a software-defined network. Instead of working hand in hand, initiatives conflict: IT shrinks the application landscape; network expands it.

Better collaboration mitigates this problem, but doesn’t, by itself, solve it. The key is to align incentives, which ideally would be reflected in contracts with external partners and in commitments among in-house stakeholders. For example, a contract with a system integrator could specify staffing criteria or that the integrators customize offerings only when doing so gives the telco a truly differentiating capability. Internally, IT and the business could agree from the outset on factors like resource allocation, rollout schedules, and budget.

Lacking a Control Tower

Robust program management—the kind that keeps a transformation on schedule and on point—creates transparency, enables quick decision making, and helps companies identify and tackle any fault lines. It also tends to be missing from many transformations.

That’s because telcos often fail to establish and empower a “control tower,” an independent entity that continually monitors the transformation, assuring its ability to create value. Clear and constant visibility into the project allows the control tower to facilitate fast, effective responses—based on data, not perception or speculation—to issues that threaten to delay or even derail the transformation.

The best control towers serve as a sort of transformation “glue,” linking the steering committee or board with the people on the ground making the changes. Control towers should be activist and opinionated when necessary. But for optimal impact, telcos need to pair them with a culture in which everyone from the C-suite down readily acknowledges and addresses problems and mistakes. By taking these steps, telcos can avoid the tendency—endemic to failed transformations—to push issues to the side and hope that they will somehow resolve, or to let them bubble slowly up the chain of command.

Large-scale transformations are risky, but many companies increase the danger by starting with one hand tied behind their back. By avoiding the recipes for failure we’ve identified, telcos can begin from a more advantageous position. They can lay the groundwork and build momentum for a transformation that lives up to its billing—and then some.

The authors thank Frank Felden, Jörg Hermes, and Caroline Dunkel for their contributions to this article.