Before you read further, be warned that this blog may well lack both the creative flair and the worrying knowledge of warfare and weaponry that some of my colleagues possess and successfully weave into their blog posts. Nonetheless, it is intended to share the difficulty a client is experiencing with the adoption of new technology.
In the world of IT business projects, we often talk about the percentage of projects that fail to deliver. In this context, I want to convey a particular challenge that comes after the technical implementation.
In this scenario, the software delivered works to the specification required and let’s assume the specification is appropriate. The new software is also a great deal better than what it replaces in terms of what it does i.e. it delivers more, is more reliable, is less costly to support, is easier to integrate, and so on.
Yet in spite of all these advantages, the software is not successfully adopted by the users and therefore not successfully implemented as the value inherent in how the software is used cannot be easily released. This results in a huge level of frustration for the CEO who has invested both money and reputation in delivering strategic change.
Before you think that this is truly basic stuff and why should you bother reading any further, let me develop this slightly further. The implementation plan delivered adequate training along with post-launch support from an engaged supplier and an internal IT team. And most importantly, the software works.
The software I am describing is of the CRM type with configurations in support of operational business functions, for example membership administration.
The existing system has been in place for many years, is difficult to support, unattractive, with truly bizarre user journeys. However, it is familiar to the users who are in fact quite expert in using it. This team cannot see the point in changing to the new system as they are happy with the status quo. Even where the existing system is not all rosy and there are blatant performance issues with it – for example it loses records, crashes and there is no one left alive who can support it – all of this is soon forgotten or forgiven when faced with something new shiny and different.
It is remarkable how people can reminisce about something so patently worse than its replacement.
So as project managers, do we put enough effort into the accommodation of the stakeholders we are delivering the software to, and not just the sponsors? In the scenario I describe, it is clearly the case that the advantages apparent to the users are insufficient to convince them of the value of adoption. This is exacerbated if the middle management layer is also not bought in or not capably managed to support the delivery of the strategic objectives.
It can be even worse if your middle management chooses to side operationally with the team. Then you can end up with what I call objection frenzy, where the noise around the new system gets so loud with exaggerated problems, that it can fail unnecessarily.
A final word of caution, CRM projects such as the one I describe are often delivered in phases perhaps by operational department. If one of your departmental phases is like the one I describe and difficult to implement then the next one is going to be all the harder, especially if the objection frenzy is supported by colleagues from the previous implementation inputting with negative commentary.
If you are looking for support with stakeholder management during the planning, delivery and implementation of your IT project, please get in touch.