What If Elon Musk Were Put in Charge of Your OSS Transformation?

Our last article asked a simple question, “How much are you effectively paying to stay on the antiquated side of the Buyer-Seller Chasm?”

Let’s be very clear here – the incurred cost (opportunity cost) of dated systems doesn’t stop while you’re deciding what to do next.

Every month spent debating, aligning, lobbying, approving and re-approving is another month your organisation bears the costs of dealing with the limitations / constraints of your current OSS/BSS.

So, that made me wonder… What would happen if someone with an extreme bias towards action took control of your OSS transformation tomorrow? Someone like an Elon Musk for example.

I’m not even talking about the OSS implementation phase here yet. That’s a longer conversation.

For this article, I’m only interested in whether Elon would do anything differently during the pre-implementation phase. That’s the time between when someone spawns the idea of a transformation and when that transformation project actually proceeds. Would he be accept a pre-implementation phase taking 6, 12, 18, 24 months or more?

Having read Musk’s biography by Walter Isaacsson, I think it’s safe to say he wouldn’t accept those timeframes.

So, how quickly would he decide that change was necessary? What information would he insist on having to make the decision? What risks would he accept and still proceed anyway? What parts of the process would he strip away or modify to ensure a decision is arrived at much faster? And what would he change on the path to get the decision made much faster?

As ill-fitting as it might be on my head, in this article I’ll put the “Musk hat” on and even compare with how PAOSS fast-tracks OSS transformations for network operator clients.

.

Careful doesn’t have to mean slow

OSS transformation decisions are difficult for good reason. They’re expensive. They’re disruptive. They affect critical systems. They’re complex.

As Kevin Stokell suggested on the previous article, “Carriers see OSS as a sunk-cost cost-center that “already works,” and ripping out deeply-integrated legacy systems is high-risk with payback that lands years later so it loses every budget fight to revenue-generating projects. Operators simply make risk acceptance decisions.”

Kevin’s right. Getting these decisions wrong can also have very real consequences for the organisation and its operations for years to come. The argument for a new / transformed OSS needs to be highly persuasive.

This isn’t an argument for high risk / recklessness or unnecessary speed. However, I’m also not convinced that taking 18 months to proceed will make it better than a decision made in 3 months or less. [One slight side-bar conversation in relation to Kevin’s quote is that I’m not always convinced that a solution “already works.” It’s more a case of “it barely works” in many cases, which is why a transformation and modernisation is so necessary].

Sometimes more decision time brings more evidence and greater clarity. Other times it just brings more meetings and procrastination.

.

Authority changes everything

The Musk comparison is obviously imperfect. Most people leading an OSS transformation don’t have anything like his level of decision control. They don’t own or even lead the company in most cases.

Most OSS decision-makers need agreement from executives, finance, procurement, architecture, operations, security and countless other stakeholders. That’s a lot of stakeholder management (which I suspect Musk doesn’t have to worry about as much).

Worse still, if the transformation goes badly, OSS decision-maker careers may be on the line. That understandably changes the way people make decisions.

However, I should also point out that Musk has enormous amounts at stake when his decisions go wrong. More than a humble employee, you could argue.

So perhaps the more interesting question isn’t whether we should make decisions like Elon. Instead I’ll ponder what someone with an extreme bias towards action, someone wearing “the musk hat,” would see and do.

.

The cost of not deciding

We spend a lot of time analysing the risk of making the wrong transformation decision. But do we ever think about the risk of making no decision?

While we wait, the existing OSS doesn’t suddenly become more flexible, more capable or more efficient. The manual processes don’t disappear. The workarounds don’t stop multiplying. The organisation doesn’t get the capabilities it knows it needs. The new offers and revenues don’t get to market faster.

The meter keeps running.

So perhaps, before another month passes, buyers should ask themselves a few of the following questions:

1. How long are we prepared to keep paying the cost of the current OSS while we decide what replaces it?
2. Does the business case include the daily / weekly / monthly opportunity cost that is incurred while a go-forward decision is being made?
3. What information do we genuinely still need before we can make the decision?
4. How do we cull the decision-points that don’t really move the needle?
5. Which approvals genuinely reduce risk – and which simply spread accountability?
6. If someone with far greater decision authority arrived tomorrow, which blockers would they strip away immediately?
7. Are we being careful, or have we simply become comfortable with moving slowly?
8. What would have to be true for us to make this decision in <90 days instead of 18 months?
9. Which parts of our decision process exist because they’re necessary – and which exist because they’ve always existed?
10. Who personally carries the downside if the decision goes wrong – and how much is that shaping the speed of the decision?
11. Who potentially prospers from others carrying the downside risk?
12. Are we spending more effort protecting ourselves from making the wrong decision than understanding the cost of making no decision?
13. If the organisation already broadly agrees that change is necessary, what exactly are we waiting for?
14. Are our processes like The Burning Rings of Fire (ie arduous, ever-smaller hoops to jump through on the approval, but with no assessment after approval to act as a continual improvement decision feedback loop)?

Make the Decision Easier to Make

Moving faster doesn’t have to mean taking more risk. In fact, much of the delay in OSS transformation comes from trying to investigate everything, document everything and compare everyone at the same level of detail before making a decision. The PAOSS Inverted Pyramid approach turns that around:

• Filter 1 – We start with the broad market (of 500+ vendors) and quickly eliminate the solutions that clearly don’t fit (ie if you need a convertible, there’s no point looking at SUVs)
• Filter 2 – Then narrow the field based on the handful of capabilities and constraints that really matter
• Filter 3 – Then take a closer look at the strongest candidates in action
• Filter 4 – Then invest the serious time, testing and due diligence only in the one or two solutions that have earned their way to the bottom of the inverted pyramid, before selecting the best-fit solution for your organisation

The Inverted Pyramid is not about shortcutting the decision. It’s about getting to the information that matters faster, reducing the number of unknowns and unnecessary decisions (eliminating the Three Forevers) then giving decision-makers greater confidence to act.

PAOSS works on the buyer’s side of the chasm. Our Blue Book OSS/BSS Vendor Directory, vendor knowledge and Inverted Pyramid approach are designed to help you turn a daunting market into a manageable decision – and reduce the time between knowing change is needed and confidently getting it underway.

If your organisation is ready to transform but struggling to turn that intent into a decision, perhaps we can help you cross the chasm sooner. First, read this article to understand more about our approach, then contact us to schedule a no-obligation chat.

The point is not that every OSS buyer can or should behave like Elon Musk. It’s that OSS transformations need someone wearing “the musk hat” throughout, making decisions with an extreme bias towards action. That’s how we arrived at the Inverted Pyramid approach, asking what unnecessary steps can be removed to expedite the OSS transformation process.

It’s definitely worth asking yourself the same types of questions before another month of opportunity cost gets added to your bill.