If you asked anyone in my team of project managers – who are some of the best in the country and between them represent the full range of ages and experience levels – to do something as simple as document a discussion or write Minutes of Meetings, you would very likely be met with a  glare. Soon that glare would turn ugly, with heated arguments and debates…. and if you insisted on introducing a document management system, the threat of somebody quitting would rear its head. I’m not exaggerating.  Adopting Documentation Management Systems, whether manual data entry or easy-to-manage automated systems, has always been seen as a big change, and changes are tough.

While all of us know the consequences of poor documentation in an abstract  theoretical way, I don’t think we fully realize the very tangible and immediate damage it can do. Perhaps that’s why on a day-to-day basis project documentation is left to a “third party” documenter, or worse, left to…well…“later”.

So how do projects get affected by the lack of a proper document management system? How do they end up delayed and/or mismanaged? Let’s look at a few points:

Establishing the Scope of work:

The Scope of Work (SOW) is a very vital document. Without a detailed SOW document we could not identify the various components of a project, nor start activities. Furthermore, the entire responsibility matrix assigned to resources would not be valid without understanding the battery limits and creating a proper individual scope boundary. Being lackadaisical about documenting this ever-important document can become a cause of delay right at the initiation of the project, like a wrong or prolonged start, and then the 100-meter dash to the finish is lost. I’ll give an example from my own experience. One of my projects mentioned renovation works as a scope without giving any more details. We got ready for the change in the Interior works for the project, we resourced accordingly and scheduled ourselves accordingly, only to realize at kick-off that the project interiors had very minor changes and the majority of works were about a structural change! Our team, schedule, and resourcing all had to change. What a blunder. The lack of a proper scope document caused so much embarrassment and headache.

Version Control

A project has many stakeholders, each producing many documents as soon as the project goes live. The Architect / Designer has his list of hundreds (at least!) of drawings, the Project Manager and Procurement Manager have their own documents, and so on down the chain of command. Think of the confusion if all those documents were not properly documented and organised! In fact that is exactly what happened to me:  one of our projects was getting delayed due to a specific item (which was not critical a few weeks prior), namely, the lack of a certain type of tile in the cafeteria. As the item moved into the “Red” for delivery, all the managers put their heads together until one of the site supervisors brought out a drawing for all of us to discuss. When we all found out how easy it was to just order the different type of tile, which as it happened was available off-the-shelf, we checked with the architect. To our great surprise we realized that he had made the change weeks ago but the latest version of his changed drawing was not available with the site supervisor, who was still referring to the old version. What a costly mistake, not to mention the loss of face for the Management team.