MacGyvering Your OSS Budget: A Contrarian Approach to Solving an OSS Cost Conundrum

There are many reasons why it’s hard to get an OSS transformation project off the ground. One of those reasons, a big one, is the catch-22 situation that arises when setting the budget for a project. How much does an OSS cost? How long is a piece of string?

Some carriers, especially the smaller telcos that don’t embark on OSS transformations very often, don’t know how much their desired OSS solutions might typically cost, making it impossible to set an initial budget. But without a budget, the OSS vendors can’t tell the telcos how much of their desired scope can realistically be delivered.

To make matters even slightly more tricky, almost every telco I speak with refers to the cost-benefit conundrum. They say that if the benefits (and functionality) are high, they can justify spending a little more. If the benefits are smaller, then the budget will need to be smaller too… But then how do they even translate functionality into benefits anyway? We’re back at that proverbial piece of string again.

It’s a classic chicken-or-egg scenario that leaves many stuck scratching their heads.

In this article, we describe the technique we use to unscramble this egg. It’s a technique that helps to deliver a cost to benefit estimate quite quickly. We find this helps our telco clients to establish an order of magnitude budget that facilitates further discussions (internally and externally) as well as the many subsequent decisions that need to be made to stand up an OSS transformation project. But more on that later.

The Enigma of OSS Solution Sizing

OSS solutions are like the Swiss Army knives of the telecom world—they’re able to do a bit of everything. They manage network inventory, keep services running smoothly, handle network provisioning, tackle faults and much more. Each vendor has a different mix of these high-level functionalities, let alone at the detailed functionality level. Being software, if they can’t already do everything out of the box, every vendor can make them do anything – a bit like MacGyver, with duct-tape and a paper clip (and I can’t miss the opportunity to mention the proverbial piece of string again!).

However, depending on how much MacGyvering is required on your OSS, the cost of these solutions can vary wildly depending on:

• Network Size: Bigger networks (and larger numbers of network make/model variants) need bigger (ie pricier) solutions
• Integration Level: The more you need it to talk to your other systems, the more it costs
• Customisation Needs: MacGyver-level customisation requests come with special price tags
• Number of Users: The more users involved or adversaries to overcome, the higher the licence count (and cost)
• Vendor and Technology Choices: Different network products, topologies, interfaces and technologies come with their own pricing quirks
• And this is only the start of sizing / dimensioning models. In recent times I’ve even seen variable pricing based on the carrier’s share-price change

Naturally, different vendors have totally different pricing models. There are no apples-for-apples comparisons here! And being software, which has almost no marginal cost of production, OSS vendors can get creative to adjust pricing, not least by playing with different CAPEX vs OPEX balances to fit a carrier’s budget for each. Oh wait, we’re still stuck in trying to determine an overall budget, let alone CAPEX vs OPEX or cloud vs on-prem infrastructure budget allocations.

An Almost Endless Loop of Uncertainty

Without a clear idea of how much an OSS solution will cost, carriers find themselves in a perpetual state of both technical and financial limbo. This can lead to several comically frustrating outcomes:

• Underbudgeting or Overbudgeting: Guess too low, and the project stalls whilst additional funds are sought; guess too high, and you risk the transformation project ending up over-blown (like the hundreds of fuel-tanks in every MacGyver episode)
• Decision Paralysis: Fear of making a costly mistake leads to inaction, delaying essential upgrades and increasing opportunity costs
• Strategic Misalignment: Without a solid budget, aligning OSS investments with broader goals and budget envelopes is like trying to hit a moving target while blindfolded (not a problem MacGyver ever had though)
• Clumsy Buyer / Seller Dances: Where finding a happy medium can often take months of backwards and forwards of adding and removing scope to get the right cost / benefit balance. And that’s just assuming you’re dealing with one vendor. If you’re considering multiple then it can be difficult to gain any sense of comparative pricing

Traditional Strategies to Break the Cycle

There are a few techniques the industry typically use to break free from this budgetary merry-go-round, thus getting to an agreed commitment to buy (and commencement of the transformation). These techniques certainly can work, but they often have drawbacks:

1. RFP Processes: Sending out detailed requests for proposals to vendors can yield precise cost estimates. Due to the “Three Forevers” approach, this can be very costly and time-consuming. Did anyone say “Kill the RFP?”
2. Market Research and Benchmarking: Gathering data from industry reports and peers can work in theory, but every telco’s needs are vastly different from others’. As a result, this data tends to be directional at best
3. Phased Implementation: Start small and expand. This is often a really good idea for implementation. Implementing OSS solutions in phases helps refine budget estimates over time. The only problem is that this approach requires a preferred-bidder decision to have already been made. It’s preferable to compare and refine before getting that far down the procurement path
4. Proof of Concept (PoC) Projects: Running small-scale trials can reveal the better cost implications before full commitment. Similar to the previous point, PoCs are a great approach, but only after you’re already convinced you have found the best-fit vendor for your needs
5. Agile Financial Planning: Adopting agile methodologies allows for continuous budget adjustments. This budgeting on the fly is great if you already have a great partnership with your preferred vendors, but that’s not always the case. In fact, many OSS transformations are only being considered because the current state products / vendors aren’t ideal
6. Vendor Partnerships: Building strong relationships with vendors can lead to more transparent pricing and potential discounts. Even if you are in that enviable position, it still usually needs a lot of effort to gather the volumetrics and required scope to get a price-point from your trusted partners. Unfortunately, this approach also doesn’t allow you to test whether there is another better-fit solution available for you on the market

Is There a Better Way?

We believe there is, but we could be a little biased (or perhaps even delusional, much like MacGyver scripts). We’re about to walk you through the approach we use and you can let us know your thoughts. We’ve found it to be useful across a multitude of vendor selection processes we’ve run with clients.

We use an Inverted Pyramid vendor selection approach and a number of “Filter questions” that are unique to each different carrier. We start off by performing a paper study that evaluates every vendor in our Blue Book OSS/BSS Vendor Directory against the telco’s requirements. At the time of writing, there are nearly 600 vendors in the directory.

The first filter looks at comparing the high-level functionality offered by each vendor against the carrier’s very-high-level functional requirements. That usually narrows the search from ~600 (the full list) down to around 30 to 50 (the long-list).

We then ask carrier-specific “filter questions” to the long-list of vendors. In addition to questions that determine functionality coverage, we also ask vendors for price-bracketing information. At this stage, we haven’t collected or shared the sizing information that a vendor would need to prepare detailed pricing. However, we can ask them for information about which pricing brackets their past projects have tended to fall within – like the following table:

Some vendors may select just one bracket (eg less than US$100k) because all projects are less than this. Others might choose 3 or 4 brackets because their projects could range from US$100k to 10M depending on size and scope.

This helps to provide us with a cost profile like the one below:

The carrier can immediately start to understand the orders of magnitude of their project within this one simple graph.

But we still need to drill down further. We can now start to look at what level of functionality / compliance is offered within each of these brackets. For example, the three vendors in the sub-$100k bracket might not deliver suitable functionality, so we can filter those out. Then perhaps 5 of the 9 in the $100k to $500k bracket do appear to deliver viable functionality so we can take a closer look at those.

It also means we can filter out all those vendors that are above $1M (for now at least because there seem to be 24 offerings that are plausibly below $1M, but that’s still to be further tested). The carrier can now confidently say that their budget is approximately $500k.

In this case, for vendors whose OSS Linda Evangelista Number is above $1M, they know the carrier’s budgets are too small to be of interest and therefore don’t have to waste their time or incur extra cost of sale.

As you can see, by applying cost, functionality, support, etc filters, we’re now getting down to a short-list for detailed evaluation. We also have evidence why others were filtered out in case any colleagues ask mid-way through a project.

BTW. We can prepare a similar profile for project duration to help our clients generate their project implementation and resourcing plans.

If you’re a carrier that is currently stuck in this type of OSS Budget Conundrum, leave us a note and we’d be delighted to walk you through the approach we use. Alternatively, if you’re a vendor and know a prospective client is similarly stuck on budget, we’d be delighted to guide them through this and the many other hurdles that await them on their OSS transformation.