Project Records Management in Three Essential Steps

Project Records Management in 3 StepsManaging records on a project is an essential activity that makes it possible to handle and use project documentation in the way that ensure smooth capturing of documents and papers by seniors, team members, and other stakeholders. Being a part of overall document management, records management allows a project manager to direct and control document flows throughout the project lifecycle, while ensuring that every single document or record serves the operational needs and helps teams capture and retrieve necessary information. It creates a framework for running project activities and procedures and paves the way for analysis, lessons learned, historical reviews, etc.

Personally, I can’t image a project having no means of managing records and documentation. I regard project records management as a consistent and continuous process that includes a range of steps and procedures to create, use and store various types and kinds of project records, files, documents, papers, sheets etc. Let’s learn more about it. In this article I talk about the definition, importance and key steps of the process for managing project records.

Definition

Managing project records is an important responsibility of a project manager who must ensure that every document or file is properly designed, formatted, communicated, secured, stored, and archived. The manager should also keep the records up-to-date and relevant. If to look at records management at the highest level, you may see that it is similar to a process rather than a responsibility. So I regard it as a process which has certain inputs, consumes some resources, and generate definite outcomes. Here’s the definition of project records management:

Project Records Management is a process of creating, directing and controlling document flows within a project, through using an administrative system, to provide effective development, versioning, filing, storing and retrieving of records, while ensuring that every record designed is utilized administratively and legally. The process creates a framework for managing the project activities and delivering necessary information to teams.

As a process, project records management is characterized by the following items:

  • Inputs: any essential information to be recorded and saved for the project
  • Resources: equipment, systems, software, communication tools, HR etc.
  • Guidelines: document management policies, document standards, filing procedures, etc.
  • Outputs: document flows, files, catalogues, record sheets, etc.

When you start managing your project, first you must be sure that there’s a framework for documenting and filing events occurring within the project (the inputs). By using systems and software (the resource), your teams can record activities and events and create documents. They follow prescribed procedures for event recording and documenting (the guidelines). Finally running the process allows you to develop necessary documentation, files and records (the outputs). In this regard, project records management seems to be cyclical – when records are created, treated, filed and documented.

The process of managing project files and records is important because of the following aspects:

  • Supporting ease and efficiency of the project activities
  • Allowing teams can find required information you when they need
  • Protecting the project data from unauthorized access and use
  • Saving time and effort
  • Reducing costs, including space costs
  • Keeping files up-to-date and versioned

Three Steps

Below I describe the process as a three step sequence. I personally use these steps to manage records and files within my projects. Hope the information will be helpful for you as well.

Step #1. Create Project Files

When you create a project file, you must be sure you do it in accordance with the standards and requirements of file management within your organization. For example, in my organization we have a file management policy stating how to create a project file, what system and tools to use, what file formats and extensions are preferable, who has authorizes for file creation, how to update filed records, and so on.

There’re five common requirements to project file creation:

  • Prompt. A file is to be created as early and quickly as possible.
  • Simple. File content should have a structure that is as simple as possible.
  • Separate. Every file is a single and separate record; two or more files can’t be combined; if there’s a need to combine the content of several files, a new file should be created.
  • Up-to-date. When a project file is updated, a versioning number as well as the date revised should be added to the file header.
  • Confidential. A file should be maintained with complete confidentiality; only authorized personnel can access the file and its content.

In any project and programme these 5 requirements should be treated with great care because otherwise the project/programme is likely to fail with creating reliable, comprehensive, complete and relevant project files.

Step #2. File Project Documents

Once you have created a file according to your file management policy and requirements, now you can proceed with filing project documents. It means you must put all your documents and white-papers into respective files. Below I list the key documents and data you should add to your project files:

  • Official mail and email correspondence, including letters, attachments, pictures
  • Papers if project meetings
  • Project request, proposal, brief.
  • Stakeholder contact details
  • Change and variance requests
  • Project diary
  • Issue logs/risk logs/decisions made
  • Status reports and summaries
  • Procurement papers
  • Team guidelines, instructions, notes, etc.
  • Handover/closure documents

You should be sure that every piece of this data is put into a file. There should be version control to ensure that the project files are updated and changed properly. The following details are required: revision number, revision date, author, editor, link to an electronic copy (if any).

Step #3. Archive and Destroy Project Records

Once all of your project documents and relevant data have been filed, your next step is to manage the records and move them to archive . Archiving project records means making documents no more available within the given environment while ensuring that the records are retrievable for further projects and lessons learned.

When you project is over, you may need to destruct the records, instead of archiving them. Anyway, you must refer to the archiving and destructing procedures of your organization when treating your project records.

In my organization we prefer archiving documentation rather than destroying. We try not to practice record destroying because we believe that any piece of documented and filed information may be required in the future. Your company may have another opinion regarding this.

However, we can’t keep all of our files forever because this seems to be highly expensive. We try to give a file the longest life possible and wait until the life is over; then we just destruct the file. Below I give you our record retention requirements which, I hope, will be useful for you:

  • Contract documents and advice records: we store this type of project records for at least 5 years after the contracts are fulfilled.
  • General project records: these are kept in accordance with the function that they support.
  • Research data records: from 5 to 7 years, depending upon the nature of the research.
  • Legal issues and case records: a minimum of 7 years.
  • Finance records are kept 5 years long.
  • Other types of project records are archived for the period of 5-7 years.

Best practice of document archiving says that an organization should try to retain a project file for the longest possible period of time. We follow this standard. And you?

Eric Morkovich

Eric is an enthusiastic project manager who has worked on various projects in the software industry for over ten years. He took on a variety of roles and responsibilities for projects and teams. Today Eric helps product companies review and improve their software definition, development, and implementation processes. Follow Eric on Twitter.

You may also like...