This is the sixth of the “buyer / seller chasm” series of articles (pt1, pt2, pt3, pt4, pt5). In it, we consider how to bring Buyers and Sellers together more effectively to build better telcos. We’d previously highlighted the issues, the pain points, the sources of friction, a bunch of solutions and more.
The title of this article poses the question that best exemplifies the chasm between buyers and sellers – the question that’s top-of-mind for buyers before kicking off any transformation project – “What’s the worst thing that could happen on an OSS transformation?”
In today’s article we’ll explore how different transformation approaches can help to narrow the span of this part of the buyer – seller chasm.
The image below is of a bridge that’s being ambitiously constructed to span the vast chasm between a telco’s current state and desired future state – the buyer’s current state on the left and the seller’s promise of a better, modern future on the right of the chasm.
A huge amount of time, planning and cost has clearly gone into the build to date. However, it’s also obvious that this project is very unlikely to ever reach completion.
It’s a clear metaphor for why OSS transformations are so widely feared and avoided, keeping buyers and sellers apart.
The fear stems from past digital transformation projects that have collapsed before they can serve their intended purpose.
In this article, we’ll ponder the title question but through two crucially different lenses regarding any significant OSS transformation:
It’s easy to imagine a bridge slowly built across a chasm, representing the OSS transformation journey from old to new. It’s designed to deliver a seamless transition, carrying the traffic of data, processes, and functionalities – and hopes and dreams of the telco – across the void. But what if this bridge collapses, like in the diagram above, having never carried a single vehicle or pedestrian? The fall-out is significant, for the people involved and in terms of the opportunity cost for the telco.
What’s really interesting is that most off-the-shelf OSS platforms are functional out of the box. Think of it like a helicopter dropping in the initial frame of the bridge that spans both sides. It may not be perfectly customised, but it represents an initial span that can then be solidified.
Even if this initial span can only support a singular process or a single pedestrian, it symbolises something critical – momentum and proof of value. This initial success is pivotal for garnering continued buy-in from stakeholders. It’s the cornerstone for the project team to create a narrative of business value, then building on it progressively. The final solution no longer seems so far from completion.
The alternative approach, that is still most widely used when buyers and sellers embark on transformation projects, is often dubbed the ‘big bang’ or perfection approach. The big bang envisions an OSS bearing its full load from day one (at some point many years in the future) with little room to iterate along the way. However, this approach is fraught with risks. Money, momentum, confidence, and business support often run out long before this grand vision is ever realised, thus never delivering business value. This type of transformation can often becomes a bridge that collapses under the weight of its own ambition.
We discuss the alternate ways of planning an OSS transformation here.
Now, let’s consider the second ‘worst thing’ scenario: what happens to the telco if the OSS transformation doesn’t succeed, or worse, doesn’t even start because buyers and sellers remain at arms length? It could even be argued that this “worst-case” could actually be more detrimental than the project failing. Due to the chasm in trust, risk and confidence, the business remains stuck in its current state, unable to cross into its desired future state. This stagnation can have dire operational and business consequences for the telco:
To answer the title question, the worst things that can happen in an OSS transformation are either:
Both stem from buyers and sellers being unable to navigate the chasm of transformation safely, leaving buyers unable to reach their desired future state without falling into the abyss of obsolescence or overambition.
Like the concepts posed in earlier articles in this series, it’s our collective task to find better ways to reduce the breadth of the buyer – seller chasm, or at least the buyer’s perception of how wide and daunting the chasm is.
We’d love to hear from you in the comments below if you recommend techniques or technologies that help narrow or bridge the gap.
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
