Most IT systems are sold into companies on the premise that they will deliver productivity increases and efficiency savings. The idea is that staff will save time through the automation of tasks. Managers will make better decisions with access to the accurate updated information whenever they need it. So why does this often not happen?
This is a complex question with many factors involved, some of which are specific to projects, some of which are more general. In this short article I will not be able to address all of them by a long way so please feel free to contact me on 0845 658 6767 to discuss them.
The most common issue I have come across is trying to fit your company’s processes into the software rather than fit the software to the company. Although the software will provide productivity saving when compared to the current method used for carrying out the task, the overheads of staff learning the new procedure more than counteracts the productivity gains from the new software. Over time this can be reduced through training or even eliminated so the productivity gains are accessed from the start. This is much easier to achieve if you have staff buy in before the software is rolled out.
This brings me to a similar and related issue- software being forced on a company from the top down. Now don’t get me wrong, software is often strategic rather than tactical, and major decisions like this have to be made by those with a complete view of the company, for example the CEO or CTO. In all cases of software roll-out I would encourage opinions to be canvassed. In the case of off-the-shelf software it can lead to in-sights that would otherwise not have been noticed, affecting which software or modules are purchased. It is amazing how often staff recommend that a module is not purchased. In the case of customized or bespoke software I’m of the opinion it is critical to the successful design of the software that users are interviewed. After all, who is in the best position to comment on software, surely it must be the people who use it? I have gone off on a tangent here about user feedback in customisation and bespoke development so I will cease by saying only that you are kidding yourself if you think you can build a business process application without speaking to the people that perform the tasks. I could write a whole article on this and will at another point so will stop now and come back to the point.
Buy-in- yes that is what I was talking about. Even though the decision is made at the top the users must be willing to take on the software and adapt their behaviour to it, although I hasten to add if your processes are streamlined already you should be changing as little as possible. Through interviews with the people at the coal face so to speak you can get them involved and generate the feeling that they are driving the decision-making processes and in a way they are and that is the point. It will give you the information to do 2 things which are my 2 major points in this article.
1. Customise the software to fit your business.
2. Develop training and manuals that fit your company processes.
This will bring the usefulness of the software in at an early stage and ensure that all the clutter of a huge software manual that makes little sense to most users is by-passed and the information that really matters and delivers those productivity increases is readily available to you and your staff. On the day of go-live you will have created a feel of excitement rather than resentment. The information gained during the interview stage will ensure that the processes are a fit to your company and focused on tasks that were wasting most of your staff’s time.
As I said at the start there are many more issues involved than I have mentioned here and I will try to write more articles to help you all out in the meantime. Good luck with your software and remember it is your software and it should work for you not the other way round.
Ralph Johnson, FelineSoft
