To the content
What are you looking for?
visitor address
Jan de Bakkerstraat 13-15
3441 ED Woerden
The Netherlands
post address
Albertus Perkstraat 88
1217 NW Hilversum
The Netherlands
contact

info@involve.eu
024 – 323 77 39

The blind spot in IT projects: behaviour as a success factor

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.

It’s not just about technology, but also about behaviour

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.

Changing behaviour demands more than just a training session

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.

Four conditions

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.

  1. The sales managers in question and their teams believe that the new way of working will help them to attain their targets. To achieve this, it is essential for managers (including at the higher levels) to promote the vision behind the new system: why do we want to collaborate across the regional businesses from a commercial perspective? What will this require from sales staff, in concrete terms, so as to create and take advantage of more opportunities?
  2. The people who are involved play an active part in achieving the change, for instance by deciding how the new way of working can best be streamlined into their daily routines. How can we record our customer information in the most efficient way? How will we work with our colleagues in other regions? How do we convert customer information into actual business activity?
  3. The change coincides comfortably with the day-to-day reality of the people involved. An example might be the ability to enter customer information directly after contacting a customer, via the same tablet that the staff use to prepare quotes and launch new projects.
  4. The change is properly supported, facilitated and embedded. Good communication, training courses and input from adoption managers and key users all make this possible. But bringing operational management in line with the new way of working is another important facet. In this case, it means that sharing information with the other regions is no longer discouraged but actually rewarded (for instance through cross-selling targets).

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.

You can’t delegate a change

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 change manager as well as a project manager

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.

Give change the attention that it needs

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.

Want to know more?

Newsletter

If you would like to receive our dutch newsletter (3 - 4 x annually) in which we share our most up to date expertise and experience, please subscribe.