Writing equipment specifications is a critical but often overlooked facet of every assembly project. Equipment specifications are a prelude to issuing RFQs and, with appropriate revisions, become part of the actual purchase order for the equipment.

Writing specifications is a critical but often overlooked facet of every assembly project. Engineers hate this task, finding it tedious and difficult. They believe it has little to do with engineering. As a result, they often do a poor job or don't write a specification at all. In reality, writing a specification is the best opportunity to do the most critical part of engineering, the part that anticipates and avoids problems. Engineers who take time to plan, to look at the big picture, and to communicate expectations will lay the groundwork for successful installation of a system that meets the needs of everyone in their organization.

What Is a Specification?

A specification is an engineering tool, a communication tool and a sales tool. Besides describing the equipment to be purchased, it must identify the needs of the organization as they relate to that equipment.

The first step in writing a specification, then, is to understand who your audience is and what their needs are. This process will enable you to incorporate solutions to their concerns in your specification.

Your audience is all the people who have an interest in the equipment: upper management, purchasing managers, project managers, project engineers, machine builders, product design engineers, and support staff, including operations, quality, facilities and maintenance. These people will have disparate concerns because of their particular niches in the organization. Upper management will want assurance that they're making a good investment. The project manager will want to know if the equipment will do what it's supposed to do, and whether the specification contains adequate detail to control the project's scope and budget. Operations will want to know how the new equipment will affect them. How many operators will they need? What training will be required?

You're an engineer, you say, not a writer or a diplomat. Don't worry. Writing a specification is mostly an engineering task. If you do the engineering right, and involve the other organizations in the process, you will succeed.

Developing Specifications

We've all heard the horror stories. Purchasing complains that the vendors don't have enough information to quote the equipment. Bids are received, but management "buy in" is not forthcoming. As soon as the contract is awarded, the vendor asks for more money to make the equipment meet minimal requirements. The equipment is installed, but it does not work. Operations complains that it's too difficult to run. Maintenance grumbles that it's too difficult to maintain. Quality protests that the equipment doesn't make good product consistently.

As the author of the specification, your goal is to avoid these problems. Of course, not even a perfect specification will solve all the world's problems. However, the one factor that is responsible for more of these problems than any other is a lack of up-front engineering.

Any engineer's job can be summarized as follows:

  • Determine the requirements to solve a problem.
  • Design a solution.
  • Document the design so that somebody can build it.
This job does not change for an engineer who is writing a specification. You need to determine the needs of the organization as they relate to the equipment, figure out what the equipment has to do to meet those requirements, and write down the thought process in the form of a specification.

When writing the specification, it will be a great advantage if you can build a team mentality with the stakeholders, including your vendors. If you involve them, they will be more likely to devote attention and creative energy to your needs. They will also give you their requirements up front--when you can get them on paper and engineer solutions--rather than tell you later as complaints.

With this in mind, begin your specification development process by identifying all the stakeholders in your organization. Make sure you talk to them early in the process. Get as much data as you can.

Then do some engineering. Figure out what the equipment needs to do. Don't worry about writing a specification yet. Limit yourself to diagrams, tables, charts and bullet lists. Prepare a presentation or summary document. This presentation should include:

  • The major requirements and objectives in bullet form.
  • A process block diagram showing inputs and outputs for each step.
  • A block diagram showing the controls requirements. (Make a separate one for hardware and software if there is a significant software component.)
Finish up by showing how the equipment will meet the requirements and objectives. Give a list of issues and unknowns that you or the organization need to work on.

Present this information in a meeting and record all feedback. If the meeting is successful, you will obtain lots of valuable information. You'll find that many of your assumptions were wrong, and your diagrams will be obsolete. This is good, because now you are getting somewhere. You will get another benefit, too: The people who attended the meeting will understand what you are trying to do and will care about the result. They'll be on your side.

Do some more engineering. Change your presentation based on the feedback from the meeting.

Now draft your specification. If you've done a good job to this point, the document will practically write itself. It's all right to leave a few unknowns and open issues. Just note them in the text.

Circulate the specification for comments. Getting people to read your document thoroughly can be difficult. Depending on the equipment complexity and the number of outstanding issues, it may be appropriate to call a meeting and walk people through the draft.

When all open issues have been resolved, you can release the specification to vendors for quotation.

Meet with the vendors and review their proposals. Often a vendor will have a good idea, but it doesn't quite meet the specification. Or, the vendor will have questions that require additions or clarifications in the specification. Once you've addressed their comments, circulate a new copy and obtain final bids.

After the contract is awarded, maintain the specification as new information surfaces. That way, you can use the document to build a thorough and objective test procedure for final acceptance of the equipment.

Content and Organization

You must keep in mind that a specification is a functional description of some equipment. It should describe what you want the equipment to do, while leaving as much latitude as possible for how to do it. The best way to accomplish this task is to think of the equipment as a black box and describe its inputs and outputs.

The core of any specification is a diagram of what the equipment will do. A top-level diagram will show the entire system as one black box along with the inputs, outputs and some key requirements. When you describe the inputs and outputs, make sure you include both material and control elements.

The top-level diagram is a worthwhile starting point, but it will not have enough detail to completely describe the equipment. You will need to create a second-level diagram that separates the equipment into its major functional pieces.

Two types of diagrams can be used for this purpose. The most common is the process approach. Break the process down into its component steps and put a block on the diagram for each step. Show the inputs and outputs for each block. A less common approach is the schematic diagram. This approach is best when the process is straightforward and the important task is to describe the attributes of the equipment. If you use this approach, make sure you divide the equipment into subsystems and label each one.

You will also need a controls block diagram. This block diagram should show the major control elements, what they control and how they interconnect. Once you have your block diagrams, you are ready to write the three sections that will form the meat of your specification. They are "System Overview," "Details by System Element," and "Control Strategy."

"System Overview" will contain the top-level block diagram and describe the inputs, outputs and top-level requirements. The top-level requirements include production rate, quality measures and layout requirements.

"Details by System Element" will contain the second-level diagram. It will have a subsection for each element of the diagram. These subsections will be similar in structure to the system overview. They will describe the inputs, outputs and other requirements for each element.

"Control Strategy" will contain the controls block diagram. This section should cover control functions, control panel layout and requirements, and safety interlocks.

As you write, think about how you will determine if the equipment meets the specifications. If you state a production rate, state how to measure it, over what time period, and how rejects and downtime will be handled. For processes such as welding or dispensing, state the quality measures you will use. Reference industry specifications if they exist.

Once you've written these three sections, you're ready to put them together as a specification.

Start with a table of contents. This will tell the reader where to look for specific information. Put all the information about a given topic in one place, and don't repeat parts of it elsewhere. This will make it difficult to remain consistent later, when you revise the document.

You will need to cover the following topics:

Equipment Purpose. A brief description of what the equipment will do and why your organization needs it. Upper management will read this section and the "System Overview" section, but probably no more.

Acceptance Testing. State the acceptance criteria and how they will be verified.

Documentation and Training. Describe what your operations and maintenance organizations will need.

Equipment Standards. Often you will reference other company documents, such as wiring standards, approved vendor lists, drawing standards, joining and fastening standards, and materials standards.

Interconnections and Mounting. It's important to state how the equipment will interface with other equipment, so the reader does not make incorrect assumptions. A drawing or sketch of any interface will be helpful. In many instances, you will be unable to precisely define the interface because the other equipment is not yet designed. In that case, you should identify the interface and describe it enough so the vendor can quote the interface, even if he doesn't know enough to design it. This topic can be dealt with in its own section, or as part of the "System Overview" and "Details by System Element" sections.

Definitions. You should define all technical terms that would be unknown to readers with a general technical background. This includes acronyms specific to your industry and technical terms that would not be taught in a basic college course.

References. It's a good idea to include a section that lists all reference documents. This includes parts drawings, layout drawings, company and external standards, and other documents referenced in the specification. If the referenced document is likely to change often, such as a part drawing, it's a good idea to specify "most recent revision" rather than the actual revision level, so you don't have to change your specification every time someone makes a minor drawing change.

Think About Style

You should choose a writing style that is precise and unambiguous. It's OK to be boring. In fact, you should deliberately be tedious and detailed. People are not reading your specification for fun. They are reading it to obtain information.

Make it a habit to use the word "shall" whenever you want to require something. Use "will" when describing external factors. Avoid "should," because it implies that something is optional. Describe the requirement for an option as: "The vendor shall provide an option for..." Describe a preference as: "The equipment may include either A or B; A is preferred."

You should repeat words and phrases rather than use pronouns. This will eliminate the largest single area of potential ambiguity.

Number all paragraphs. You can use your computor to generate paragraph numbering automatically.

Keep the document under revision control. Whenever you make changes, note them in a revision control section. To keep your numbering intact, replace deleted sections or paragraphs with the word "deleted." If you add paragraphs, add them at the end of the relevant section or subsection so that previous paragraphs are not renumbered.

Finally, keep it simple. If you find it difficult to describe something clearly in a few sentences, you're probably trying to be too detailed. Ask yourself if you are describing the function, or if you're trying to tell the reader how to solve the problem. If it's the latter, then you've strayed from specification activity into design activity.

If you're uncomfortable with controls, a control engineer can help you create one. If you follow this approach, you will discover that you can enjoy writing a specification!