Avoiding dead-end digital transformation projects

Avoiding dead-end digital transformation projects

“If you don't know where you are going, you might wind up someplace else.”

- Yogi Berra

Those of us who have spent enough time in telecom know this all too well. 

We’ve seen the slow, tragic death of transformation projects that got far down the line only to run out of budget or into unforeseen challenges. 

No one gets out unscathed when this happens. Vendors have wasted precious time and money. Operators don’t get the features and business benefits they desperately need. Financial stakeholders lose patience. 

Digital transformation initiatives are especially prone to this fate given the complexity of integrating myriad new and legacy systems. Yet, for every single telco, getting these projects right and on time is essential to survival. 

So what needs to happen on the people, skills and systems front to ensure success? Well, a considerable amount of homework for starters. 

Let’s explore some of the reasons big projects go astray and what can be done to keep them on track and on budget. Our perspective is informed by the early work we are doing with customers implementing solutions with multiple systems and integration points for data driven operations and automation. In these engagements, we have seen many recurring hallmarks of winning strategies, beginning with a clear understanding of what is actually needed. 

A simple question with a complicated answer: What is needed? 

At the outset of a project, it needs to be clear what is needed. Not just, “I want to buy features X, Y and Z,” but what exactly are these features and will they be the only ones needed? Here, we are trying to understand what the user story is. 

As simple as it sounds, this is often challenging to articulate, resulting in only snippets of requirements being conveyed to stakeholders. When these snippets are given to vendors as requirements, they will respond that they are “compliant” or “not compliant” and it is not until the project delivery phase that technical and solution gaps appear and problems arise. 

Customers often expect vendors to anticipate the problems that may exist within an organization but the fact is vendors will never fully understand the inner workings of a customer before an engagement begins. Therefore, success hinges on uncovering in advance the technical complexities of the deployment, especially limitations that may exist and the scope of the teams that will be needed to support. 

When this crucial step is skipped, operators are at the mercy of vendors that must map the environment as they go. When unanticipated problems arise, such as a requirement for more IP backbone capacity, an integration with an unexpected legacy system or an integration that must happen six times instead of one, the project cost balloons. 

Especially with complex, high stakes initiatives like the integration of automation and AI, operators will be best positioned if they map a detailed lay of the land before engaging vendors. This has the added benefit of accelerating timetables and improving requirements gathering that makes it easier to assign an appropriate cost to the project. 

What is the true cost of the project? 

$200 headphones are worth it to me because I travel often, frequently do conference calls and value noise cancellation. My mother would never consider paying this much for headphones because a $20 pair is more than capable of serving her primary use case of listening to music quietly at home. 

If operators don’t understand what they will ask of vendors beyond an end-state vision, they will not be able to appropriately value the initiative and set a budget to achieve it. 

In our experience, the best way to calculate the true value scope is to:

  • Develop a clear understanding of what is needed and develop a business case to match what is desired to an appropriate budget. 
  • Determine whether the organizational structure, people and time capacity exist to be successful. 
  • Understand at a deeper level the technical landscape, such as the number of instances of a system, software versions and capability to consume and expose data in a given format.

This work will provide the information needed to plot the best path to achieving the new vision and help establish a more accurate budget projection. After all, we know the cost of a solution is not simply the sum of the components. 

In telecom, not having a clear integration scope can be a project killer. The reality is that the end-state architecture always includes existing systems that need adaptation to the new wanted operating model. These costs need to be proactively accounted for. 

A real world perspective on preparation

I was once part of a solutioning team exploring how to utilize the use of telemetry data coming from the RAN to enable near real-time collection of call trace details and performance degradation. The benefits of collecting RAN metrics in telemetry format supports reacting to changes as they appear versus waiting for traditional data collection and processing, but also introduces high volumes of small data chunks to flow through the IP backbone. 

As we peeled back the onion of how to accommodate this functionality, we determined that our IP backbone was insufficient and that we needed to scale up capacity. This is an example where three system owners that usually don’t directly collaborate on use cases needed to sit down and work out a common solution and plan for execution.

Ultimately, we determined exactly how our organizational infrastructure would be impacted. We went step by step, combing through every roadblock and cost implication. This took time but when we reached the buying stage, we knew exactly what we needed, what the roadblocks would be and what budget could be expected to support it. 

Better to plan the journey than let the journey dictate the plan

When it comes to massively complex digital transformation projects, it will always be faster and cheaper to spend the time needed up front to understand every facet versus diving straight into long vendor engagements where every day brings a new discovery of what was not known.

The reward for this hard work is ending up exactly where you planned at the cost expected. 

So what have your experiences been on this front? We’d love to hear the good and the bad in the comments!

Mention the author, Perivoye Stoyanovski , in the comments to start a conversation.

Pankaj Hadke

Digital BSS Transformation | Microservices | API Design

5mo

Perivoye Stoyanovski Thank you for sharing honest feedback on digital transformation strategy. It is imperative to have a detailed plan right from feature definition to code deployment and evolution strategy. Business must understand technology and technology must understand business for transformation programs to succeed.

James Lindsay

Championing Autonomous RAN ¦ Pioneering O-RAN/vRAN Revolution ¦ German Digital Re-Invention ¦ eSIM/iSIM Adoption

5mo

Perivoye Stoyanovski Thank you for the blog post & some good points. Lack of clearly articulated requirements, leading to an almost incoherent user story from the stakeholder. Leading to, in my experience, delivery of full features/functions capabilities in parts. As in post successful validation trials. Operational deployment is planned within Q1, but only some of the capability is delivered, then the remainder across Q2/Q3. Or even worse it mutates to something not required.

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics