Large IT projects are 20 times more likely to fail than similar sized projects in other industries. Think on that for a moment. Why is this? The answer is not simple, and many different aspects can come into play causing a project to overrun. When this happens, there’s a cost both in terms of time and money. Sometimes these costs are unsustainable and lead to the failure of the company itself, an unthinkable outcome when projects are first conceived. Whilst the technical aspects of a project are sometimes the cause of failure, losing the users or not engaging them in the first place is a sure recipe for disaster. Getting the technical aspects right but forgetting about adoption still results in the new system being used improperly or not at all.

So, what can you do when you see that your users are not buying in to the system and your investment looks like it will be heading down the drain? Below we’ve listed five things you can do as soon as you see an issue arising.

Recognise that things aren’t going to plan

First of all, you have to be honest about where you are. Go right back to the beginning to when you defined your measures of success. What were they and are they being met? Some call this ‘benefits realisation’, but essentially it means, ‘is the project delivering what it set out to deliver?’ All projects should be tied into business objectives which are in turn translated into benefits that you want to derive from undertaking the project. If the measures of success you identified are not happening, then you need to ask why. You must recognise that there’s an issue, understand what is happening and take responsibility for sorting things out before you ‘reset’.

Revisit the business case

In order to obtain budget, all projects start with a business case. Why are we doing this? What will the business gain from this investment? The business case should very clearly outline the reasons for undertaking the project. It can be that later down the line, some of the harder to achieve benefits are side lined in favour of the ones that are easier to achieve. In any case, all benefits must be tracked and measured otherwise the adoption of the system could be going astray and it will be more difficult to spot. Sometimes ‘getting the project over the line’ is the easy part. Making it stick is a whole other matter. Once you’ve recognised an issue, go back over the business case and work out how far adrift you are from your course.

Get feedback from your users

It’s critical to involve the users early on if an issue has been identified. First of all, they are going to be feeling the pain. Whether it’s pressure to adopt a system that they don’t understand, or they’re not bought into, you have to work out what their view is to be able to put together an intervention plan. You should have some friendly users on your radar already from the early stages of the project. Go to these users first to get an idea of what is going on. Taking honest feedback in small groups is a great way to understand what is happening. You may have to do this with different stakeholder groups to get a full grasp on the situation.

Come up with and execute a plan

This sounds obvious but panic usually ensues if a documented approach isn’t formulated. You can definitely make things worse if you get things wrong in this situation. Your plan should include change, comms and training activities, as these are always needed in varying degrees. If you’ve identified that people are resistant to the change, then perhaps your focus should be more on ‘hearts and minds’. Alternatively, if everyone is onboard but they just don’t know how to use the system, then training should be your focus.

Your interventions should be created with the aim of redirecting the project back to the initial benefits. You’ll then be able to track progress against these to see if your actions are bringing you closer to them.

You may consider bringing in specialist resources such as those offered by Lawford Knight. When faced with a project that isn’t working, you need people who’ve been called into similar situations before. It’s likely that internal resources, or those who have been on the project for a while, will be jaded by being on a failing project. It’s often a good idea to inject fresh energy and ideas into the situation. This also serves as a good cut off point where you can draw a line under the failure and move on with positivity.

Once you have your resources in place, it’s a case of putting your plan into action. Be relentless here. Weed out resistors and spend time with them to understand their point of view. Sometimes resistors who hold a lot of clout can do an awful lot of damage. The company has committed to this project and any resistors will have their reasons for being that way. Everyone can be brought to a place where they can at the very least turn down the volume. You will often find that the loudest negative voices can become the biggest advocates of change too.

Training is nearly always appropriate in a failing project. We like to utilise a heavy communications aspect in our training interventions. Remember, it isn’t just how to ‘press buttons’, it’s why you are pressing them in the first place that’s important.

Review at regular intervals

When your plan is up and running, don’t assume that it’s all plain sailing. You must have regular reviews with your project team and key stakeholders to see how things are going. As well as looking at the outputs, you should also be carrying out checks to see how messages are landing, what the feedback is from training sessions and looking at the system itself to see what the usage statistics are. Don’t forget that you can tweak your approach if needed as you go along in response to feedback from your users. Perhaps the most important thing is to stick with it and see things through to the end. Saving a failing project is never going to be easy, but it’s extremely rewarding