Recently a massive enterprise IT project was scrapped by Avon, according to a report on Forbes.com. The core issue of the failed software project seems to have been the difficulty users had working with the new system. In fact the system was so troubling to use that key sales people simply left the company rather than having to deal with the new system. The new software system cost somewhere between $100 million and $125 million to implement. Yet despite the large amount of money spent the usability of the system appears to have left its user base unimpressed and perhaps more to the point, frustrated in the extreme.
Based on news reports and similar IT project failures in the past, the problems with the Avon project point to a very common problem: failure of management and consultants to thoroughly involve the user community prior to a large system roll out. So how can large companies help insure that their user base will actually use their expensive new software systems once implemented? The following are a few helpful pointers which may save your company hundreds of thousands of dollars:
- Gather User Stories prior to redesign. Interview both “power users” as well as typical users, and determine their daily workflow, as well as how that workflow is helped or hindered by the current software. Does the current system require a multitude of clicks and selections in order to get to the “meat” of what the user is doing on a regular basis? Is the user using a broad swath of functionality or do they use the same 5% of functionality over and over? Does the system force them to re-login every five minutes in spite of the fact that the system is used in a secure location? Address all conceivable issues in the new design and be sure to vet the proposed solutions with the user base.
- Address inconsistencies in user stories and requirements. Not all user stories should be considered automatically flawless simply because they come from users. Users are experienced but not always using the system as intended and may be forcing themselves to work much harder than required. Is the user taking five steps when only one step is required if they new the functionality to use? Is the user using the system in the way the designers intended? Are there misunderstandings that are hindering the user’s productivity?
- Create mockups to test use cases and garner feedback. The use of mockups is sadly ignored in almost every large IT project. Mockups are “demo versions” of sub-systems and dashboards which are created in order to introduce new paradigms and gather feedback from users. If a user has never experienced the layout or design of a new system, the worst day of a user’s life is the day that the new system is put into place. Getting users used to the look and feel of the new system helps insure productivity the day that the system is rolled out, instead of panic-mode.
- Insure your shiny new system works flawlessly before foisting it on users. Your user base may abandon your expensive new software project quickly if bugs crop up in typical use cases. Your users must experience the “Ah-Hah!” happy moments many times over before they will tolerate bugs. Not only should use testing should be extensive as per usual, but your code must be written so that boundary conditions, out-of-range inputs and outputs and general assumptions are handled smoothly. Assertions should always be baked into the code to verify the assumptions and should be left on in production systems in order to catch problems. Assertions can usually be attached by a debugger in order to track down the problem.
In summary, you must involve your user base in the development of large IT systems in order to both architect a smooth workflow and achieve very early user buy-in to the new system.