The Importance of Good Specifications

Problem: Poor Specifications Create Problems Later

A contractor, consultant or supplier can only price and deliver the requirements that they understand.
If your specification can reasonably be interpreted in two different ways, don’t be surprised when the contractor chooses the interpretation that is easier or cheaper for them.

They may genuinely believe they are complying with your requirements.
You may genuinely believe they aren’t.

Both parties then spend time arguing about something that should have been clear before the contract was awarded.

Unclear or Contradictory Requirements

Unclear specifications create Requests for Information (RFIs), clarifications, meetings and delays.

Contradictory specifications are even worse.

One part of the specification might say one thing, a drawing says something different, and another project document contains a third requirement.

Which one is correct?

If you haven’t clearly defined this, you have created an argument waiting to happen.

You can also end up paying for it.

If the contractor has reasonably priced their tender based on one interpretation and you later tell them another interpretation was intended, they may have a valid reason to request additional time or money.

This is closely related to the same problem I discuss in Make Clear Definitions. If you use terminology, abbreviations or technical definitions that could be misunderstood, define them.

Don’t assume everyone reading your specification has the same knowledge or interpretation as the person who wrote it.

Outdated Specifications Standards and Codes

Another common problem is reusing old specifications.
This is very easy to do.

You have a specification from a similar project completed six years ago. It looks pretty good. Rather than starting again, someone copies it, changes  the project name and issues it for the next project.

Unfortunately, the requirements around it haven’t necessarily stood still for six years. 

• Standards may have changed
• Company requirements may have changed
• Equipment may have changed
• Technology may have changed.
• Legislation, building codes or regulatory requirements may have changed.
• Your clients expectations may also have changed.

I used to say that if a specification is more than five years old, it is probably outdated. I would refine that slightly now: If a specification is several years old, treat its age as a warning that it needs a proper review rather than just assuming it is still correct.

For Australian projects, check the current status of referenced Australian Standards through the Standards Australia catalogue. 

Where building work is involved, also confirm the applicable National Construction Code requirements and any state, territory or local variations.

For projects in the USA, as far as I can tell there is no single organisation that publishes every standard. ANSI coordinates the US voluntary standards system, but standards are developed by many organisations, including ASTM International, ASME, NFPA, IEEE and UL Standards & Engagement.

US building codes add another wrinkle. I believe model codes such as the I-Codes only become legally applicable when they are adopted by the relevant state or local authority, and that authority may adopt a particular edition with amendments. The International Code Council explains the adoption process.

So don’t automatically substitute the newest publications for the edition named in the contract or adopted by the jurisdictions. Check three things: the current publication status, the edition contractually specified, and the edition legally applicable at the project location. If they differ, resolve the conflict before issuing the work.

A simple example would be a specification requiring electrical wiring to use a particular colour, while the applicable current or adopted requirements call for something different. If you issued the outdated requirements to the contractor, they might quite reasonably install what you told them to install.

You then discover it needs to be changed.,

Who pays?

At the very least, you have just created a problem that could have been avoided by checking the specification before it was issued.

Incomplete Specifications

A specification also needs to include enough information for the contractor or consultant to understand what they are expected to deliver.

Depending on the type of project, missing information might include:

• P&ID legends
• Line types
• Drafting requirements
• Drawing standards
• Required deliverables
• Required document formats
• Equipment requirements
• Material requirements
• Performance requirements
• Flow rates
• Production rates
• Testing requirements
• Inspection requirements
• Hold points
• Required standards and code editions
• Required completion dates

I discuss the importance of explicitly defining dates separately in Specify the Due Date of Project Deliverables.

If information is missing when the work is tendered, the tenderer may not allow for it.
You then provide the missing requirement after contract award and discover they want more money or additional time.

You might have a contract clause saying: 

“The contractor must comply with additional specifications provided by the client.”

That may give you some contractual protection, depending on the contract. But it doesn’t make good project management. If the contractor needs the information to correctly understand, price or schedule the work, give it to them before they submit their tender wherever possible. You will get a better overall project outcome.

Specifications That Aren’t Actually Supplied

This is one of my pet hates.

A tender package refers to:

• The organisation’s standard electrical specification
• Standard mechanical requirements
• Drafting standards
• Painting specification
• Approved equipment lists
• Standard testing procedures

But none of those documents are included with the tender.

Instead, the tender says something like:

“Available from our website.”

Sometimes there is a link.

Sometimes the link doesn’t work.

Sometimes it points to an old version.

Sometimes finding the specification on the organisation’s website requires the investigative skills of Sherlock Holmes.

I have found that many contractors simply won’t go looking for all these documents.
Others already have a copy from a previous project and assume it is still current.
And some will assume that if the document wasn’t important enough for you to include in the tender package, it probably isn’t particularly important.

Don’t create that opportunity for misunderstanding.

If a specification applies to the work, preferably include the specification in the tender package.

This is particularly important for internal company specifications that the contractor cannot easily obtain elsewhere.

Even if the contractor has previously worked for your organisation, send the current controlled version again.

The Same Requirement Appears in Multiple Places

Repeating requirements can also cause problems.

It might seem helpful to put the same information in several places so nobody can miss it.
The problem comes six months later when someone changes one copy but forgets about the others.

Now you have:

• Specification section 3: 200 microns
• Specification section 8: 250 microns
• Drawing note 17: 300 microns

Congratulations. Your attempt to make the requirement extra clear has made it three times less clear.

Where possible, define a requirement once and refer back to that requirement from other documents.

If the project documents could still conflict, include a clear order of precedence explaining which document takes priority.

For example, your contract might define an order such as:

1. Contract conditions
2. Project-specific specifications
3. Drawings
4. Standard specifications
5. Referenced standards and codes

That is only an example. The correct order will depend on your project, contract and jurisdiction.

The important point is that there should be an agreed way of resolving conflicting requirements.

Australia’s NATSPEC and the US-based Construction Specifications Institute’s MasterFormat are useful specification systems and organisational frameworks. But neither replaces the need for a project specific precedence clause in the contract documents.

As project manager, you also need to understand any precedence rules in the documents your client has given you.

Don’t wait until a dispute to discover which document supposedly overrides another.

Following a Bad Specification Without Questioning it

There is another side to this.

Sometimes you are the person receiving the specification.

The client gives you a scope or technical specification that contains a mistake, is outdated or specifies an unnecessarily expensive solution.

You could simply say:

“That’s what the client asked for.”

Then design or build it exactly as specified.

I don’t think that’s good project management.

• If you can see a better, safer, faster or cheaper way of achieving the client’s objective, tell them.
• If you believe their specification contains an error, tell them.
• If an old or inapplicable standard or code edition has been referenced, raise it.
• If two sections contradict each other, ask for clarification.

Good clients generally want to know if there is a way to get a better project outcome or save money.

The important thing is not to quietly change their requirements yourself.
Raise the issue, propose the alternative and get the agreed change documented.

As I discussed in Document All Client Communication, important clarifications, instructions and agreements should be recorded rather than relying on someone’s memory of a conversation.