In the telecommunications industry, Tier-2 (smaller) network operators often look up to their larger Tier-1 counterparts as models for building networks, telco standards and operational support systems (OSS). However, and the Tier-1 operators will never admit to this, but the lessons don’t always need to flow top-down from T1 to T2. In fact, the pragmatic approaches that Tier-2 operators adopt due to budget constraints can provide valuable insights for Tier-1 operators to learn from, especially in a time when profitability and OSS budgets are under pressure at many T1s.
While Tier-1 operators often take a bespoke, feature-heavy approach to OSS procurement, Tier-2 carriers tend to focus on practicality, speed, and cost-effectiveness (as per our most recent article). At PAOSS, we’re advocating for T1s to increasingly emulate the pragmatism of Tier-2 players – where leveraging off-the-shelf solutions and refining vendor selection processes might be a smarter way forward for the entire industry.
The Problems Caused by the Traditional “Three Forevers” Approach
One of the most pervasive traps in OSS procurement across both Tier-1 and Tier-2 operators is what we call the “Three Forevers” approach to vendor selection:
- Forever #1 – The Long Requirements List: This takes forever when operators, particularly Tier-1s, attempt to capture every conceivable need and whim in their requirement specifications. Moreover, this requires massive engagement with all stakeholders to battle it out over a list of requirements, most of which will never move the needle. The list is often driven more by the cleverness of the stakeholders being able to invent brilliant requirements (which may or may not ever really be needed). It’s common for an RFP to have thousands and thousands of requirements, in documents that are hundreds of pages long
- Forever #2 – The Lengthy Response Cycle: Due to the lengthy RFP documents and thousands of requirements, it often takes vendors forever to respond. When any of those requirements aren’t already in their solution, the vendors then need to determine a roadmap of features that need to be added. This can introduce more project risk, so risk margins are added to the costs
- Forever #3 – The Time-consuming Vendor Evaluation Cycle: Depending on how many vendor responses have been received, this is where a third forever can elapse. We’ve seen examples where there have been 20 vendor responses, each of thousands of pages, that the network operator then needs to evaluate. These bloated vendor evaluations have the potential for dragging out selection timelines and decision-making processes
And we haven’t even arrived at Forever #4 – Deep Evaluation or Forever #5 – The Implementation Process stages yet – where the complex, bespoke solutions chosen by Tier-1s often lead to prolonged evaluation, POC (Proof of Concept), development and integration cycles. Instead, we recommend the Inverted Pyramid approach to circumvent the first Three Forevers. Rather than starting with a massive requirements list to filter in, we start with all vendors and progressively filter out. The implementation process will still take its time regardless of using the traditional approach or our inverted pyramid approach.
How the Inverted Pyramid Approach helps with Vendor Selection
To avoid the pitfalls above, operators of all sizes can adopt the Inverted Pyramid Approach to vendor selection. This method prioritises the evaluation of off-the-shelf solutions first, starting from the list of 500+ vendors in our OSS/BSS Vendor Directory and a targeted list of “move the needle” requirements that we refine with customers. We might start with 500+ vendors but within weeks we’ve filtered this down to the best-fit solutions for deeper evaluation.
The Inverted Pyramid Approach flips the traditional model of OSS procurement:
- Filter #1 – Start with ALL Off-the-Shelf Solutions to Create a “Long-List” of Suitable Vendors: Begin the evaluation of the entire list of vendors in our vendor directory and filter based on the client’s required functional categories (eg Network Inventory, Network Assurance, etc). This quickly reduces the list from 500+ to around 30-50 candidate vendors with proven, standard solutions. Modern OSS vendors offer robust, scalable software that covers most common requirements within each of these categories, thus reducing the need for custom development
- Filter #2 – Apply the Client’s “Filter Questions” to Create a “Short-List” of Suitable Vendors: Review and refine a list of “filter questions” prepared by PAOSS in conjunction with the client. This is used to evaluate vendors against the unique high-level, “move-the-needle,” requirements of the client. The filter questions are crafted to create a combination of functional, pricing, support and other requirements of each client. These help to identify the top 3-5 best-fit solutions for the client’s needs. Very high-level (VROOM) price estimations appear at this stage
- Filter #3 – Conduct Demo Sessions with the “Short-List” Vendors: PAOSS works with the client to refine the list of end-to-end demo scenarios for the short-listed vendors to demonstrate. This helps to identify the product look and feel, capabilities and efficiency at performing end-to-end workflows, not just unit functionality. High-level pricing and TCO (Total Cost of Ownership) estimations appear at this stage. The objective of this stage is to identify the 1-2 vendors to proceed to POC (Proof of Concept) and detailed pricing / scoping
- Filter #4 – Thorough Product / Vendor Evaluation: This stage supports the much deeper analysis that needs to be planned in conjunction with client’s procurement rules (eg prep of business case, etc, etc). It typically involves a POC with a preferred vendor (or vendors) to test the end-to-end scenarios with the client’s context (ie their network, topologies, service types, processes, org chart, ops model, etc)
This approach enables Tier-2 operators to sidestep the first “Three Forevers,” while delivering results faster, with fewer resources and less internal prioritisation sessions discussing edge-case requirements. It’s a pragmatic model that Tier-1 operators could seriously consider – especially if they face shrinking OSS budgets, pressure to transform quickly and/or increasing market pressure.
Lessons in Pragmatism: A Tier-2 Perspective
Tier-2 operators don’t have the luxury of sprawling OSS budgets. Instead, they focus on extracting maximum value from minimal investment. They don’t try to design the “perfect” OSS; they aim for the best-fit OSS within their constraints and develop workarounds that aren’t available out of the box.
This mindset often results in faster, leaner and more effective implementations. Off-the-shelf solutions are favored not only for their affordability but for their shorter time-to-market—a factor that has become increasingly critical.
Our previous article, “Build, Buy, or Blend: The First Step on Your Roadmap to OSS Transformation Success,” underscores the importance of speed when selecting and implementing OSS solutions. It highlights how off-the-shelf options allow operators to achieve operational outcomes faster, making them more adaptable to market demands. Tier-1 operators, accustomed to large-scale, bespoke solutions, might find this pace daunting but it’s a necessity in today’s fast-moving telecom landscape.
Shrinking Budgets, Growing Need for Efficiency
For Tier-1 operators, OSS has traditionally been seen as a long-term, high-cost, high-complexity, highly-customised and high-risk investment. However, shrinking IT / OSS budgets may force them to rethink this model. The rigid, heavily-customised systems of the past are no longer sustainable, especially when pragmatic alternatives exist.
Tier-2 carriers’ ability to deploy off-the-shelf solutions quickly and iteratively should inspire Tier-1 operators to shed old habits. By adopting the Inverted Pyramid Approach, Tier-1s can prioritise speed and efficiency while still meeting their operational goals.
Final Thoughts: Building Faster (Better?) OSS without Breaking the Bank
The challenges faced by Tier-1 and Tier-2 operators certainly differ in scale and complexity. However, Tier-1 operators can learn from the lessons of Tier-2 operators by adopting the pragmatic, results-driven mindset of their smaller counterparts / competitors to build faster, leaner, and more cost-effective OSS.
Ultimately, the most important takeaway is that OSS success isn’t about who has the biggest budget – sometimes an OSS budget is too big. Instead, it’s about who can move the fastest while delivering the greatest value. And in this area, Tier-2 operators have a lot to teach their big brothers.