written by owen on 2017-Mar-04.

I have worked with many a software and one of the main implementation problems is getting users to accept change, upgrades, or enhancements to/from platforms that they are accustomed to. Project managers tend to put the blame on the client/users but often fail to see the the quagmire in which they themselves operate. Below I will compile a list of reasons why user acceptance is so difficult and why the problem is not always about a resistance to change;

Focusing on the wrong things

Your software is mostly used by people on desktop computers yet you go around promoting the virtues of the mobile version because clearly "mobile is the future". The system requires heavy data entry but you focus on how bueatiful the charts and the reports look. These are just a few instances of the team ignoring the important use cases in favour of highlighting buzzwords and catch phrases.

Blaming the Client

The users say the software is too complicated so you suggest more training. Users keep making data entry errors you suggest they get a university degree in civil engineering. The interface is cumbersome to use - you say "look, look, its easy see!? All you have to do is click here then click there!". This is maybe the biggest problem with projects that start off rocky. The complains of the client users are often ignored and their complaints are cast back on them because "they are the problem". Look, Look, its easy! X has done it without problems!

Threats, Evangelism, Cheer leading

In some cases there is nothing you can do to get some people to accept change, especially when they cannot see the benefits of the new system you are trying to implement. If you cannot sell the software to a client there is a chance that your software may be a bad fit for the situation. If you cannot prove to the user easily that your thing is better than what they had then there is no use threatening them - it might work for some but it wont work for all. You are trying to sell a fish to a fisher man. You might be stuck in a bind with a something that sucks but being positive about a bad situation is not going to help the people who actually have to do the work every day. Positive vibes can only bring you so far. Paid shills, evangalists can only get you so far.

Blaming the Hardware

The interface takes up half the client screen - BUY BIGGER MONITORS! The software takes long to load, runs slowly - UPGRADE THE SERVERS! This report is taking too long to run - INSTALL MORE RAM! The browser locks up for a couple seconds once a button is clicked - UPGRADE YOUR BROWSERS! My browser is slow - UPGRADE YOUR OS! My operating system is slow - UPGRADE EVERYTHING! This is another form of casting blame elsewhere when large problems start to creep up during implementation. If the software is slow the team must work to remedy the software in its current state instead of trying to alter the hardware environment to fit the needs of poorly written software. Slow software is slow for a reason. Hire an expert to look at it. Upgrade you mouse, mouse pad, trackpad, monitor, RAM, OS, drivers, eyes, ears, reflexes! Clearly something needs to upgrade!

Buying bad software

In this day and age every project manager must be able to admit that the software that they are trying to implement falls short in some aspects. The software may be good on a few points but falls short on random edge cases, usability, interface design, speed or reporting. Whether off the shelf or custom software bad software is ship built to crash upon the shore. There is not much you can do after the fact but make the best of a bad situation, compromise, patch, hack in features and making promises.

Making promises that you cannot keep

Software is not a magical thing that is limitless. It comes with limits, no matter how advanced the platform is there will be a way to break it so there is no use promising users that you can make any change or handle ANY ENHANCEMENT they request. At the end of the day you will either run out of time or money or both. If the software is bad at its core you will basically have to accept it for what it is and work around issues in a transparent manner. You want what? Of course it can do that! Just wait 8 months until we get a patch to 50k lines of code!

Ad hoc troubling shooting, hacking, patching and fire fighting

Many problems will arise during implementation of software but one needs to ensure that issues are not glossed over and patched so as to rush the implementation. These issues may popup again at a point in the future when it may be detrimental to the entire system. Care must be taken to ensure that any issues are implemented in a seamless way. Hacky stuff and wild customization must be avoided at all costs (see making promises you cannot keep). Especially when it comes to off the shelf software where too many customizations will lead to expensive upgrade and maintenance costs in the future. Reckless fire fighting is the easiest way of forking your version of the software into a white elephant (useless or troublesome system, especially one that is expensive to maintain or difficult to dispose of) leading to vendor lock in. Ad hoc fixes are often forgotten then popup at later times to kill innocence bystanders.

Conclusion

At the end of the day no software is perfect and you will always find users/clients that have issues that need to be addressed. These issues must be carefully looked at or prioritized if you intend to have smooth and quick implementation. Even after implementation steps must be taken to ensure that the people you have on-boarded stay on board and the software lives a long productive life, free of pain and suffering. Resist the urge to blame the client/users for shortfalls in the software and make an effort to understand and alleviate the concerns. A couple years ago I wrote about why software gets replaced but I did not mention that some of these things can be detected from early in the implementation phase and avoided.

permanent link. Find similar posts in Articles.