* * *
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. Englehart
PrincipalDirector of Dispute Resolution Support Services
Construction Process Solutions, Ltd.
www.cpsconsult.com
No comments:
Post a Comment