The 5 Most Common Software Implementation Failures
Before buying software, we often spend a great deal of time researching options and comparing features, to find the best solution for the business. But once we have made the decision to buy, we’ve really only taken the first step of the journey. The software implementation process is what holds the key to the full value of your investment.
But what sort of things can go wrong at the implementation stage? Let’s take a look at some of the most common implementation failures and what we can learn from them.
Typical software implementation failures
In a successful software implementation, several factors need to be considered and planned for in advance. Some of the most common – and disastrous – implementation failures can in fact be prevented with the help of relatively simple preparations.
These are five of the most common reasons for implementation failure that we see:
1. The implementation is slow and painful
Once the buying decision is made, the organisation is often keen to get started with using it as quickly as possible – especially if this has been hailed as the long-awaited remedy for existing bottlenecks and technical challenges. But sometimes the configuration, integrations, user testing and troubleshooting seem to turn into a never-ending story.
Solution: It is crucial to have a skilled, focused taskforce involved in implementing the software rather than just assigning it to whoever happens to be available at the time. It is also important to have crystal clear definitions of functionality and integrations from the start, to avoid the implementation becoming a moving target. You may want to consider taking a phased approach, for example rolling out one set of integrations at a time.
2. People aren’t using the software
Perhaps the most frustrating of all implementation failures is discovering that the users who were supposed to be getting the most value from the software are in fact not taking advantage of it. This is typically caused by a lack of buy-in from these people to begin with, or a misunderstanding of their requirements.
As a contrast, the most efficient software solutions are the ones that are designed to support your business processes rather than forcing people to change the way they naturally work. However, without knowing those processes inside out, you won’t be able to create a software solution that people love to use.
Solution: By doing careful research and interviewing users prior to investing in something, you can identify exactly what you need the solution to do. There may not be an off-the-shelf product available, but bespoke software can often be many times more cost-effective while also providing unparalleled flexibility.
3. Training isn’t good enough
User training and onboarding is something that should always be included in the software acquisition cost. No matter how intuitive a new system may be, users will need a level of handholding to ensure they adopt the functionality correctly. Assuming that users will seek answers in a database or simply ‘learn by doing’ often leads to stress, frustration and reluctance to use the system.
Training can easily become a very expensive afterthought, as users start making mistakes or reverting back to their old systems. But rather than wait for users to break the rules, you can give them the best possible chances of success through high quality training.
Solution: Your business should start preparing training materials the moment you sign the software purchase order. You may require separate training tracks for different user levels, as well as a range of written and visual user guides, aligned with the various job roles and functions. Whether or not you carry out live, online or in-person training sessions, it’s important to give users the chance to ask questions and become confident in their knowledge about the system.
Depending on the complexity of the software, you may also want to consider providing training on an ongoing basis in the form of refresher training, different levels of software certification, or regular ‘tips and tricks’ sessions.
4. Success can’t be measured
When you deploy new software, you want to measure things like return on investment and increased productivity. These are critical factors in ensuring the business spends its IT budget wisely – but you can’t measure them unless you have defined goals for the implementation. In order to establish how well you are doing, you need to know what you were aiming to achieve in the first place.
Solution: You often lay the foundation for your success factors as soon as you start looking for a software solution. You obviously justify your investment in a new solution by discussing how it will improve the business; perhaps it is expected to increase sales, make processor faster, or reduce costs. These are all goals which should be quantified into tangible numbers and percentages. Work with the software vendor, consultants and implementation teams to draw up measurable goals based on research, use case examples, and testing.
It may be tempting to be ambitious when setting goals and expectations, but remember that it’s better to set the bar of expectation slightly lower to allow for things like project delays and a temporary drop in productivity while users are learning to use the new system.
5. Dependencies and requirements are unclear
When it comes to software implementations, nobody likes surprises. You don’t want to get halfway into the configuration process only to discover that one of your teams is requesting an integration to some random application you have never heard of, or that the software has a limit of ten data fields when you need fifty. Unexpected challenges can often delay or derail an implementation project – especially if there is no immediate solution available to the problem.
Solution: A software implementation always needs to be deeply rooted in the user base. We shouldn’t allow it to become an insular project of one person or team; but involve representatives of every user function to draw up a detailed view of what the processes and interdependencies look like.
In addition to any process functionality, it’s also important to ensure there is a detailed view of what reporting, dashboards and analytical requirements look like. It should be clearly defined what the leadership needs, in terms of data output and visuals, to support their decision making.
If disaster has already struck
If you’re in the middle of an implementation project that has failed or stalled, it’s of course no use complaining about the preparations that should have been done. However, it may be well worth calling on the help of a professional team to help you roll things back and re-establish the use case in your organisation. An external perspective can often give you an opportunity to evaluate the situation without rationalising decisions that may harm the business.