OSS Change Management

“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.

Understanding the Business Model

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.

Implementing Change

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!

The Kotter Model for Change

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

• Unless the organisation has an urgent, compelling reason for change then the project will not get the prioritisation and urgency of effort that it needs
• The compelling event for the OSS (eg impending crisis, competitive opportunity, etc) must be clearly articulated and communicated to generate a “call-to-arms”

Step 2:  Creating the Guiding Coalition

• OSS transformation is so wide-ranging that a powerful force is required to sustain the project
• The guiding coalition must have multiple project champions that are required to have:
  • Position Power – including business unit managers and/or key stakeholders
  • Expertise – to ensure informed decisions are made
  • Credibility – to ensure recommendations are taken seriously throughout the organisation
  • Leadership – to drive the organisation through the transformation through a combination of vision and management
  • The guiding coalition needs to agree on a common goal rather than the goals of individual business units

Step 3:  Developing a Change Vision

• Must present a clear, concise future state as well as how it is to be achieved and by when
• Develop strategies for achieving the goal, so that team leaders can align individual goals with the organisation’s top priorities
• Each individual or team can only focus on 1-3 high-level priorities at a time

Step 4:  Communicating the Vision for Buy-in

• Use every mechanism available to reiterate the vision
• Perpetuate the vision through all members of the Guiding Coalition, business unit managers, team leaders, etc
• The reason most people don’t reach their goals is because they never set them
• Leaders on the team must clearly define the activities to achieve the 1-3 higher-level goals

Step 5:  Empowering Broad-based Action

• Transformation can only occur on the efforts of many, but most people are fundamentally change averse
• Understand and remove obstacles (behaviours, skills, attitudes, etc) thus empowering change
• Make changes to ancillary systems or structures that might undermine the vision
• Encourage innovative ideas, activities, actions

Step 6:  Generating Short-term Wins

• Essential to show the team, stakeholders and opposers that progress is being made
• Examples of short-term wins can include:
  • Commission OSS tools that have simple and/or one-way data flows (eg SNMP traps to an alarm management tool, or performance files to a performance management tool)
  • Convince the vendor to establish a “sandpit” environment (an “out-of-the-box” version of vendor software that is functional but not yet customised for the organisation) for team members to begin using
  • Rationalisation of infrastructure, particularly if it generates cost savings (eg reduction of licences or hardware replacement)
  • Organisational re-alignments / re-structuring
  • Implementation that overcomes immediate business needs
  • Implementation that reduces revenue leakage or activates new revenues
• Create a compelling implementation scoreboard
• Plan for performance improvements that will be visible to a broader audience than just the implementation team, the implement the improvements
• Create mechanisms to recognise and reward employees who have been responsible for the deliverables

Step 7:  Never Letting Up

• Hold each other accountable
• Build teams around those who can implement the vision
• Programs need reinvigoration. Projects, themes, processes, people
• Refine or remove systems, processes and policies that don’t align with the overarching vision

Step 8:  Incorporating Changes into the Culture

• Build upon changes that you’ve successfully implemented
• Refine the processes, training and mentoring to articulate the improvements
• Build a pyramid of support for the change, ensuring the change becomes inculcated in 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-flight planning changes

“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.