So often projects go wrong precisely because change is not managed. And when the people – for whom a system is developed – do not accept the change, the entire project can fail! It’s one of the big risks that all too often is not even considered. I have seen projects where hundreds of thousands of dollars basically just go down the drain – all because people did not understand the importance of winning over, not just the stakeholders, but the day to day users.
It’s not an easy area to manage, but it must be done!
I always try to consider this aspect from the very beginning of the project. It’s important to discuss this with the stakeholders and project sponsors. Usually they would have a good idea of where the blocks may be expected and that’s a good starting point. If those people understand the risk and are prepared to support your change management strategies you are off to a good start.
Steps for Leading Change
There are many blogs and articles on change management. Possibly Kotter’s 8 principles is one of the better known ones. I won’t go through the principles here, but you can find a good example in this article, The 8-Step Process for Leading Change.
But to put things simply, I like to start with the following steps:
- Identify the people who will be affected by the change.
- Identify what the real benefits will be for them.
- Identify why the change is important.
- Identify what the perceived drawbacks will be for them – from their perspective (blocks).
- Identify who among that audience are the most open to change, who can understand the benefits, and who I can use to help me spread my message (champions).
- Think up fun ways to communicate information about what is coming and how it will benefit the audience.
- Draw up a change management plan with dates and actions – this must include ways to get the people identified in step 1 involved and enthusiastic.
A Simple Example Scenario
Here’s a simple example scenario of an impending change and the first steps I would take.
A new system is being introduced whereby applications that are emailed to the Admin team will be auto-forwarded directly into the application system and matched and linked to clients. The benefits of this are:
- Save hours of work for admin staff because they will no longer need to save emails to their desktops, and then manually attach them to client records in the database for processing.
- Reduce the risk of emails being forgotten or overlooked.
- Reduce risk of human error.
- Enable better KPI reporting for management because actions carried out can be tracked from the moment the email arrives rather than when someone finally completes the manual process.
First, identify those key issues for this scenario (steps 1 – 5 above).
Key Issue Example 1
Who: Management.
Real Benefits: Accurate KPI reporting and reduced risk.
Why: Report on real time to deliver is a key improvement required by the strategic plan.
Blocks: None – all managers are on board.
Champions: Team Leader.
Key Issue Example 2
Who: The Admin Team.
Real Benefits: Smoother processing, less scanning and allows the team to focus on the really important tasks.
Why: Reduces risk for the business and improves productivity (i.e., staff have more time to process the applications).
Blocks: People are afraid that reducing work will result in management cutting jobs and people think it will be a difficult process and are afraid they won’t cope.
Champions: Cindy Smith, Peter Redman
Communicate the Benefits of the Changes
Once the parameters of the change situation are known, it’s time to think of ways to communicate the benefits of the changes. I would work out a rough plan and then meet with the people I’d identified as champions to plan the change management. I would be very careful not to just push my ideas, after all, the champions probably understand their colleagues better than I do, and they could very likely come up with better ideas than me!
In all communications the most important thing is to make sure that you sell the benefits – not the features! So, you are not aiming at getting the audience to understand the technicalities of how the email gets from the client into the database (smart as that might be). Your aim is for your audience to understand that loads of tedious work will be transformed into more time to do the real work – processing the applications.
One of the blocks in this example is a fear that jobs could be cut because of the new system or module. Right away you need to clarify if there is any foundation to this fear. If not, your work is so much easier; you simply have to find ways to reassure people that this is not the case. If, however, jobs will be cut, then you will definitely need support from higher management and / or HR, and you will need to understand the strategy that the organisation has around this. Any worthy organisation will have redundancy packages and transition strategies in place for this.
The other block that has been identified is that people fear the process will be difficult to grasp. For this, you need to have plans in place for how people will be trained and for easy to follow user guides and then you need to communicate this to reassure people that there will be strategies in place to bring them up to speed as easily as possible with full support.
Some ideas for fun things that I’ve used in the past:
- In the lead up to change, send out periodic “did you know” emails. Depending on the length of the project these could be weekly or fortnightly. These should be concise but contain something that really sells a benefit of what is coming. For example: “Did you know that when an application arrives from one of the incoming mail boxes you will automatically receive an alert so you won’t have to keep checking if there is work waiting for you?” Another could be “Did you know you will be able to link directly to the incoming application from the alert you receive?” You could add sketches or real screen shots to bring these to life.
- Throughout the life cycle of the project it is important to keep communicating will all users and stakeholders. This can take a variety of forms ranging from a quarterly newsletter that is catchy and informative to holding monthly project update meetings. Be careful not to hold too many meetings and when you do, make sure that there is really some benefit and some wow factor so people walk away excited and enthused.
- Adding fun: If the audience has an appreciation for humour definitely capitalise on that. For example when holding requirement gathering meetings, instead of using terms such as nice-to-have and mandatory, for categories you could use “can’t live without”, “would be heaven, but hey, does heaven exist?” and “meh”.
I hope this post has given you some ideas about how to get people to buy in to change activities. Let me know what you think by leaving a comment below.
About the Author
Michelle Kandiliotis has worked predominantly in the role of business analysis over the past 15 years with some diversions into project and general management. Michelle is passionate about creativity, communication, mentoring, inspiring and motivating people, having fun, and benefiting the organisation.