(With apologies to Leo Tolstoy) ‘Happy EDRMS projects are all alike; every unhappy EDRMS project is unhappy in its own way.’
Tolstoy was really talking about families (in ‘Anna Karenina’, 1877) but with a simple word substitution we find our understanding of EDRMS projects has been significantly advanced.
Indeed, one could write a whole library of books to illustrate and explain the multitude of problems that can bring an EDRMS project undone. In contrast, successful EDRMS projects tend to be successful because of good governance and project management. We will explore the features of good EDRMS project in another posting.
I have grouped some of the common pit-falls under themes:
- Project management is a specialist skill, and much like a captain of a ship. Not many people would be happy to board a ship only to find out, once at sea, that there is no captain aboard. But many EDRMS projects begin without an experienced project manager, with a project manager hedged about by limitations on their actions, or with a project manager carrying the full duties of a regular role in addition to the PM role.
- Project scoping makes clear the playing field for the project. Are we playing soccer or rugby? Are we playing an international grade game, or are we tossing a ball around the back-yard? In a later blog posting, we will be exploring project scoping problems further.
- Project governance makes clear who is responsible for what. Further, it makes clear the relationships and responsibilities of the project manager versus the project team; the project manager versus the project’s executive sponsor; the project manager versus the project managers of the various vendors (hardware, software, professional services etc.) that are engaged to participate in the project.
- Executive sponsorship. Last but not least, the project must a project sponsor – a member of the organisation’s executive leadership team, who will champion the project with his/her colleagues. I will explore the role of the executive sponsor in a later blog posting.
Virtually every aspect of system design, process change, legacy system management, data migration, training, communications and business as usual planning can be grouped under ‘User experience’. Why? Because someone has to use the system – a creature known as a ‘user’. Because of its unhealthy and illegal connotations, not many people want to be known as ‘users’. However, EDRMS projects are dominated by IT thinking and language, so we are stuck with the term.
A project that takes the user as the centre of the project is more likely to be a success.
- A user must be ready and motivated to participate in the change. They must feel that they are part of the change and not the victims of the change; they must feel that the project benefits are benefits for them; and they must feel that they have the technical skills to actually use the technology.
- A user will use the user interface, so the interface must make sense and be appealing to them.
- A user must use data from the legacy systems that are decommissioned by the project, therefore:
- User-centric decisions must be made about what legacy data is to be migrated.
- User-centric decisions must be made about how to represent the legacy data within the system. Every system represents and categorised its data in its own way; therefore, migrating data from system A to system B will (at the very least) change the appearance of that data and how it is searched in the eyes of the user.
- A user will use multiple systems in the course of their working day; they will often use multiple systems to manage a single process. If the user has to manually jump between systems, manually re-enter data between systems etc. then there they will not be particularly impressed or motivated to make use of a new system. A user should experience a seamless integration between systems – for example, they should use a single system and not be immediately aware that the actions they initiate in that system are (a) calling data from another system or (b) triggering actions in another system.
- A user experiencing a new system must actually be experiencing the benefits of process change – all business process comprise a mix of technology, people, and procedures. If you change one element of a process, then the whole process is fundamentally changed. Representatives of the users must be engaged to assist with the explicit re-design of business processes. If the relationship is not understood between technological change and what people actually do as part of a business process, then the process itself might fail as a result of the introduction of the new system.
Business as usual
A project must not be allowed to finish without leaving a (positive) mark. It must not simply be allowed to run out of steam. An EDRMS project is an enabling step as part of a larger programme of activities. The system must transition from project into operational mode.
A common (and necessary) project step is to recruit (from external or internal sources) a specialist team of project team members, and to train operational staff from across the business to play their part in the project.
A common mistake is to simply disband the specialist team at the end of the project, usually because of the budget has run out. Instead, it is commonly assumed that the operational staff will simply carry on with the administration and leadership of the system (including the broader process change vision of the initial project) – without the support of the specialist trained staff of the project, and without allowance for on-going training of the operational staff.
The new system – both its technical features and its business change vision – must become embedded in a business as usual culture.
Next time we will discuss a simple analytical tool to review the goals of the project against the resources and project decisions allocated to the project.