Seven Reasons Why Software Doesn’t Make Work Easier

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. So what were the obstacles to easier software?

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.

2. Configuration

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)
• Manuals
• Wikis
• Webinars
• Training videos
• Online training
• One to one (or small group) training
• Group training

With so many options available, 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.

I personally recommend that developers are forced to anonymously sit at the back of a training course while new users are shown how to use the software. The developers aren’t allowed to communicate with the users in any way, but just have to watch. The users will stumble around trying to achieve something, they will press the wrong buttons, go to the wrong screens, and often will eventually give up. Or they will swear at how cumbersome it is. The developers will either leave the room with great ideas as to how to make the system faster and easier to use, or will complain about how stupid users can be. You now know which developers you keep, and which developers you want to loose.

5. Project focused development

For the project being reviewed, development was primarily sponsored through new contracts won by the business.

New features were integrated into existing features where possible, or designed so that other contracts would gain benefit from it so there was an overall improvement. The biggest issue however was that existing contracts did not have the benefits of continual improvement.

The question was normally “how can we comply with this” rather than “how can we run our business better”.

6. Acceptance with second best

Users have been continually told to persevere with poor performance, as well as not to request changes. There are a number of reasons for this including:

• much of the software they use is totally beyond the company’s ability to fix (e.g. everyone’s favourite word processor and spread sheet).
• historically if something doesn’t work the solution is to reset the computer and come back later.
• consequently computers are notorious for problems that magically come and go and can’t be fixed
• even if a problem can be fixed, the person who has to fix it is too busy or the problem isn’t of high enough importance

This was a direct consequence of the attitude of the previously mentioned attitude of  “how can we comply with this contract” rather than “how can we run our business better”.  Users were continually told that changes weren’t possible because they weren’t a priority.

The end result is that users eventually stop complaining. It sounds like a win for the business (“the number of change requests has now dropped to nearly none”) but the reality is that the user, and consequently the business, is now putting up with second best.

7. Losing agility

What made the project so successful early on was its ability to quickly adapt the software to the users’ requirements. As time progressed the attitude became  “the business has to get used to waiting six months for a change and can’t just expect it to happen”.

The final result was a slow lumbering beast that was frustrating users and no longer meeting the business needs.

The first six points are not a once-off check list, but a continual necessity. Businesses need to adapt to survive, which means the software needs to adapt. The ability of a company to incorporate these ideas quickly is a core part of the business being able to adapt quickly.

Summary

So who is responsible for ensuring software makes life easier for the user? The answer is “everyone”. It’s a company culture issue. Unfortunately my experience has shown that it is too easy to promote a culture of frustration and compromise.

By the way, this research was for a company where we developed a call centre/tradesperson works managament system that we have helped develop over the past 10 years. That may explain why we left out point 8  which would have been “rushed development” and there would never be the point “poorly developed software”.

I also reflect on this and think that I need to get back to the LTrace Sterilisation Tracking software and review the procedures on the sites where it is installed. Then I know that at least one developer gained some benefit from this blog. And hopefully my clients will benefit from easier software.