OSS Change Management

“For changes to be of any true value, they’ve got to be lasting and consistent“Tony Robbins

Various researchers have proven 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 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

Based on years of observations of OSS implementations, I have come to believe that organisational change management is THE 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 have observed projects where the tools and data sets have been configured nigh on perfect for the customer’s needs, but have seen the project fail due to the organisation being unable to cope with the change that the tools introduce. 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.

From these projects I have formulated a list of risks and associated actions aimed at managing the change created by the OctopOSS.

I have only recently become aware of the work of Dr John Kotter who presented the following 8 steps of change in a Harvard Business Review article. These 8 steps closely align with my independent observations on the successes / failures of OSS transformation, 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.

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 theOSS(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

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.