Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
The following how-to guide provides a 7-step approach to planning large-scale, complex OSS/BSS Transformations using The Transformation Project Framework (TPF).
OSS/BSS transformations are notoriously complex and risky. They often require an intricate understanding of, and reengineering of, systems that have evolved over decades, And each of these components often have their own legacy processes and data silos. When these systems are integrated, the variant tree grows exponentially. And due to the importance of OSS/BSS to the operation of every network business, the stakes of successful transformation are immeasurably high.
The typical transformation journey tends to be riddled with potential pitfalls including massive disruption to critical services, ballooning costs due to unforeseen challenges and resistance to change among teams who can have a debilitating fear of the known (and perhaps an even bigger fear of the known!). There are also layers of dependencies to navigate across people, process, hardware, software and more. All of these factors combine to create an environment where fear pervades and confident leadership is required.
In other words, a clear, concise and comprehensive plan can help to allay the fears of many. They can also help to aggregate and coordinate resources, whether human, suppliers or capital.
.
Clearly, OSS (Operations Support Systems) and BSS (Business Support Systems) transformation programs tend to be large, complex and risky. As such, it’s often difficult to know where to start… and even more difficult to manage the transformation through to completion.
In conjunction with TM Forum, Passionate about OSS (PAOSS) has developed the The Transformation Project Framework (TPF) (also known as GB1011). PAOSS was awarded the TM Forum Contributor of the Year for its work on this framework.
It has been designed to systematically address most of the challenges mentioned above, offering a clear, flexible, and standardised approach to managing complex OSS/BSS transformation projects.
After a quick introduction to the TPF, the intent of this page is to provide you with the tools, and a step-by-step approach, for you to plan, then implement your own complex OSS/BSS Transformation. If you need guidance along the way, PAOSS provides planning and implementation support services, but hopefully this page will help you on your journey of self-sufficiency.
.
The key issues that the TPF addresses include:
Lack of Standardisation and Best Practices
There are already widely-used project management methodologies, such as PMP / PMBOK, but the specifics of OSS/BSS transformation best practices and standard methodologies are absent. The problem with OSS/BSS transformations, as perceived by many, is that every project is vastly different from the rest. The TPF addresses this by providing a common taxonomy and a set of defined work breakdown structures (WBS). This enables organisations to leverage established guidelines and proven strategies.
Complex Integration of Legacy and Modern Systems
The transition from traditional BSS/OSS systems to digital architectures based on Open Digital Architecture (ODA) and Open APIs is inherently complex. The TPF assists in bridging the gap by mapping transformation activities to specific TM Forum assets, which in turn simplifies the integration of new technologies with legacy systems
Inefficient Project Planning and Execution
Without a systematic framework, transformation projects can fall prey to ad-hoc and inconsistent planning methods. The TPF offers a structured approach that facilitates clear scoping, strategy definition, and agile execution. This reduces the risks associated with managing multiple overlapping projects and streamlines the coordination of transformation activities
Difficulty in Assessing Current Maturity and Future Needs
Many organisations lack a reliable method to evaluate their current state and to envision the desired future state in a way that aligns with market and technological trends. By incorporating elements like the Digital Maturity Model (DMM) and Digital Organisation Transformation (DOT) Model, the TPF guides stakeholders through a comprehensive assessment process, ensuring that transformation strategies are both informed and forward-looking
Misalignment Between Business Goals and Technology Implementation
Transformations often falter because they do not adequately address the full spectrum of business, operational and technological challenges. The TPF helps in aligning project activities with business objectives, ensuring that every stage—from strategy definition to implementation—is geared towards realising tangible business benefits
The Transformation Project Framework serves as an essential blueprint for organisations aiming to execute digital transformations in a consistent and integrated manner.
The TPF provides flexibility and extensibility to cover any type of OSS/BSS transformation, including project categories such as:
Technology-centric transformations (eg new OSS)
Operational-centric transformations (eg new Ops Models)
Business-centric transformations (eg new Go-to-Market such as new customer offers or bundles)
Product-centric transformations (eg new OSS vendor products or capabilities)
Data centric transformations (eg greater insights, analytics, etc)
Finance centric transformations (eg new revenue models)
.
eTOM (Enhanced Telecommunications Operations Map) (GB921) is a widely known and widely used standard in the OSS/BSS industry.
As such, the TPF has been designed in a similar fashion to build on existing familiarity with eTOM.
The TPF is designed to be for transformation & project activities as eTOM is to process activities.
This is achieved by defining each area of project activity as discrete elements that can be progressively decomposed to reveal further detail or interconnected branches of related tasks.
These elements are then integrated into a Work Breakdown Structure (WBS) model to illustrate organisational, functional, project phasing and other relationships that are required to plan an OSS and/or BSS transformation project.
The TPF also includes examples of WBS for various types of OSS/BSS transformations.
.
Now, that’s enough on the theory. The next sections provide a Step-by-Step guide to help you design your own OSS Transformation Plan, no matter how complex your unique situation is.
The aim of the TPF is to use top-down planning rather than a bottom-up approach. This means, we will address the project phases and then provide more granular breakdown of activities from there.
At the highest level, every transformation can be classified into five key facets:
Figure 1 – Level 1 TPF Project Model
This can be built out as the first layer of the WBS in Divv.AI as shown below:
Figure 2 – Level 1 TPF WBS Hierarchy
.
This transition between phases can also be visualised as follows:
Figure 3 – Level 1 TPF Project Implementation Planning Flow
.
We then turn the project phases into the initial top-down WBS structure (Level 1/2 Activities) using the GB1011 outline:
Figure 4 – Level 1+2 TPF WBS Hierarchy
Here’s a worked example using TPF building blocks below in Figure 5.
Figure 5 – Level 1+2 Worked Example WBS using TPF modules
.
After starting with the initial TPF template, we then progressively drill deeper into the hierarchy of activities (ie Level 2, 3 and 4+ activities) that meet the needs of the project.
Next, we continue to break the project activities down into smaller activities (noting that the colour-coding indicates which stakeholder is responsible for the activity)
Figure 6 – Further Decomposition of the TPF WBS Hierarchy
A common story you hear in the OSS industry is that every project plan is bespoke. There’s definitely some truth in that but what we’ve noticed over many years of designing these projects is:
However, we do still want to bring some consistency to the Delivery / Implementation Phase too.
We do this by evaluating the project:
We’ll discuss more about these two features in the sections below.
.
As mentioned earlier, the Implementation Phase section of the WBS tends to be unique per project and per customer.
This is where we either add a single project or multiple projects into the master WBS under the project section (ie WBS 1.5). These projects are in alignment with the implementation plan discussed in Figure 2 above.
The example below shows a program with 11 projects (WBS 1.5.1 to 1.5.11) and room for others to be added.
Figure 7 – Multiple Implementation Projects in an OSS/BSS Transformation Program
Each of the listed projects (eg Field Workforce [WBS 1.5.3]) has its own sub-WBS on a separate sheet, such as the cropped example in Figure 8 below.
Figure 8 – Cropped Example of a Project sub-WBS
Each of these Projects will be very different in nature, but we still aim for consistency. We do this by leveraging common transformation streams or building blocks, as shown in Figure 9 below:
Figure 9 – Common Transformation Streams
You may have noticed that these streams correspond with the top row of activities in the sub-WBS shown in Figure 8.
The most eagle-eyed of you will have also noticed that not all of these streams will be required on all projects. In Figure 8, you’ll notice that The Customer Transformation and Business Model Transformation streams aren’t required for this Field Workforce transformation project.
.
Beneath these transformation streams, the TPF also provides a database of hundreds of project activities. These atomic objects can help you to build out the details of your OSS transformation plan. Some of the pre-defined activities are shown in Figure 10 below but you can also create your own as needed for your project.
Figure 10 – Atomic Project Activity Pick-list
.
Now we have the structure of our entire WBS completed. It’s our project or program POAP (Plan on a Page).
Next, it’s time to add in further details about each activity. As shown in Figure 11, these include details such as:
Figure 11 – Extensible Attribute List for each WBS Activity
These attributes are important for what comes next. They help to generate the detailed tickets of work and project management artefacts. In turn, these are used to help in the day-to-day implementation of the project / program.
.
Firstly, the WBS activities and hierarchy can also be used to generate:
The actual hierarchy you use might be dependent on which Agile Ticketing tool you use. For example, the default hierarchy in Jira is limited (Epic → Story → Sub-task).
An example of an extended Jira hierarchy might look more like the following, which can reflect the deeper hierarchical layers needed on complex OSS Transformations:
Figure 12 below shows an example of how the WBS hierarchy on the left maps to the Agile Ticket hierarchy on the right:
Figure 12 – Hierarchy of WBS / Agile Activities
As we build the hierarchy of tickets, we also use the attributes (discussed in section 5 above) to generate the details within each Activity / Ticket-of-Work. An example is shown in Figure 13 below.
Figure 13 – Detailed Agile Ticket of Work
.
The WBS and associated attributes are then used to create reports such as:
We then use these project artefacts to manage the project on a day-by-day basis.
.
Step-by-step video of how to create a complex transformation plan based around the concepts of The Transformation Project Framework (TPF) (GB1011) using WBS tools is coming soon.
.
As you undoubtedly know already, each OSS challenge is unique. They’re all complex, they’re all different. Hopefully the step-by-step guide shown above has helped you map out your transformation plan.
If you’re seeking further assistance putting together your unique OSS transformation plan, we’d be delighted to assist.
To discuss ways you can optimise the effectiveness of your next OSS/BSS transformation, start with Step A and Request an Appointment:
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.