
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.
“For changes to be of any true value, they’ve got to be lasting and consistent“
Tony Robbins
Various researchers have shown that approximately 70% of major change efforts are destined to fail. Anecdotally at least, this would appear to be mirrored in the failure rate of OSS projects.
The level of interdependency within OSS has a direct relationship to the complexity of change management. To use an analogy, in a standard game of chess, each piece moves in isolation based on certain fixed rules. But in an interdependent system like an OSS, it is like having strings, pulleys, etc linking the movement of one piece to another. So when a player wishes to move their castle by 5 spaces, it also moves their Queen by a seemingly random half a space, two pawns by 2 spaces and their Knight by one space. Even with excruciating planning, such a game could easily disintegrate into mayhem. This is where clear guiding visions are necessary to keep pulling the project towards a desired end state, irrespective of the unplanned impacts that arise.
As vendors increase the functionality of their solutions and as new systems are integrated with legacy systems, the level of complexity increases. As described in the Requirement Capture section, focusing on a simple set of benefits rather than product functionality will also simplify the change management process. To continue the analogy above, the aim is to remove the strings and pulleys so that the pieces can move in isolation.
There are so many options in terms of products, bundles, content, solutions, etc that a customer can build their network operations business model around. We currently have at our disposal the widest range of alternatives that we’ve ever seen in telecommunications. It is essential to understand the company’s business model before attempting a change program. This often provides the guiding vision for what the project is trying to achieve.
Since there is already a significant body of knowledge relating to strategic vision, it is assumed that the business model is already clearly articulated and is suitable for basing an OSS vision upon it. In some cases, a new business model will be driving the OSS transformation, effectively making it the key reason for initiating the change.
The amount of change in technology innovation, process, regulatory, etc means that businesses are taking an almost Darwinian approach to business models, adapting to new opportunities and approaches. In response, this places an increased emphasis on the OSS’s ability to facilitate those changes.
Organisational change management is arguably the most overlooked, yet fundamental building block around which an OSS project should be formed. An implementation team will typically focus on the functionality of the OSS rather than the organisation that will use that functionality. I’ve seen OSS transformation projects where the tools and data sets have been configured all but perfectly to match the customer’s needs, yet still seen the project fail due to the organisation being unable to cope with the changes introduced. In these situations, end-users quickly lose faith in the tools and develop workaround solutions. This in turn leads to process inconsistencies and a reduced integrity of the data in the OSS, which in turn leads to a further loss in faith in the tools. It is a vicious cycle that dooms the project to long-term failure. The OSS death spiral!
Dr John Kotter presented the following 8 steps of change in a Harvard Business Review article. These 8 steps closely align with the successes / failures of OSS transformations, which are shown as dot-points under each of Kotter’s 8 steps.
It should be clearly noted that Steps 1 and 2 are an unconditional requirement for the success of OSS transformation, but are commonly overlooked or not given the attention that is required. They’re often only implemented after the project is already showing signs of failure.
Step 1. Establishing a Sense of Urgency
Step 2: Creating the Guiding Coalition
Step 3: Developing a Change Vision
Step 4: Communicating the Vision for Buy-in
Step 5: Empowering Broad-based Action
Step 6: Generating Short-term Wins
Step 7: Never Letting Up
Step 8: Incorporating Changes into the Culture
This blog entry goes as far as to suggest that an OSS apprenticeship is required to incorporate the cultural change required to support your new OSS.
For more information about The 8-Step Process for Leading Change, please refer to Dr. Kotter’s book Leading Change.
“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
Dwight D. Eisenhower
OSS/BSS projects often have complexities and dependencies that few others can match. Initial plans invariably don’t fully reflect the obstacles facing the implementation team. As such, in-flight planning change is an essential attribute to build into your project.
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.