It’s the Users... An Old Story Repeated Many Times

Current Rating:
(0 ratings)

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

Report

Rate Post

You need to log in to rate blog posts. Click here to login.

Add a Comment

You need to log in to post messages. Click here to login.

Comments

Brooke Martin

failed implementation

I agree with you on this blog. Though you make mention of IT being left out... I don’t see the connection between user adoption and IT. I see IT as important part of a project for technical DB and Server type functions and requirements... but user adoption is different.

I have seen successful projects with very little IT help succeed and projects with a lot of IT involvement succeed...

A good solution or integrator knows that all users are required in the sign-off of a successful project and will bring those players in at the appropriate time.

On flip side, too much IT and User involvement can be a problem.
Report
Was this helpful? Yes No
Reply
Bud Porter-Roth

IT and Projects

Brooke, because each project is unique and can be very large or very small it is hard to generalize - but, I find, generally speaking, that Users are ill-equipped to do functional requirements definition and don't apply the rigor that IT would. Without good requirements, the system is doomed to failure. Typically when IT is involved in the front-end of the project, helping to define/drive the requirements, the requirements are better defined and IT is much more knowlegable about each business application, such as AP, and can provide much better support because of their application knowledge. This in turn builds user confidence during the critical initial adoption of the system. One company that I have worked with actually embeds an IT support person in the business unit so that the IT person becomes as knowledgable about the business application as a user.

Back to your statement that IT only defines the DB and the technical requirements, I think that IT should be doing more in the project definition phase.

Report
Was this helpful? Yes No
Reply

Daniel Kozlowski

Great adoption is from great software not great focus groups

Though there is always a need to include users, simply including them does not mean the IT team or Software Vendor andSystems Integrator/Consultant wont deliver a pile of doggie dodo.

Great usability drives great adoption and usability comes from the software vendor and the team delivering it.
Report
Was this helpful? Yes No
Reply

Dorothea Jama-Auerswald

User involvement- Yes, but it needs careful management.

Interesting to read about your experience. After so many years and failed projects it is suprising to see that it is still happening.
I am currently working on a re-implementation project where our problem was the exact opposite of the one you are describing. The users were involved but because they did understand the purpose of an ECM or/and preferred not to use it, they simply continued to use shared drives as their main storage for documents and records.

Almost all their 'requirements' were implemented in an attempt to placate them but without really analysing what they were trying to do and determining if it would have been possible with the existing functions. Another element in the failure was that 'requirements' from senior management were given top priority even when the vast majority of users could not find any application for the related functions.
In the end, we ended up with an unmanageable and extremely difficult to maintain 'monster' that is despised by the majority of users.
Today, the most common reaction from users to our system is "no one told us how to use it".

On the re-implementation project we are trying to put these lessons into practice which has meant putting a lot of effort into really understanding what
it is the users need to do rather than taking their 'needs' at face value.
Often, by digging deeper we found that the 'need' or 'problem' was only proximate, and that there was a broader problem they were trying to solve which
they were expressing through this 'need'. I suppose the other important lesson we are re-learning is that it critical to build a system which is easy and
intuitive for the majority of users including occasional users versus having a system which is overloaded with complexity and which tries to satisfy every user whim.
Report
Was this helpful? Yes No
Reply
Bud Porter-Roth

Requirements definition is a TEAM Effort

Dorothea, Thanks for the comments and observations. I really appreciate your insight that sometimes "requirements" are just symptoms of the problem but don't describe the real problem (like a headache being a symptom of cancer). And it is too often that systems are built based on symptoms...

It is my experience that (generally speaking!) IT (and consultants) is much better equipped to support the user when doing requirements definition and to separate the "symptoms" from the actual "problem". It is also my experience that the best systems are the result of a good team effort between the user and IT.
Report
Was this helpful? Yes No
Reply

This post and comment(s) reflect the personal perspectives of community members, and not necessarily those of their employers or of AIIM International