The reason companies invest in software is to make work easier – right? Then why do so many users laugh at the idea?
After reviewing a large project I came up with seven reasons why the software wasn’t making work easier. Looking at the list I realised that it wasn’t just limited to this one project, but were common in many organisations and in many programs.
1. Processes and procedures are not written in conjunction with the software
The person writing the procedures does not incorporate the specific software in the flow. This then results in the software being an obstacle to the work flow.
In the project being investigated, the people writing the procedures had not used the software and were not aware of the features available. In fact what happened was that someone was focusing on procedures while another person was delegated with making the software do what was required. This split in responsibility is a false concept.
The larger the software package, the more it will need to be configured or customised for the client. Time configuring the system correctly is an investment in the success of the project.
As an extension of the first point, it was found that the software wasn’t actually configured to meet the requirements of the user, business or customer. It’s not that it couldn’t, but that no-one had invested the time to fully set up the system.
When rolling out a large project, there is a strong emphasis on being “on time” and “on budget”. When it comes to “on quality” the focus is often on ensuring the software works – that is, it isn’t buggy. The full test of “on quality” needs to expand to include being correctly configured.
The great aspect of configuration is that it can be done relatively easily. To clarify, it is easier than modifying the actual program code and releasing it. Configuration is meant to be the way to tweak software to really meet the user’s needs.
Which means that as the program is rolled out, and users start to use it, the program can be adapted to meet the true requirements. It means that after being in use for some time and requirements change that the software can adapt with it.
Provided someone is doing it.
3. Lack of training
There are now many ways to pass knowledge onto the user. They include:
- Correctly laid out software with meaningful labels etc
- Tips (pop-up information boxes in the software)
- Help (F1)
- Training videos
- Online training
- One to one (or small group) training
- Group training
With so many options available, shareit for pc it is amazing how poorly trained users are. Part of the reason is that there are a number of fundamental questions that need to be answered:
- Generically, how do you use the software?
- Specifically for a given task or role, how do you use the software?
- What does the user need to know for the day to day tasks?
- What does the user need to know for when things go wrong, or for the infrequent tasks?
- What do advanced users need to know?
It is relatively easy for the developers to create a document on what the program does, but they can’t necessarily write the manual on what the user is meant to do. This is getting back to the first point about the procedures linking in with the software.
So training needs to focus on processes and procedures as much as how to use the software.
There also needs to be multiple layers of training, starting with the day to day training up to the advanced training of key staff.
4. Functionality only, not efficiency
Most of the development on the project only focused on ensuring something could be achieved. There was little or no focus on either operational efficiency or database efficiency.
There were periodic reviews of really poorly performing aspects of the system, but there had been little consideration on how efficiently a task could be achieved.
Fundamental to good software is the concept of “it has to make life easier”. This starts with the specification, but needs to flow through the design stage, testing and release. The software needs to adapt to ensure that it remains easy to use.