How we change what others think, feel, believe and do

Delivery

Disciplines > Change Management > The 4D Change Project Framework > Delivery

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.

Deployment

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.

Timescale

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.

• Implementing all in one go makes process transition and interface with other processes easier, but it may require widespread short-term education and any solution failure could be catastrophic.
• Deploying the solution piece-wise allows for safer real-world testing and enables implementation support from a smaller team, but takes longer and can cause problems where multiple solutions are being used by different people.

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:

• Time pressures: Too busy at the moment. Delayed meetings. Missed appointments.
• No need: Current solution is sufficient. Not for me.
• Objections: Problems with the product. Difficult to use. Not good solution.
• Poor analysis: Situation not understood. Needs more study.
• Better way: Not a good solution. Here’s a better way.

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.

Communication

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.

Education

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:

• Training classes: Standard classroom sessions that can range from an hour to several days.
• Presentations: Presenting to groups in various meetings to educate in their social groups.
• Learning groups: Methods such as Action Learning used self-driven groups to help learning.
• Written documents: Manuals or online help, ranging from ‘quick start’ guides to technical manuals.
• Posters: Posters on the wall remind people of changes and can highlight key points.
• Available help: From support people, helpdesk or local champions.

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:

• Level 1: Satisfaction with course, as measured with the ‘happy sheet’ feedback in the classroom.
• Level 2: Assessed knowledge and skill, typically done with a test at the end of the course.
• Level 3: Behavioural change back in the workplace.
• Level 4: Actual benefit gained by the organisation.

Managing commitment

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.

Assurance

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:

• Preparing contingencies
• Introducing the solution one element at a time
• Introducing the solution one group at a time
• Running the solution in parallel with the old system
• Having a ‘swat team’ ready to investigate problems or provide extra resource

Support

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.

Review

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.

Solution performance

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:

• Cost savings made, both one-off and ongoing.
• Time savings made, both one-off and ongoing.
• Reduction of burden on schools and other stakeholders.
• Increase in satisfaction of key stakeholders.

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:

• Did the project go to plan? Were any milestones missed? Was the final solution delivered on time? Why?
• Did unexpected stakeholders and issues appear later that could have been identified in the Discovery stage?
• Was the solution sufficiently described to enable agreement with stakeholders, design of detail and preparation for test?
• How well was the solution designed? Did it meet or exceed needs? Was it easy to construct, once designed?
• How well were risks identified and managed? Was sufficient effort put into preparing for them?
• What overall governance structure was used on the project? Was it sufficient?
• How well was the solution tested? What unexpected failures or issues arose about it?
• What resistance or reluctance to change was encountered? How well was this managed?
• How competent were the people working in the project? Could they have been supported differently?

Perception surveys

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:

• Were your overall needs met?
• Was there clear agreement of what would be delivered? Was this achieved?
• Were you kept sufficiently informed of progress? Were others kept informed?
• Were communications clear and to the point?
• Were changes to the solution and other issues handled effectively?
• Was the solution deployed effectively?
• What would you change about how the project was managed?
• What happened during the project that you would recommend carrying forward to other projects?
• Questions to ask people working in the project may include:
• Was the project well-managed overall?
• Did you feel that your contribution to the project was valued?

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.

Lessons learned

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:

• Keep: What worked? What strengths were identified? What should be perpetuated?
• Remove: What did not work? Why? What should not be done next time?
• Change: What should be changed? What should be kept but done in a different way?
• Add: What should have been done, but was not?

Handover

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.

Handover planning

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:

• Proof of quality assurance of solution, that it is tested and largely error free (it may well be impossible to guarantee zero errors).
• That they have had opportunity to test the solution, if possible in an operational environment.
• Manuals for new and experienced users, plus technical support documentation.
• A full copy of project documentation, from Project Brief to Design.
• Information about any outstanding commitments (inbound and outbound).
• Details of any agreements and contractual arrangements, with copies of contracts and SLAs.
• Copies of key correspondence, including agreements with other parties.
• Minutes and presentations from all project meetings.
• Availability of support for a period of time.

Archive

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:

• Key project documents, including Project Brief, Specification, Project Plan, Risk Register, etc.
• Information about stakeholders, from contact information to survey reports.
• Solution documents such as user manuals and training materials.
• Copies (as appropriate) of software source code and build instructions.
• Additional documents created, such as reports and research notes.
• Meeting minutes, decision logs and other operational records.
• Key email messages and details of other communications.
• Copies of contracts, SLAs and other formal agreements.
• Latest version of other documents described in this guide.

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.

Decamping

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.

Documents

The project may be considered complete when the following documents are completed, agreed, communicated and archived, and hence Gate 4 is agreed.

Handover Agreement

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:

• Stakeholders, their details and their interests (including possible future changes in these).
• Commitments and work outstanding within the project or by other people.
• Resources being handed over required to sustain the work.
• Process and technology details for operating the solution.
• Timelines of events that will happen and plans for these.
• Risks and issues outstanding.
• Deliverables created in the project.
• Management materials and other documentation from the project.

Project Review Report

The Project Review Report collates all review activity, including internal and external measurements, perceptions and reflections. This includes

• Project outcomes: What outcomes and benefits were achieved and whether the project was considered overall as being successful.
• Lessons learned: How projects should be run differently in future, including promoting best practice and

Project Story

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:

• Problem:
  • What was the original problem or issue as experienced and communicated?
  • What stakeholders were affected? How?
  • What was the original request for action?
  • What success criteria were set?
• Analysis:
  • How was the situation understood?
  • What measurement, mapping, etc. was done? What was discovered from this?
  • What interviews and discussions were held? What was discovered from these?
  • What were the causes of the problem?
• Solution:
  • What options were considered?
  • What was the solution used? Why this rather than other options?
  • How was the solution implemented?
  • What problems and issues were overcome in order to reach a successful conclusion?
• Outcome:
  • What happened as a result of the solution being implemented?
  • What benefits were gained? What did people say? What measurable changes were there?
  • What outstanding work is still to do?
  • What learnings were gained about change projects?

See also

Gate 4 Checklist