"Oh yes, and don't forget to put mortar between EACH and EVERY brick"

...in fact it shouldn't have to contain instructions to thoroughly test the system before reporting substantial completion

All writing has a target audience, whether it's your local newspaper or this trade magazine (assuming you aren't reading this magazine after finding it in a dentist's office and wondering what the heck we're talking about), there are certain assumptions made about the reader by the writer of any material. Those assumptions include a certain degree of shared knowledge and understanding of the context and content of the material by the target audience. By making those basic assumptions, the written material need not contain all the background information for reference. For example there's no expectation that a regular reader of Better Homes and Garden will equally enjoy Scientific American. A technical specification contract document follows the same assumption.

For the general building trades, the specification sections are often very short and almost skeletal in their content. Building materials are very much standardized and the methods and materials are often highly regulated, or at the very least they have a substantial history which eliminates the need to tell the masonry contractor "Oh yes, and don't forget to put mortar between EACH and EVERY brick". The general building trades also have something else going for them, a moderately consistent standard of training and licensing in those fields, which means the specification writer can have some degree of confidence that every electrician has the same basic knowledge, and barring a bout of excessive partying the night before that they will consistently provide the same basic skill level throughout their work, whether it is connecting breaker panels, or wiring switches and outlets, their work will meet code when done.

The specification sections for our zany, rapidly changing industry; the world of convergence and high tech, tend to be very big, and very detailed. No matter how detailed the specs get, it seems there is a need to always make them bigger and more detailed to plug loop holes where the expectation of having a shared knowledge base and a common understanding of the technical approach fails. In short it seems we often have to specify that mortar must be used between each and every brick.

There seems to be a general industry problem with expectations of the specification and what it should contain. Or there is a problem with the assumptions of the shared knowledge base of the readers of the specification by the writers of the specification. I'd like to toss out some ideas, and I am hoping that it generates some discussion (I'd like it to stop short of flaming email, but some nice reasoned discussion would be good).

First let's look at what a specification isn't. A specification is not a step by step guide on how to break into a new field of contracting. There should be no expectation that a specification document will have enough detail in it to show a contractor how to implement a technology that is new to them. A specification is intended to be read by someone who is already versed in the technology, terminology and methodology. It shouldn't have to contain instructions on how to make good solder joints, or how to strip and dress cable when terminating cables (unless there is some unusual practice required), and in fact it shouldn't have to contain instructions to thoroughly test the system before reporting substantial completion. The specification shouldn't have to describe how to do a good job of contracting and installation, that should be part of the shared knowledge assumption. Phrases the consultant never wants to hear include: "We never allow time for testing in any of our other projects," or "We didn't allow the time for shop drawings do we really have to do that?" This begs the questions: How do you know you are done if you don't test the systems? How do you instruct your crews to do the work if you don't normally do shop drawings?

There are some items that are almost impossible to realistically specify in great detail. Software operation is one of them, whether that is control system software or equipment setup and operation software. High level functions and requirements can be specified, such as general relationships between system states and the routing etc., but the specification document would be the size of a phone book if a consultant tried to specify the total interface between every aspect of the software and hardware. Even in writing specs for software (for software companies to respond to) there is a difficulty in specifying every possible snake and ladder required in all the operations. At some point the specification writer has to assume that the contractor will have enough knowledge in their field of expertise to recognize the goal, the required approach, understand the relationships described, and then be able to respond appropriately.

There are many aspects of software that are so complex to describe, that it would be quicker to just do the programming. There is a definite limit to the data compression available in passing along information from writer to reader, and it is often the case that it would take longer to describe an operation than to do it. This is where the shared knowledge base is critical. It should never be necessary to describe the step by step instructions of how to start a computer and run the software, connect to the device, ensure that they communicate and then program the device, etc. At some point, the contractor responding to a specification has to understand what the scope of work is, and if they don't, then perhaps they should either pass on responding, or seek some training to acquire that shared knowledge base. (Recognizing that there can be badly written specifications out there, and those may come from many possible sources, if they appear to rely on a shared knowledge base from another planet, or another industry, then perhaps it is wise to pass on responding to those specs as well, strictly as a shrewd business plan.)

...the specs could be much more detailed, but as they get more detailed they have to exclude more and more alternate products...

...the last thing you want to do is find out you won because you forgot to add in $10,000 worth of gear or labor

This applies to other technical fundamentals such as loudspeaker cluster construction and alignment, building and refining the system gain structure, electronic and electro-acoustic test and measurement, etc. The specification document is not intended to be a step by step training course in how to do these types of installations. The understanding of these elements HAS to be part of the shared knowledge base that's assumed to exist with all contractors. It's in these areas where technology convergence is showing its most threadbare spots, many contractors crossing over from other fields don't have this shared basic knowledge.

A specification is usually not a definitive itemized shopping list of all the equipment necessary (except in rare cases) as most specifications allow alternate or equal products that have different requirements for interfaces to each other and to other systems. There is always a conundrum here, the specs could be much more detailed, but as they get more detailed they have to exclude more and more alternate products since the greater detail can usually only apply to one particular product. Where there is more than one viable alternative, the specification can't be extremely detailed. Take a simple thing like control systems, there are two major manufacturers that have essentially equivalent functions, and yet the actual hardware count and configuration can be different and still deliver the same result. The hardware will also be dependent on which external devices the contractor chooses, and which interfaces are required (RS-232, IR, switch contact etc.). So there is often type approval but the exact layout of the system and component selection and count is up to the manufacturer and contractor to determine. If one product were selected and no alternates were allowed, then extreme detail could be provided, but that would not generally be in the client's best interest.

A specification should be a very specific description of the expectations of system function, system features and system performance. The combination of the written document and associated drawings should clearly describe the expectations of the specification writer (and with any luck, the owner). Where it is unclear, it should be questioned for clarity PRIOR to bidding, if there is no clarification as a result, it is either a problem with a lack of shared knowledge base, or the design is just inherently unclear, either way it should be a danger sign to the contractor, just nature's way of saying "RUN FOR YOU LIVES!"

The time for a contractor to be thorough about reviewing a specification is prior to bidding, not just after winning. This means that you can't wait until the night before to have a good look at the specification and hope to get a good understanding of what's involved. The contractor should never assume that there is nothing of interest in the "boiler plate" that makes up the conditions and criteria. This is the part of the document that has all the real gotcha's in it; the requirement for all work to be done between midnight and 6AM; or for a very tight time frame that will require lots of overtime and air freight; or that a large performance bond is required. Never assume the boiler plate is of no interest, and just jump straight to the hardware list and drawing.

I would strongly recommend that a financial officer in the contracting company review the document section by section, and initial each one, noting which ones may impact the bid price. Then the technical guys should go through the entire document, read each section that pertains to conditions of doing the install (do your installers need security clearance and can any of them get it?), initial each one and then charge into the hardware. After that, the techies and the financial types should sit down and compare notes about the gotcha's before developing a bid price. And ask silly questions, it is a lot easier to deal with silly questions than silly mistakes. Oh, and double check the adding before you finalize the totals, don't assume that the spreadsheet never makes mistakes, ensure that all your fields and subtotals are included in the total, the last thing you want to do is find out you won because you forgot to add in $10,000 worth of gear or labor.

It is important to understand that the consultants aren't trying to get contractors to bid to lose money. In fact what we hope to see is that contractor will make enough money on the job to take ownership of the project, and the client, so that the reason they will do a good job of the installation is to secure the client as a long term customer. In that respect the systems consulting business is different than the other building trades, an ideal outcome of what we do is more like match making, the systems contractor is likely the only contractor involved in a project that will have a relationship with the client after the warranty period is over. Most other building trades that do new construction are interchangeable with any other trade contractor. One electrician or plumber is pretty much like any other, but the systems contractor could have a long relationship with the client (and hopefully not because of extensive warranty service requirements). For the contractor to place themselves in a position to have that happens requires an understanding of what the specification document is and what it isn't. It also means that the contractor has to make sure they have the shared knowledge base that makes this process work.