Organizations that have implemented any type of software or technology affecting business operations and/or the way employees perform their duties constantly face the challenge of how to successfully get the project completed without overstressing the organization. Change management is a set of steps design to modify the way an organization performs its core business processes and can be either technology-driven or non-technology driven designed to minimize existing work interruption.
Regardless of the driver for the organizational change, without addressing the impact on the end-users and the organization; the project can be very, very painful for everyone involved especially if the organization attempts these complex projects with the “learn as you go”, “this is just another IT project”, or “no big deal” attitude. Considering these technologies have such a far-reaching impact throughout, organizations typically rely on and/or get input and assistance from industry subject matter experts, who can help share best practices while working with the organization through all project phases. It is critical to ensure you use resources from ALL groups/teams/departments that would be affected by the new/updated technology(ies).
When not involving the correct users, it is almost guaranteed that rolling out the solution will end up with a solution (at least initially) with the following types of issues:
- that does not allow all users to access their records/documents as expected from their perspectives, or
- that takes much longer than anticipated, or
- where the functionality initially determined to be required is reduced.
These issues occur more frequently than most people would think and can be directly tied to resource frustration and/or lack of adequate planning and timing. When the appropriate resources are not included from the beginning it is much harder to gain organizational user acceptance of any new technology, especially document/records management. This is because document/records management technologies affect everyone in the organization one way or another, so broad acceptance of why organizations are implementing these technologies along with input from affected users on the design and functionality is crucial. Especially when trying to gain wide organizational acceptance.
The primary reason behind these issues lies in the fact that Enterprise Content Management (ECM) technologies are considered to be “enabling technologies” and not “replacement technologies.” These technologies enable the users to perform their duties while minimizing or eliminating manual activities that can be handled by various components of ECM utilized as tools and support mechanisms to perform business operations.
This is an important differentiation between the two approaches. Years ago, the flexibility and lack of modularity of the ECM solution components greatly limited the ability of the users to modify the solution to meet their needs, rather than the users needing to change their methods/processes to work with the limited functionality. With the “enabling technology” approach which almost all solution providers support these days, the solution can be easily customized to meet various departmental and organization requirements and provide a great deal of flexibility.
Some organizations have tried to simply ‘tell the users’ how the new process will function without spending the time to get input from all involved. The problem with this is that the first thing users do after integration/implementation is to simply come up with new ‘workarounds’ so that they can continue using their and/or work process change will be catastrophic. Too little organizational and/or work process change will have limited and potentially negative impacts on the business operation.
Why are these points widely seen throughout the industry? Well, consider the following examples of too little change and ask yourself if you have gone through any projects with these issues, or know of a project that had these issues:
- An organization decides to store documents electronically and decides to only implement document imaging after processing has completed, so the users still need to do everything manually except for retrieval “after the fact” which many, many times do not deliver the anticipated results.
- An organization decides to implement routing/workflow without performing a detailed process-oriented baseline and try to use a basic, or high level, task-oriented baseline resulting in a lack of understanding of exactly how the workflows through the organization. After initial implementation, the users are unable to either complete their work or have to create new “workarounds” to perform their work and prefer creating workaround rather than use the new ECM technology to their full extent.
- End-users are not included in the process from the BEGINNING of the process or the project and the system does not address the end-user(s) issues and problems and/or is not complete, so the system “falls” out of production very quickly.
- Users are not given assistance and guidance in preparing existing data/records that would need to be loaded into the system prior to going “live” allowing users to begin working with the next technologies rather than having “some records” in the new system going forward, but existing data/records are stored in the old environment forcing users to try to figure out what approach they need to follow to continue processing.
…and some examples of too much change:
- An organization decides to implement document imaging, forms processing, and routing/workflow as the initial phase of the project. When the system goes into production there is effectively no transition period between the old approach and the new approach. As soon as the system goes into operation, the organization “freezes” or users are unable to perform their work because they didn’t have adequate time to transition from manual task to new automated procedure, the system is not fully tested from the user perspective, etc.
- An organization decides to design the ECM system from a technical perspective only while other new systems are being updated and implemented. The new ECM solution contains all the “bells and whistles” that the technical implementation team thinks the users would really like, without truly understanding the impact of implementing too many system components/modules during a similar time period, etc.
These examples show either too little or too much change and are commonly seen throughout the industry for ECM projects that aren’t successful. These issues can easily put an organization into a constant state of “flux” and be detrimental to the overall business operation or provide such little change that the technology doesn’t meet the business objectives and/or goals. Along with these examples, other reasons that ECM projects fail include:
- The users only have a basic understanding of the intent of the new system and how it is intended to operate;
- The users have a set of basic, or “out of the box” functionality that doesn’t address their needs for legacy application integration, indexing requirements, query/search functionality, and/or workflow forms;
- The organization doesn’t fully identify the detailed functional requirements and specifications of how the system should operate;
- The system isn’t fully tested from the end-user perspective before going “live”;
- There is inadequate acceptance from the user community;
- Lack of detailed training, no revised end-user procedures and/or a clear understanding of how to use the new ECM features; and
- There is a lack of clear management support behind the new approach to doing business.
To summarize, change management considerations for ECM related technologies, communicate with the organization as much as possible while ensuring that you don’t lose control of your project. Have a set of enthusiastic users identified who can be representative of the organization and provide input and feedback throughout the project phases. These users, also referred to as “champion users” are typically senior users who other users get assistance from when working on complicated issues and/or provide leadership to teams of employees.
It is usually best if these people are either “working” supervisors” or “lead workers” as they typically understand both the manual process, technology systems, and the corporate culture. This will help ensure that the project has representation from the full journey level staff who need to perform the work while keeping in the boundaries established by the management team. Communicating as much as possible will ensure that users have an opportunity to express their thoughts, concerns, and expectations which will enable the management team to determine the best approach to completing the project with the anticipated level of acceptance and desired results. This is not to say that all user issues/concerns must be addressed through technology, but it is important to develop a “ground-swell” of acceptance/support for the overall implementation effort.
For more information on this topic or other document/records management related technologies, contact the Working Group 2 Standards Program Committee Chair, Robert Blatt at email@example.com or (805) 529–0600 or the Standards Program Director, Betsy Fanning at firstname.lastname@example.org or (571) 218–9817.