Information Governance | Electronic Records Management (ERM) | Enterprise Content Management (ECM)
Before getting started with an implementation, and way before moving onto the eight secrets, it is useful to recall why you are considering a content or records management implementation in the first place and to confirm there's a commitment to proceed.
This kind of "strategic mobilization" should kick off any ECM or ERM project. To do this effectively, organizations should gather sponsors and stakeholders, identify the team that will lead the project, understand what the vision of the sponsor of the project is, and understand where significant gaps are likely to arise.
At its core, this is about defining 1) who needs to be involved, and 2) the scope of the project. Framing the initiative and confirming commitment needs a variety of key stakeholders: business, legal, executive, records, and IT. And don't forget some representation from the people who will actually have to use all this technology! In terms of scope, this will need to be done across a number of dimensions, including some or all of the following factors: 1) geography, 2) organizational, 3) legacy content, 4) information types, 5) information classes, and 6) timing.
All of this should lead to a charter for the initiative. I will confess my bias in this area, which will carry over into some of the documentation described in the eight secrets -- this document is better off being short and strategic and actually read than long and detailed and gathering dust on a shelf (or whatever the equivalent is in digital form). My friend Martin White from InranetFocus.com has some good advice -- think Magna Carta, not a 100-page document.
Everyone still on board? Have a charter and sponsorship and commitment? OK, then, let's get going.
Without further ago, here are the eight secrets of an effective content or records management implementation:
-
Build a Business Strategy and Blueprint.
A successful blueprint begins with identifying the critical success factors for the initiative, how they will be measured, and what the drivers will be (i.e., how will life be different after all this work).
A good business blueprint includes the following:
An Executive Summary that summarizes the key information contained in the business blueprint, and highlights the recommendations and decision required.
A High-Level Program Plan that shows a sequence of projects and approximate delivery schedule. This will likely include a series of tactical and strategic projects.
A series of Business Case justifications covering the multiple dimensions of any ECM or ERM project:
- The strategic case shows why the ECM-related project is required and what business needs the project satisfies.
- The economic case contains a summary of costs and benefits. The economic case focuses on comparing alternative ways of implementing the ECM-related project.
- The funding case confirms that the available sources of funding are sufficient to implement the ECM environment and operate the ECM service.
- The commercial case describes plans for the procurement of any ECM services or technology from suppliers.
- The project management case describes the governance arrangement for the project and details of the project team.
A Future-State Conceptual Architecture illustrates the gap between the initial Current-State Conceptual Architecture, and what is proposed as the conceptual components of the solution to solve the concerns of the business.
-
Conduct a Technology Assessment and Create a Blueprint.
As its name implies, the technology assessment concentrates on the technical aspects of your strategy. The goal of the assessment is to develop a technology blueprint similar in scope to the business blueprint defined in Secret #1 but focused on technology.
There are five main stages in producing an effective set of technical requirements for an ECM or ERM related initiative:
The first stage is to plan the work effort that is required to develop the technical requirements and blueprint. Sufficient time should be allowed to obtain consensus and agreement; this can often be considerable and often takes longer than those closest to the project anticipate.
The second stage is to gather requirements. This will involve obtaining needs from the key stakeholders and users.
After having gathered an initial set of requirements, the third step is to analyze and understand the requirements.
The fourth stage is the documentation of the requirements. Documentation of the requirements is a powerful tool for achieving consensus on the end-state solution.
The fifth and final stage is to obtain agreement to the documented set of requirements. This will involve obtaining some kind of sign-off authority from each of the key stakeholders. [Again, recall the earlier advice -- volume doesn't score extra points!]
-
Think Through a Governance Structure and Approach.
Information governance is a set of formal and documented policies, procedures, and rules that control how enterprise content will be managed potentially across its entire lifecycle, from the point of creation to ultimate destruction. Defining expectations, building a system that supports and enforces these expectations, and defining the role that end users have relative to those expectations is critical to an effective governance structure.
A sound Information Governance Framework will include the following:
- Laying down policies that will govern behaviors.
- Defining processes for all stages of the Information Lifecycle.
- Setting standards that must be followed when carrying out a defined process.
- Appointing specific people to be responsible for the information assets.
- Providing tools and technology to enable staff to carry out the defined processes to the required standards.
- Auditing the elements of the Framework regularly to ensure that the guidelines are being followed.
Again, it is important that all of this be incorporated into a governance document that is understood, endorsed, and supported by the key stakeholders in the organization. AIIM research indicates that many of the core problems encountered during an implementation have poor or ill-defined governance at their core.
-
Create a Roadmap and Project Plan.
A project plan typically how the following activities will be addressed: 1) Project management, 2) Testing and deployment, and 3 Issue resolution.
We define project management as a structure, process, and procedure based on the organization's preferred Project Management methodology. The role and responsibility of the Project Manager is to make decisions and balance resources across the entire program and to make sure that all projects are working to a set of shared requirements. The project manager monitors plans and progress across all projects in the ECM project to ensure coherence and integration across the whole program.
-
Build a Sound Foundation.
Organizations need to make sure that the appropriate software development environment exists for the project. Some of the questions to ask: 1) Is the configuration management environment set up, so that code and other artifacts can be checked in when they are completed? 2) Do the developers have a workable development environment? 3) Are the developers trained in the tools that will be used to build the system?
Another core foundational requirement is defining the enterprise information architecture. Some of the necessary tasks at this stage are: 1) Defining the enterprise master data model; 2) Defining the master data management architecture; 3) Defining when synchronization of content, data, and information are required by different systems to meet their business-based information needs; and 4) Defining the master data definitions and business rules.
Taxonomy design and metadata development are also core elements in building a sound foundation. [One sentence for these two -- obviously easier said than done!]
-
Design the Plan.
The design phase of a project typically includes the following activities:
Design of user support and operational procedures. The user support and operational procedures are intended to create the documentation and training program for all users and technical support staff as they relate to the project.
Security. Security design builds in the appropriate content security model, supporting security at each level of the system – whether at the repository, folder/collection, document, element, or physical levels.
Design of infrastructure management processes. The infrastructure management process design provides a set of requirements for the physical implementation of the information platform and its associated management functions. The target audience for the design documents produced by this activity is operations staff such as Systems Administrators and Systems Operators.
User collaboration. User content generated through increasingly powerful collaborative tools is a growing challenge in many ECM and ERM environments. A key element in designing the plan is to define how these tools will work in relation to the rest of the ECM environment.
User interfaces. The user interface is specifically focused on the layout, information access, and information presentation of the ECM environment.
-
Deploy the Plan and Cycle Through Phases of Assessment and Improvement.
Once you get to the point of deploying your solution, there are four main phases to consider: development, testing, actual deployment, and improvement. These phases typically recur as different versions and levels of functionality are introduced and improved.
Development -- transforms the design into working modules that can be tested. This includes the development of operational documentation and training materials.
Testing -- focuses testing of the environment at many levels, from technical functioning (at all) through to testing of end-to-end processes.
Deployment -- delivers the new system into production. This includes setting up the production environment, installing the new system applications, interfaces and repositories, publishing the system documentation, training users, and initiating production operations.
Operation and continuous improvement -- focused on delivering incremental improvements to existing functionality.
-
And Don't Forget Change Management!
AIIM research suggests that the main pitfalls for an ECM project stem not from technology but from a failure to anticipate change management issues.
Regardless of the kind of change -- whether technological, cultural, procedural, role-based, or any other -- organization must determine whether they are ready to face the change and adjust to it. Determining readiness is a big factor in the potential success of your ECM project.
Organizational change is always going to appear threatening to people as it is often linked to job security. Some enterprises freely disseminate information regarding strategy changes. Other firms are very secretive and feel that this is for senior management only. Practitioners should be as open and honest with staff about change as they possibly can. Typically, people will more readily embrace the change process if clear information is available.
The readiness of both management and affected workers to accept and adapt to change are the most crucial factors in the success, or failure, of your project. Management may be far more ready to change than the potentially affected workers, particularly if the idea for the proposed change is coming from management – as it typically is. However, just because you have meetings with middle or senior management who are very enthusiastic about this new project, doesn’t mean that the organization as a whole is ready to change.
It can feel daunting, I know, and at this point, you may be thinking, do I really want to do this?
Obviously, we feel the answer is yes. It wasn't easy for organizations to set up strategies and structures to manage money, people, and resources. But we all did it because these areas were deemed strategically important to organizational success.
Developing and implementing an information management strategy is hard work, but it's not impossible work.
