You can’t get the promised return on investment (ROI) if people don’t use the features that supposedly generate that return. That’s why spending time after deployment understanding usage, and making changes to get the benefits, matters so much.
It’s one of the two ways, in fact, to raise the actual return on investment obtained (AROIO), one of the key metrics of success surrounding IT. (AROIO, remember, is like the “profit” obtained in the enterprise.)
When requirements are laid down for a new IT system, they’re often the results of extensive gathering of opinion. This person likes toolbars, and wants one. That person hates toolbars, so wants clear navigation and services buttons on the screen. This other person likes very flexible user interfaces, and wants all sorts of functions buried in right-button contextual menus. A fourth can’t stand anything to be hidden, so menus must be long and clear.
Some do better with graphical representations, others with form filling approaches, still others with rows and columns of fields.
I use user interface elements here because we can all “see” this in our mind’s eye. There are innumerable other decisions that get buried in logic, in data design, etc., that work the same way.
Some of these differences, incidentally, deal with how people will habitually use any system. Are they regular or casual users? Are they desktop or mobile users? Other differences have to do with age and expectations: younger staff — Tapscott’s “Digital Natives” — expect systems to be different from those who’ve been working with mainframe-based systems.
What it means to you is that if you want to drive AROIO higher, you need to get out in the field and observe.
One such set of observations, in a multi-national corporation, found that a new system had been widely accepted and was well used in Asia, less so in North America, and poorly in Europe. Why this mattered was that Europe less than 5% of the functionality (the new functionality was the supposed point of return on investment) was being used by the majority of people. You can’t achieve an actual ROI that way!
Each audience, in turn, was of a different age, with different expectations as to what a “good” system looked like. The requirements had dutifully gathered all of these and all options were included. What wasn’t done was to teach people how to tailor the system to suit their needs — and the default settings favoured the younger, Asian community (because it looked “newest”, but also created the most “busy” look).
You may find, as this company did, that training and field support could unlock more of the promised ROI (raising AROIO cheaply). But it’s not always so simple.
Several years ago a Vice-President commissioned a system to provide collaborative computer support for a function that historically was paper-and-pencil and meeting based.
The resulting system was state of the art. But almost no one used it.
It was ahead of its time: it begged for a mobile implementation, but at the time it was built pads and tablets weren’t a part of the technological ecology. What little did exist in mobile required pens or pointers (as opposed to fingers as today).
For people on their feet, moving about, the fewer moving parts, the better.
No one — for nearly two years — noticed that the new system was effectively unused. Zero ROI. (Less than zero, given the costs of building it, running it, and the workaround costs to avoid using it.)
Fifteen minutes in the workplace would have made this obvious. Do you begin to understand why the ROI you approve doesn’t show up on the bottom line?
Field work is essential to drive AROIO — and with it, value.