"*" indicates required fields
info@involve.eu
024 – 323 77 39
It’s a universal truth: anyone who invests time and money on the implementation of new IT systems expects to see a handsome return. Often, the challenge in achieving this isn’t just a technical one but also – and most often – to do with the change, a factor that is regularly underestimated.
A large systems installation company wants to implement a new CRM system. The company comprises a number of regional businesses that operate independently, with each running its own P&L account. The business case says “If all our businesses record and share up-to-date customer information with each other, we’ll get a better overview of what the commercial opportunities might be. And then we can all monetise them better, for instance through more cross-selling and up-selling.”
When the system is up and running and the users have been trained, things don’t turn out that way, however. It transpires that the sales manager isn’t really pushing people to keep customer information updated and they have other priorities. The standard practice among the sales teams is that you need to be busy with customers and business, rather than “administrative nonsense”. Also, sharing information with other businesses tends to go against the grain: surely you’re not giving away leads? The result is that the new CRM system doesn’t get enough data fed into it, and there’s no way that the sales teams can convert that information into more business transactions.
Major IT investments are generally supported by a positive business case. The revenue side of these business cases sometimes shows operational economies in IT costs, for instance if you replace multiple different systems with a single one, or if you replace a system on local servers with a cloud-based solution. However, in many cases the profit isn’t inherent in the new system itself but in the way people are going to use it. Digital design & construction in a BIM system lets building companies enjoy greater efficiency with lower defect costs, at least if it’s used properly. A CRM system helps you take better advantage of commercial opportunities, at least if it’s used properly. A modern Field Service system for technical fieldwork provides faster solutions to disruptions and faster invoicing, at least if it’s used properly.
In these examples, realising the business case depends first and foremost on the behaviour of the staff. It’s a question of change. And while most implementation plans certainly take change into account, change often ends up being snowed under in practice. Or, put a better way, the change is often grasped in a limited way, as an issue that the project can resolve itself through training, e-learning modules or an adoption campaign.
We look at situations slightly differently, from our practical experience of organisational change management. It’s just not possible to “manage” change from inside a project. People are fundamentally against “being changed”, but they’re good at changing themselves. And their behaviour can be most readily determined in the context of the line organisation and their teams, for instance because their managers are working towards specific targets or because there are mutually shared standards.
The true story in our introduction makes it clear that a new system cannot magically change people’s behaviour. And that training sessions and adoption campaigns are just not enough when the problem lies elsewhere. In that example, what is really needed to successfully implement the new CRM system? In this case, we can identify four preconditions.
By addressing “adoption” as widely as possible, the organisation in question here is now working hard (and with increasing success) at achieving the promised returns from this major investment.
It should be clear that these sorts of preconditions are determined largely within the line organisation, and that you cannot therefore delegate the change side of an IT project to a project manager. The project provides the foundation stones for a new way of working, but the change itself happens in the line, in the teams. The art lies in ensuring that the right things happen at the right times there as well. A project manager has no direct control over the essential preconditions for change. And sometimes these are even ruled out of scope for the project: once the system is running, we’re done. But who makes this happen? The fact is that coordinating the change process often isn’t even clearly devolved within the line organisation.
A great solution that we often see is the appointment of a change manager alongside a project manager; someone to develop and support the change process inside the line organisation. Who helps important stakeholders in the line to develop and disseminate a clear vision for the change. Who takes the initiative to ensure that managers are ready and able to play their parts in the change process. Who helps the project leader to take substantive steps (such as detailing new working processes) in a way that also effectively supports the change. Who makes sure that communications and other interventions run smoothly. And who helps to embed the desired behaviours in the teams’ management.
One important aspect here is that the change manager should ideally not be reporting within the project, but rather to the most appropriate line manager. Why so? Because the change manager supports processes: he or she helps the organisation from a basis of knowledge and expertise but does not take over the responsibility for the change process. The project manager does have the responsibility for achieving results, i.e. for the technical side of the project. If the change manager is placed within the project itself, those roles start to overlap. The client may address the project about the technical side, but then the project has to address the client for the change aspects, while at the same time supporting the client. In practice, this is often quite laborious.
Let’s summarise: we can say that the change aspects of IT projects are often crucial for achieving the anticipated returns and that they’re often a blind spot. We would argue for an effective change process to be set up, in parallel with the technical process, so that the future users in the teams are onside at the right time to move in the desired direction and then go on to welcome the new system for the support it provides to those moves.