Understand how change management and project management fit together
Why isn’t change part of the project life cycle?
Many project professionals would argue that managing the transition from the current state to a new way of working is within the scope of the project life cycle. Practically, this does not happen, with the activities and effort required to manage the change brought about by the project passed to the users at project closure. This is because:
- It is not cost effective for project teams to remain in place once development and testing of the deliverables has been completed.
- Change activities can benefit from the knowledge of the project team, but individuals cannot outsource implementation and embedding, they have to make the changes for themselves.
- Projects are expected to deliver on time, on budget and to specific quality criteria, but the pace and scope of changes that individuals adopt cannot be constrained in this way.
- The objectives of project and change activities are different. Project activities deliver the potential for change: the new processes, systems, organisation structure, etc.; change activities create the persuasion, motivation and leading by example that results in the new business environment.
Projects and change deliver business transformation
Business transformation requires a combination of change management and project management. Change management defines what is required, triggering a project to create the requirement. The project results in new information, systems and processes which are then implemented into the business environment through change management activities.
Figure 29 shows how change management can trigger projects through the change life cycle, and how each phase of the change life cycle is dependent upon the successful delivery of these projects.
This might make me unpopular, but projects don’t come first. They only exist because somewhere in the organisation a decision has been taken to make a change. My organisation has invested heavily in project management training and setting up a project management office, which has given a lot of power to the project managers. But really they are not in control; it’s the people who decide that we need to change who are running the show.
Projects do not take place in isolation. They require the involvement of those who will use the project deliverables, incorporating them into new ways of working. This involvement is affected by how users feel about the proposed changes. The vision and stories of how the change will lead to an improved working environment are key to influencing, motivating and persuading individuals to give their time and expertise to the project. In turn, the deliverables and achievements of the projects can be used to inspire and enthuse users to become more involved in changing their environment. Figure 30 shows how the change management techniques explained in this book trigger the need for projects and can also be used to implement what the projects deliver.
Integrating change activities into the project life cycle
In order to demonstrate how change management can be improved through stronger links with project management, I have aligned the two disciplines within a simple five-step project life cycle, but my suggestions are applicable to all project life cycles including those defined in PRINCE2® or the bodies of knowledge from the Association for Project Management or the Project Management Institute.
Rather than define every activity, document, review or decision, I shall examine each stage of the life cycle of a project to find the opportunities for implementing and embedding change.
The purpose of this stage is to understand the idea that forms the basis of the potential project and define it in sufficient detail for it to be reviewed and evaluated. At the end of this stage, the idea is either rejected, or authorisation is given to define it further.
Figure 32 shows how outputs from the change life cycle are essential inputs to the creation of the project brief. The project brief explains the purpose of the project, and this is driven by the requirements of the change, embodied in the vision, stories, roadmap and blueprint.
Concept is an information-gathering stage resulting in a definition of the scope, requirements, objectives, benefits and risks of the project. This information is typically recorded in a project brief or project scope document and is used to decide if the project is viable and worth defining further.
This information is a product of:
- research about the change and the reasons for the business transformation;
- requirements-gathering activities, which provide an opportunity for users to describe what is to be created by the project and how these deliverables will be deployed.
Research about the change
Figure 33 shows how the documents produced to justify the change will not be wholly relevant to the scope and objectives of a specific project, but are a useful source of background information.
In my role as project manager, I really enjoy working on projects that have come about through a well-planned change. Objectives and scope are pre-defined as my project has to match what the change is trying to achieve. It is more difficult to work on projects that start out as apparently small-scale ‘improvements’ but evolve into large-scale change, as more and more needs are identified. Then I feel as if the responsibility for the whole change effort has become my problem, when what we really need is a change manager looking at the implications from an organisation-wide perspective.
Requirements gathering involves discussion with all stakeholders to pinpoint what deliverables are needed, which features are most important, what inputs the deliverables require and what outputs they will lead to (e.g. information, decisions or physical items).
To keep the project on schedule, project teams might be tempted to speak to as few stakeholders as possible. However, by asking for this information, the project team are encouraging individuals to begin the transition. The earlier individuals can move through shock, anger and denial into acceptance of the change, the earlier the implementation of the change can begin.
To widen participation in requirements gathering, the project team should enhance interviews and one-to-one meetings with the use of focus groups and workshops. These involve a higher number of participants and have the capacity to generate an energy and engagement with the project and its associated change that is not possible in an interview.
When the idea for the change is first announced, there is likely to be shock and in some cases anger that the current approach is no longer ‘fit for purpose’. People are acutely aware of how much they could lose when change happens, and this can make them unwilling to participate in a requirements-gathering exercise. This may be in stark contrast to the project team who are excited to be involved in the project and are looking forward to getting started. The project team needs to give the users an opportunity to vent their anger and to decide for themselves how much to co-operate.
This stage defines the activities needed to deliver the idea: to prioritise, sequence and resource the activities through the creation of a project plan. The project organisation structure is designed and details of how the project will be managed are defined in a range of strategy documents. This information is contained within a project initiation document or project charter. At the end of this stage, those sponsoring the project can evaluate it and either reject it or authorise its development.
Figure 34 shows how specific change management documents can add vital information to the project plan. For example, the roadmap and blueprint can provide milestones that the project must achieve, and the change plan and change communications plan identify specific activities relating to the implementation of what the project delivers, which will require the involvement of the project team.
There are benefits to be gained from working with the change team in creating a unified project/change plan:
- Those who work in project management have often received extensive training in planning, scheduling and resourcing techniques that can be of benefit to those who are creating the change plans.
- The activities in each plan share common resources so it is sensible to integrate the activities to avoid resource conflicts and minimise disruption to business as usual.
- It removes duplication of effort. This is especially true of communication where there is potential to create confusion amongst the stakeholders if project and change communications are not integrated.
Incorporating change management into the project plan means including more activities, but it also makes available a bigger pool of resources. We can now draw on all those impacted by the implementation of the change. When assigning resources to each activity, ask ‘How can I involve people who are part of this change?’ Involvement provides individuals with a mechanism to move through the transition curve and increases their ownership, so that they are doing change to themselves rather than having it done to them. There should be no restrictions on the type of activity that can be offered as an opportunity for involvement:
- defining the new business processes;
- defining the information flows and decision points for each new business process;
- defining the functionality of systems and software;
- defining the information fields for screens and reports;
- identifying how quality will be reviewed in the process;
- specifying the quality criteria that processes and systems need to meet.
A lot of the activities identified in the change plan can be incorporated in the project plan, so that whilst the new products and services are being developed, they are also being marketed to the users. These pre-transition activities can support the change on two levels by:
- helping individuals prepare emotionally for the change, using their interaction with the project to move through the transition curve;
- identifying activities to prepare the working environment to be ready for the change. The project is delivering new products and services but they will only realise business benefits if the support mechanism around them is ready. This includes:
redefining business processes to take account of new functionality;
reorganising roles and responsibilities;
preparing the physical and IT infrastructure to be ready to incorporate the new products and services.
Part of project planning involves identifying and analysing the risks. Traditionally this covers risks to the delivery of the project but we need to widen this to include risks of adoption of the change, risk of productivity dip during the implementation of the change and the risk that the change will destabilise the business-as-usual environment. By identifying these risks and identifying the actions needed to mitigate them there is a knock-on effect to the scope of the project plan, as many of these mitigating actions will reside within the business-as-usual environment.
The business case for the project is developed to prove the viability of the project. The benefits are measurable improvements that result from successful delivery of the project, but, in some cases, the creation of the deliverables is only beneficial when it is implemented as part of the overall change. Therefore, the benefits of the project and the benefits of the change may be closely aligned.
The costs of those projects that incorporate change management activities may be higher than those projects that focus solely on delivery. This is because the time taken to involve those impacted by the change is greater and often requires more resources, for example:
- workshops to involve a high number of individuals in requirements gathering, planning, risk analysis and communication activities;
- training significant numbers of people in understanding the deliverables and providing one-to-one user support.
Figure 35 shows that incorporating change activities into the project life cycle can shorten the overall duration of the business transformation as individuals move towards acceptance of the change through their involvement in the project, rather than their transition being triggered at the end of the project.
Overall, the additional costs of incorporating change activities into the project should be outweighed by the shorter time taken to fully embed the change and realise the benefits.
Organisations that have a successful track record in implementing change align the processes for project and change and the teams responsible for them to a common objective of realising the benefits of the change. This shared responsibility can be reflected in the organisation structure that is created to support transformational change.
Figure 36 shows those responsible for the change incorporated into the project organisation structure, whilst in Figure 37, project and change structures share a common senior-level governance structure.
As part of the project initiation document or project charter, how key elements of the project will be managed are defined, including the approach to risk and issue management, how quality will be managed and how the benefits identified in the project business case will be reviewed and measured.
Benefits from the project cannot be realised unless the project deliverables have been implemented and embedded into the business environment. Therefore, there is a strong link between the activities undertaken within a specific project to deliver benefits and the activities that continue after project closure to ensure that the new ways of working are delivering the improvements expected. Whilst progress on the achievement of benefits will be reviewed throughout the project life cycle, the need to realise benefits from the overall change is the responsibility of the change manager. The change manager and project manager need to work closely together to ensure that their efforts are complementary and not in conflict. If the project is not on course to deliver any benefits, then its viability is questioned; but similarly if the change is poorly communicated and resistance to change is high, then the ability of the project team to deliver benefits is negatively impacted.
The purpose of this stage is to research, design and develop the deliverables. Some of those working in the project team will have been drawn from the user community. Their combined knowledge of the project deliverables and the business environment mean that they can contribute greatly to persuading and influencing their colleagues to become positively engaged with the change.
The project team needs people who can ‘walk in the shoes’ of those being affected by the change. They can have peer-to-peer conversations with those who are suffering as a result of the change, they can talk the language and explain why the change is going to make life easier, not as a corporate message, but with real proof about real processes.
These project team members can provide the information needed to trigger the development of new roles and responsibilities, new processes and KPIs. Time must be included in the project plan for these individuals to perform their project role and to carry out their relationship role, building a bridge between the work that their former colleagues are doing (the current business as usual) and the results of their project work (the new business as usual).
If the project plan allows time for developing, testing and delivering only, vital opportunities for communication will be lost.
The purpose of these communication activities is to suggest ways in which deliverables from the project can be used to overcome well-known problems within the business-as-usual environment, or to implement ideas that have been talked about and have support, but have never been implemented. It is the up-to-date knowledge of business processes that make these project team members effective communicators, as they have a ready-made rapport with their colleagues and are able to empathise with them and engage with them as a peer group.
Figure 38 shows how activities from the change life cycle continue to be of value throughout the development phase of the project. The stories that individuals use to explain the change can provide a good understanding of how the project deliverables will be used in the business environment. The feedback from stakeholders and the reactions of those adjusting to the change through transition can impact how the deliverables will be used and, therefore, what functions should be examined during quality reviews.
During development, the project can become inward looking, concentrating on solving technical problems and ensuring progress is on time and on budget. To retain focus on the alignment of the project and the wider change initiative, the progress reports from project team members and the progress reports from the project manager to the sponsors and senior decision makers should include assessment of the success of the change activities, identifying:
- the level of support for the change;
- the level of adoption that has already taken place;
- the challenges to successful implementation of the project deliverables.
The purpose of this stage is to quality review the deliverables of the project, either as individual components (unit testing), or fitted together as the final integrated product (system testing).
Testing is an opportunity for more users to become involved in the change. Users begin the process of implementing the change by using the testing of how the deliverables operate to define the processes that will surround them. Workshops can be held to define the inputs, processes and outputs that are affected by the new deliverables. This is an opportunity to transfer ownership for the deliverables from the project team, who created them, to those who will be responsible for implementing the change and creating the new business-as-usual environment.
Testing is not only about the quality of what has been produced, but also about whether it is fit for purpose to achieve the desired business gain. What this means in practice is that the product can deliver benefits in the way it can be used, rather than necessarily meeting exactly the original specification that was set for it. This tells us that for the project to contribute effectively to change, there has to be tolerance in the scope and requirements of what is produced.
Test scripts have to be developed that describe how the product is to be used and what the expected outputs are; the questions they ask should be answered with a definitive ‘Yes’ or ‘No’. This encourages testing to investigate the impact of the deliverable on the overall business process rather than testing the presence of specific features – identifying if use of the product has delivered business benefits.
Another problem is the pressure to accept test results that prove that the product has met the requirements, even if the test indicates that the desired business benefits have not been achieved. The reason for this is that having to go back and rework part of the product in response to a failed test can have a serious impact on the schedule and budget of the project.
Training in the new deliverables usually takes place in this phase of the project life cycle, and this is an excellent opportunity to engage people with the change. The purpose of the training has to widen from ‘How does the deliverable work?’ to ‘How should the deliverable be applied to my work?’
Project training is usually training in the functions, features and uses of the products created by the project. In implementing change, the focus of the training needs to be on how to apply what has been created to business needs. This requires a level of engagement with the anticipated benefits of the change and how processes and working practices will need to alter to make full use of what the project creates. For this reason, training of those involved in implementing the change should take place as early as possible so that they can use their knowledge to feed into the change.
The purpose of this stage is to hand over the deliverables to the users, ensure that all the project documentation has been completed and is ready for archiving, and that all outstanding issues have been closed or have been notified to the users. It is at this point that the project team are released to other work.
During the project, greater understanding of the requirements and the management of risks and issues will have led to amendments to some deliverables, and the need for some deliverables to be removed and new products added. The project team has built up a detailed understanding of the deliverables, including:
- detailed understanding of the inputs and outputs from each of the deliverables;
- the performance of the deliverables under different test conditions;
- minor amendments to the deliverables from their original specification;
- good practice about the way in which the deliverables should be used.
This is often vital information for those managing the change, as it answers many of the typical questions raised by those implementing the change; for example, ‘Why does it do this? It would be more useful if it did X; why did the project team not include this feature?’ The project team has the answer to the questions, ‘How did we get to this point?’ and ‘Why does the product work this way?’
This knowledge can help those implementing the deliverables to make the detailed changes to their working practices that will realise benefits and create the positive outcomes intended by the change. However, it is often at such a low level of detail that:
- It appears so minor that it is not always captured in the project documentation.
- Those implementing change do not have the time or inclination to trawl through detailed project specifications and test results to find it.
For this reason, closure should include a period of support between some members of the project team and those responsible for implementing change. Contributors to this book outlined their own approach to this:
On any project that we deliver, I schedule for 25% to 30% of the project team to be available for up to a month after go-live. They are available to answer any and every question that users have, but as this doesn’t always keep them fully occupied, we schedule preparation work for their next projects during this time.
We call the period between handing over the deliverables and walking away ‘the warranty period’. I agree with the department heads how long they want support and then pick a couple of those who worked on the project the longest and know the most to stay around and help the users.
I build this transfer of knowledge into the project plan. A couple of users are selected early in the project to be project liaison officers and they sit with the project team and absorb everything there is to know. They go to every project meeting, they review everything the project team produce and they are responsible for communicating what they know back to their colleagues.
Another critical element of closure is the project review, which establishes if the project has delivered what was required and if it has delivered the benefits that were outlined in the project business case. It is essential the results of this meeting are communicated to those managing the overall change:
• project successes (achievement of benefits, well-received project deliverables) will feed the impetus for making the change;
• shortfalls in expectations will increase the resistance to change.
If possible, the change manager should participate in the reviews and understand the impact of the project at a detailed level, so that any amendments to the change plan can be identified.