It does not take a huge project to spawn vast amounts of project knowledge, information, and documentation. Yet strangely, project document management does not feature in any of the principal Project Management methodologies.
Yet the ability to organize and manage project information is essential. Maybe we think it’s easy. Perhaps we think it is too dull. Or do we just hope we can pass it off to an administrator or Project Controller?
But the truth is that Project Document Management is every bit as much your responsibility as a Project Manager, as other things. It sits alongside planning, risk management, cost control, and quality management. And even if you choose to delegate it, two things will always be true:
To learn more about Project Document Management and how to properly organize all your records, plans, and documents, you need a guide. So, we invited one of the best.
Malcolm has been at the forefront of Project Management thinking and delivery in the UK for over twenty years. The Association for Project Management (APM) awarded Malcolm its most prestigious award in 1999. The Monty Finniston Award is a ‘lifetime achievement’ award for contribution to the profession.
Malcolm is the founder of PROJECT in a box. This SaaS* tool supported many of the functions of your Project, Program and Portfolio Support Office. And what it did supremely well is organize your project information and documentation.
[ * SaaS: Software as a Service]
So, who better to tell us about project documentation management?
In this article, Malcolm looks at why it is important to be tidy and organized in your project and some tips for helping you to deliver on that.
There is a lot to cover here. So let’s break it down into these four sections:
We all know that each project is a unique venture with its objectives, circumstances, and team put together for one time only. Then, they disband once the project has met its objectives. This uniqueness can lead to Project Managers ‘reinventing of the wheel’ each time. As a result, we too often see chaotic structures and processes. This can be especially the case with first-time project managers.
The consequences of inventing things anew each time can be severe:
The overall impact of poor project document management can be a negative effect on all aspects of your project.
When your project receives its first audit, your document management and information organization will get a severe test!
My experience of project audits is very much that if you look organised and can quickly find the particular things that auditors ask for, then you won’t get too many more difficult questions.
But, if a lack of order surfaces early the audits can become much more penetrating. Now, your document management becomes a governance issue. And auditors will want to examine your systems and processes.
Now this should already be enough reasons why organized project documentation is important. But now, imagine when you have multiple projects to manage at the same time. Maybe they are for different customers; potentially with commercial confidentiality involved.
Now think about how easy it would be to get into a mess with cross-contamination of documentation. And never mind how hard it may be for you to find the information you need.
For more on the challenge of managing multiple projects:
and Manage Project Information" width="" height="" />
Every project will involve expending resources. And, in return, it will deliver benefits to its sponsoring organization. A project is always complex and unique. And it involves agreeing with people what they need to do and by when. Usually there is interaction between different groups of stakeholders and dependencies between activities, which you’ll need to manage.
If this is not to be totally chaotic, you need to be organized to make it a success. And this applies to information, data, and project documentation, as much as to everything else.
The types of document management organization that are appropriate will vary for different:
Hence, they will depend on what activities you are undertaking and the complexity of the organization involved in delivering the change.
Projects usually control all of their activities with documentation of some sort. Even if interactions are in person, we usually follow-up with notes to confirm any agreement of what will be done, and by when.
Of course, when we come to thinking about commercial interactions with suppliers or contractors, for buying equipment and services, it becomes more complex. With commercial arrangements, we generate a lot of documentation. And will need to keep contracts, tender documents, warranties, and financial records.
Some documentation will have specific requirements. For example, materials certification and test results may need to be stored in a way that is incorruptible. And, in some projects, we must retain it for a specific period, to meet regulatory conditions.
So a well-run project creates a lot of documentation. And it all needs managing. That shouldn’t be a surprise to a Project Manager: but often it is!
In the days before we all had personal computers, a whole part of the project team, in a complex project, was assigned to managing these materials. Project Librarian was a common role. Frequently. these days the Project Manager or the PMO (see below) will create a folder structure to store their documentation.
That sounds like ‘job done’.
But beware… Project Documentation has some strange attributes.
Project Managers have developed many Project Management methodologies over the years. They aim to establish a consistency in our approach to how we deliver projects.
So, there are lots of different methodologies and none is truly universal. They all work better on some types of projects – and less well on others. Most of us learn some of these as part of our professional development and they encourage us to follow defined processes when we deliver our projects. Not unsurprisingly, they often identify – and sometimes specify – the documentation we might collect, create, and work on as we move through the processes.
The simplest project document management solution is to mirror the structure of the methodology you are using in your folder structure.
But, if you are using a simple folder structure like this to hold your project documentation, then it will cause you a major issue. Usually, we see this evolution:
And here the problems really start.
Both approaches are helpful, but you can’t do both. So, you have to use one or the other. Also, you will find that some content really needs to be available in multiple places. But folder structures just don’t work like that, so your structure is always sub-optimal. This means you will forever be searching out the things you need.
If you think that is a problem for you as Project Manager, just imagine what it will be like for your team members who will really struggle to find the things they need.
Usually, they just end up asking ‘can you please send me the latest copy of x?’ Therefore, your valuable time gets sucked into acting as a librarian for your colleagues.
In fact, for many years PRINCE2 had a standard role of Project Librarian, whose job was to manage all these issues. Now it is commonly part of the role definition for project support.
This is a real, tangible issue. And, as projects become more complex, this issue can grind you down. And it can also slow down your project and even cause failures if people retrieve the wrong versions.
We need solutions. First, let’s have a look at some of the ways people often address these challenges.
Yes, all projects will be different. But many parts of them will have strong similarities. And even the variable parts can have some consistency if you create a well-organized folder structure for managing your documentation.
Thinking about that structure at the start of your project will help you later. So, I would suggest:
The project controls folder contains a folder for each Document that may be required by your methodology of choice. Number and name these, with those you are not using in this particular project marked as (not used). For example:
The communications folder contains a folder for each organization with whom you are communicating. Start with the standard organizations that you communicate with often and on most projects. Then any new ones added afterward. Again, number and name them, for example:
The meetings folder contains a set of folders one for each meeting and named as follows:
2020-04-09-1 – Project Team Meeting
Using the date in this format makes it easy to order the folders chronologically. And if you have more than one meeting on one day, add a -1, -2 element.
The deliverables folder contains a folder structure which maps against what you are going in the project. These could be a list of deliverables, stages, purchases, or subcontracts. And, if your project is complex, you may wish to introduce this type of structure within it. Again, folders should have a number and a name.
A great solution here is to mirror your Product or Work Breakdown Structure, or your work packages.
Into each of these folders you place all material relevant to the folder topic. To make this repeatable you can set up a blank set with the things that come up most often and including your common templates so that this folder structure can be simply copied and modified for the next project.
By setting up such a standard approach it becomes easier for people to find the things they need quickly especially if working on several projects at the same time.
If you want to take this further you can introduce structured file names with numbering references. This can further help people to easily find documents within the structure. So, for example:
This approach will help you to know where to store items. And it will help you find them once they are in your filing system.
It won’t help you particularly with:
For the files which are just evidence or records of, say, a conversation, You do not need to bother to record a version.
But where a document changes, like your schedule or business case, you will need to
At its simplest, I would suggest adding a version number to the end of the file name so it becomes, for example:
[project name] P2 schedule v27.mpp
For more complex projects, OnlinePMCourses recommends a slightly more sophisticated version control approach – based on software version control. We advocate a two-part version number. The first part denotes major revisions. The second part, small revisions.
All version numbers should be two- or three-digits, using leading zeros. If the first part is 00, this represents a draft that has not yet received approval.
All documents under version control should have the full version number (or filename) in the header or footer of every page.
Some of your folders are going to get pretty busy. And you can’t guarantee that people won’t accidentally edit the last version rather than remembering to save it as V28 first.
But, if they do habve the discipline, you should be able to retain most of your key versions.
If you are running a formal Baselining or Approvals approach, you can also tag key versions so that standout in your folder, for example:
[project name] P3 schedule v08 – Approved and Baselined.mpp
Please Note: PROJECT in a Box has been discontinued.
We plan to update this article shortly. In the meantime, please consider this section to be purely illustrative.
Can we do better?
Of course we can!
As you might expect there are also specialist tools designed to help you with this challenge. They go by the generic name of a Project Management Information System, or PMIS.
Let’s have a look at Community Edition from PROJECT in a box,
It will help you collect, order and organise your project documentation and it is totally free.
The Community Edition of PROJECT in a Box isn’t one of those free trials that you put your effort into and suddenly find out you have to pay to continue.
Since its launch, fifteen years ago, the free Community Edition has been downloaded and used by over half a million users to organize their projects. It has been recommended by many training organizations and used on Degree and Masters-level Project Management courses at a number of Universities.
When you start a new project in Project in a Box, you create it from one of the method templates available in the system. Usually, you will use the one closest matched to the type of project you are going to deliver. Available method templates include:
When you create the project and choose a name, it sets up the set of template files appropriate for that type of project. In addition, it also creates place holders for the documentation you are likely to be working with. You can think of this as your starter project library.
However, and this is where it gets interesting, the system also sets up the common groupings of these documents that you are likely to need during the project. Depending on the methodology, this might be all the documents used in a particular process step or all the documents associated with planning or all the role definitions.
You use these groupings to navigate the project by clicking on them in a diagram. And the software then shows you an explorer view for that group of documentation.
So what that means is when you select ‘Project Concept’ you can see the Project Mandate (with template) and a placeholder for the documents you need to collect – in this case PM and Board communications. That is, just the content you need in that activity.
However, when you move onto the ‘Start’ process, you can see this content again but augmented with the next things you need, like:
The system holds the content once but can show it to you in multiple places. This contrasts with a standard flat-file system on your computer. There, if you want to see it in two places, you either have to duplicate it (dangerous to version control) or create clumsy aliases.
Likewise, later on, when you are closing the project, you don’t need to see the Mandate. So, you will be shown end project reports that you do need.
This approach is a much more natural way of interacting with the documentation. It removes the pressure of seeing everything you have to do to complete. Instead, the tool just gives you the bite sized chunks you need, for the stage you are at.
This approach also saves you having to hold a method in your head or to keep referring back to manuals or guidance about what comes next.
The software also handles all the detail of project document management. It covers:
When you acquire new content, you just open the document into which you want to place it, and drag and drop it in (or use browse). You can do this with any type of file you want. Community Edition will then keep a copy of that file for, you associated with that document. It will also record when you added it and you can keep notes about the document, like the source.
Any Project Document Management system must be capable of effective version control. PROJECT in a box works like a Document Management System (DMS) in this regard.
Any files held in the tool can be versioned including:
Users can either view or check out every file in the system.
Viewing a file gives you a copy to read, but you cannot to make changes to it. The version you get to view will always be the latest available one in the system. This file will be named to include the project name, file name and version number. That might seem trivial but, when discussing them at a meeting, knowing everyone is looking at the same version can be big time-saver.
And if you want to go the next step and change your file, you check it out. You can then make changes to your file and when you are ready you can check it back in.
Checking it back in will store that as a new version. There is no need to remember to change the file name. PROJECT in a box it does it all for you.
Next time anyone views or checks out that file, it automatically gives them the latest one. Of course, sometimes you want to go back and see an earlier version. You can track back through earlier versions and view them, but you can never check them out.
This is the essential configuration control of your files. It keeps you always looking at and working on the latest versions and will save you loads of time.
This is especially important with your registers or plans, which you will be updating very frequently. And the tool supports any file type. So you can manage your MS Project Plan like this or alternatively you can use the PROJECT in a box free project controls tool, Planner.
Projects get audited. But it need not be as traumatic as it might…
Well, not if you are prepared.
With PROJECT in a box, it will be no trouble now when you are asked to show:
Now you can find it easily in your folder structure. This confidence will go a long way in keeping your Auditor happy.
You have a choice:
PROJECT in a Box is a MS Windows application. So, once you install it to your PC or Laptop you can take it anywhere with you and it won’t need internet access to operate it. You can even make it portable and run it from a USB stick or zip it and email it to yourself if you want (you will need a windows OS to run it though).
If you are a MAC user, you can run it on Parallels or another windows emulator.
As Community Edition uses files you will always have access to your project files. You will not have fed all your project info into a proprietary system which suddenly erects a pay wall. If you have wish to, you can uninstall it anytime and still have full access to your files.
Paid versions allow shared access to files on a server, through browser or windows interfaces.
It is clearly a great idea to keep your project documentation organized. It will make your life easier and could be the difference between success and failure for your project. Like most things in project management, some foresight and planning will give you better results than just diving in. So, either use a strong folder structure and we have recommended or a tool like Community Edition.
We’d love to hear your thoughts on project document management. As always, we’ll respond to any comments you leave below.
Subscribe to get the latest posts sent to your email.
