In reviewing implementations of Enterprise Content Management (ECM) systems, one typical issue raised is how to balance the need to achieve User Acceptance of the system with IT goals in regards to reduced development and support. Too often, instead of a balance, the discussion can lead to an either or with Custom Development on one side and “out of the box” on the other. This post will share our methodology in regards to User Acceptance and balancing IT development and support goals.
User Acceptance is the top priority
Over and over, we will see ECM implementations that struggle with user acceptance of the system. What many ECM clients typically fails to realize in regards to some of the unique requirements of content management include:
- User’s don’t HAVE to use the system – most systems have manual or paper based ways to get stuff done. An overly complex or error-prone system will not infuse confidence in the users and will result in poor user acceptance.
- Knowledge Workers – often times the more educated users are, the LESS likely they are to accept any responsibility for using the system incorrectly, whether that is indexing incorrectly (and not being able to find the document later) or not specifying the correct approvers. How many times have we heard “Well, the system shouldn’t have let me do that!!”
- Bad news travels faster than good news – First impressions and complaints travel faster and farther with knowledge workers particularly at the beginning of system deployment when experience and training can be an issue. We have seen many implementations where the initial impression (first few days) might be rough and hard to shake in regards to user perception and user acceptance.
In focusing on User Acceptance, the relationship between IT and the user community should be similar to the relationship between and home architect and their client . The architect can start with a basic plan/model but will work with the customer to make business decisions about cabinets, counter tops and other changes. The buyer, concerned about cost and timeline, will, when asked, make business decisions based on the architect’s thoughts of previous home building experience, costs and timeline issues.
User Acceptance = Trust + Shared Responsibility
The key to User Acceptance is to get users involved at the beginning of the process regardless of an “out of the box” or custom approach. Too many times, IT can get caught in the developer trap of “Just tell us your requirements and we will build/configure the system based on our interpretation”. The approach of “throwing requirements over the IT wall and the system get’s thrown back over when done” does not build user trust and responsibility. The first step in getting User Acceptance of the system is for IT to build trust and shared responsibility for the success of the system. Some best practices from the TSG methodology include:
- Face to Face Meetings – We can’t stress this enough but trust is very hard to develop via emails and conference calls. Building trust is as much about relationships as about abilities. Trust is best developed face to face.
- Shared Responsibility – ECM works best when users share responsibility with IT for getting something successful done on time and on budget. Too often, projects can imply that it is “IT’s money” and the user group trying to get as much as they can. Shared Responsibility between key users and IT will result in a better working relationship rather than a conflict model with finger pointing in regards to “whose fault” is it that X doesn’t work.
- Interviews – IT needs to take the time to listen to the user’s needs and help drive requirements. IT can build trust with the users by focusing on listening (rather than telling) and having history of implementing similar technology (sharing experience) for other similar systems. Users want to make business decisions in regards to functionality rather than be told what they can and cannot do. IT needs to bring creativity into addressing issues regardless of technology approach and should look to bring in experience (consultants or other business groups) to prove to users that system functionality will be consistent with how others are using the technology.
- Prototype/Focus Group – Users need to be shown, not just told, what the system will do. To fully understand the requirements, users want to see what works and what doesn’t work. Key to reducing complaints at the beginning of a project is the user’s familiarity with the system through prototype as well as training sessions.
- Divide the users – Too often, we see implementations that tend to treat the users as one big group and attempt to satisfy with one interface. In actually, most ECM implementations have diverse groups of Authors, Consumers and Approvers. Each has different requirements that should result in different training, potentially different interfaces and different requirements to achieve user acceptance for their group.
- Staged Implementation – Similar to a “one size fits all” interface, many organizations tend to roll out with a “big bang” approach of vault (create, search) and approval functions. Like an early win in a primary election, Small wins with ECM early in the project result in confidence and positive momentum. TSG typically recommends easy store, search and retrieval steps before introducing complex workflow and approval to get that first small win and avoid user frustration.
- Joint Implementation Planning – User Acceptance of system functionality works best when users are involved in making budget and timeline decisions. User Acceptance is higher when users are involved and agree on cost/timeline decisions.
Summary
While everyone can agree that User Acceptance is a critical factor in the success of ECM tools, most implementations struggle with how to achieve it. This post has presented a methodology for beginning projects with a focus on getting key users involved in system decisions to help eventual User Acceptance. If you have any additional thoughts or experience that you can share, please post below.
Leave a Reply