We write a lot about value-driven prioritization of software requirements. It’s easy (when defining requirements) to forget that we have to sell the product before anyone gets any value from it. With internal use software for large companies (like enterprise software, intranets, erp systems), “sell it” means “get high user adoption rates.” High user rates are key to getting ROI when process-improvement is one of the targets of the software.
Closing the sale means creating the perception of value. Creating actual value does not assure that someone will believe that there is value prior to actually using the software. Sustaining a perception of value over time (or across multiple customers) requires that there be actual value underneath the perceived value. A reasonable way to think about perceived value is to think about it as desireability.
Kathy Sierra posted a while ago on her blog, Creating Passionate Users, ten ways to make products more desirable.
Her list, which has more detail in her post:
- Pay attention to style.
- Pay attention to the emotional appeal.
- Show it in action…with real people.
- Don’t use pictures of generic shiny happy people that have become cliches.
- Make sure it’s clear to prospective users how this helps them kick ass.
- Appeal to as many senses as possible.
- Make it meaningful.
- Make it justifiable, so the user doesn’t have to feel guilty.
- Support a community of users.
- Never underestimate the power of fun.
Conclusion
When marketing the product, follow Kathy’s advice above
When prioritizing the requirements for early releases, make sure and invest some time on the surprise and delight features.
When defining functional requirements, designing, scoping and implementing the solution, think about the aestetics and usability of the application.
“With internal use software for large companies (like enterprise software, intranets, erp systems), “sell it†means “get high user adoption rates. ”
This implies that the average user in a large (or not so large) company gets to choose which software they will use, and have the option of not ‘adopting’ new software/systems. Where is this happening? Can you provide examples?
My experience, which I think is pretty typical, is that business management sponsors have budgets to acquire assets they need to operate their business, and software as part of systems is one of those assets. It is used as deployed to support and improve the effectiveness of business staff, and that means all staff. If a new order entry or other critical system is deployed, the order entry staff don’t really have a choice of using it or not.
So sure, go ahead and deliver the most enjoyable software you can, it certainly helps the user satisfaction ratings, but even the dis-satisfied staff still have to use the software.
Dave, thanks for reading and for commenting!
I’ve worked with several companies that match your experience, where usage of the ERP system is handed down by fiat.
Several examples come to mind (my intuition tells me “most”, where users did not universally follow this order. Feel free to PM me for more details if you like, as I feel it would be inappropriate to mention them by name in this forum. I will provide one example that illustrates two types of fallout in seperate systems from lack of user adoption, even in the presence of a mandate.
A company implemented multiple software systems as part of an ERP strategy. A CRM system was implemented for lead-management and ongoing client-account management. A seperate SFA system was implemented to handle complex engineering processing of orders that were initiated from within the CRM system. An ERP system was implemented for fullfilment of those orders, as well as billing and other execution-related activities. The total system cost was over $100 million (but less than $1 billion, as far as I know).
The “mandate” was that sales people would manage all account information via the CRM software, and initiate all sales through the CRM software. Those sales would be processed within the SFA software, which would push data into the ERP system, from which all provisioning would happen.
All three systems failed to live up to the user satisfaction challenge.
The ERP system is used because it is so integral to this company’s business that it is impossible to process an order either within manufacturing or accounts payable that is not within the system.
The SFA system is very hard to use. A small percentage of people bypass this system (which creates detailed line-item orders for the ERP system) and submit orders directly to the ERP system. The capability exists to do this for risk-mitigation. If the SFA system were to go down, the company would need this “back door” to allow people to initiate orders that could then be processed throughout the rest of the organization. The impact of this limited “revolt” by users is limited, but non-zero.
The CRM system was so bad that people “refused” to use it, and ultimately, the fiat was revoked, after tens of millions of dollars were wasted on it.
Users do revolt. It does happen. User satisfaction matters.
Thanks again, and please keep challenging the stuff you read here.
“…usage of the ERP system is handed down by fiat. ”
In general and in your example, who did the ‘handing down’? A Business Sponsor or IT?
Any IT department still trying to do that these days deserves any revolt that happens. IT does not own systems: we build them, and we service/enhance them over time based on what SLA is in place, but the business owns them. For example, if IT recommends system enhancements or replacement and the business says no or not now, that’s it, juts like when your car mechanic recommends a new air filter and you say no or not yet, it ain’t his car at risk, he’s done his professional best to help you.
Now, if the ‘handing down’ came from a business sponsor (would have been pretty high-up in your example), then users should rightly complain up their hierarchy that they can’t meet their objectives or goals because the systems don’t work. If senior management doesn’t listen, then that’s dysfunctional and certainly lower management or users will then use whatever means availble to work-around the mess and still get their incentive bonuses.
In either case, it would seem that the business spent a lot of money but got bad systems. Did IT mess it up? Did the sponsor say ‘implement it, finsihed or not’? I have seen that one before. There are all sorts of reasons for bad systems, and certainly those of us charged with delivering them and servicing them should improve our efforts to prevent such disasters when we can.
Great comments Dave!
In the specific example I cited, I believe (but did not hear directly) that a Sr. VP “task force” was created and one of the members had responsibility for this system – and drove the associated mandate.
I personally have seen this type of fiat handed down by CEO at one fortune 100 company, from VP of sales, and from CIO acting as proxy for other business departments.
I agree that when IT lays down the law the tail is wagging the dog. IT often ends up enforcing the law, however.
And yes, a lot of money is wasted on these large systems. The agile proponents argue that the teams were incapable of dealing with change, did not involve the ‘customers’ along the way, and ended up delivering the wrong stuff at the end.
Agile or not, the primary source of problems is failure to define what should be done. Poor quality, incomplete delivery, and bad design have all caused problems on projects that I’ve seen or been involved with – but those tend to be deck chairs on the Titanic.
When the vision is spot on, the execution problems are easily addressed (in comparison). My 2 cents.
Scott