...The problem wasn't one of features and functionality -- the software did everything they wanted it to do. The problem was one of design -- learning how to use this system was quite difficult, and often ran contrary to how people currently worked.
In our presentation on user-centered design, we utilize the following diagram as an overview of a process:
Such as it is, the cycle "begins" with "Gathering Assumptions and Requirements." This is the step where you look internally to understand the business drivers of whatever project you're involved with. The thing is, that's pretty much where this company began and ended. They understood the business drivers, got a sense of the features and functionalities they wanted, and then would go out and buy software to solve it.
The problem is, as they learned, that the issues isn't with features and functionality, but with the software fitting into current work processes. What this means is that, when buying enterprise software, companies need to do more work, move forward along the cycle, to "Understand Goals and Tasks." This is where you observe user behavior and needs in order to understand the processes people engage in to accomplish their tasks.
What surprised the client was that they thought this was the responsibility of the vendor. Part of the reason they bought this software was for the "wisdom" the software was meant to have embedded within. That there was a "wisdom" in how the software presents work processes, and that the company ought to learn from that wisdom and adjust their work accordingly, taking advantage of this "wisdom."
This totally took me aback. How on earth could this enterprise software tell you how to do your work? It's your work! And, this is what the client learned, in a painful way. That software can't come in and change how people work--such software will simply be ignored, be rejected. Companies have to step up and take more responsibility for the integration of software within their organizations, because no one else knows how those companies work. This is something that content management system vendors have had to deal with, and has lead to a solution of separating the content/data and the presentation.
Remember, the problem with the software wasn't features or functionality, it was how those tools were presented. Unfortunately, the design of the system was hardcoded (which is shocking, since it is served through a web browser).
What will be clear, moving forward, is that enterprise software companies will have to follow the lead of CMS and provide a greater degree of flexibility in how people can interface with their tools.
