Sustainable Change Requires Preparation

Last time I wrote about a simple change lifecycle with a start, middle and end, and I focused attention to the end phase. That may seem a topsy turvy way of looking at things, but the reality is that if we don't think about the end goal at the start, we are going to have serious problems throughout the change cycle. It is generally accepted that change initiatives should be managed as projects. This is not an unreasonable assumption as one definition of a project is

"a temporary endeavour undertaken to create a unique product, service or result."

In the case of a change initiative the unique product, service or result is the change itself. Given that our assumption is valid it becomes apparent that the start of our change cycle will involve some planning and analysis activities. The extent and nature of these start up activities will depend on the size and nature of the change, and will also vary depending on your position within the organisation.

The difference between change project and other projects is that the degree of rigour required in the start-up activities is much greater when initiating organisational change. There are some additional considerations which may not be obvious to a product project oriented organisation. When an organisation kicks-off a new project, for example to build a new piece of software, there should be some form of up-front benefit and impact analysis. It's a good idea to launch a project knowing that you will get some return on investment, and feeling relatively confident that the new work will not negatively affect existing business (although sadly this type of due diligence is often not performed, and projects with little chance of success are undertaken regardless of their implications).

When undertaking an internal change project it is also a good idea to perform some kind of analysis regarding the ability and the capacity of the organisation to change. This means looking at the change history of the organisation (how successful were previous changes), the capacity of the organisation to absorb more change (how much change has recently taken place) and for both new and old businesses it's important to ensure that the infrastructure to support change is in place and effective (is there a change method, are there competent change agents). It is important to actually take notice of the data that you gather during this analysis. Many organisations ignore the information and go ahead regardless of the facts which will dramatically increase the risk of failure.

Who should be performing this start-up work? A dedicated change team is key, and should consist of a core team and subject matter experts who are co-opted into the team. Change management and project management are intimately linked and the change leader should have experience of both. Technical project managers may have the appropriate hard skills but sometimes lack the understanding of the change management cycle and the inherent difficulties associated with changing habits and culture. Change agents without the discipline of project management will also endanger the initiative as key tasks and activities may be forgotten or under prioritised.

Management and control are paramount in a change programme just as they are in a technical one. A change project needs scope management, budgetary control, configuration management, risk, issues and resource management. Communications and stakeholder management need to be in place and followed with additional rigour.

All these activities need a degree of up-front planning and management to maximise your ability to succeed. And of course you need to define, document and communicate your SMART (specific, measurable, achievable, relevant and time-bounded) objectives, along with your measurement plan to help you understand when you've reached you goal.

 In the next entry we'll look at the Five Facets of Change - the keys to running successful change programmes.

Knowing When Enough is Enough

In an increasingly unstable world, where corporations and individuals are being subjected to manifest and constant change it's frustrating to realise that there are still very few people who understand enough about the management of change to enable change programmes to have the best chance of succeeding. Often, even the simplest concepts are ignored. Given that change generally occurs over a period of time, it's not unreasonable to believe that some sort of lifecycle exists which can help us to manage the change. Even when change is spontaneous (such as when a person leaves an organisation), the effects still take time to manifest themselves across the organisational environment, particularly in the way that other people adjust and adapt. Some commentators actually resist the notion of organisational change altogether by talking about transitions by which we move from our current state to a desired state over a period of time. So our simple change or transition lifecycle consists of three parts; a beginning, a middle and an end. In reality, each cycle probably feeds into further cycles in a rolling wave of changes, but we'll come back to that in a moment. Despite the simplicity of the lifecycle, many organisations ignore both the beginning and the end, and focus all their attention on the middle. There's an element of human nature at work here because the middle is the part of the cycle where things are seen to happen, especially by senior management. In this respect, a transition project is just the same as any other project. Impatient sponsors or customers want to see action and results. Time spent doing up-front planning appears to have less value than time spent doing. And as for time spent reviewing at the end - well, clearly that's of no value at all since the project has delivered, so there's no point in paying for it. It's a bit like trying to get children to wrap up presents before Christmas and write thank you letters afterwards - generally they're not interested because there's no obvious reward for doing so. One of the key tasks that you need to perform during the beginning of your change cycle is to create the criteria to enable you to understand when the change is completed, which includes understanding when it's appropriate to begin the next change cycle. One of the main reasons that change initiatives fail is that new change cycles take place before the real success or failure of the preceding cycle is fully realised. I've come across several organisations that have embarked on rolling wave change initiatives where the current wave cancels out the achievements of previous ones - the old one step forward, three steps back scenario. Not only is this a waste of time, effort and money, but it leads to confusion across the organisation because change is never allowed to become embedded before it is swept out with the next tide. Confusion brought about through change initiatives will ultimately reduce the chance of success of future changes. The workforce will lose faith and trust in management that appear to be generating change for its own sake. During the start-up phase of your transition you simply must set SMART objectives against which the change can be monitored during the transition. These don't have to be particularly complicated, but they must be designed so that you know when to stop. Once you've reached that end point, as part of the review process, there needs to be some mechanism to ring fence those changes so that subsequent change doesn't eradicate all the good work you've put in. Unless of course, the change has been unsuccessful and you need to fix it. But of course, that wouldn't happen to you, because you will have spent adequate time at the start to make sure that you minimise your risk of failing! Next time, we'll look at the start phase of the change cycle in more detail.

Leave "Stealth Mode" to the spy planes

Over the years I've heard numerous references to "Process Improvement by Stealth". The New Oxford American Dictionary defines stealth as "cautious and surreptitious action or movement". Neither cautious or surreptitious are words that should be associated with process improvement or indeed any change initiative where the first three laws for success are Communicate, Communicate and Communicate. Stealth mode directly implies that you have something to hide or that something is not quite above board, and this in turn will anger, frustrate and disingenuate your key stakeholders, namely, the very people you are trying to change. If you can't be honest about what you are trying to achieve and the reasons behind it, and you cannot articulate those objectives in an open way then you shouldn't expect to be successful. Not only will the current change initiative fail, you will have sown the seeds for mistrust in future efforts. Is there ever a place for stealth in the world of business change? I believe there is, and there is evidence that it can be successful. The exception to the rule is when the change is initiated from below the management chain, where informal working practices are replaced by more rigourous processes, and adopted across teams and departments without formal process improvement or change management activities, and become the cultural norm. Whole businesses and industries have been born from this kind of stealth which tends to carry risks to individuals rather than organisations. In other cases businesses have been saved significant expenditure by individuals taking stealthy approaches to implementing management mandates which were born through ignorance and micromanagement. In general, however, leave stealth to the spy planes, and approach your change initiatives with open and honest communication and dialogue to minimise your risk of failure.

Consider all your Stakeholders

Over the next few days I'm going to change tack a little bit and post some bite size blog entries focusing on some critical success factors and key points of failure associated with operating an effective process management function and performing process improvement. Each of the entries I'm going to post represents an element of process management that is often overlooked, especially in inexperienced organisations or teams, but which may make or break your process related efforts. Today I want to pick up on the need to consider all your stakeholders, not just the immediately obvious ones. This is particularly relevant in the context of Software Process Improvement, where it is easy to focus your efforts in the project management and software engineering process areas. This is even more likely if you are attempting to run your improvements as part of a CMMI project rather than a business improvement programme. Clearly project management and software engineering groups and their managers are key stakeholders in this type of improvement programme. However, spare a thought for some of the other people you need to engage with. A few groups spring to mind immediately:

1. Finance
2. Human Resources
3. Procurement / Supply Chain Management

In most enterprises, there will be very few, if any, Applications Development/Maintenance projects or programmes that do not interface with these groups to some degree. Get the department heads involved in your process activities as early as possible. You need their support, and you need to know what improvement activities they themselves may be undertaking. There is no point in creating wonderful PM and engineering processes if they do not properly interface to the rest of the enterprise. A failure to take a holistic view of process improvement will cause no end of problems in the long term even if you appear to get away with it in the short term.