OSS Vendor Selection & Transformation Kick-off

“The hardest choices in life aren’t between what’s right and what’s wrong but between what’s right and what’s best.”
Jamie Ford

Have you been assigned the task of kicking off an OSS / BSS implementation project? Are you currently planning where to start?

Have you already experienced an OSS / BSS transformation? The process of transforming your OSS / BSS is full of potential pitfalls isn’t it? There are soooo many potential risks and issues to think about and overcome. Not only that, but there are so many alternatives to consider.

Guiding principles

We consider the following key principles when kicking off a transformation:

1. Develop an option reduction strategy – at the start, you have many alternatives to consider (eg vendors / products, technology, activities, activity sequencing, integrations, requirements, priorities, etc). This can lead to paralysis by analysis. For example, there are over 500 listings in our Blue Book OSS/BSS Vendors Directory, which sounds intimidating. How do you identify which ones are best for you? We find that by applying a few simple filters, we can usually get to a much shorter, and more manageable, list quite quickly. Apply these filters as early as possible to reduce effort for you and the vendors
2. Be pragmatic – unless you have the budget and appetite for lots of customisations, you’ll never get a perfect fit solution. Aim for best-fit rather than perfect fit – for compromise rather than compromised. This is an important consideration combined with point 1 above too. Being pragmatic may require prioritisation techniques, such as the Whale Curve
3. Re-consider your procurement objectives – the typical procurement KPIs don’t tend to work on large OSS / BSS projects. Consider these alternatives instead
4. If sourcing products from suppliers (instead of custom-built), don’t over-specify – the RADAR analogy is a good example of letting the market define their best-fit approach to solving your problems. Capture and define objectives rather than the detailed solution / requirements
5. Bake in change management strategies from the earliest stages (eg requirement gathering) – change management tends to be underestimated on OSS projects. Here’s an 8-step change management plan (Kotter)
6. Complexity / Variant-trees are OSS killers – similar to point 1 and 2, keep the project as simple as you can (hard for us technical-types)

Our Transformation Model

At Passionate About OSS, we’ve been through dozens of OSS / BSS transformations. Whilst every one of them has been different in many ways, we’ve sought to create building blocks along the way. These building blocks have been designed to make the process more repeatable and less risky. We continue to refine the process and customise for each customer’s unique situation.

Passionate About OSS initiated TM Forum’s GB1011 – The Transformation Project Framework (TPF) – which helps organisations plan, coordinate and de-risk their OSS transformations. We even received TM Forum’s Outstanding Contributor Award for this work.

The link below provides a high-level overview of the process we follow:

Download the Passionate About OSS Transformation Methodology here.

When conducting an OSS / BSS vendor selection process, the customer is effectively choosing a strategic business partner. It is likely that the solution will remain an important tool for the CSP for many years. Whilst benefits, functionality and technology are important evaluation factors, it’s also important to choose a vendor / integrator that is able to form a tight-knit business relationship with the customer.

Whilst we identify key factors for the CSP to determine their appropriate vendor, by correlation it will also identify key insights into how a vendor should position itself or differentiate itself to best form a lengthy relationship with the CSP.

We are clearly of the opinion that selling is about giving the customer what they need rather than trying to sell them on a product. As such, the vendor’s solution must be positioned such that it best meets the customer’s needs and this can only occur through a close understanding of the customer, their business model and where they are in the business life-cycle. Our vendor selection mechanisms allow the vendor to understand the CSP better and hence be able to deliver a more specific solution to meet their needs.

In some cases, the vendor may even be able to provide insights and present opportunities directly into the CSP’s business model that the CSP was never even aware of. Clearly these OSS solutions are a means to an end (business benefits) rather than an end unto themselves (software functions), but the CSP’s evaluation teams often focus on the latter.

OSS Vendor Selection Process

From the link above, the following is an example of a vendor selection process that we use to initiate discussions with customers.

You’ll notice that it includes conducting an initial shortlisting process to identify the vendors who have the tools of best fit for your requirements, followed by detailed product/vendor analysis, then through to commercials and contract.

If you need assistance with your vendor selection process, please leave us a message via the contact form below. We have a set of templates refined through helping many customers to select their OSS vendor that may also help your vendor selection.

OSS Budget Estimations

Naturally, pricing is a major consideration when choosing a vendor product. Each vendor has a different model for pricing their solution, which makes it very difficult to estimate the real TCO (Total Cost of Ownership). There are so many variables when finding the right OSS for a customer’s needs and the vendors have so much pricing flexibility that the best way is to design a set of requirements and request a quote. That’s the reason the RFI (Request for Information) and shortlisting steps have proven to be so important in the process flow shown in the diagram above.

Vendors know that OSS tools are very sticky and they often make it difficult for a CSP to remove them after they have been installed. As such, vendors know that the tools will remain in use for many years and can build their pricing model around this. This could include lowering the up-front costs significantly but reaping greater remuneration during subsequent years or via contract variations.

This blog entry provides initial rules of thumb for estimating the cost of your OctopOSS. It should be clearly noted that the variables are many so cost analysis requires a deep investigation of the vendor and their offering.

Some of the fundamental pricing questions for the vendor/s include:

• What licensing model do you use – Examples include per user, per concurrent user, per processor (ie servers and/or PCs that the applications are installed upon), open-source and/or cloud / consumption-based models. It also includes whether the licenses are recurring (eg annual) or perpetual. Annual licenses are often intertwined with the support fees (see next point)
• What warranty / support model do you offer – Examples include business hours only, 24×7, on-site support, remote support, etc. This also includes response times and other service level agreements (SLAs) that may be necessary
• Preferred pricing profile – one-time capital expense (CAPEX), versus ongoing license (OPEX) or a blended profile to suit budget profiles
• Update schedule – how often are updates released to customers (eg every 3 months, as needed, etc). This also can tie in with the license costs and support models offered by the vendor
• What turnaround is offered when remedying bugs and are there separate classifications depending on the severity of the required bug-fix (eg mission critical / severe, major, minor, etc)
• What is the scaling model in terms of licenses (eg do licenses increase in blocks of 50 additional concurrent licenses or increments on a per user basis)
• What is the scaling model in terms of hardware/software (eg can the hardware/software be scaled and if so, what metrics are used). More importantly, are there any upper limits on the scalability of the solution being offering
• What are the known risks / issues to be aware of when installing the vendor’s solution. There are always risks and issues that the vendors should openly share with the CSP so that both parties can deal with them transparently from the start
• What is the product roadmap for introduction of new products, services, features

Building an OSS / BSS Business Case

You can find our OSS Business Case Builder by clicking below:

You can view more about the vendor selection support services we offer here.

To book a time to informally discuss your OSS Transformation Kick-off strategy, fill in the contact form below.