In the first of this short series on EDRMS project failure, I said that project failure can mean many things:
- Failure to fulfil explicit project goals.
- Failure to meet stakeholder expectations.
- Low user uptake.
All three types of project failure must be taken seriously. However, it can be said that a project that is going to fail has failed before it has even begun – when the scope and resources of the project fail to match the vision of the project.
EDRMS projects usually have a number of stated goals, such as:
- Transformation of the organisational culture and business processes.
- Compliance with external regulation.
- Replacement of specific systems.
I have listed consciously these three goals in a particular order – from a broad vision statement, which requires individual and collective change; to a corporate legal requirement, that requires a combination of systems, process and cultural attitudes that can demonstrate both intention and ability of the organisation to fulfil specific legal requirements; and finally to an enabling step (replacing existing systems) in the organisation’s journey to achieve the other two goals.
In many cases, individual EDRMS projects are scoped and resourced in reverse order. Namely, to replace an existing system, with the intention that the new system will be (more) compliant than the old system, and with the hope that changing a system with somehow change the culture and processes of the organisation.
As I briefly mentioned in the last posting, business processes comprise technology, procedures and people. To change one element (e.g. technology) will fundamentally change the process. However, technology change is often scoped as simply that, a change of technology. The broader organisational implications of the technology change can often be overlooked. It is simply hoped that technology change will achieve the stated vision. The reality is that reliance on hope is not sufficient, and the goals of an EDRMS project are left largely unfulfilled.
Organisational change should be a conscious activity. And therefore there should be an alignment of the project goals with the scope and resources of the project.
The following activity – simple in form – can be used to evaluate the congruence between project goals with the scope and resources of the project.
Take a white board or a piece of paper.
- Draw up four columns (yes, four columns. Bear with me here).
- In the first column, describe your current systems, business problems, and organisational culture.
- If time permits, explore how each of these elements relate to the organisation, to individual teams and departments, and to individual users. Otherwise, even a few general dot points will still illustrate the situation.
- Call this column ‘Current situation’ or simply column ‘X’.
- In the third column (not the second column! Don’t get ahead of yourself), list your project goals.
- Again, if time permits, the list can be expanded to relate to the whole organisation, individual teams and departments and individual users.
- Call this column ‘Future situation’ or simply column ‘Z’.
Typically, with knowledge of the current and future states, EDRMS projects will kick-off at this point. We know where we are now, we know where we want to be, the way forward should be self-evident. Let’s go! Wrong! Exploration of the transition process from ‘X’ and ‘Y’ and the identification of the enabling steps require explicit analysis and planning.
So, what do we do?
- In the second column, list the steps required to get from column ‘X’ to column ‘Z’.
- This column will describe the scope of the EDRMS project. Or more specifically, the collection of projects that will comprise the change process – project scoping, business case preparation, development of the business classification scheme, business process mapping, system selection, system design, system implementation etc.
- Some changes will be self-evident, hence the willingness to jump over this step. Especially system related – e.g. ‘our existing system is a problem, so let’s replace it’.
- List some of the likely considerations when cutting over from the old to a new system (e.g. user training, data migration, user communications, and interim process changes).
- List some of the steps required to change behaviours and attitudes – for the organisation, for departments and teams, and individuals. This is the tricky bit. How do you change behaviours and attitudes? Is it sufficient to rollout new technology and leave users to work things out for themselves? If you’re still reading my blog, then you will probably have already worked the answer to this question for yourself.
- Consider the types of project roles that will need to be created – business analyst, records management adviser, communications specialist, integration specialist, data migration specialist etc.
- Call this column ‘Enabling steps’ or simply ‘Z’.
Whew! That was a lot of work. Can we get on with the project now? Please? No, there is one more column (yes, I know I’m a hard task master).
- In the fourth column (yes, you are now allowed to write in this column), list what you need to do to maintain the vision outlined in column ‘Z’.
- Think about the operational roles required to maintain the system and the business change vision; consider the training and resources that these roles. Technical Administrator, Business Administrator, Trainer etc.
- Think about the changed behaviours and attitudes you will have achieved at the organisational, departmental and individual level during the main project. How do we support and maintain these changes? How do you ensure that new staff, and when existing staff change their roles, are supported in the changed culture?
- Call this column ‘Business as usual’ or simply ‘Z+’.
Whew! Now we can sit back and see what we’ve done. By reading the columns X, Y, Z, Z+ from left to right, we now have the scope of the project – from where we are now (‘X’), to what we need to do to change (‘Y’), to the changed situation (‘Z’) and finally, to what we need to maintain the changes (‘Z+’).
Next time we will discuss business processes, and their three part composition of technology, procedures and people.