Building an OSS Implementation Team | Passionate About OSS and BSS

“Two men looked through prison bars. One saw mud, the other saw stars.”
Proverb

Are you ready to build the team that will actually deliver your OSS/BSS transformation?

Most organisations begin by selecting a platform, software vendor and systems integrator. However, the biggest constraint is often not the technology. It’s whether the operator has assembled the right people, given them enough authority and protected enough of their time to make the transformation work.

An OSS or BSS transformation reaches into products, customers, networks, services, data, processes, finance, operations and technology. This makes it an OctopOSS: a transformation with many interconnected tentacles and no single person or organisation that understands them all.

The ability to remain focused on the desired outcomes is an essential attribute for every member of the transformation team. However, successful delivery requires much more than optimism. It requires a deliberately designed joint team that combines the operator’s knowledge with the vendor’s product expertise and the systems integrator’s delivery capability.

We’ve broken this page into two parts:

The high-level summary (TL;DR) section at the top
Below the Line – The much more detailed section to help plan large / complex project teams

TL;DR: The implementation team in one view

An OSS/BSS transformation should be delivered by a joint operator, vendor and systems integrator team. Each party contributes different knowledge and should retain clear accountability for the decisions it is best placed to make.

Party	Primary contribution	Responsibilities it should normally retain
Network operator	Knowledge of its customers, products, services, networks, processes, data, policies, risks and operating environment	Business outcomes and transformation priorities Product, process and policy decisions Source-data ownership and data acceptance Operational requirements and support arrangements User acceptance and business readiness Final solution and operational acceptance Ownership of the retained operating model
Product vendor	Detailed knowledge of the selected product, its configuration options, implementation patterns, limitations and roadmap	Product architecture and supported configuration Product-specific design guidance Identification of product constraints Product installation, configuration and specialist testing Product defect diagnosis and remediation Product documentation and knowledge transfer Product support, patches and upgrades
Systems integrator	End-to-end delivery, integration, migration, testing and cutover experience across multiple systems and suppliers	End-to-end solution integration Delivery planning and workstream coordination Interface and custom-development delivery Migration execution and reconciliation System integration and end-to-end testing Cutover planning and execution Cross-vendor issue resolution

The product vendor and systems integrator may be the same organisation in some cases. Even where they are, the product and end-to-end integration responsibilities will typically remain logically separate. The best configuration for one vendor product is not automatically the best design for the operator’s entire operating environment.

High-level role families

Most major transformations require capabilities from the following role families:

Executive sponsorship, governance and transformation control
Business ownership, product management and process design
Operator subject matter expertise
Enterprise, solution, data, integration and security architecture
Product configuration, software development and technical delivery
Data modelling, migration, cleansing and reconciliation
Testing, quality assurance and business acceptance
Change management, communications, training and adoption
Operational readiness, service transition and cutover
Hypercare, warranty support and retained operations

A role is not necessarily a full-time position or a separate person. Smaller transformations may combine several roles. Large or complex programmes may require an entire team beneath one role heading.

Essential attributes of the team

The breadth of an OSS/BSS transformation means that no individual, department or supplier holds all the answers. Every team member must be willing to learn from others and contribute knowledge beyond their immediate workstream.

Strategic vision and communication: The ability to create, share and maintain focus on a common destination
Focus on the greater good: The willingness to optimise for the operator’s end-to-end outcome rather than one department, product or contract
Leadership and motivation: The ability to inform, engage and energise the people affected by the transformation
Diversity and respect: Recognition that different disciplines bring different forms of expertise and see different risks
Problem solving: A bias towards finding practical ways through roadblocks, dependencies and ambiguity
Conflict resolution: The ability to resolve disagreements without allowing blame or contractual positioning to stall delivery
Availability: Reliable participation from people whose time has been genuinely allocated to the project
Decision-making authority: The ability to make decisions or escalate them quickly to someone who can
Transparency: Early disclosure of risks, defects, assumptions, constraints and uncertainty
Operational pragmatism: A focus on whether the solution will work in real operational conditions
Accountability: Ownership of agreed outputs rather than attendance at meetings
Knowledge sharing: A commitment to leaving lasting capability within the operator

High-level team design principles

Design the project organisation and future operating organisation together
Build a joint operator, vendor and SI team rather than separate customer and supplier camps
Create peer-to-peer counterparts for the most important roles
Separate advisers from people authorised to make and accept decisions
Engage testers, operators and support teams during design rather than immediately before go-live
Protect operator subject matter experts from being continually redirected to business-as-usual work
Use controlled evidence without allowing excessive documentation and meetings to consume delivery capacity
Plan knowledge transfer as an apprenticeship throughout delivery rather than an event at the end
Define hypercare, warranty and support responsibilities before cutover
Retain ownership of architecture, data, configuration and operational outcomes within the operator

An operator can delegate implementation activities, but it cannot outsource accountability for understanding, accepting and operating the resulting OSS/BSS environment.

Below this line:

Detailed OSS/BSS transformation team structure

A joint team with peer-to-peer counterparts

The implementation organisation should not consist of an operator team that throws requirements over the fence to a supplier team. Important roles should have clear counterparts across the operator, vendor and SI organisations.

Operator role	Vendor or SI counterpart	Purpose of the relationship
Executive sponsor	Vendor and SI executive sponsors	Resolve strategic, commercial and resourcing issues that cannot be settled by the delivery teams
Transformation owner	Supplier delivery executive	Align business outcomes, delivery commitments, priorities and acceptance expectations
Operator programme manager	SI or prime-vendor programme manager	Maintain one integrated delivery plan, dependency model and escalation path
Operator design authority and solution architect	SI solution architect and vendor product architect	Ensure product-specific designs combine into an operable end-to-end solution
Operator data owner	Migration lead and vendor data specialists	Agree data definitions, mappings, correction rules, reconciliation thresholds and acceptance
Operator test authority and UAT lead	SI test manager and vendor test leads	Align technical testing with business processes, operational scenarios and acceptance criteria
Operator operations owner	Service-transition, hypercare and supplier support leads	Prepare support arrangements and progressively transfer operational responsibility

The purpose of peer-to-peer alignment is not to duplicate every position. It is to ensure that important decisions have an informed representative on each side and that no critical responsibility falls into the gap between organisations.

OSS/BSS transformation role catalogue

The following table describes the roles and accountable capabilities commonly required for a significant OSS or BSS transformation. The exact structure will vary according to the programme’s scope, size, sourcing model, technology and organisational maturity.

Role name	Short description	Typical home	Typical responsibilities
Executive governance and transformation control
Executive sponsor	Provides executive authority, organisational air cover and visible commitment to the transformation	Network operator, with executive counterparts at the vendor and SI	Champion the transformation’s intended business outcomes Secure funding, resources and executive support Resolve cross-functional priority and capacity conflicts Remove organisational roadblocks beyond the programme’s authority Maintain executive relationships with major suppliers Approve major scope, risk and investment decisions
Transformation owner	Holds overall accountability for the transformation outcome and the future business capability	Network operator	Define the transformation’s objectives and success measures Own the target business and operating outcomes Prioritise scope, benefits and delivery trade-offs Appoint accountable business, process and data owners Accept material business risks and residual gaps Approve transition into operations Track benefits after implementation
Programme director or programme manager	Coordinates the end-to-end transformation across workstreams, organisations and delivery phases	Operator or SI, with an operator programme owner retaining accountability	Build and maintain the integrated programme plan Coordinate workstreams, suppliers and internal teams Manage dependencies, milestones and critical paths Establish governance, reporting and escalation routines Manage programme risks, issues and decisions Ensure decisions are made within required timeframes Maintain alignment between scope, cost, schedule and outcomes
PMO and project controls lead	Provides the information, controls and delivery discipline required to manage the programme	Operator, SI or a combined PMO	Maintain schedules, milestones and workstream reporting Manage risk, issue, action and dependency registers Track budgets, forecasts, resources and progress Maintain decision, assumption and change logs Coordinate governance forums and reporting packs Manage document control and programme repositories Identify emerging delivery variance
Commercial, contract and supplier manager	Maintains commercial clarity across the operator, vendor, SI and other delivery partners	Network operator, with supplier commercial counterparts	Manage contracts, statements of work and supplier obligations Maintain deliverable and acceptance schedules Assess commercial impacts of scope changes Track licences, subscriptions, support and warranty terms Align milestone payments with accepted outcomes Manage commercial escalations and disputes Prevent contractual ambiguity from becoming a delivery gap
Design authority	Provides a formal forum for significant architecture, design and technical-debt decisions	Operator-led, with vendor and SI representation	Define architecture and design principles Review significant solution decisions Approve or reject deviations from target architecture Resolve cross-domain design conflicts Assess operability, maintainability and upgrade impacts Record accepted technical debt and remediation plans Ensure local workstream decisions remain end-to-end coherent
Business ownership, processes and operator expertise
Business capability or product owner	Represents the business outcomes and user capabilities that the transformation must deliver	Network operator	Define and prioritise business capabilities Maintain the business backlog Clarify business rules and expected outcomes Resolve priority conflicts between user groups Define acceptance criteria with business analysts and testers Approve delivered business capability Track adoption and benefits after go-live
Process owner	Owns an end-to-end business or operational process and the policies governing it	Network operator	Validate the current process and its known variations Approve the future-state process Define process controls, exceptions and escalation paths Clarify which activities should be automated, changed or removed Define process measures and performance expectations Resolve policy decisions exposed during design Accept the implemented process
Operator domain subject matter expert	Provides detailed knowledge of the operator’s products, networks, data, processes and operational exceptions	Network operator	Explain how current systems and processes work in practice Identify undocumented rules, exceptions and dependencies Help design workable future-state processes Define service, resource, product and workflow behaviours Identify source data and known data-quality problems Review designs, configurations and interface mappings Create realistic test scenarios and validate results Support training, cutover and early-life operations
Business analyst and service designer	Translates business outcomes and operational knowledge into implementable requirements, processes and acceptance criteria	Operator, SI or shared	Facilitate requirements and discovery workshops Document current and future processes Develop personas, use cases and operational scenarios Translate SME knowledge into clear requirements Define business rules and acceptance criteria Maintain traceability between outcomes, requirements and tests Identify gaps between business needs and product capabilities
Architecture and solution design
Enterprise architect	Ensures the transformation aligns with the operator’s enterprise strategy, technology landscape and long-term roadmap	Network operator	Define the target enterprise architecture Position the transformation within the broader technology roadmap Identify strategic systems of record and control points Define principles for integration, data, security and platforms Assess impacts on adjacent programmes and capabilities Review major architecture decisions and exceptions Protect long-term flexibility and avoid unnecessary lock-in
Operator solution architect	Protects the operator’s end-to-end solution interests and ensures that supplier designs fit its environment	Network operator	Define operator-side solution requirements and constraints Establish application, data and integration boundaries Review vendor and SI solution designs Ensure non-functional requirements are addressed Assess maintainability, operability and supportability Identify hidden dependencies and architecture gaps Represent the operator through detailed design decisions
SI end-to-end solution architect	Owns the coherence of the implemented solution across products, interfaces, infrastructure and delivery workstreams	Systems integrator or prime implementation partner	Develop the end-to-end solution design Combine product designs into one implementable architecture Coordinate technical decisions across workstreams Resolve gaps and overlaps between supplier responsibilities Maintain traceability to functional and non-functional requirements Ensure integration, migration, security and operations are considered together Support technical assurance through build, test and cutover
Vendor product architect	Provides authoritative guidance on how the vendor’s product should be designed, configured and extended	Product vendor	Explain product capabilities, constraints and configuration patterns Recommend supported approaches using standard product functionality Identify when requirements require customisation or product change Assess upgrade and roadmap implications Review product-specific designs and extensions Support diagnosis of complex product issues Provide product architecture documentation and knowledge transfer
Integration, API and orchestration architect	Designs the interactions that connect the transformed platform with networks, channels and surrounding systems	Operator or SI, with vendor specialists contributing	Maintain the interface and integration catalogue Define interaction patterns, APIs, events and data contracts Design orchestration sequences and responsibility boundaries Define error handling, retries, reconciliation and recovery Address security, performance, observability and versioning Identify ordering and timing dependencies Ensure interfaces can be operated and supported after go-live
Data architect and migration lead	Designs the target information structures and directs the migration of data into the new environment	Operator, SI or shared	Define target data structures and information relationships Identify source systems, ownership and extraction approaches Develop mapping, transformation and enrichment rules Plan migration waves, rehearsals and cutover loads Coordinate cleansing, creation and correction activities Define reconciliation methods and acceptance thresholds Manage migration defects, exceptions and rollback considerations Transfer unresolved data-quality work into ongoing governance
Data owner and domain data steward	Provides authority over data meaning, quality expectations and acceptance within a business or technical domain	Network operator	Approve data definitions and ownership boundaries Confirm authoritative data sources Set data-quality and completeness thresholds Approve mapping, correction and defaulting rules Resolve ambiguous or conflicting data interpretations Validate migrated data and reconciliation results Own ongoing data-quality controls after handover
Build, configuration and technical delivery
Technical delivery lead	Coordinates the detailed build, configuration, development and technical delivery activities	SI or vendor, with an operator technical counterpart	Translate approved designs into build plans Coordinate configuration, development and technical resources Manage dependencies between applications and environments Enforce build, code and configuration standards Track technical progress, defects and blockers Coordinate technical demonstrations and reviews Ensure build artefacts are documented and controlled
Product configuration and application specialists	Configure and extend the selected product to support the approved processes, services and business rules	Vendor, SI or trained operator specialists	Configure workflows, rules, catalogues and user functions Develop approved product extensions Perform unit and component testing Maintain configuration records and deployment packages Support design playback and user demonstrations Investigate configuration-related defects Transfer configuration knowledge to the operator
Platform, infrastructure, cloud, security and DevSecOps lead	Provides the environments, platform services and engineering controls required to run the solution safely and reliably	Operator, SI, cloud provider or shared	Design and provision development, test and production environments Implement availability, resilience and disaster-recovery arrangements Establish identity, access, security and audit controls Implement deployment pipelines and configuration controls Define monitoring, logging and observability Plan capacity, performance, backup and restoration Support vulnerability, penetration and operational testing Prepare platform operating procedures
Testing, acceptance and quality
Test manager and quality assurance team	Defines and controls the strategy used to demonstrate that the solution meets its requirements and can operate safely	Operator, SI or an independent test function	Develop the overall test strategy and plans Engage during requirements and design Maintain traceability between requirements and test evidence Coordinate component, integration, end-to-end and non-functional testing Define test entry and exit criteria Manage defects, severity definitions and retesting Report testing progress, coverage and residual risk Maintain evidence required for acceptance
UAT lead and business testers	Demonstrate that the solution supports real business and operational activities rather than only technical specifications	Network operator	Develop business scenarios from real user activities Prepare representative users, data and test conditions Execute user acceptance testing Validate business rules, usability and process outcomes Identify operational gaps and unexpected behaviours Prioritise defects from a business perspective Recommend business acceptance or rejection Contribute scenarios to future regression testing
Change, adoption and knowledge transfer
Change, communications, training and knowledge-transfer lead	Prepares people and teams to adopt, operate and improve the transformed environment	Operator-led, with vendor and SI support	Assess role, process and organisational impacts Develop stakeholder and communications plans Build training plans for users, administrators and support teams Coordinate training content, environments and delivery Establish super-user and change-champion networks Track competency, readiness and adoption Coordinate hands-on knowledge transfer throughout delivery Ensure critical knowledge is retained after suppliers leave
Operational readiness, cutover and handover
Operational readiness and service-transition lead	Ensures the transformed solution can be supported and operated from the moment it enters production	Network operator, with SI and vendor counterparts	Define the future support and operating model Establish L1, L2 and L3 responsibility boundaries Coordinate runbooks, procedures and support documentation Confirm monitoring, access, backup and recovery arrangements Prepare incident, problem, change and escalation processes Confirm supplier support contracts and contact paths Assess operational competency and readiness Recommend operational acceptance or identify gaps
Cutover and release manager	Plans and directs the controlled transition from the current environment to the transformed solution	Operator, SI or shared	Develop the integrated cutover plan and runbook Coordinate technical, data, business and supplier activities Conduct cutover rehearsals and readiness reviews Define go, no-go and rollback criteria Establish the cutover command structure Coordinate communications and status reporting Control production deployment and migration sequencing Capture lessons and unresolved actions following cutover
Hypercare and early-life support manager	Coordinates enhanced support during the period of highest operational risk after go-live	Operator or SI, with vendor and support-team participation	Establish the hypercare command centre and operating rhythm Coordinate incidents, defects, data issues and user support Maintain clear severity, ownership and escalation rules Track stability, transaction success, fallout and operational workload Separate defects from enhancements and training issues Coordinate supplier warranty and remediation activities Transfer unresolved work into BAU ownership Assess and recommend exit from hypercare
Retained operations and continuous improvement
OSS/BSS platform and product owner	Owns the production platform, roadmap, service quality and ongoing improvement after the project organisation disbands	Network operator	Own the platform roadmap and improvement backlog Prioritise defects, upgrades, configuration changes and enhancements Coordinate business, architecture, operations and supplier stakeholders Manage licences, support contracts and vendor performance Track availability, adoption, operational performance and benefits Maintain configuration, release and lifecycle governance Ensure the platform continues to meet changing business needs
L1, L2 and L3 support leads	Provide progressively deeper support for users, business processes, applications, integrations and vendor products	Operator for L1 and much of L2, vendor and SI for specialist L3 support	Receive, classify and triage incidents and requests Use known procedures, diagnostics and workarounds Investigate application, data and integration problems Escalate product defects and complex technical issues Maintain known-error records and support knowledge Coordinate patches, fixes and problem investigations Track support performance and recurring failure patterns
Continuous-improvement and automation owner	Uses operational evidence to progressively improve processes, data, automation and user outcomes	Network operator	Analyse incidents, fallout, manual effort and recurring defects Maintain an evidence-based improvement backlog Prioritise process simplification and automation opportunities Coordinate improvements across business and technical teams Define controls and accountability for new automations Measure whether changes produce the expected outcomes Feed operational learning into future releases

Why operator SMEs are indispensable

Vendors understand their products. Systems integrators understand implementation and integration. Only the operator understands how its own products, customers, commercial rules, networks, operational processes, exceptions and historical data work in practice.

This knowledge is rarely held in one repository. It is distributed across people, systems, spreadsheets, procedures, informal workarounds and years of accumulated operational experience. Operator SMEs are therefore required throughout design, configuration, data migration, testing, cutover and handover.

Types of operator SMEs commonly required

SME domain	Typical knowledge and contributions
Products, offers and catalogues	Offer structures, eligibility, pricing, bundles, product rules, service definitions, product lifecycle and catalogue relationships
Sales, channels and customer management	Lead-to-order activities, channel variations, customer structures, CRM processes, customer communications and care journeys
Order management and fulfilment	Order decomposition, validation, orchestration, provisioning, fallout, jeopardy, activation and completion rules
Billing, charging and finance	Rating, charging, billing cycles, taxation, payments, collections, adjustments, journals, reconciliation and financial controls
Revenue assurance, fraud and risk	Leakage controls, usage reconciliation, fraud scenarios, risk policies, exception handling and investigation processes
Network and service design	Network technologies, topology, capacity, service decomposition, resource allocation, design rules and engineering standards
Inventory and data	Data sources, meanings, naming, identifiers, relationships, lineage, quality issues, correction practices and ownership
Assurance and network operations	Alarm handling, incident management, correlation, diagnostics, service impact, maintenance, performance and NOC practices
Field operations and workforce	Appointments, dispatch, skills, territories, work orders, inventory, field procedures and completion evidence
Wholesale, interconnect, roaming and partners	Partner agreements, interfaces, order flows, settlement, SLA, dispute and regulatory obligations
Security, privacy, regulatory and legal	Identity, access, audit, retention, privacy, lawful access, consent, regulatory reporting and compliance controls
IT, platform and service operations	Hosting, environments, security operations, monitoring, releases, backups, support, service management and supplier processes

SMEs are not substitutes for accountable owners

SMEs provide knowledge, advice and validation. They should not be expected to carry decision accountability unless this authority has been explicitly delegated.

Role	Primary accountability
Subject matter expert	Provides knowledge, identifies implications and validates whether designs reflect operational reality
Process owner	Approves process design, policy, controls and performance expectations
Data owner	Approves data definitions, ownership boundaries, correction rules and acceptance thresholds
Product owner	Prioritises business capability, scope and backlog
Business owner	Accepts business outcomes and residual business risks
Design authority	Approves significant technical designs, deviations and technical debt
Operational acceptance owner	Determines whether the solution is supportable and ready to enter operations

Without these distinctions, a programme can have many knowledgeable people in workshops but nobody authorised to settle a disputed requirement, approve a data rule or accept an operational risk.

Protecting operator SME capacity

Transformation programmes frequently use a matrix structure, drawing specialists from the functional teams that operate the existing business. This creates an unavoidable conflict: the people most valuable to the transformation are often also the people most critical to daily operations.

An SME who is assigned to the project but never released from BAU is not a project resource.

The programme should:

Identify named primary and backup SMEs for each domain
Estimate SME demand by project phase rather than using one flat allocation
Agree minimum allocations with functional managers
Backfill critical operational responsibilities where necessary
Schedule workshops, design reviews and tests sufficiently early
Define which decisions each SME may make without further approval
Establish response-time expectations for questions and design reviews
Track missed SME contributions as programme dependencies and risks
Avoid reliance on one indispensable individual
Include project participation in departmental objectives and capacity plans

The executive sponsor should intervene when operational managers repeatedly withdraw agreed resources. Otherwise, the transformation will stall while still reporting that the required people have technically been assigned.

Decision rights matter as much as the organisation chart

An organisation chart shows reporting relationships. It does not necessarily show who can make decisions, who must perform the work or who accepts the result.

For important activities and deliverables, the programme should identify:

Decision role	Question answered
Recommends	Who evaluates the available options and proposes a course of action?
Decides	Who has authority to select the course of action?
Delivers	Who performs the work and produces the agreed output?
Validates	Who confirms that the output is accurate, complete and fit for its intended purpose?
Accepts	Who formally accepts the deliverable and any remaining risk?
Operates	Who becomes responsible for the output after it enters production?

These roles may be mapped into a RACI, RAPID or similar responsibility model. The important outcome is not the acronym. It is that the programme knows where each major decision goes and does not rely on steering committees to settle every routine design question.

Role participation changes through the lifecycle

The transformation team is not static. Different role families expand and contract as the programme moves from planning into design, delivery, migration, testing and operations [cutover, post-handover hypercase and business-as-usual].

Role family	Mobilisation	Design	Build	Migration	Testing	Cutover	Hypercare	BAU
Executive governance	High	Medium	Medium	Medium	Medium	High	Medium	Low
Programme and PMO	High	High	High	High	High	High	High	Low
Business and process owners	High	High	Medium	Medium	High	High	High	High
Operator SMEs	Medium	High	High	High	High	High	High	Medium
Architecture	High	High	High	Medium	Medium	Medium	Medium	Medium
Technical delivery	Medium	High	High	High	High	High	High	Medium
Data and migration	Medium	High	High	High	High	High	High	Medium
Testing and quality	Medium	High	Medium	High	High	High	High	Medium
Change and training	Medium	High	High	Medium	High	High	High	Medium
Operations and support	Low	Medium	Medium	Medium	High	High	High	High

This table is indicative. The exact level of participation depends on many factors (including scope, delivery method, operator maturity, supplier model and risk).

Testing begins during requirements and design

Testing should not be treated as a late delivery phase that begins once configuration is largely complete. Test specialists should participate during requirements and design so that every important requirement has a practical method of verification.

Testing may include:

Unit and component testing
Product configuration testing
Interface and system integration testing
End-to-end process testing
Migration and reconciliation testing
User acceptance testing
Performance, capacity and volume testing
Resilience, failover and disaster-recovery testing
Security and access-control testing
Operational-readiness testing
Regression testing
Cutover rehearsals

Operator SMEs are essential to testing because technically valid results can still be operationally incorrect. Realistic testing requires knowledge of product variations, process exceptions, data irregularities and the failure conditions that operational teams encounter.

Operational readiness and handover

Handover should not be a final meeting where the project team delivers documentation and departs. It should be a progressive transfer of knowledge, access, procedures and accountability throughout implementation.

Operational teams should be embedded early enough to understand how the solution has been designed and why key decisions were made. They should participate in design reviews, testing, cutover rehearsals and defect investigations before being asked to support the production environment.

Operational readiness should cover

Named service, platform, product and operational owners
Defined L1, L2 and L3 support responsibilities
Incident, problem, change, request and escalation processes
Monitoring, alerting, logging and operational dashboards
User, administrative and privileged-access procedures
Runbooks, standard operating procedures and known workarounds
Backup, restoration, resilience and disaster-recovery arrangements
Performance, capacity and availability baselines
Vendor, SI and third-party support contracts
Supplier contact and escalation paths
Release, patch and environment-management procedures
Licence, certificate and technical-dependency registers
Data-quality monitoring and reconciliation controls
Training, competency and knowledge-transfer evidence
Known errors, residual defects and accepted risks
Operational acceptance criteria
Go-live, no-go and rollback authority

Post-handover support model

Support level	Typical owner	Typical responsibilities
L1: Front-line support	Operator service desk, NOC, customer care or business operations	Receive and classify incidents and requests Perform initial diagnostics Use approved procedures and known workarounds Resolve common user and operational issues Collect evidence before escalation Communicate status to affected users
L2: Application, platform and data support	Operator OSS/BSS platform team, application support, integration support or data operations	Investigate application, configuration and data issues Analyse logs, interfaces, workflows and failed transactions Correct authorised configuration or data problems Perform reconciliation and recovery activities Develop workarounds and known-error records Escalate suspected product defects or complex integration issues
L3: Product and specialist engineering	Product vendor, SI or specialist third party	Investigate complex product and integration defects Perform detailed code and product analysis Develop patches, fixes or complex configuration changes Support major incidents and problem investigations Advise on product constraints and upgrade paths Engage vendor engineering where deeper remediation is required

The support model should make clear where the vendor’s product responsibility ends and where the SI’s integration responsibility begins. Otherwise, complex incidents can circulate between suppliers while the operator remains accountable for the customer impact.

Hypercare and warranty

Hypercare is the controlled period between production cutover and normal operations. It should provide additional business, operational and technical support while transaction volumes stabilise, users build confidence and previously unseen defects emerge.

Hypercare should define

A command structure and decision-making authority
Operating hours and on-call arrangements
Daily incident, defect and data-reconciliation reviews
Severity definitions and escalation paths
Business, operational and technical dashboards
Vendor and SI warranty responsibilities
Rules for separating defects, enhancements and training issues
Fast access to specialist product, integration and data resources
Methods for transferring unresolved items into BAU backlogs
Objective exit criteria

Example hypercare exit criteria

No unresolved critical incident without an approved recovery plan
High-severity defects closed or explicitly accepted by the accountable owner
Operational KPIs stable within agreed thresholds
Migration reconciliation within approved tolerances
Support teams demonstrably capable of performing their assigned functions
Monitoring, escalation and incident processes proven in production
Runbooks and knowledge articles updated from early-life experience
Known errors and workarounds transferred into BAU repositories
Remaining supplier obligations assigned and tracked
Platform, process, data and service owners have formally accepted accountability

From the project organisation to the operating organisation

The operating team should not be invented after the implementation team has nearly finished. The future operating model should be designed alongside the solution and progressively populated by people who participate during delivery.

Project role or capability	Typical post-handover destination
Transformation business owner	BAU business capability owner or executive benefits owner
Product owner	OSS/BSS product owner or platform roadmap owner
Process owner	BAU operational or business process owner
Operator solution architect	Enterprise, domain or platform architecture function
Product configuration lead	Platform product team, configuration team or L2 application support
Integration lead	Integration platform team, application support or specialist L3 support
Data migration lead	Data operations, governance or stewardship function
Test manager	Release assurance and regression-testing function
Operational-readiness lead	Service management, platform operations or service-transition function
Cutover manager	Release and deployment-management function
Training and knowledge-transfer lead	Product owner, learning function or super-user network
Project defect and improvement backlog	Platform roadmap, problem-management queue and continuous-improvement backlog

The retained OSS/BSS functional unit

A specialist OSS/BSS functional unit may be required after handover where the operator regularly:

Introduces new products and services
Changes fulfilment, assurance or customer-management processes
Updates orchestration and automation rules
Onboards new networks, devices, partners or data sources
Refines service and resource models
Corrects or enriches operational data
Performs regular product upgrades and releases
Maintains specialised integrations and configurations
Requires specialist operations beyond a general IT infrastructure function

This retained capability may include:

Platform and product ownership
Architecture and roadmap management
Application and platform operations
Configuration and workflow specialists
Integration and API support
Data operations and stewardship
Release, test and environment management
Supplier and licence management
Incident and problem management
User administration, training and adoption
Continuous improvement and automation governance

The objective is not necessarily to retain every delivery specialist. It is to retain enough knowledge and control to operate the platform, challenge suppliers, make safe changes and continue improving the environment.

Low documentation does not mean low evidence

OSS/BSS programmes can become strangled by excessive meetings, documents and approval cycles. The PMO should minimise administrative work that does not improve decisions, coordination, delivery or operational readiness.

However, a low-documentation approach should not become an excuse for undocumented decisions, untraceable requirements or weak handover evidence. A practical minimum set of controlled artefacts normally includes:

Integrated plan and responsibility model
Decision and assumption log
Requirements, use cases and acceptance criteria
Architecture decisions and approved designs
Process, product and service models
Interface contracts and integration specifications
Data definitions, mappings and reconciliation rules
Environment and deployment records
Test plans, cases, defects and acceptance evidence
Cutover and rollback plans
Runbooks and support procedures
Operational acceptance evidence
Known-error and residual-risk registers
Retained product and improvement backlog
Training materials
Product guides (release notes, user guides, admin guides, etc)

Common transformation team failure modes

Treating the vendor’s implementation team as the entire transformation team
Assigning operator SMEs without protecting their capacity
Confusing knowledgeable advisers with accountable decision owners
Allowing business, process, architecture and data decisions to occur independently
Using one generic solution architect title without clarifying operator, SI and vendor responsibilities
Bringing testers into the programme after the build is substantially complete
Bringing operational and support teams into the programme immediately before go-live
Treating training as a final-week activity
Relying on documents rather than hands-on knowledge transfer
Leaving end-to-end integration responsibility divided between several suppliers
Failing to identify who accepts residual business, data and operational risk
Ending vendor and SI participation on go-live day
Allowing project knowledge to leave with contractors and supplier personnel
Designing the implementation organisation without designing the future operating model
Measuring completion of technical deliverables without measuring adoption or operational performance
Allowing contractual defensiveness to replace collaborative problem solving

Conclusion

A successful OSS/BSS transformation requires far more than a software product and an implementation supplier. It requires a multidisciplinary team that combines operator knowledge, vendor product expertise and systems integration capability.

The operator’s SMEs are particularly important. They provide the detailed knowledge required to design processes, define products and services, model data, configure integrations, build realistic tests and prepare operational teams. However, they must be supported by accountable owners who can make decisions and accept outcomes.

The best implementation teams are designed backwards from the future operating model. They involve operators and support teams early, transfer knowledge throughout delivery and retain enough internal capability to operate, govern and continually improve the platform after the temporary project organisation has disbanded.

The project is not complete when the platform goes live. It is complete when the operator can confidently own, operate and improve it.

Related Passionate About OSS resources

Depending on what you’re looking to achieve, the following resources and links to other PAOSS materials may prove useful:

Implementation teams, planning and operating models

OSS/BSS Use-Cases and Personas (ie role types)
A free downloadable spreadsheet containing over 70 OSS/BSS personas and nearly 700 use cases performed by those personas
https://passionateaboutoss.com/product/oss-bss-use-cases/
How to plan the resources and budget needed for an OSS transformation project
Explores the relationship between the temporary transformation organisation and the retained BAU organisation, including the challenges of assigning operational staff to project roles
https://passionateaboutoss.com/how-to-plan-the-resources-and-budget-needed-for-an-oss-transformation-project/
Working alongside a vendor to implement your OSS
Explains how operator knowledge and vendor product knowledge must be combined throughout implementation
https://passionateaboutoss.com/oss-implementations/vendor-implementation/
100-Day Plan for OSS/BSS Transformation
A free transformation mobilisation plan covering workstreams, decision points, governance, delivery sequencing and the outputs required before scaled execution
https://passionateaboutoss.com/product/100-day-oss-bss-transformation-plan/
OSS Operating Model Blueprint for Telcos
Provides a detailed model for post-handover teams, accountabilities, decision rights, operational interactions and continuous improvement
https://passionateaboutoss.com/oss-operating-model-blueprint/
Customer Experience: Operational Handover
Discusses operational preparation, embedded knowledge transfer and production support during the transition into operations
https://passionateaboutoss.com/customer-experience-operational-handover/
Project Kick-off
Covers project planning, work breakdown structures, human-resource planning, risk controls and joint team formation
https://passionateaboutoss.com/oss-implementations/project-kick-off/
The Ultimate Framework for Planning Large-Scale OSS Transformations
Describes the Transformation Project Framework and its approach to current state, future state, gap analysis and implementation planning with WBS (Work Breakdown Structures):
https://passionateaboutoss.com/background/the-ultimate-framework-for-planning-large-scale-oss-transformations/

Requirements, processes, data, testing and change

Capturing OSS Requirements
Provides techniques for identifying the high-value activities and outcomes that requirements should support
https://passionateaboutoss.com/oss-implementations/capturing-requirements/
Planning Your OSS Data
Covers data sources, modelling, mapping, cleansing, migration, validation and the respective contributions of operator and vendor teams
https://passionateaboutoss.com/oss-implementations/oss-data/
OSS/BSS Testing: The V-Model
Explains why test specialists should participate from requirements capture onwards and how requirements relate to test phases
https://passionateaboutoss.com/oss-bss-testing-the-v-model/
Managing Change on OSS Projects
Discusses sponsorship, change leadership, communications, capability-building and organisational adoption
https://passionateaboutoss.com/oss-implementations/oss-change-management/
Developing an OSS Training Plan
Positions OSS/BSS learning as a long-term apprenticeship involving experience, mentoring and hands-on participation
https://passionateaboutoss.com/developing-an-oss-training-plan/

PAOSS products, templates and training

OSS/BSS Process Mapping Guide
A free workbook containing more than 50 starter telecom process maps, example workgroups and alignment with frameworks including eTOM and ITIL
https://passionateaboutoss.com/product/oss-bss-process-maps/
Telecom Product and Service Mapping Guide
Provides reusable starting models for more than 80 telecom product and service types, including relationships between offers, services and network resources
https://passionateaboutoss.com/product/telco-product-service-mapping-guide/
OSS Persona and Workflow Mapping
A course for identifying the people who use OSS/BSS, the workflows they perform and the outcomes that matter most to the organisation
https://passionateaboutoss.com/product/oss-persona-and-workflow-mapping-paoss-pre-02/
OSS/BSS Project Planning
A detailed masterclass on the Transformation Project Framework, project planning, risk, stakeholder alignment and large-scale transformation execution
https://passionateaboutoss.com/product/oss-bss-project-planning-paoss-pre-06/
Mastering Your OSS
A practical implementation guide containing techniques and lessons developed across complex OSS projects
https://passionateaboutoss.com/product/mastering-your-oss-operational-support-system-implementation-tips-and-techniques/

Transformation assistance from PAOSS

Passionate About OSS supports operators, vendors, systems integrators and consulting teams with OSS/BSS transformation planning, architecture, process design, data modelling and migration, implementation documentation, testing, training and operational-handover planning.

Learn more about how PAOSS supports OSS/BSS implementers

OSS Implementation Team