Time is Money

I’ve recently had many opportunities to think about software adoption and the many factors that affect it, from both the product management side and the end-user side.
In all cases, the most important thing to keep in mind when considering adoption of a new piece of software is that time is money.
Think of every user as having a bank account full of time. Your software can either increase or decrease the balance of their account and this directly affects whether or not the software will be used.
An application can have every function provided by the current process or system and still not be adopted by the user community. People don’t want to spend time to learn a new process. Minimizing the change to existing processes can help speed up adoption by the community.
This is where use case analysis can be crucial. Even when replacing a manual process with an automated tool, you should carefully examine what tasks are being performed and how they are done today. If you have too many disparate steps between old and new, you are putting yourself at risk for low adoption rates.
Every step that deviates from the standard process takes ‘money’ out of the bank. Change too many steps, and you’re bound to go bankrupt.
Even worse is when a new tool performs the same function in more time than the existing tool. Nothing angers an end-user like having to learn a new process on a new tool and having it take twice as long as it did on their old mainframe application.
Of course, there wouldn’t be much point in adopting new software if it didn’t provide some benefit to the company as a whole. You have to keep in mind, however, that if it doesn’t benefit the individual end-users in some way, you run to risk of low adoption (assuming the end-users have a choice of tools).
The key is to put some money back in the bank whenever you can.
The tool has to have features that save the user’s time or allow them to perform functions that they couldn’t do at all in the past. New features are not nearly as important as speeding up existing tasks. People enjoy the ‘Gee Whiz!’ factor for the new features, but the end-users still have a job to do and they want to do it as quickly as possible.
Every feature should be analyzed against the overall business needs but also against the job of the end-user to ensure it will be needed and used. Performance requirements can then be written to ensure the new application performs at least as well as the existing process or software.
In the end, implementation of a new tool is a balancing act.
Here’s a pseudo-scientific formula to help illustrate the points above: Adoption Rate = [ (Time Savings) + 1/10 * (New Features) ] - [ (New Process) + 10 * (Time Costs) ]You may not get exactly 1/10th the benefit out of a new feature vs. a time savings, but the factor gives a good approximation.
The more process changes you introduce, the more time savings and new features you need to come up with to compensate for the loss in time. The more time savings your tool will provide, the greater the changes you can make and still keep the users happy.
It all boils down to simple budgeting – don’t spend more of your user’s time than you save them or you will be in the red before you know it.