* * *
How Should We Go About Documenting Our Project?
A Pound of Bologna or that 4 Oz. Fillet??
How many times have you heard, “We didn’t document that project well enough?” Such regrets are typically aimed at the lack of stacks of documentation. However, quantity does not equate to quality, and often times, in the interest of a perceived desire for pushing as many e-mails through the pipe, the project team loses sight that the quality of the documentation is more important.
What is meant by referring to “quality?” There are 4 primary characteristics that a project player should consider when considering a project’s plan for documentation, as well as when considering what, when, to whom, how, and in what “form” a particular piece of documentation should go out:
· The substantive nature of the documentation.
· The documentation’s conformance with the contract requirements.
· The documentation’s conformance with the “big picture” risk profile.
· The documentation’s form and how effective it can be used in a forensic setting.
The content of the documentation should be factually accurate, sufficiently comprehensive, but the aim should be for brevity. Avoid positions in documentation. There are certainly times when positional communiqué need to occur, but such communiqué themselves should rely upon quality documentation. As a particular practical tip, a common oversight in the preparation of documentation is to focus on what is occurring, as contrasted to, or perhaps complimented by, registering what should have been occurring, but couldn’t and why.
The documentation must strive to conform to the contract requirements. It is particularly galling to incur the emotional and real cost of producing documentation, only to see the effectiveness significantly undermined because of a failure to conform to the contract. In order to do so, the first step is to read the contract. Not surprisingly, most project level players fail to review and gain an understanding of what the particular project’s documentation requirements may be. Upper level project management (particularly those charged with P/L and risk management) should provide an abstract of the contract’s requirements and ensure that the organization’s processes and protocols can be molded to fit those requirements, and that those documenting the project understand what those requirements are. Don’t fall into the “This is the way we have always done it” trap.
Before drafting that e-mail (and certainly before hitting the “send” button), or before filling out that daily log, documenters should take a breath a read what they are proposing to write and think how it will read a year later. Superintendent and foremen daily logs are often rife with complaints about their own company. Needless to say . . . those come back to haunt them.
Finally, if the documentation is so cumbersome and expensive to retrieve and use, then all the time and effort in preparing it is wasted. As part of an organization’s risk management plan, the use (and power) of technology should be considered. Handwritten daily logs, while perhaps tradition, and clearly served a purpose 30 years ago, are often illegible, incomplete, incoherent, and require a monumental amount of time and resources to be useful in a forensic setting. Innovative (and intelligent and appropriate) uses of ubiquitous programs such as Excel should be considered. (Note: Excel is essentially a data base compilation application. However, to utilize its robustness, the user must recognize the importance and power of entering individual types of data into individual cells, and doing so in a consistent fashion. In other words, it should not be used as word processor.)
Documentation is a key part of any risk management program. However, the difference between an effective risk management program and one that fails is the quality of that documentation and not the quantity produced.
“It is quality rather than quantity that matters.”
Lucius Annaeus Seneca
Andrew T. EnglehartPrincipal
Director of Dispute Resolution Support Services
Construction Process Solutions, Ltd.