Change Management: Before we get started, I need to make the following disclaimer: this article is not a hard-core change management article in which we discuss procedures and processes.
Instead, this article is aimed at people who want to know about change management in general and change management of IT projects, perhaps because you would like your own projects to be better received in future than they have been in the past.
The article is aimed at people who know that the success of an IT project should be measured by the reaction of the end users, but who are in doubt about how best to contribute to the project’s success by means of sound change management processes.
What is IT change management?
Unfortunately, it is rarely the technical requirement specifications that cause problems when changes to a company’s IT platform are implemented.
“Unfortunately” because it is often fairly easy to find solutions to such challenges. You can often solve the problem through programming or perhaps by tweaking the IT infrastructure so that the system operates more smoothly.
No, it is not the technical aspects that cause problems. It is the users.
Users who want things the way they always were. Users who don’t want to spend time and effort getting to know a new program, and who don’t have the necessary energy to change their ways. Most people don’t like change, when it really boils down to it.
Change Management is not about project management
IT change management is therefore neither about project management nor scrum methods or Kanban boards.
In fact, it is almost the complete opposite: it is about getting the users to embrace planned system changes and about giving the users the impression that the project is being managed professionally.
Simply speaking, change management of IT projects involves ensuring that the project becomes a success once implemented. This is a formalised process in which you consult the end users to create acceptance and perhaps even get the same end users to endorse the project and recommend it to colleagues and other stakeholders.
To make this scenario a reality, the change management work must commence long before you are ready to press the large red “implement” button. In fact, the work begins the very minute a project has been kick-started, and long before the first code is written.
When is change management needed?
It is tempting to believe that the formalised control of stakeholders only makes sense in large projects, but this is actually not the case.
Think of it like this: you don’t only consult your neighbours if you want to construct a building with 16 floors. You also have to consult them if you want to build a carport, or even if all you want to do is to plant hedging around the perimeter of your property. But why? Because your plans affect the day-to-day life of your neighbours.
The same applies to change management of IT projects, which are more about how the project affects the day-to-day work of your colleagues or customers than about its size.
READ ALSO: Dear IT manager. Are you ready? For the future.
Large company or small company – the process is the same
Of course, the process is not quite the same in a company with 500 employees as in one with 30, but the difference is smaller than you think. In both cases you have to avoid annoying your colleagues unnecessarily, and you must avoid at all cost that your project becomes one everybody loves to hate.
Negative talk around the coffee machine can start a vicious cycle and must be avoided. In reality there is only one way to stop the negativity: to involve the users in the change process at an early stage.
When and how should the users be involved?
A brief answer is: as soon as possible, and it doesn’t actually matter whether the users are colleagues or customers.
In large companies, the solution will typically be to involve the people who are responsible for the applications. An example would be a person who is responsible for your SAP solution or for the smooth running of the Office package.
By consulting individuals with relevant responsibility from the very beginning of the project, you make sure that a number of key employees feel heard, and with a bit of luck these employees will be ambassadors for the project when they get back to the company.
These key employees can also act as spokespersons for the end users, in part because they are often end users themselves, and in part because they are in daily contact with other colleagues about their specific application.
Input from users produce better solutions
By involving key employees in the right manner and truly listening to and adjusting the IT project on the basis of their input, you achieve two things:
- You avoid the vicious cycle of negative comments about the project.
- You can correct minor errors and integration issues and ensure a smooth roll-out of the new systems, while at the same time causing minimum disruption to the day-to-day work of the end users.
Of course, good change management is not a panacea that makes all problems vanish like dew before the sun. Thorough preparation can take care of perhaps 80% of the problems caused by an IT roll-out.
Once the majority of the problems are out of the way, you are left with a lot more resources to solve the last 20% that might pop up along the way.
How much information should you give?
As you have probably figured out, a good change management flow is about providing information and communicating with your users before hitting them with a system update.
Even simple updates of the Office package can mean hours, if not weeks, of extra work for an employee in the finance department who manages all his/her reporting with the help of carefully adjusted macros. If the macros suddenly no longer work, it can result in missed deadlines, overtime work and a lot of stress for the entire finance department.
Therefore, the main rule is: rather too much information than too little.
Make sure to start early when informing end users of upcoming updates. Explain what the updates will mean to them, and why they are important.
If your users understand why a system update is necessary, they are more likely to be patient with any problems that arise.
Let your users decide
Another good trick in the book is to leave it to the users to decide when they want the update to take place.
If an engineer needs to perform a number of calculations which may take three days, it is very useful for him/her to be able to postpone the updates until the calculations have been completed. Otherwise, the engineer risks having to explain the delay to an impatient customer.
Allowing the users to determine when the updates take place also gives them a feeling of control. They are given a choice and therefore not powerless about how they structure and plan their time. I am sure we have all experienced the irritation when switching on the computer to prepare for a presentation and then pling, you have to wait for 30 minutes while the system is being updated. Talk about a bad start to the day!
All things considered, change management in IT processes revolves around staying on good terms with the users who will have to live with the changes afterwards. Get them involved at an early stage and listen to their input. And remember to inform all the employees who are not involved in the planning as early as possible and as much as possible, so they always get an opportunity to plan their time around the updates. That is the only way you can avoid the biggest mistakes in an IT project.
