Rollouts of EDRMS software are overwhelming. They introduce new software and new methods of information storage to almost everyone in an organisation. As an EDRMS Project Manager your tasks are also initially overwhelming. First you need to find the most suitable software. Next the pressure’s on to find the perfect configuration. At the same time you need to make sure you’re meeting the compliance and legislative requirements. Plus, for the project to be successful people need to actually use the software. Then, on top of all that pressure, is the history of failure. To get over that hurdle you need a communication and change strategy.
And who are you? You’re the project manager – now. Maybe you were the records manager before, the IT manager, the CIO or the Corporate Services Director. Or you could be an external consultant with the enviable position title of EDRMS Project Manager. Whatever your title or position it’s unlikely you’ve had a project quite like this before, stretching across a huge range of skills and knowledge necessary for success. On top of all the decisions and learning in front of you, you may also have the confronting task of delivering training to thousands of people in many different locations.
Despite the task of rolling out an EDRMS solution being daunting and the overall history being one of failure, be reassured it’s been done successfully before. The knowledge is available to avoid failure and here we’ve outlined core elements you and your team need to address to build and deliver a successful EDRMS project.
Goals
Although it seems like such common sense to have measurable goals in an EDRMS project, they are extremely rare. The scope of the project is almost always defined; for example, how many users, the level of training, timeframe for rollout, budget, and type of records to be stored.
Scope provides everyone with the boundaries of the project. Working beyond the scope is not covered in the budget. However, scope and goals are quite different.
Goals define the levels of success and timelines for achievement of the project. For example: How many users trained in 3 months; Average number of people creating records daily in month 6. Goals must be specific, measurable, achievable, realistic and time bound – SMART goals. This is common knowledge in any type of project management but rarely actually applied in EDRMS projects.
Creating goals is challenging. Defining what the goals should be in an EDRMS project can be difficult. After all, what is user success; creating or editing or viewing or searching? Is the level of creation based on number of records or number of people creating? And does that vary by business unit?
Rather than having a simple statement as a goal it can be less threatening to define a level of expected success, with over achievement and under achievement levels also defined.
With goals set contingency plans can be discussed and prepared, and when necessary, rapidly implemented. Without clear goals teams repeatedly flounder and lose focus in the project.
Further, project achievements can be celebrated. As a result, enthusiasm is retained to move forward to the next stage of the project, be it rollout or improved use.
Team Skills
Be ruthless about having the right blend of team skills. In planning your project team develop a matrix of the skills required. Sure you need people with technical skills in IT, EDRMS, Records, Training and Change, but to what level, experience and how many staff? Often the technical skills are the easy part to understand and source. However, your team members also need a range of other skills, including but not limited to management, administration, presentation, interpersonal and communication skills. Design the skills matrix taking into account the tasks to be completed to achieve the outcomes required of your project. The design should also take into account interpersonal relationships required to form a diverse team which can coalesce around the objectives of the project. .
Projects come unstuck when the skills of the team do not match the needs of the project. For example, you may have a technically great administrator who likes to keep everything close to their chest and provide the most advanced solution that, as a result, consistently presents user unfriendly solutions. Or you may have an efficient training developer who has a myopic solution that doesn’t cater for the budget, time or working style of your end users.
It is also important that your team members have a long term vision. Each of them needs to be a leader; not only of their own teams, but also of the people you are rolling out to. Therefore, include a proactive approach and change readiness as skills in your matrix, plus the ability to manage stress – it happens often. Assess each person in the team as to their skills. Not every person may have the peak range of skills for their role. However, ask yourself are they people who have shown they can learn rapidly? Or have they previously displayed an ability to work with others to compensate for any gaps on their part?
Working Together
Your project team needs to operate like a cooperative. Everyone needs to be focused on a single overall objective to which they need to operationally align. Projects run from 1 to 5 years; it depends on the size of your organisation and the approach. In some cases the project team is fully employed by the project; for others it forms only part of their everyday role.
Regardless of the structure build in the time, opportunities and the environment for everyone to build relationships (get to know each other fully). Building relationships requires investment of extra time and probably budget, early in the project. To be effective, team members have to give up some ownership of their areas of expertise and be open to input from the rest of the team. At times, they need to make adaptations to their preferred approach to allow for a considered team approach to be applied, in order to make a successful project. Giving up ownership and changing one’s approach does not happen instantly, or automatically. As the project manager you may need to orchestrate this.
Returns on the initial investment are realised over the lifespan of the project with faster, better, collaborative decision making. Everyone in the project is more communicative, developing a deeper understanding of the “what” and the “why” of all the decisions. They are therefore in a position to project positive communications on the project. To get the best system configuration and training possible for end users requires a diverse team working together.
Risk & Reaction
Be aware of the risks to the success of your project (but first you’ll need to know your goals). The attitude of “I’ve planned so well there are no risks” is a falsehood. Define and rate the likelihood and consequences of risks as a team. Put actions in place to reduce the likelihood and/or consequence of those which provide an unacceptable risk to the project. Devise ways of measuring whether the risks are being realised or not and whether the actions you take are working or not.
Don’t expect your team members to be fully aware of the risks. The best you can hope for is that they are aware of the risks in their area of expertise. Make risks an open discussion that is revisited on a quarterly basis as a minimum. EDRMS roll-outs are big projects and new risks appear as it progresses for which you simply do not have the experience to identify from the outset.
Defining and rating risk is the easy first part of managing the risk in your EDRMS project. Managing the implementation of the actions and monitoring their effectiveness is the more difficult second part.
Unfortunately, in many EDRMS projects taking action on risks is replaced by procrastination as relevant stakeholders cannot see the benefit of taking action on something which has not yet occurred. Our advice is to take the action and monitor the effectiveness of the action. The news of adverse events in an EDRMS project spreads like wildfire. The EDRMS project or the software name quickly gets a bad name and people become reluctant to get involved in the project or use the software. Negative rumours are known to be the death knell of EDRMS projects.
Continuous Improvement
EDRMS projects are not identical and there is not a single defined approach or plan. The project itself, as we like to say in the training industry, is a learning experience. That’s a good thing. Everyone who finishes the project is smarter and wiser, even if they are experienced in EDRMS rollouts.
Project teams can be overwhelmed by what they don’t know. Ensure as project manager, that you and the team operate in an environment where it’s okay to not know. We can’t be experts at everything, but we can ask questions, apply logical thought processes and be open to input of others. In creating that environment, each person learns as the project develops and works together to provide solutions.
Build reflection into project meetings on a quarterly basis. Ask people to reflect and contribute what they have learnt. You’ll frequently find this exposes knowledge that other people were not aware of. It also builds your team’s confidence in themselves. They see personal progress. This is especially important at stages of the project where there is little to measure, or physical progress is slow.
EDRMS project success is improving. The good news stories are becoming more prevalent at recordkeeping events and conferences. A common message is clear from these stories: build and retain a strong team, and celebrate wins.
