Using Schedules to Make Life Easier

By
Friday, April 17th, 2015
liked this article
Embed
Dulux Exsulite Architecture – 300 X 250 (expire Dec 31 2016)
advertisement
documentation
FavoriteLoadingsave article

As architects and designers, we all use schedules, legends and abbreviations (SL&A) with good intention. We want their use to both make the task of documentation easier and make the documents more readable.

This intention is to be expected of good documentation practice, but there are some practices in the use of SL&A which actually do the opposite. I believe this occurs a lot more than we should be comfortable with.

It is not only the builder and subcontractors we hinder when we unintentionally document poorly. We hinder ourselves, and not just in hindered production and reading of our documents, but in the possibility of things going wrong on-site, ranging from builder and subbie frustration and loss of confidence to document misinterpretation.

If you are guilty of one or more of these deficiencies, put ego aside, be honest with yourself and simply act to correct them. Many of these things can be fixed quickly and you will receive immediate benefits from the resulting improved documentation and document interpretation.

General Tips

  1. Schedule Layout: Put the limited variables across the top (usually the items the schedule is about) and the very long list of variables down the page (like the list of rooms or locations) where you have unlimited listing space.
  2. Schedules are for quick reference and should be minimal and brief (a quick find tool of basic information.) The specification contains the detail.
  3. If absolutely necessary, give a cross reference where other related detail on that item is. Note that if other related detail is in an obvious place, no cross referencing is needed. The builder should know what is in the contract documents.
  4. A4 size schedule headers/footers need to have a title, be page numbered X of Y in the bottom RHS of the page (if the hard copy document is dismantled, a reader will know what is required to have a full document), include the architect/project name, and schedule revision number.
  5. Detail applicable only to that schedule should be in the schedule. For example, a colour schedule gives only colours, an internal room finishes schedule gives only finishes (note: details such as painted plasterboard, and the concrete block wall behind it should not be included – it is on the plans and it is not a finish.)
  6. Showing fixture photographs are not necessary in contract documents although they can aid visual scanning.  If they are to be used, they should show the fixture only and not a photo of the fixture in place in another building – you may find that parts of that other building may get built into your job.
  7. Avoid using an ‘Everything All’ schedule. A good example is the good old ‘Fixtures, Fittings, Furniture, Fabric, Finishes Schedule’ – having everything lumped together makes things very hard to find.
  8. Separate your door and your door hardware schedules. Avoid double up like scheduling door swing (already on the plans) or door thickness, which should be in the specification.

Avoid Landscape Page Format

  1. Landscape page format forces the need to constantly turn a hard copy specification 90 degrees to read schedules (often a schedule is attached to and read in conjunction with the spec.)
  2. Portrait format allows twice as many pages to be spread across a desk, which aids documentation production.
  3. If landscape format is needed to fit the information, too much information is being scheduled (remember this is a quick find tool for basic information.)
  4. More information per page can fit onto portrait format (more lines occur down the page.)
  5. Stapling landscape double-sided pages is difficult to read when printed double sided.
  6. Hard copy landscape format file search is more difficult, with text 90 degrees to portrait format.

Legends

  1. Legends are for quick reference and should be minimal and brief. They should not replace all drawing notes. Large legends increase both drawing and reading time and become a burden.
  2. Legends are best edited for and located at the specific documentation part. Remote legends (legends not on the page that has the original abbreviation) greatly increase reading time. A4 size schedule legends can occur at the top of each schedule page in the header part.
  3. Universal legends (often put on drawing cover sheets) can promote a lot of confusion because often no one takes the time to edit them, so many items scheduled are not actually part of that job.
  4. Don’t put legends into categories (especially when grouped on the same page or sheet.) A reader has to memorise the legend item, go to a legend, then instead of just going to the alphabetical listing, they have to negotiate a number of categorised legends, so they have to stop and think of where the abbreviation came from, then make a deduction on which category they need to go to, then if not found, re-start the whole confounding process. The reader may even forget the abbreviation and have to go back to the drawing being looked at to find it again.

Legend abbreviations

  1. Abbreviations need to be minimal and quickly identified (for example, use T1 and not TFT1 to denote Timber Finish Type 1) and should be commonly understood (e.g. FC – Fibre Cement [not Filing Cabinet.])
  2. Abbreviations for detailed items should occur where the detail occurs (for instance, different glass type abbreviations should occur on the window schedule, not on the 1:100 elevations).
  3. Maybe it is best to write on the drawing what the item is. For example, write “flashing” instead of “FLSG.” This prevents wasting everyone’s time by putting that in a legend, especially when that legend is not on that page.
  4. Last but not least, if you use an abbreviation, put it in a legend. I would guess at least 50 per cent of the time when I am reading others documents, and I look for an abbreviation in a legend, it is not there!

This list is by no means an exhaustive list, but I think you will understand the principles here.

It is challenging to get really tight documentation (and impossible to have perfect documentation), but it is doable for all of us.

One error can be a nuisance, then subsequent errors can start to erode the contractual relationship.  Before you know it, you have a fight on your hands and no client will refer you on, let alone come back for repeat projects, if a contract has been marred by dispute.

Embed
FavoriteLoadingsave article

Comments

 characters available
*Please refer to our comment policy before submitting
Discussions