Enterprise content management (ECM) platforms are versatile and can be leveraged for several different purposes beyond simply just document management. From customer relationship management (CRM) and enterprise asset management (EAM) to contract lifecycle management (CLM), enterprise content management systems are utilized to manage many core business functions.
However, there are more prevalent enterprise content management use case scenarios than others, and I recently took a look at our 100 largest customers to identify the most common business function that M-Files is used for. As I anticipated, project content management and case management were the most common applications of M‑Files for these companies.
In this first in a series of posts about best practices for using M-Files for project content management, I’ll discuss putting metadata at the forefront of the project planning process, defining project roles, responsibilities, phases and milestones, as well as identifying project documentation volume and content types.
1. Put metadata front and center in your enterprise content management solution during project planning process
Are you familiar with the phrase, proper planning prevents poor performance? The essence behind “The 5 P’s” is that your projects should all follow the same phases of planning, organizing, leading and controlling.
Your project plan should outline the deliverables of a project, the schedule and responsibilities for each stakeholder– and M-Files enables you to harness the power of metadata to gain greater control over each of these core project components. Leveraging metadata early on in the project planning process is essential for building a solid foundation for effective project content and process management.
2. Define project roles, responsibilities, phases and milestones
It’s important to clearly define all stakeholders of a project as well as their specific roles early on in the project planning process. In addition to internal staff, some project team members may be external stakeholders (such as subcontractors, partner or customers), so defining the roles and responsibilities of each project team member at the onset is critical for defining permission management parameters.
With M-Files, you can specify project team member roles as properties within the project metadata card. For example, you can easily establish roles for the project manager, the members of the implementation team, the external stakeholders, and the members of the test organization. In larger and more complex projects, M-Files can also be configured to specify content and process organization independently for each phase of the project.
Once roles and responsibilities have been clearly identified, the next step in the process is to define the phases of the project with relevant data. This may include task deadlines for each phase, rules for initiating assignments once project milestones has been achieved, or disseminating specific documentation to project team members after the completion of each milestone.
3. Identify Project Document Volume and Content Types
When you have the project scope and outline in place (and before the project is initiated), identify the different document types that will be associated with all phases of the project as well as the anticipated volume of project documentation. If you are managing a smaller project with only a few team members and phases, your use of metadata should be congruent with the scope of the project. For example, for a smaller project with only a handful of team members, assignments and document types to manage, you will want to incorporate only the few simple metadata attributes necessary to facilitate a smooth project management process. Integrating a complex metadata scheme for a simple project will make it difficult for team members to adhere to the desired process and will result in a less-than optimum project outcome.
My advice is to keep it simple by defining which project team members should have an access to which document types — and implement your metadata-driven permissions accordingly. The value of this approach becomes apparent when you need to add new members to the project or if your system is audited by your customers and you need to prove that you follow your permission policy. This “Ounce of prevention versus a pound of cure” strategy provides the flexibility to quickly and easily adapt if the scale of the project is adjusted because of the need to integrate new team members, deliverables or document types in the future. You can learn more about the importance of proactively classifying the information and documentation developed and managed during the course of business in one of our past blog posts entitled, “Classifying Information in a QMS provides the Foundation for Practical Quality Management.”
Do you leverage an enterprise content management (ECM) system to manage project content at your organization? I’d love to hear from you if you have an interesting project content management use case example. And keep an eye out for “Part 2” of my take on improving project content management, in which I’ll touch on document lifecycle management and how to ensure your project team adheres to defined project processes and policies.
Latest posts by Mika Javanainen (see all)
- Sink or Swim: Managing the Growing Flood of Dark Data with EIM - September 13, 2016
- M-Files 2015.2: Collaboration and Mobility Enhancements Take Center Stage - April 13, 2016
- What You Need to Know about Encryption in M-Files - March 2, 2016