How we change what others think, feel, believe and do
The final phase of the change process can be simple and can be the most difficult stage. When deploying a change, assumed cooperation with target people can turn to resistance to change. Likewise support that may have been promise beforehand can evaporate as managers get cold feet about the potential personal impact of allying themselves with something that they are not sure will succeed in practice (and thus creating a self-fulfilling prophecy).
Delivery activity may or may not require significant deployment work or may be a simple handover. When completed, the project will then need a set of ‘wrap-up’ activities to allow the project manager to cleanly let go.
Unless there is a simple handover to someone else, the main activity of the Delivery phase is often deploying the deliverable to people. This can be the most difficult part of the project as resistance to change may be encountered. The diagram below shows the classic three Lewin stages of change and how these can be navigated.
New processes and products may be implemented for everyone at once or may be deployed one group at a time. This may not be a simple choice as there are pros and cons to either approach.
A compromise solution that may work is to start slowly, with ‘early adopters’ that help you test the solution and education in ‘real world’ use, then speed up the process to deploy the proven solution more widely. The diagram below shows the classic pattern of diffusion across a population. Each group is a different segment and needs different approaches.
Understanding emotional impact
When the news of change is perceived as ‘bad news’, then people typically go through an emotional cycle, as in the extended Kübler-Ross cycle shown below, in which they can show a range of symptoms as they struggle with the shock of the change.
A number of symptoms may be seen in this cycle during denial, anger and bargaining including:
Even when the solution is accepted positively, there can be problems as people go through a ‘honeymoon’ period where they expect things to be perfect and are disappointed when they are not. As with bad news, these ripples often need to be carefully managed.
Communications are of course important before and during substantive change and especially where external customer are involved. These should be carefully planned in the previous phase and adequately resourced.
Note that communication is a two-way process and what is communicated is the interpretation that people put upon the message, not what the sender intends to be understood. This highlights the importance of questioning, listening and verifying what is understood.
A dilemma with communication is what you tell people when, especially if the news is viewed negatively. Telling them early may cause disaffection and potential loss of staff, yet leaving it to the last minute creates shock and reactance. The best approach is often a stage-wise approach that reveals the change in managed chunks, starting with ‘change is coming’ and later reaching ‘you are affected in this way’. Engaging people in adult dialogue through the process can help smooth the way, for example where the inevitability of the change is clarified and alternative options explored.
Just giving the deliverables to people may not be enough – they may not understand or have time to explore and figure it out. A planned set of education should fit in with the target audience. Education can take a number of forms, including:
Note that education is what happens in the student’s head, not what is delivered. Adults in particular learn by doing, and especially where there is skill (rather than knowledge) involved. A practical ratio is 1/3 presentation and 2/3 activities that involve the student.
The success of education can be measured on the Kirkpatrick scale, which looks beyond the classroom to the real benefits gained. Thus there are four levels:
Previous commitment to a change can evaporate when the ‘rubber hits the road’ and implementation action is required. Beyond communication and education, commitment also may need constant personal attention to ensure objections are handled or escalated.
One of the most powerful forms of sustaining commitment is to actively engage people in the change, from design to implementation and also in managing commitment. When senior managers stand up and talk about the change, for example, they start to build their own internal commitment to justify their actions. Likewise when individuals have had a say in the design of a solution they attach their sense of identity more to it.
If commitment is not gained when it is needed then a formal escalation route is needed, which must be agreed and assured beforehand. In managing change, the people affected probably do not work for you and if necessary you need to work the formal chain of command.
As you deploy the solution, you need to ensure that the new approach does not fail. As above, this can be caused by human issues. It can also result from problems with design or construction, typically unexpected corner cases which are not supported.
Assurance activities in deployment typically involve double-checking that things are going to plan and that issues where the solution is less than perfect are identified and addressed. This can lead to sticking-plaster fixes and an early ‘version 2’ that integrates changes.
Where the total efficacy of the solution is unsure, other measures may also be taken to limit potential damage, including:
Where products are deployed, an ongoing system of maintenance and support may need to be implemented to ensure that the system will continue to work and that people are able to use it, including new people who may not have benefited from the deployment education and support.
Supporting the solution may require an ongoing helpdesk or individual person who can be called at any time to provide answers or physical help. It may also need education on an ongoing basis for new starters and advanced users. Support for the solution may also require a management and support system for those working in support, for example with descriptions of competencies required along with technical documentation and training.
Another way of providing support for simple solutions is to include this as documentation with the product itself, such as with a useful help system and ‘frequently answered questions’ documents. Note that support for managers sometimes needs to be different to support for those who will use the system.
At the end of the project, some form of review should be held to assess how the project worked in practice and to identify lessons to be disseminated to reduce the chance of problems recurring in future projects.
A review of the solution compares how well the final deliverables met the original intent. This can be done by comparing the solution with the outcome requirements from the Discovery phase. In particular where measurable success factors have been identified, these can be assessed to give an objective assessment.
Where possible, the performance of the solution should be shown quantitatively and indicate the benefits gained. This can include:
Review of the project process
As well as the outcomes, the processes by which the project was managed may be reviewed. This both helps the individual project manager improve and also shares learning and good practice with others. For the project manager this can take a strong integrity as they open themselves up to criticism and also critically review their own performance. A careful and honest balance needs to taken here between accepting personal responsibility, identifying improvements to the methodology and accepting the unpredictable events that led to difficulties along the way.
The real concern in any case is improvement, whether this is personal or methodological. The route to identifying the truth in this is to seek cause and effect, answering the question ‘why’ both for things that worked as expected and things that were more or less successful than intended. Open dialogue can be helpful where is disagreement about causes.
Questions to ask may include:
Surveys to determine satisfaction and other perceptions can be applied to key customers, people affected by the change and people working within the project and other stakeholders. Change projects affect different groups very differently and it is quite feasible that some groups will be less satisfied than others. A useful focus in such cases is that change management activity minimized the impact that the change had.
Questions to ask key client and customer people include:
When asking questions, it is useful to both include questions that have yes/no or multiple choice answers that allow comparisons, and qualitative comments that help with suggestions for improvement.
A useful review mechanism is the ‘Lessons learned’ meeting in which people involved in the project meet to capture perceptions and experiences into a set of ‘lessons learned’. Learning already gained from surveys, meetings and reflections may be presented in this meeting and implications discussed.
Four key questions are as follows:
When the project is completed, ownership of the solution and other project documentation needs to be handed over to a longer-term owner. Typically this is an operational manager but may include groups such as the Project Management Office or a technical support person or group.
Planning for handover should start right at the beginning of the project, with the ultimate owners being identified in the Discovery phase and delivery of their needs for handover being included in the project plans. They also need to be included throughout the project. The alternative is to reach handover and find either that you have nobody to whom you can hand over the project or that handover is refused unless significant extra work is done.
BAU owner acceptance
Handover of the project should be a relatively formal affair and is at the heart of Gate 4, with all requirements of the handover manager and group being checked off. Such requirements may include:
When the project is completed all documentation should be saved to a clear read-only structure within IRIS, where it can be accessed by appropriate people into the future. The general rule for archiving is to find a reasonable balance between archiving everything and selecting key documents. The principle is that if anyone needs to know anything about the project in the future, then it can be found reasonably easily in the archive.
Documentation to archive may include:
Particularly if there are more than a few documents in the archive, it can also be helpful to create a contents/index that helps people understand what is there and find the documents they need.
Sometimes separated out as the last 'close project' phase, decamping can be thought of as what happens when you end a camping holiday. The night before you may have a great celebration with stories of all your adventures. Then on the day you need to fold up the tents, put them away, clean up the field and put away your rubbish, leaving the site nice and tidy.
The project may be considered complete when the following documents are completed, agreed, communicated and archived, and hence Gate 4 is agreed.
In most projects the solution and documentation is handed over to another party for ongoing ownership. This may simply be handing documents to PMO and it may include a more complex change in reporting or ongoing management of the project. Critical is that this handover is done cleanly and with the agreement of all involved.
Handover agreements may include details and materials on:
Project Review Report
The Project Review Report collates all review activity, including internal and external measurements, perceptions and reflections. This includes
A Project Story provides a useful communication into the future to explain the project. This encapsulates learning about change and enables promotion of the Vanguard approach to change projects.
Whilst projects may vary and flexibility in this framework is helpful, a standard framing also helps the reader understand different projects stories. A useful framing for this is ‘PASO’ (which coincidentally means ‘transition’ or ‘change’ in Spanish). Questions that may be answered for each stage include: