Transformation Readiness
This section articulates what must be in place before any transformation work starts — the foundations that determine whether a programme succeeds or fails.
Most transformations fail long before implementation starts — because the foundations were never put in place before the work began.
Three Pillars
The prerequisites are organised into three pillars — each containing the domains that must be addressed at the right stage of the programme.
Strategic Foundations
Before programme launchNon-negotiable preconditions — without these, there is no programme.
Execution Preparation
Before execution beginsEverything that must be ready before — or very early in — execution.
Transition & Go-Live
Before first releaseCutover and operational readiness — ensuring go-live is controlled and reversible.
Strategic Foundations
Vision, funding, architecture, operating model, change management, regulatory constraints, and success measures must be settled before any delivery begins.
Why It Matters
The business owner defines what the transformation is for — not just what it replaces. They own the business vision, prioritise outcomes over features, and ensure the programme delivers value, not just software. They are the ultimate owner of the budget and the business case. Without this role, IT fills the vacuum and optimises for delivery, not for the business objectives that justified the investment.
Without This
No clear vision. Priorities shift quarterly. Nobody owns outcomes. The programme loses executive confidence within 12 months.
Typical Operator Position
Most operators have a named sponsor. Few have one with genuine authority over scope, process change, and value realisation.
Key Questions
- Is there a business owner who owns the transformation vision, roadmap, and target outcomes?
- Do they have authority over priorities, scope, process change, and value realisation?
- Are business outcomes defined in measurable terms — not just "modernise"?
- Does the organisation understand the end goal — or only the technology being replaced?
Why It Matters
Programme governance provides the structure for strategic decision-making, risk oversight, and benefits assurance across the full transformation lifecycle. It includes the programme board (composition, cadence, authority), stage gates with explicit go/no-go criteria, a risk register with named owners and active mitigation, benefits tracking aligned to the business case, and escalation paths from programme to executive level.
Without This
Strategic risks go unmanaged. Stage gates have no criteria. The programme drifts from business case objectives. Problems escalate only when they become crises.
Typical Operator Position
Most programmes establish a programme board but without clear stage-gate criteria or a living risk register. Risk management is often reactive rather than anticipatory.
Key Questions
- Is a programme board established with defined membership, cadence, and decision authority?
- Are stage gates defined with explicit go/no-go criteria at each phase boundary?
- Is there a risk register with named owners, mitigation plans, and regular review cadence?
- Is benefits tracking in place — aligned to the business case and reviewed at each gate?
- Is there an escalation path from programme governance to executive leadership?
Why It Matters
The business case is the programme's licence to operate. It articulates the value drivers, investment profile, payback timeline, and the assumptions that must hold for the transformation to be worthwhile. It is not a one-time artefact — it should be revisited at every major gate to validate that the original rationale still holds. Without it, the programme cannot defend itself against competing priorities or demonstrate return on investment.
Without This
The programme starts without a clear rationale. Value is assumed but never quantified. When pressure comes — and it always does — there is no baseline to defend the investment. Scope is cut arbitrarily because nobody knows what drives value and what does not.
Typical Operator Position
Most operators have a business case but it is rarely revisited after approval. Value drivers are typically high-level and not mapped to specific releases or capabilities. The business case is often written to secure funding rather than to guide delivery.
Key Questions
- Is there an approved business case with defined value drivers, investment profile, and payback assumptions?
- Is the business case mapped to specific outcomes per release — not just a total cost justification?
- Are the assumptions in the business case explicitly stated and testable?
- Is the business case revisited at programme gates, or is it a static document?
- Does the business case account for opportunity cost and the cost of inaction?
Why It Matters
The budget turns the business case into funded execution. Without upfront budget approval with clear allocation across workstreams — platform, integration, data migration, testing, change management, contingency — the programme is vulnerable to quarterly re-negotiation, scope cuts at the wrong moment, and death by a thousand budget reviews. Ring-fenced funding signals genuine organisational commitment.
Without This
The programme starts on conditional funding. Budget is contested at every gate. Workstreams are cut mid-flight. Vendor contracts are signed before the full cost envelope is understood. Contingency is raided in the first quarter.
Typical Operator Position
Budget is typically approved at headline level but workstream allocation is delayed. Contingency is frequently under-provisioned or raided within the first year. Dual-running costs are rarely budgeted upfront.
Key Questions
- Is the full transformation budget approved — not just the platform licence?
- Is budget allocated across workstreams: platform, integration, data migration, testing, change management, and contingency?
- Is the budget ring-fenced and protected from quarterly re-approval or reallocation?
- Does the budget account for dual-running costs during the coexistence period?
- Is there a realistic contingency provision — typically 15-25% for BSS/OSS programmes?
- Are vendor commercial terms aligned to the budget profile and payment milestones?
Why It Matters
Without architecture leadership, vendors fill the vacuum. Each workstream makes local decisions that are globally incoherent. Integration seams multiply. The integration architecture is particularly critical: middleware/ESB/API gateway patterns, contract-first vs implementation-first approach, event-driven vs synchronous integration, error handling, and retry semantics must all be defined upfront. In a multi-vendor environment, integration is where 30-40% of programme effort is spent — and where most unplanned rework originates.
Without This
Vendors define your architecture by default. Integration costs double. Point-to-point integrations proliferate. Rework starts in year two.
Typical Operator Position
Architecture leadership is the most common gap. Many programmes have enterprise architects but lack dedicated BSS/OSS domain architects with transformation authority.
Key Questions
- Is there a named architect with authority over BSS/OSS design decisions?
- Is the target-state architecture documented — catalog model, system roles, integration patterns, SoR boundaries?
- Is the integration architecture defined — middleware/API gateway, contract-first approach, event vs sync patterns, error handling?
- Are architectural principles agreed — or will they be negotiated sprint-by-sprint?
- Does the architect understand catalog-driven, TMF-aligned, runtime architecture?
Why It Matters
Every downstream decision — architecture, scope, vendor selection, budget allocation, data migration approach, cutover strategy — depends on the transformation approach. A greenfield deployment for new customers has entirely different implications to a brownfield migration of 2 million existing subscribers. Choosing product-by-product migration vs business-unit-by-business-unit changes team structure, vendor engagement, and timeline. This is not a technical decision — it is a strategic one that must involve the business owner, architecture lead, and programme leadership.
Without This
The programme starts without agreement on the fundamental approach. Architecture is designed for greenfield while the business expects brownfield migration. Scope is defined without knowing which customers or products go first. Every workstream makes different assumptions about the transformation sequence.
Typical Operator Position
Most operators default to a hybrid approach without explicitly deciding what that means. The transformation approach is often assumed rather than documented, debated, and agreed. Programmes frequently discover 6 months in that stakeholders had different expectations about what "transformation" meant.
Key Questions
- Is the approach explicitly decided — greenfield, brownfield, or hybrid?
- Which products or services are targeted for the first release — and why those first?
- Which business unit or customer segment leads the transformation?
- Is the migration pattern defined — product-by-product, customer-segmented, strangler, or big bang?
- Is there a defined exit plan from legacy — or will dual-stack run indefinitely?
- Has the approach been validated against data migration complexity and legacy constraints?
Why It Matters
"Transform the BSS stack" is not a scope statement — it is a wish. Without explicit product scope, use case boundaries, release definitions, and a baselined project plan, every workstream expands until the programme becomes undeliverable. The project plan translates scope into a sequenced, time-bound delivery schedule — it is the bridge between strategy and execution.
Without This
Every workstream interprets scope differently. Release dates slip because "done" was never defined. No baselined plan means no way to measure progress or deviation.
Typical Operator Position
Operators typically define system scope early but delay product-level scope definition and project plan baselining until too late. First-release boundaries are often negotiated under deadline pressure.
Key Questions
- Which products are in scope for the first release — and which are explicitly excluded?
- Is there a baselined project plan with milestones, dependencies, and critical path?
- Are the target use cases defined end-to-end (lead-to-cash, trouble-to-resolve)?
- Are release boundaries agreed — what goes live in R1 vs R2 vs R3?
- Is there a product-by-product or domain-by-domain transformation sequence?
Why It Matters
The operating model defines the organisational structure, roles, responsibilities, and ways of working that will exist after the transformation. Without it, change management has no target to manage towards, team design has no blueprint, and the programme delivers new technology into an old organisation. Product management, service operations, network operations, and IT support roles all shift when BSS/OSS changes — these shifts must be designed, not discovered.
Without This
Change management becomes internal communications without substance. Teams are reorganised reactively during delivery. Role conflicts emerge at go-live when nobody knows who owns the new processes. The organisation reverts to legacy ways of working within months.
Typical Operator Position
Most operators acknowledge the need for operating model change but defer it until late in the programme. Target operating model design is typically under-resourced and treated as an HR activity rather than a strategic design exercise.
Key Questions
- Is the target operating model defined — covering roles, team structures, and process ownership post-transformation?
- Are the changes to product management, service operations, and IT support roles explicitly mapped?
- Is there a transition plan from current to target operating model aligned to delivery milestones?
- Has the operating model been validated with the business units and teams who will live with it?
- Are new skills requirements identified and recruitment or upskilling plans in place?
Why It Matters
A BSS/OSS transformation changes how hundreds of people work — sales teams quoting differently, operations teams using new tools, finance teams reconciling against new billing structures. Communication leading up to the start of the programme is vital: stakeholders from product, IT, operations, finance, and commercial teams must understand the vision, the impact on their teams, and their role in the transformation before it begins. If they are not pulling in the same direction from the outset, every decision becomes contested and every dependency becomes a political negotiation. The people who will resist the transformation need to be identified and engaged early — not discovered when they block a critical dependency. Training must also be planned from the outset — both technical training for the implementation team (platform, TMF APIs, catalog tooling) and operational training for end users who will work with the new systems day-to-day.
Without This
Stakeholders from different parts of the business work at cross-purposes. Resistance builds unchecked. Key people are surprised by changes that affect their teams. Political opposition becomes entrenched before the first release. The transformation delivers technology without organisational change.
Typical Operator Position
Change management is the most underinvested domain in BSS/OSS transformations. Most programmes treat it as a communications exercise that starts 3 months before go-live — by which point resistance is already embedded and cross-functional alignment has never been established.
Key Questions
- Is there a dedicated change management lead with organisational authority — appointed before programme launch?
- Has pre-programme communication been planned to align key stakeholders across business, IT, operations, and finance?
- Has a stakeholder impact assessment been completed — who is affected, how, and when?
- Have resistant stakeholders been identified and engaged with a specific management plan?
- Is there a structured training plan — both technical (implementation team, platform, APIs) and operational (end-user process training)?
- Are adoption metrics defined — not just system deployment, but actual usage and process compliance?
- Are frontline managers engaged as change champions from the start of the programme?
Prerequisites Are Not Optional
Technology choice is only one variable in a transformation.
The prerequisites above are the load-bearing foundations that determine whether the programme delivers value or becomes a multi-year cost centre.
Address them before execution begins — discover them during execution, and the programme pays in delays, rework, and organisational fatigue.