How many times have we talked and written about making the User the center of attention when implementing a new technology? In several recent engagements, I’ve found that the implemented system has largely failed not because of the system, but because of user rejection. Some examples:
One. An enterprise-wide system was purchased and implemented without any input or approval from the user community and, believe it or not, did not include the IT department (in fact, IT was kept at a distance during implementation by the system integrator). It was a pure power play by senior management. Now, many years later, the system has cost the company many many millions, the users still do not like the system but being forced to use it, have adapted to it, and after many years, the system is still not fully implemented. But keeping our focus on the real problem, the users feel disenfranchised, have developed and use many workarounds, and basically feel frustrated with the whole “thing”.
When we showed selected department managers and users three potential new systems, through extended all day demonstrations, they were in awe of the functionality of the new systems and flabbergasted at how un-user friendly and how inefficient their current system was compared to the systems demonstrated.
Even with a very positive ROI (payback 1 year), the user’s enthusiasm for the new systems demonstrated, and a promise of future connections not previously possible, the old system remains. While management would like to replace it, the old system has become so entrenched that it most likely will never be replaced. While senior management continues to ponder what to do, the system is being fixed bit by bit, extended bit by bit into new areas, and generally speaking, becoming an irreplaceable part of the company.
Lesson learned, this system will continue to cost the company three times more than a new system each year it operates (in millions), in addition to the extra work users due each day due to the system’s shortcomings.
Two. An enterprise-wide system was purchased and implemented without any input or approval from the user community and forced upon IT (by senior management) as the solution they had to implement (similar to number one above but with a twist). For reasons unknown, as I came into the project late, senior management made a command decision to purchase this product and dropped it on IT, who was completely unprepared. IT, for unknown reasons, completely ignored the user community and built a system that was presented to the users. The users completely rejected the system and forced IT to return to the drawing boards and, in addition, required IT to work with users to develop user-based requirements. This was painful to all parties involved but IT took the greatest hit when several IT managers were put out to pasture when the full extent of the failure became known.
The outcome is still being written but the users are beginning to adopt the new system and it looks like it may be successful after all. In addition, this company has learned an important lesson; the users must be part of the process in order for a project to be successful.
Three. An enterprise-wide system was purchased and implemented without any input or approval from the user community or IT (am I sensing a pattern here?). The system was purchased by senior management without review of other systems/technologies and built/customized/implemented without any user involvement. It was a “leave on Friday, new system on Monday” situation and needless to say, it didn’t work out of the box and after several years still doesn’t work. Actually it works, sort of, but nobody is happy with it.
The users literally dread using the system and have created many workarounds to get their work done. Many of the users do all of their work “off-line” (C-drive, flash drives, and now cloud-drives, etc.) and only access the system when they have a final document to upload.
In interviewing users, they all had a variation on the same theme, the system was implemented without consulting them, they were not given adequate training (even now), there was no governance provided on how to name files, and they didn’t like the user interface (“It is not how I work!”). Most felt that this system made them less productive and they long for the return of the shared drive.
I find it interesting that companies, like the ones above, have no idea of how hard they make it for the users to do their work. And, users being normal people, want to do a good job, be proud of their work, and want to feel appreciated at the end of the day.
While none of the three example companies have gone out of business because of the system failures, all three have spent significantly more money than planned, have caused problems that will take years to correct, and most importantly, have placed their users in a comprised position. In example number one, above, many users now feel twice burned because they were shown a better system, told the new system is coming, and now so much time has passed that they know a new system will not happen.
The message is simple – don’t ignore your user base, actively include them as much as possible, ask them to be part of the process, and make them part of the overall feedback process.
Bud Porter-Roth
www.erms.com
#SharePoint #ElectronicRecordsManagement #enduserinvolvement #systemimplementation #documentmanagement #ScanningandCapture