Part 2 of this post is now available
Creating the right organizational structure for your ECM program can set the stage for success. In the first of a two part article, I will talk about the roles and responsibilities that should be included in your ECM team.
But first, a caveat. The roles as well as the org structures I will discuss next time are intended to be a starting point. We don't live in a perfect world (at least I don't, not so sure about you…) and we can't always count on creating the ideal organizational structure. Existing structures, HR policies, sponsorship issues and other organizational dynamics can get in the way. My goal is to give you a guideline based on my experience with what works.
The idea is that the roles and structures apply irrespective of technology. Like me, this article is vendor-neutral.
And one final point. Although many of the roles listed below are called "teams" this can often be done by one person or multiple roles can be combined, depending on the scale of your organization, your budget and your ECM program. Again, this is intended to be a guideline to help you develop a structure that works best for you and your organization.
The role of the steering committee is akin to that of the Board of Directors of a company; they provide high-level direction for the activities of the ECM program and sign off on major program deliverables. The steering committee should be made up of senior executives (ideally C-level executives or, if that isn't feasible in your organization, their direct reports).
Your project sponsor should be a member of your steering committee and should be your go-to person when you need to escalate issues or if you need business guidance. You should have regular meetings with your steering committee. Ideally once a month but no less than quarterly.
The Program Manager runs the ECM program and is responsible for the initiatives conducted under the ECM banner. This person is ultimately responsible for all deliverables, budgets, timelines and program objectives. Some specific tasks of the program manager include:
Drive the creation and execution of the ECM strategy
Liaison to the steering committee
Manage vendor relationships
Hire and manage the ECM team
Contribute to or lead the development of an appropriate information architecture
Identify, track and act upon key metrics for the ECM program
The project team leads the implementation and design of discrete ECM initiatives. This can include document imaging rollouts, shared drive migrations, team site deployments, the creation of new workflows, system upgrades and many other projects.
The core skills on your project team should be a combination of strong project managers and ECM-savvy business analysts. I have often seen these roles combined and this is my preferred structure. Only in very large projects will you require a standalone project manager
Information Governance Team
The information governance team is responsible for the creation and implementation of your ECM governance framework . This includes aligning ECM activities with the relevant corporate policies by creating guidelines, standards and procedures related to ECM.
The information governance team also works closely with the project team to develop and implement metadata standards, taxonomy standards and the overall information architecture for your ECM solution. They are the "go-to" team for questions about content disposition or exceptions to your ECM principles (for example, when is it okay to copy content rather than link a single document in multiple locations).
And yes, the information governance group also includes the more traditional records management roles. This includes the creation and application of a corporate retention and disposition schedule and can also include the management of a records centre or corporate library.
Change Management Team
This role is responsible for ensuring that your end user community is ready, willing and able to adopt ECM. While this activity is often rolled into the accountabilities of the projects team, in my experience it is best to have a person or a team dedicated to ensuring the significant changes that can come from an ECM implementation are accounted for. This is often the single biggest cause of ECM project failure. When we consider that the change required to succeed with many core use-cases for ECM (for example, moving from a "File / Save As…" world to the need to add metadata to a simple MS Office document), there is little wonder end users will often rebel.
The change management team works actively with the project teams and the program office to ensure they incorporate good change management practice as part of each project plan. The information gathered as part of this process is incorporated an overall change management strategy, which identifies the change impact of each ECM activity and ensures that communication, training and support plans are in place to ease the end user transition to your ECM solution.
The training team's role is relatively straightforward; ensure that your user community knows how to use the ECM toolset. This is often more of an art than a science. My advice is to focus on providing your end users with "one best way" for performing a particular task. Even though the tool likely supports a variety of methods for achieving the same thing, there's nothing more confusing than giving someone three ways to save a document.
The training team should be ECM experts in their own right. Although it can be tempting to repurpose existing trainers to also provide ECM training, the complexities and subtleties of ECM are often lost on people who are not experts. Where this isn't possible, use the ECM experts from your other teams to implement a "train the trainer" approach.
Your support team is often made up of members of your projects team, change team or training team (or all the above). The role of the support team is to provide second-level support to your end user community. They must be ECM experts and should know the nuances of your ECM toolset very well. They will work closely with your help desk and technical team to identify and trend issues, and will help prioritize system fixes or enhancements.
Your technical team is tasked with keeping your ECM system up and running. Despite the complexities of ECM applications, you know this team is successful when it looks easy. Technical teams generally have development groups, operational / system administration groups and may also have their own infrastructure groups.
It is critical that your technical team have a close working relationship with your all other teams. Although your projects, change, training, governance and support teams should be ECM experts, the best solutions come from open conversations with the technical team. This will ensure that the implications of any proposed customizations, new modules or other system changes are well understood and communicated to your user community.
We can't forget end users, of course. They're the reason we are doing all of this in the first place. Ensure that you have a good feedback loop through each of your teams so the end user experience is understood and incorporated into the continuous improvement of your ECM program.
It is also common to have a close relationship between the ECM team and the communications and / or portal team. There groups are often a separate entity, but there is significant overlap in areas like governance and information architecture.
The Role of Consultants
It is important to recognize that consultants or vendor professional services teams can and should play a role in your ECM program. They have the expertise that comes from having implemented ECM in a variety of different organizations and you should be able to take advantage of their knowledge and experience.
However, when working with consultants it is critical to have an employee assigned to shadow the consultant and ultimately take over their role. Although it can be valuable to engage consultants to establish or revamp your ECM program, it can be risky to become too reliant on them. If your consultants don't want to mentor your employees to eventually replace them, find different consultants.
I hope this has been a useful guide. Next time I will share some sample ECM organizational structures. In the meantime, I welcome your comments and feedback.
#OrgStructure #ElectronicRecordsManagement #ProjectManagement #ECM #strategy #SharePoint
Cross-posted to the C3 Associates ECM Blog.