Project Design: Drawing Up Documentation
As a project develops through its lifecycle, changes will come about. Shifts in client requirements or budget, site restrictions and superceded equipment all have a part to play. Where previously we looked at how to manage and document these changes, here we will look at how to correctly document these revisions on the design drawings.
It is good practice whenever changes are made to design drawings to highlight the parts that have changed with a revision cloud. This helps the other stakeholders on a project quickly and easily see what has changed and assess the impact these changes may have on areas of the project they are involved with.
The changes are also documented in the revision version block, in the main drawing title block. Including the revision number, a brief description of the change and the date the drawings were revised.
Standard revision stages or versions follow the P T C system:
Preliminary with revision numbers P1, P2, etc. These documents would be the first draft or issue and are highly likely to need revision once reviewed by the other stakeholders on a project. They might also be marked with not for construction.
Tender with revision numbers T1, T2, etc.
These documents are at a stage where they have been reviewed and agreed upon by all stakeholders. They are the documents used for companies to bid for a project on. This stage is often not required if the AV company producing the drawings has already been contracted by the client.
Construction with revision numbers C1, C2, etc. These drawings are the final agreed set that the project will be built from. They should be fully co-ordinated with all the other trades working on site to ensure the minimum amount of changes are required on site during the build process.
Commonly the final revision number of the construction stage will be record drawings which show things exactly as they are built in reality. This can often differ from the original construction drawings and as always revisions should be clouded to illustrate what changed from the original design. This revision can sometimes carry a different stage letter R for Record but it is generally contained within the Construction stage as it relates directly to this and there tends to only be one as built or record revision.
It is also common practice that the notes of the revisions made are removed when the Stage moves on from one to the next. This keeps a clear set of revisions made during each of the stages of drawing revision and means that a final set of drawings from each stage should be kept on file as a complete record of how you arrived at the final design.
Revisions should be clouded to illustrate what changed from the original design.
Of somewhat greater importance than correct revisions, the approval of a particular revision of a drawing must be made before it can be released to other project stakeholders. Approval implies that the Approver takes responsibility for the content of the revision of the document. This responsibility is often shrugged off by the use of alternative terms such as "No Comment" however the effect of this often raises arguments about liability further down the line and therefore should be avoided.
The most common method of approval is the A B C status, where:
A is the highest level of approval meaning that the Reviewer can find no problems.
B is a mid-level of approval meaning "Fit for construction or manufacture subject to the notes supplied"
C is the lowest level of approval meaning "Not fit for construction or manufacture".
Approval of revisions should always be carried out by someone other than the person who revised the drawings. It may seem obvious but it is important that the approver is able to look at the revisions from a clear perspective, unhindered by the knowledge of what was required by the actual revision or how it was achieved.
My intention with this and the previous column was to help integrators get a solid footing in the constantly shifting sands that can be an AV project. Revising projects accurately, quickly and clearly is the goal and the aim is simple; to record who said or issued what, when, why and how. This is the key to keeping all the profitability you started out with, still in the project when it reaches completion.
Keith Jones studied Product Design at Central St. Martins where he graduated in 1996. Since then Keith worked in numerous high end audio outlets, culminating in owning and running his own AV installation company from 2001-2008. After a career break he started Jones designs in August 2009 which has recently morphed into a Ltd. company called designflow, with his business partner Kelly Ashforth. Designflow aims to increase awareness of design in AV and help installers win jobs and create proper documentation for them.