How rigorous OSS procurement can still get the transformation completely wrong

Most OSS experts focus on the implementation and post-go-live performance aspects of a transformation. That makes perfect sense, because they’re the most visible phases. But by the time implementation begins, many of the decisions that shape success or failure have already been set in place.

The pre-implementation phase is often underestimated – treated as a vendor selection exercise – a period of requirements, demos, scorecards and negotiation. In reality, it’s where the transformation is positioned for success or unwittingly set up to struggle.

How do I know? PAOSS specialises in the pre-implementation phase: helping clients ask the right questions before commitments send them down an expensive but misaligned path.

The following five questions should help steer you on your pre-implementation phase.

1. Are we solving the right operational problems?

Many OSS transformations start with a familiar set of frustrations.

The tools are old. Processes are slow. Inventory can’t be relied upon. Teams overcome gaps by using spreadsheets. Automation is limited. Reporting is inconsistent. Customers are waiting too long. Engineers are working around systems instead of through them.

These are real problems no doubt, but they’re often symptoms rather than causes.

Before an organisation starts selecting vendors, it needs to understand what kind of problem it’s really trying to solve and where it’s going to steer the organisation. Remember, OSS and BSS aren’t just operations tools. They steer the entire business model, as shown in the diagram below.

So to come back to the point, what’s the real problem? Is the main issue the platform itself? Are tools preventing more efficient workflows or new offers being made? Is it poor data quality? Is it unclear accountability between teams? Is it an operating model that no longer fits the network, service portfolio or customer promise?

An RFP can become a long list of frustrations translated into software requirements. That creates the illusion of completeness, but it doesn’t necessarily create a clear, strategic direction.

A vendor can respond to requirements. They can demonstrate capability. They can show how their platform supports certain use cases. But they can’t compensate for a transformation that’s been framed around the wrong problem. That’s like kicking towards the wrong goalposts.

The first pre-implementation question is therefore simple, but often uncomfortable: are we solving the right operational problem? Not for day 1 after go-live, but for the next 5-10 years into the future when the solution will still be in production.

Until that answer is clear, vendor selection risks becoming a very structured way to make the wrong decision.

..

2. What target state are we trying to reach – and what waypoints make the target possible?

Most OSS transformations have some form of target state in mind. There may be a target architecture, a future systems landscape, a capability model or a set of automation ambitions.

But this is one of my biggest bug-bears with OSS implementation plans. They design for an idealistic end-state that is never possible to reach because they don’t consider the numerous constraints that need to be overcome along the way.

Plotting a path through a tangled mess of legacy systems is often far more challenging than designing a bright shiny end state.

Moreover, target architecture isn’t the same as a target operating model.

The organisation may need guidance to consider how work could / will flow in the future. Which teams will own which decisions? Which processes will be standardised? Are M&A (ie OSS consolidation) events likely? Which activities will be automated? Will their be pivots in business and revenue models? Which legacy systems will remain for a period of time? Which compromises are acceptable along the way?

This is where waypoints matter.

A transformation doesn’t move from current state to ideal future state in one leap. It moves through a series of practical transition states. Each stepping stone state needs to be achievable.

Without these waypoints, it’s common for too many dependencies and constraints to be ignored.

A strong pre-implementation phase makes the journey visible before the contract is signed. It tests the ambition against sequencing, dependencies, constraints and capacity.

The question isn’t just “where do we want to get to?” It’s also “what’s the credible path from here to there?”

And here’s the interesting thing about the pre-implementation phase – the activities here are far more consistent / repeatable, regardless of what type of transformation you’re undertaking, than for later phases. That’s what we built the Transformation Project Framework around (refer to TM Forum GB1011).

.

3. Do stakeholders agree on what success means – and are they planning far enough ahead?

As per the earlier diagram, OSS transformation touches many parts of the organisation. In fact, probably almost every part of the organisation.

Operations want stability and efficiency. IT wants rationalisation and integration discipline. Network teams want technical accuracy and operational control. Finance wants cost confidence. Marking and sales want hot, convertible leads. Executives want strategic outcomes. Customer-facing teams want better service performance.

Everyone may agree that change is needed. That doesn’t mean they agree on what success means.

This is one of the most common pre-implementation traps. Stakeholders align around the need for transformation, but not around the decisions that will shape it or the metrics that prove whether it’s successful. They support the programme in principle, but carry different assumptions about priorities, trade-offs, ownership and timing.

Those differences often stay hidden during early procurement because everyone’s excited to start the journey. There are workshops, requirements documents, vendor responses, etc. But once implementation begins, unresolved expectations and assumptions surface quickly.

The pre-implementation phase won’t eliminate this, but if run well, should bring these tensions forward before lock-in.

Stakeholders need to agree not only on the vendor decision, but on the operating outcomes and resource allocation that follows. They need to plan beyond selection into implementation, adoption, governance and post-go-live operation (5-10 years into the future!!).

If they don’t, the programme may start with apparent consensus, only to fracture later. Challenging times will come. The stakeholder group needs to be aligned and ready to battle through them together.

.

4. Are our processes and data ready to support transformation?

Even the strongest OSS vendor can struggle when the operational foundations aren’t ready. Process variation and poor data quality are two of the biggest examples.

I talk about data quality a lot, so let’s just skip over this one today for TLDR purposes! If you are interested in knowing more about this space, leave us a message to discuss.

.

5. Is procurement selecting for implementation success or short-term commercial “wins”?

Procurement plays a vital role in OSS transformation. Commercial discipline is important. Competitive tension matters. Contractual protection matters. Cost control matters.

But procurement can become a problem when the process optimises for the wrong measures.

A large reduction from list price may look like success (many procurement people are even incentivised against this metric). A tightly controlled RFP may look rigorous and defensible. But none of these guarantee implementation success.

Unfortunately the traditional procurement model is flawed from the outset. OSS transformation is not just a software purchase. It’s a long-term partnership commitment and operational change journey.

That means procurement needs to evaluate more than functional compliance and price. It needs to consider implementation approach, partnership quality, domain understanding, delivery transparency, change governance, cultural fit and the vendor’s ability to support the client’s long-term transformation path.

This is especially important because the cheapest or most compliant-looking option may not be the option best suited to the organisation’s actual capabilities, readiness, constraints and ambitions.

.

Vendor selection isn’t the start

A strong procurement process should be tightly entwined with comprehensive implementation planning (of the pre-implementation, implementation and post-go-live phases).

The pre-implementation question is therefore direct: is procurement helping the organisation select for transformation success, or is it optimising for short-term commercial “wins” (eg negotiated reductions from list price)?

Most OSS transformations don’t fail because the vendor selection process lacked activity (too much activity?!). They fail because great questions weren’t even asked, let alone answered before implementation began.

Vendor selection is just one piece of the art of OSS/BSS transformation.

The pre-implementation phase matters more than most people give it credit for.

PAOSS guides clients through the questions that need answering before / during / after vendor selection – across strategy, scope, stakeholder alignment, process and data readiness, procurement logic and implementation planning.

Before you enter vendor selection, run a Transformation Readiness Review (by yourself or with PAOSS) to test whether your organisation is ready to support the totality of the journey ahead.