Not including business representatives in the make-up of the project team. The team members remain aloof from the business with little understanding of business processes, business records and business drivers.
Active business representation in the project team is a must. This may be by way of a specific business specialist steering committee who are educated on the project goals and scope, and EDRMS capability from the project outset. Through facilitated meetings informed members are then able to provide input on adoption enhancements within the constraints of the project. Additionally they can be harnessed as a change management conduit to provide project briefings to their business areas. Or less formal input may suit some organisations better, with review and comment requested from the business at specific stages of the project. If this method is chosen then care has to be taken to ensure that the business clearly understands the ramifications of what they have been asked to comment on. Otherwise review and commentary is conducted in an intellectual vacuum with predictable poor results.
Excluding business representation altogether in the project team risks inward looking records management focused on compliance rather than the outward looking risk reduction and productivity enhancement focus that increases adoption.
Waiting for senior managers to provide leadership of the project. Idle project teams expect that, because they have been given a budget and a ‘mandate’ from senior management to ensure the organisation complies with relevant regulations, senior managers will provide leadership from the beginning and all through the life of the project.
Senior managers sponsoring an EDRMS project rarely understand what has to be developed and executed to comply with regulations regarding recordkeeping. Nor does their experience provide comprehension of the changes in business processes and establishment of standards necessary to comply.
Project teams have to continually educate senior managers, not only on what they have actually tasked the project team to do, but also on the benefits in productivity and risk reduction. This is not to suggest that senior managers are incompetent. It is stating the facts that most senior managers have a limited affiliation with recordkeeping and the interactions they have had are more likely to be about archiving practices and about compliance. Senior managers will only truly become leaders and drivers of the project when there is sufficient structure and strategy in place for them to understand and articulate the business benefits of an EDRMS. The project team must take on the responsibility to passionately lead throughout the project.
A lack focus and inability to clearly articulate the purpose of each element of the project. These project teams inevitability lose support at some time from some stakeholders for elements of the project. If the stakeholders are influential then the whole of the project may be compromised.
Project teams must resist a ‘cookie-cutter’ approach to the implementation; assuming that elements of the implementation that worked on other EDRMS and non-EDRMS projects will work for their particular project. Each business environment, starting point and desired end point is different from business to business. Each element of an implementation approach must be able to be justified by way of explanation of its purpose and how it meets the needs of the business.
Failure to plan adequately and therefore, as the old adage reminds us, planning to fail.
Not only does each element of an EDRMS implementation need a purpose it must be planned in detail. It is insufficient to plan the software roll-out and not plan the training rollout such that people trained in the use of the EDRMS can use it productively when they return from the training to their workplace. It is unacceptable to plan the training schedule and not to plan how to deal with people who are reluctant to use the system. All elements of the project; software, records management, change and training, are integral to success and must be planned with a fully integrated approach.
There will also be risks. They are not to be ignored. It is unacceptable to not have contingency plans for known risk events.
Striving for unattainable goals that stretch the capability of departments and end users and risk the success of the project. Greed leads to stress and negative perceptions of the project that become pervasive.
Typical of goals which are set at unattainable levels is the percentage of people creating records. This goal is often set at an arbitrary level and as a result of not thinking through who actually needs to create a record versus viewing or editing it, set too high.
On a broader level, project teams aim for too high a level of recordkeeping maturity expecting outcomes such as business workflow to be integrated into the EDRMS across the organisation. It is better, certainly in large organisations to seek adoption of uncomplicated tasks such as creating, viewing and editing across the organisation or driving the adoption of more complex tasks such as workflow across a single process such as recruitment or accounts payable.
Allowing disbelief in the productivity and risk reduction benefits of an EDRMS to remain unchallenged, or not even being aware the disbelief exists. Such disbelief is often the death knell of a project.
Most change management programs which fail do so because of a lack of understanding of what people perceive they have to give up rather than because they have to learn new things. Similarly, projects fail because of what people disbelieve rather than what they believe. When stakeholders disbelieve an EDRMS will provide benefits, even if they believe the EDRMS is required for compliance, there is minimal chance of success. Project teams must work hard to understand what people actively disbelieve and dispel those disbeliefs through demonstrations and case studies.
Project managers who lack EDRMS experience often lack the ability to recognise the nuances of an EDRMS implementation that distinguishes it from a normal software implementation. A key nuance is that in most software implementations there is no choice but to use the system. In an EDRMS implementation, there are alternatives to its use. Users have to be convinced to choose to use the software.
Similarly, using trainers who have little training experience or little EDRMS experience means that the training focuses on software features rather than overcoming user fears and resistance. Users need to be trained in manner in which they will believe in the ‘Why’ of using the system rather than just the how. Understanding and believing in the ‘Why’ we use a system is necessary when we want people to choose to use a system.