Over the years, I’ve been a software seller, implementer and implementee. While software companies all use the phrase “driving adoption,” sometimes the only ones driving anything are the software companies — driving sales. Typically management at the customer buys the software with the goal of getting the software’s promised ROI. Hopes are high that the software will solve a big business problem, but sometimes the implementation fails to achieve good adoption. User adoption cannot be ignored or the software’s tenure at a customer will be short-lived. This creates the user phenomenon of “lie low and wait this one blows over.” People do not like change, especially in the way that they do their jobs. Software requires both change and change management, and change is often resisted. Even if the change will mean better, cheaper, faster, and easier, it is human nature to try to resist and maintain the status quo.
First is business fit. How radical a departure from current business practices will this software require? What’s the company culture in relation to using software? How sophisticated and comfortable are users about software? How well have other software implementations gone? How good is the company at software adoption?
Second is usability. How easy is the software to use? The account executives, programmers and software geeks in the company selling the software product may think it’s very easy to use. They’ve been using it and working on it — or at least glancing at it from afar — and as a result, lose their user perspective. Many of them have never had a user perspective. When I worked on a team in manufacturing where I had to implement a complex MRP (material requirements planning) system, we had to convince Joe or Jane User that this software would make their jobs easier by actually demonstrating to them how it would — on their turf and terms. I had a great boss who had a simple usability litmus test He would ask, “Is this software usable by human beings?” Too often the answer was no.
If the software is deemed to be usable by human beings or could be tweaked to pass that test, look closely at the impact on business processes. “Automate” does not equate to “optimize.” Make sure that the system is aligned with business processes and that users are trained and prepared for an implementation. If the processes needed to be modified or improved to ensure a smooth implementation, we made sure that the key users took the lead to get the processes ready and in place before any software was turned on. We ran war rooms and conference room pilots. We did user testing (as distinct from the testing software developers do). We did as much as we could to prevent major disruptions during implementation. Most importantly, we communicated, trained and covered political bases of support to try to ensure a “no big surprises” implementation.
On the flip side, I have seen too often where software is plopped in right on top of existing programs and often convoluted business practices. And the business is brought to its knees by complexity of the software and the added work. Adoption goes nowhere.
As one colleague said to me when I was in the software business, “I have a recurring nightmare that I created the most beautiful piece of software, but no one could or would implement it.
Source:-http://www.spendmatters.com/index.cfm/2011/1/24/Software-Implementation-Automate-Doesnt-Equal-Optimize
