IT projects bring about changes for a company. Change management tailored to the requirements of the company can be decisive in whether the project succeeds.
IT projects often entail considerable changes for the company – or rather: its employees. Whether a new operating system is to be introduced or migration to the cloud is imminent: Well-established processes are taken apart and employees have to adapt their way of working to the new circumstances. IT projects therefore, like any change, have a potential for conflict that should not be ignored.
Effective change management is the method of choice to mitigate the associated risks in IT projects. The term "change management" is generally used to describe how a company deals with planned or ongoing changes in the sense of consciously and purposefully shaping the change process. This is primarily a strategic issue rather than a legal one. Nonetheless, the necessary contractual requirements for implementing effective change management should be established within the framework of an IT project contract.
Convincerather than surprise – accompany change in a meaningful way
In the literature, change processes are often described in models consisting of multiple phases. What these models have in common is that the first step is to make those affected realise that the status quo needs to change. This step is intended to boost acceptance of the specific changes. The changed conditions can be expected to ultimately become established as the new status quo. A decisive factor in the success of a project involving changes in a company is whether those affected by the change accept it.
Companies often underestimate how large the group of stakeholders that need to be involved in IT projects is. Even the best IT system will not be able to offer the company any added value if the employees entrusted with operating it are unable or unwilling to use it appropriately. The reasons for this can essentially be grouped into two categories: a lack of willingness to change and actual inability to deal with change. Whatever the reason the employees do not support the change, this poses considerable challenges for the affected company.
Engaging employees – Awakening the desire for change
First of all, it is crucial that employees recognise the need for change. Employees should therefore be brought into the process as early as possible to ensure that the project runs smoothly.
In this context, "early" means during the initial planning phase of the project. If employees feel that they can help shape the change, that their input is valued and that concerns are addressed, this will have a positive effect on the acceptance of the change. Against this background, it may be worthwhile, for example, to actively ask the workforce for specific suggestions to improve the existing system in order to establish some awareness of the shortcomings that can be observed in it. This makes it clear that a change, for example in the form of a new system, is needed.
Employees are only granted a limited right to have a say in the implementation of the project by applicable mandatory laws (for example if a project requires the involvement of the works council). However, informing employees and giving them the opportunity to provide feedback counteracts the feeling on their part that decisions are being made without taking the interests of the workforce into account. Taking meaningful input from the workforce into account makes employees active participants involved in the change process rather than passively affected parties.
In addition to simply providing information about the upcoming innovations, iterative implementation of the project can also be useful. If, for example, a new operating system is being rolled out to employees, it may be advisable to install it on users' PCs in multiple waves rather than on all of them at the same time. It is a good idea to first select a user group for which you can be confident that the changeover will not pose any particular problems, for example because the users have proven to be particularly tech-savvy in the past. This gives other users the opportunity to observe how the system works in practice, allowing employees to overcome their reservations about the new technology without losing access to the system they are already familiar with. Such an iterative rollout must be taken into account in the project contract, for example through a flexible ramp-up plan including support for the resulting extended migration period.
Making use of internal potential
Onboarding employees early is not only indirectly in the interest of the company in the context of increased acceptance but can also directly provide valuable insights for the project. The employees' wealth of experience and expertise are resources that should be utilized. Specialist departments usually know very well where there is a bottleneck in the current system that makes it difficult to work efficiently and often have concrete ideas about how workflows could be optimised. This input should be taken into account early when a new system is being specified and selected.
There is one other point that often leads to problems in the context of IT projects and can be clarified by consulting with the workforce at an early stage: the auditing of the assumed actual state, based on which the project is planned. All too often, parallel structures have established themselves over time alongside the existing system. These parallel structures can affect the assessment of the project and are often overlooked in planning. For example, if the existing system only allows for files up to a certain size to be saved directly in the system, employees may have uploaded larger files to a SharePoint server to work around this restriction. If this process is ignored when planning a new system that no longer has restrictions based on file size, the subsequent storage space requirements will be grossly underestimated. What specifics actually occur in the respective company is ultimately a question that can only be answered on a case-by-case basis and is often made easier by involving employees in the change management process.
Of course, consulting with employees early in the project takes time. However, companies are generally well advised to plan this time into the project. Spending time on this can help to avoid cumbersome adjustments to the new system later and teething problems in its productive use.
The importance of developing necessary skills
Even if the project has the full support of the workforce – without developing the necessary skills to work with the changed conditions, difficulties will be practically unavoidable once the project has been implemented. Generally, the company will be dependent on the project partner for this, meaning that the partner's obligations in this regard should be set out in the contract. How know-how is built up in a company is often a matter of corporate culture. As is so often the case, there are various ways of achieving this goal.
IT systems are usually supplied with a comprehensive manual that describes the system's functionality in detail. Manuals form a good basis for teaching, especially when those being taught are expected to learn not only how to operate the new system but also basic error diagnostics and troubleshooting, for example as part of internal first-level support. For end users, however, learning about the system only using such a manual would generally be too time-consuming and overwhelming. This is why there is now a preference for specialised training courses that address the respective requirements of the specific user group. Many providers of standard software often offer these directly themselves, but in the case of custom developments, special attention should be paid to ensuring that the provider offers suitable training concepts for the newly created software. This option should also be contractually stipulated. In addition to training courses conducted purely by the provider, "train-the-trainer" concepts can also be considered, in which selected employees of the company are empowered to conduct the internal training courses themselves through training from the provider.
An iterative introduction of a new system (as described above) can also cause the necessary expertise to organically "grow" into the company. Once the users in the pilot group have gained initial experience, they can function as internal vectors and pass on their knowledge directly to colleagues in subsequent groups.
It must also be ensured that the provider, and if necessary internal support teams, can deliver sufficient support during the introductory phase. As long as users are not yet familiar with the new system, a significantly increased need for support is to be expected. This may make it necessary, for example, to contractually agree on named contacts or a fixed number of support staff to be assigned exclusively to the project. Particularly in the case of critical hardware-related projects, it can also make sense in exceptional cases to agree on a support employee of the provider being physically available on site at the company for a certain period of time.
Meeting resistance
Needs-based change management is an extremely helpful tool – but not a panacea. In spite of all efforts, it is to be expected that some of the workforce will not want to support the changes, be it out of fear of change per se or of negative effects on their own position in the company. Experience shows that around one in ten employees can be expected to put up fundamental resistance to changes in the company that affect them. Even if all employees are fully informed and extensively trained, it should therefore be expected that particular employees will not or will only reluctantly support the change.
In principle, the company can expressly order within the scope of its right to issue instructions under the employment contract that the new system be used. Employees are typically obligated to comply with these instructions. If the resistance persists, it should be clarified whether the resistance is objectively justified (e.g. because there are technical problems that make it impossible to work efficiently with the new system) or whether it stems from a fundamentally obstructionist attitude. If objective reasons can be ruled out, further measures under employment law may be appropriate.
Needs-based change management can help minimise the expected resistance to a project and the associated inefficiencies and costs. Change management should therefore be considered from the outset and accordingly taken into account in the project contract in order to account for the change's considerable impact on the course and success of the project.
You can find out more about this in our blog series on IT projects (in German). You can subscribe to this blog series via the RSS feed to be informed about new posts.
