EDRMS planning: research applied to reality

This article appeared in the November, 2011 issue of IQ – the Records and Information Management Professionals Australasia (RIM) Quarterly magazine. To download, click here: EDRMS planning: research applied to reality

EDRMS implementation has evolved. Recognition that a successful implementation requires adoption, not just software installation, has become the norm in the 2010’s. Project managers are investing the extra effort in planning strategically to drive adoption. As a result, project team members are starting to work towards the common goal of user preference of the EDRMS as the repository of choice. . There’s a long way to go before all is harmonious, and even further before it’s easy. However, we’ve moved beyond the ‘just another software roll-out’ mentality that dominated the project approach up to 2009.

At InForum 2011 we presented the research project “Training & Change Models for EDRMS: What’s passing and Failing?” The presentation provided industry data on success factors for EDRMS adoption. Success factors consistently increased success by 5 to 20 percentage points for no dollar increase in costs in most cases. Great news for any organisation undertaking an implementation!

With the data analysed the question quickly arises, “How do you apply the insights from the research statistics at the coal face?” This is especially relevant for an EDRMS implementation as each organisation has unique constraints and culture that necessitates a differentiated application of the rules of success. In this article we’ll take a look at the planning stage of a project and provide guidelines for getting the most out of the rules of success.

Key Roles for Success

The statistics tell us that an EDRMS project team relies on seven key roles for success. Projects without the full contingent of these key roles were less successful than average . For instance projects that included a Change Manager and Business Representatives lifted the success rate from the norm of 75% to over 95%. But only 35% and 20% respectively of EDRMS rollout projects included these roles.

Project Manager
Record Manager
IT Manager
EDRMS Manager
Change Manager
L&D Manager
Business Representatives

Including a Change Manager and Business Representatives in the project team is an easy decision with this information in hand.

The latter is a no dollar cost inclusion, although it requires additional project management time to manage. Including Business Representatives on the project team ensures end user viewpoints are front of mind at all times. However, these people require education on the vision, scope and technicalities of the project in order to make a valuable contribution. If they are poorly managed the project may be undermined by a series of self-centred demands. Business representatives may be included in the project teams in two ways. Business representatives may be part of a steering committee providing informed input at regular meetings. Or Business Representatives may provide evaluation of the configuration at various critical points and the business rules.

Including a Change Manager is often not a zero cost option with external recruits required. However, given the need to change people’s behaviours to drive adoption of the EDRMS when users have the choice not to, a skilled change manager is a necessity. This is backed by the survey results showing a failure rate of 83% where organisations did not utilise a communications strategy. On reflection a much higher cost than the inclusion of a specialised Change Manager.

Another key finding of the research project related to the recruitment of the project team was the low rate of success of project managers who had previously only performed a software rollout (50%), as compared to project managers with previous EDRMS rollout experience (92%) and no rollout experience (85%).

There are many constraints which may prevent a project from appointing a project manager with the ideal EDRMS rollout experience. Those projects lead by managers with less than ideal credentials are most likely to have failed because they did not recognise and address the weakness. A project manager with only software rollout experience will not have experienced the challenges of changing end user behaviour to achieve adoption of the EDRMS as a choice. In most software rollouts end users have no choice but to use the software. Therefore the project manager only experienced in software rollout may not place sufficient emphasis on change management or training design and delivery.

Identifying Skill Sets

The immediate impression, when it comes to thinking about filling all of the roles, is of a lot of roles at an advanced level. Especially given that even a small rollout to 200 staff may take 12 months or more and require input from these roles over that time to improve success rates.

The key is to identify the skill sets associated with each role and ensure they are fully represented on your project team. For example, the project manager is also likely to have the skills sets of being the EDRMS, Record or IT Manager. Or the EDRMS manager may need to have the skills to create the change or training program.

To give yourself the highest chance of success, take the responsibility of identifying the skill set and required level of skill in each role seriously. Be careful not to shortcut, or frame the team to look stronger than they really are, to convince yourself or your managers that all bases are covered. Taking shortcuts will only weaken your project.

However, if there are gaps, knowing what they are is good. You can manage the risks to the project early creating risk treatment plans. For instance, if your project team does not include managerial skills at the IT manager level, but does include an IT staff member, you risk a lower level of IT support and slower action on the system. Develop a relationship with the IT manager external to the project team to create the opportunity to ensure clear communications between the staff member and the manager and place your project in a position to receive priority treatment.

It is important to note that not all roles require knowledge of the organisation or the business it performs, but that knowledge must exist within the team and be transferable. Also, external resources can be contracted on an “as needs” basis to cost effectively fill specialist skill shortages.

Knowing the gaps in capability places you in the position to ensure you have specialists in the areas of weakness supporting the project. By doing so your project has every opportunity to be a success.