Change Management In Practice

An effective change manager will prepare an organisation for change in the early stages of project definition and stakeholder review. This may involve taking managers through a sales process and responding to any apparent resistance.

The process is likely to improve the project definition and buy-in. It will also ensure that it is clear the moment resistance materializes.

It is unrealistic to expect an independent change manager to tackle all forms of resistance but the change director can use his or her intervention as a signal to the organisation – such interventions should be few but telling.

An independent change manager is a cross between a foil and a lightning conductor – the foil ensuring that positive energy is deflected to the right place, the lightening conductor removing negative energy from the organisation.

Resistance is a key element in why change fails so, how can we manage resistance positively and avoid failure?

A recent informal UK survey of 120 government transformation programmes identified that:

  • 15% achieved their objectives
  • A further 20% failed to achieve their objectives but were nevertheless regarded as satisfactory
  • 65% were unsatisfactory.

A subsequent discussion forum identified 7 key reasons why change fails:

  1. The organisation had not been clear about the reasons for the change and the overall objectives. This plays into the hands of any vested interests.
  2. They had failed to move from talking to action quickly enough. This leads to mixed messages and gives resistance a better opportunity to focus.
  3. The leaders had not been prepared for the change of management style required to manage a changed business or one where change is normal. “Change programmes” fail in that they are seen as just that: “programmes”. The mentality of “now we’re going to do change and then we’ll get back to normal” causes the failure. Change as the cliché goes is a constant; so a one-off programme, which presumably has a start and a finish, doesn’t address the long-term change in management style.
  4. They had chosen a change methodology or approach that did not suit the business. Or worse still had piled methodology upon methodology, programme upon programme.
  5. The organisation had not been prepared and the internal culture had ‘pushed back’ against the change.
  6. The business had ‘ram-raided’ certain functions with little regard to the overall business (i.e. they had changed one part of the process and not considered the impact up or downstream) In short they had panicked and were looking for a quick win or to declare victory too soon.
  7. They had set the strategic direction for the change and then the leaders had remained remote from the change (sometimes called ‘Distance Transformation’) leaving the actual change to less motivated people. Success has many parents; failure is an orphan.

Very few organisations will be affected simultaneously by all seven; however, any one in isolation will make the change programme inconsistent and aggravate resistance. Advance planning and stakeholder management will avoid some of these pitfalls. Furthermore, the list is an invaluable diagnostic tool for identifying why (and where) resistance is taking place, giving an opportunity to defuse resistance by correcting mistakes.


Project Initiation – Basic Planning

How important is project planning?

The key to any successful project is in effective planning.  Often project planning is ignored by inexperienced project managers, in favour of getting on with the work immediately. However, what these managers fail to realise is the true value of a project plan: in saving time, money and problems further down the project lifecycle. Creating a project plan and its accompanying documentation (such as a Terms of Reference or TOR) is therefore one of the first things you should do when undertaking any kind of project work.

With this in mind, what follows is a simple, practical approach to project planning. As it is designed to be an overview of the topic we will not be drilling down into the finer detail of all the specific documents, such as the TOR; these will be dealt with seperately in due course. With this in mind, when we talk about a ‘project plan’, in this context it refers to the process only. In reality, it will comprise a portfolio of documents which collectively form a plan.

Step 1 – Project Goals

A project is successful when the needs of the stakeholders have been met. A stakeholder can be anyone who is directly or indirectly impacted by the project but, as a general rule, every project will have the following primary stakeholders:

  1. Business sponsors
  2. Users
  3. Suppliers

As a first step, it is important to identify the stakeholders in your project as they will all need to be represented on the management team. Once you understand this, the next step is to establish their needs. One way of doing this is by conducting stakeholder interviews: these may be done individually or in a group environment in which everyone shares their thoughts. Take time during this process to draw out the true needs that create real benefits. Learn to identify needs that are not relevant and which fail to deliver benefits; these can be recorded but given a low priority.

The next step, once you have gathered the information and have a comprehensive list of needs, is to prioritise them. From the prioritised list, create a set of goals that can be easily measured. A technique for doing this is to review them against the SMART principle; they should be Specific, Measureable, Attainable, Relevant and Timely. That way it will be easy to know when a goal has been achieved.

With your goals clearly established, record these in the project plan; they normally fit into the Terms of Reference (TOR) document. It can be useful to also include the needs and expectations of your stakeholders. This is the most difficult part of the planning process completed. It is now time to move on and look at the project deliverables.

Step 2 – Project Deliverables

Using the goals you have defined in step 1, create a list of things the project needs to deliver in order to meet those goals. Specify when and how each item must be delivered.

Add the deliverables to the project plan (the TOR document) with an estimated delivery date. More accurate delivery dates will be established during the scheduling phase, which will follow next.

Step 3 – Project Schedule

Create a list of tasks that need to be carried out for each deliverable identified in step 2. For each task identify the following:

  1. The amount of effort (hours or days) required to complete the task.
  2. The resource who will carry out the task.

Once you have established the amount of effort for each task, you can work out the effort required for each deliverable; give it an accurate delivery date. Update your deliverables section with the more accurate dates.

At this point in the planning process, you could choose to use a software package such as Microsoft Project to create your project schedule. Alternatively, use one of the many free templates available. Input details about all of the deliverables, tasks, durations and the resources who will complete each task. The output from this activity is commonly displayed and tracked within a gantt chart

A common problem at this point is when a project has an imposed delivery deadline from the sponsor, that based on your estimates, is not realistic. If you discover that this is the case you must contact the sponsor immediately. The options you have in this situation are:

  1. Renegotiate the deadline (project delay).
  2. Employ additional resources (increased cost).
  3. Reduce the scope of the project (less delivered).

Use the project schedule to support and justify pursuing one of these options.

Step 4 – Supporting Plans

This section deals with additional plans you should create as part of the planning process. They normally form separate documents – they are vital nuts and bolts in your planning portfolio:

  1. Human Resource Plan – Identify by name the individuals and organisations with a leading role in the project. For each entry, describe their roles and responsibilities on the project. Next, describe the number and type of people needed to carry out the project. For each resource, detail start dates, estimated duration and the method you will use for obtaining them. Finally, create a single sheet containing this information.
  2. Communications Plan – Create a document showing who needs to be kept informed about the project and how they will receive the information. The most common mechanism is a regular progress report (weekly or monthly), describing how the project is performing, the milestones that have been achieved and any work planned for the next period.
  3. Risk Management Plan – Risk management is an important part of project management. Although often overlooked, it is important to identify as many risks to your project as possible. Here are some examples of common project risks:
  • Time and cost estimates are too optimistic.
  • Customer review and feedback cycle is too slow.
  • Unexpected budget cuts.
  • Unclear roles and responsibilities.
  • Stakeholder input is not sought or their needs are not properly understood.
  • Stakeholders have changing requirements after the project has started.
  • Stakeholders add new requirements after the project has started
    Poor communication resulting in misunderstandings, quality problems and rework.
  • Lack of resource commitment.

Risks can be tracked using a simple risk log and, as the project gets underway, issues should also be added as they materialise. Add each risk you have identified to your log: write down what you will do in the event it occurs and what you will do to prevent it from occurring. Review your risk log on a regular basis, adding new risks as they occur during the life of the project. Convert them into issues, if they come to fruition. Remember, when risks are ignored they don’t go away.

Finally, remember to update all the documents as the project progresses and measure progress against the plan; keep all interested parties updated on progress.