Engineering Management Concerns About Specifications

  1. Cost Growth
  2. Contracts
  3. The specifier's authority
  4. Constructive changes
  5. Who is responsible for losses from errors in specifications?
  6. Statements of work versus specifications
  7. Organization
  8. Citing specifications and standards
  9. Performance vs. Design Specifications
  10. Quantities must be clearly denoted
  11. Verification of requirements
  12. Tolerances
  13. Warranties
  1. Unbounded tasks
  2. Government Furnished Equipment and Information
  3. Conflicting requirements
  4. Impossibility of performance
  5. Agreements-to-agree
  6. Commercial and Non-Developmental Items
  7. Hazardous materials
  8. Approval and authorization
  9. The Contracting Officer
  10. Data requirements in Specifications and SOWs
  11. Time pressure and professionalism
  12. Property disposal

Cost growth

no cost growth

The main objective of specification writing is to get the project done with as little cost growth as possible. Cost growth shows up as Engineering Change Proposals (ECPs), Requests for Equitable Adjustment (claims) and modifications to recently bought items (mods). Some ECPs and some mods arise legitimately from changing mission requirements.

Many, however, arise from time pressure and inattention to detail in the project phases prior to contract award. Claims often happen because of inattention to administrative matters during the contract, and because of disputes over the meaning of the specifications.

Engineering projects build upon the work as it is completed, much as a building is built from the ground up, starting with the foundation.  When an error is made, the cost of correcting it is greatest when it was made early in the process and not discovered until subsequent work has been done.  The earlier in the process that the error was made, the more work has to be done over.  This is why we must pay very careful attention to project planning and specification writing: they are the foundation for all the rest of the work.

The worst possible cost-growth situation occurs when a contractor pursues legal action like a contract appeal or a lawsuit. Care in specification writing is one of the most important measures an engineer can take towards preventing such situations.

Before you write the specifications, find out all the details you can about what your product should do and what it should not do.  Also find out what materials and methods the manufacturers may use to make the product.  Determine for certain that what you are going to specify is doableArmed with good up-front engineering information, you should be able to prepare a good set of specifications and a credible cost estimate.

While on the topic of cost estimates and cost growth, I should point out that properly preparing a cost estimate is a very important a part of cost-growth prevention.  The reason is simple:  the cost estimate is the baseline.  If you estimate too low, then your cost growth will be that much greater.  Estimates tend to run low because estimators are more likely to overlook some cost elements than they are to include elements that are not really necessary.  The moral is to be thorough and try not to overlook anything.


A contract is an agreement between two parties involving the mutual exchange of some things of value, known as "consideration."  Ordinarily it's simply money in exchange for some goods or services, but sometimes it defines a complex set of duties and compensation for both parties.  Such is most often the case in engineering contracts, of which the specifications are the core.  When you write specifications, you must therefore be aware that you are writing a contract, which is subject to a stringent set of concepts and rules.  Consequently, you should keep the following contract fundamentals in mind when drafting your specifications.

Your contract will be presumed complete at the time of contract award.  If you've inadvertently left something out and want to add it after contract award, you will have to negotiate a supplementary agreement and furnish something, like more money, to your contractor in exchange.  Explicit requirements to agree about something at a later date violate this principle.

Changes to contracts are never unilateral.  The only exceptions are rare situations in which the Government has to use its sovereign power to respond to an emergency.  Even in those cases, both parties have to sit down later on and agree upon equitable compensation.

Also presumed upon contract award is the unlikely fact that both parties fully understand and agree upon all the words written in the contract.  The truth with engineering projects is often that neither party fully understands what work has to be done until the work is actually under way.  Only then do myriad details become evident, and only then do we find out that the contractor had interpreted some of our words differently from what we had intended.

Whose interpretation prevails?  The rule is that the contractor interprets the specifications, as long as the interpretation is reasonable.  The Government is responsible for furnishing sufficiently clear and complete language to evoke the intended understanding in the reader, and the Government is also responsible for any expenses that may be incurred if the contractor does not interpret the specifications as intended.

By the way, legal authorities like the courts and appeals boards are usually very liberal in deciding whether or not a contractor's interpretation is reasonable.  If there is any way at all to read your words differently from what you intended, then there is a chance that a contractor will choose it and later on require redirection in the form of an engineering change.  Occasionally one will encounter contractors who take full advantage of their power to interpret, as it provides them with more profit than by merely doing it right the first time.  In such cases, there are three elements of cost:  first, doing the work incorrectly, then undoing what was done; and finally, redoing the job correctly.

The specifier's authority

Here we have a civics lesson that deals with a topic fundamental to all modern forms of government:  limitations on the authority of officials.  It summarizes the essential difference between writing specifications for public contracts and writing them for private-sector work.  Public policies imposing limitations on the authority of officials were developed in order to prevent the kinds of corruption that prevailed under the feudal system.  Abiding by those policies is among the most fundamental of our responsibilities as government workers.

As you probably know, the actual authority to obligate the Government contractually is held only by contracting officers, and the actions of those officers are very tightly constrained by extensive regulations.  The work we do as acquisition engineers is actually in support of those contracting officers.  We attend to the complex technical details while they take care of the complex legal and administrative details.  By being delegated such responsibility, we also make a lot of decisions that affect the scope of the work to be done by contractors and the duties that must be performed by the Government.

Along with this bit of delegated authority come the necessary limitations.  For example, government engineers have authority to specify only minimum, essential, validated requirements.  Such requirements should always be traceable to higher-level documentation, and should always be defensible in concrete terms of need.  That means you can't specify a performance or design feature just because you think it's nice to have or is the latest and greatest thing to come from the vendors.

There are numerous other limitations on what and how we are authorized to specify.  In general, the following things are forbidden:

Regarding duties that must be performed by the Government, there are often cases where creating Government obligations within the specifications may unnecessarily shift risks back to the Government.  Those are situations we engineers are responsible for avoiding whenever possible.  When we needlessly agree to send equipment or information, or to complete some task on schedule, or make a promise of any kind, we've incurred an obligation, and fallen short of our responsibility. If we don't deliver as promised, the Government will take the blame for missed schedules and cost overruns.  If you intend to make such obligations in your specification or statement of work, be sure that you are truly authorized to do so, and that your contracting officer is made aware of them.

Constructive changes

The term "constructive changes" comes from the legal usage of the word "construction," which pertains to determining the meaning of language.  A constructive change happens when a contractor has read some specifications and decided upon how to comply, and then the customer decides upon a different interpretation, forcing the contractor to change course.  The costs of constructive changes are supposed to be borne by the customer, and are considered valid when submitted as claims.

Who is responsible for losses from errors in specifications?

When a project goes sour, the most likely thing the contractor's lawyers will do is examine the specifications and find a number of errors and inconsistencies in them that they claim to have mislead their client.  Very few specifications are totally free from such defects.  The party responsible for the losses is then the party who drafted the defective specifications.  Such responsibility is a fundamental principle of law. This should make it immediately clear as to why Government project engineers would be wise to use a Statement of Objectives whenever possible instead of preparing specifications--especially design specifications.

By the way, private engineering firms who prepare specifications under contract usually put a clause in all their contracts that disclaims responsibility for errors found in their work.  The insurance companies that cover them for professional liability insist upon it.

Statements of work versus specifications

In a broad sense, statements of work are a form of specifications, and therefore most of this guide is applicable to both.  The distinction is mainly a Government administrative practice.

Specifications describe goods -- in most cases it's either hardware or software, but it could be other products, like chocolate-chip cookies. Statements of work describe services to be performed. The Government separates the two so it will be easier to enforce the statutory ban on contracting for personal services. Separating the services from the goods also helps to make the specifications more easily re-usable for multiple purchases.

Though it's sometimes tolerated in practice, statements of work should not contain equipment specifications, and equipment specifications should not contain requirements for contractors to perform services.  If you need to buy both goods and services, then you should prepare both the specifications and a statement of work.  Typically, statements of work that accompany equipment specifications describe supplementary engineering tasks that enhance the quality of the product.  These are the "ilities," configuration management and software engineering requirements that are essential to military items but often absent in the development of commercial products.  In general, we should let the contractor decide what work must be done to produce a product described by specifications, so if there is any doubt, leave it out.

By the way, a third kind of requirements document, the Statement of Objectives, has recently come on the scene in the Government.


The document that defines the proper organization for all armed-forces specifications is MIL-STD-961. For statements of work, use MIL-HDBK-245.  Many other Government agencies use these same standards for guidance, though some have their own standards.  You should have a copy of them, and be familiar with their content. For training device specifications, we usually use Appendix A from MIL-STD-961.

Specifically to NAWCTSD engineers:  If you don't follow the guidance in the two documents mentioned above, you will have difficulty getting your package through the approval chain.  Also available are boilerplate documents that were prepared as a baseline for writers of new specifications and SOWs. Use the boilerplates, but be careful not to blindly copy paragraphs from them unless you're sure their content is correct and necessary for your application.  On a more practical note, organizing your document according to the prescribed sources makes it easy for experienced readers to find things in your document.

When you number the paragraphs, be sure to follow the standard outline as closely as you can. You may deviate from the prescribed organization if you have a good reason to do so, but you must conform to the top-level divisions. For example, in a traditional six-part specification, section 1 is always scope and background information, section 2 is always applicable documents, section 3 is always requirements, section 4 always relates to testing and verification, section 5 always relates to packaging and shipping, and section 6 is usually a collection of related information and notes.  Statements of work are the same except that they do not have sections 4 through 6.  Be particularly careful not to state any of your requirements in section 1, since requirements stated there are not necessarily binding.

Once you've set up a scheme of organization, it's very important to follow it rigorously and not have requirements stated in the wrong places.

Above all, don't let the standardized outline dominate your own document to the extent that it interferes with clarity and conciseness.  McRobb gives an excellent example of how following a prescribed outline too closely can make a document confusing and difficult to read.

By the way, some reviewers will pay close attention to the accuracy of your table of contents.  If your document has fewer than five pages, don't include one.  If you have one, make sure it correctly reflects the pagination of the draft you submit for review.

Citing specifications and standards

Be careful when you cite a published specification or standard.

1. Cite industry standards, if possible, instead of Government ones. Government specifications and standards are not OK unless you have a properly obtained waiver. There are exceptions to this rule for certain types of Government specifications, and those exceptions are best tracked by checking with the Defense Standardization Program Office's Web site.

2. Be sure to read the document you're citing, or you may be embarrassed to find that the document and the way you've cited it are not compatible. The classic case is the Federal specification that defined several grades of glass, including a "greenhouse" grade, which could be the poorest quality glass, just as long as it was translucent. Navy training device specifications for many years cited this general glass specification, but did not specify the grade. They said only that all the glass should conform to the Federal specification. I don't know of anyone who got greenhouse glass, but if they did, they would have had to accept it or pay for an engineering change to replace it.

3. Be sure to check the revision status of each document cited. Citing canceled specifications is unprofessional and costly.

4. Be aware of the problems inherent in "tiering" .

Performance or design

Engineering specifications may specify either the performance or the design of the product. This is a distinction used by lawyers and judges in determining who should be held responsible when projects go sour.  Formerly, the distinction was of little interest to working engineers, and many are still not aware of it. Consequently, specifications written by engineers often turn out to be a mixture of both performance and design.  In Government work, the time for such unawareness is over, since all Government systems-level specifications, like the ones we write for Navy training devices, are now required to be performance specifications. Nothing about the policy to use performance specifications is really new; engineering management textbooks from the 1960's, and perhaps even earlier, advise private-sector engineers to confine their specifications to the performance type unless a genuine need exists to do otherwise. This is because performance specifications place the full responsibility on the contractor for proper performance of the purchased goods.

Whenever we specify design, we are responsible for the resulting performance of the product. If the product fails the acceptance test, and the Government specified some aspect of the design, then the Government may have to accept the product even if it doesn't work right. Consequently, writing design requirements is never advisable unless the specifiers have recent experience at designing a nearly identical item, and fully understand all aspects of the design problem. High-level direction from the Defense Department explicitly forbids the specification of design in Government contracts unless a waiver has been obtained from an authorized official. In Defense work, those officials are known as the "Milestone Decision Authorities." Other federal agencies have similar policies.

When writing performance requirements, it is especially important that you accompany each requirement by a carefully stated description of the method that will be used to verify correct performance. You must do so to eliminate the possibility of disputes over whether or not the product meets the criteria for acceptability.


Clearly stating the quantities to be supplied is essential.

You must be careful not to specify "more" of something, or "additional" features without clearly stating how many, or how much. Failure to make the quantities clear often causes disputes.

Here's a good example of how quantities can be muddled: I once reviewed a draft specification that required "a number one and number two engine mockup." Upon questioning the authors, I was told they really expected to get two mockups, not just one as a contractor could have interpreted.  Had the error gone undetected, correcting it later on would have cost the Government several orders of magnitude more than what it cost to have me sit for weeks like I did examining that set of specifications.

Verification of requirements

If you can't check it, you can't buy it.

We must be able to examine, analyze, demonstrate or test what we buy. When you specify something that is not defined well enough to be verified by one of these techniques, the requirement is meaningless to everyone except yourself. Contractors will legitimately argue that the product doesn't need to meet requirements that are meaningful only to the drafter of the specifications.

Specifications should contain, as well as a statement of each requirement, a corresponding statement of the method by which the fulfillment of the requirement will be verified. Such corresponding statements normally appear in Section 4. of military procurement specifications, and are usually organized in a paragraph structure identical to that of the requirement statements in Section 3. Be as specific as you can when you write them, and remember that the contractor's opinion is the only opinion that matters in deciding whether or not a particular requirement has been met.  State your testing requirement so that the test establishes as fact whether or not the product is working the way you need it to work. The Government's position in disputes over acceptability can rely only on clearly demonstrable facts, not on opinion.

There is a reason for the procedural element of verification besides the obvious one.  It has to do with the preciseness and descriptiveness of the specification's language, and is based on an important topic in scientific method known as operationalism.


You must specify tolerances as well as dimensions. This is particularly true of requirements for measurement and alignment.

Be sure your tolerance requirements are not overly stringent. Unnecessarily tight tolerances usually increase cost.


A warranty makes a promise. It makes the warrantor responsible for the expenses caused if the item is not as good as promised. It is highly desirable to a buyer that the goods carry a warranty ensuring as much as possible about the goods.

It is not desirable in the least for you to grant a contractor certain types of warranties. These are warranties of:

  1. The correctness, completeness, and suitability of furnished items, and
  2. The suitability of an item for a particular purpose.

Specification writers need to be aware of how easy it is to inadvertently warrant something in their documents. Merely mentioning an item as a possible design alternative may give a warranty of suitability for the purpose. Merely making a statement of opinion that could be taken as factual might also constitute a warranty.

It may not matter that an item mentioned is actually able to do the job. If the contractor selects a way to use the item that makes it unsuitable, the Government may be forced to pay the cost of redesign.

In general, the best way to avoid making unintentional warranties is to confine your specifications to requirement statements. Avoid saying anything else at all.

Unbounded requirements

Some things are easy to express in colloquial language, but never actually occur in real life.  It's closely akin to, and perhaps even a special case of, the "totality" problem.  Careful logic just isn't a part of the casual way most of us are accustomed to communicating as we interact with others on a day-to-day basis. Avoiding casualness is one of the greatest challenges in specification writing.

When we specify something like "to the greatest extent possible" it could be interpreted to mean we expect the contractor to hire the whole human race and put them to work for the duration of the contract.

This caution applies to all specifications, but be especially careful of this error when you're writing specifications to be used under a time-and-materials or cost reimbursement type of contract.

Government Furnished Equipment and Information

Engineers and program managers are advised to avoid these two if at all possible. Here are five reasons why.

  1. The contractor needs to have them on time, and we often have no control over when they are delivered.
  2. The furnished items must be perfect, or the contractor has a valid claim.
  3. If GFE needs repair, the business of getting it fixed is usually very difficult and time consuming.
  4. GFE usually costs a great deal more than equivalent commercial items.
  5. GFI carries an implied warranty as to its correctness.

Sometimes, however, GFE and GFI are necessary, and sometimes the cost savings they offer are significant. If you can, arrange to have the contractor inspect and accept the GFE and GFI before contract award.

Conflicting requirements

Conflicting RequirementsThis type of error usually is made because the document is written in pieces by several people at widely separated times. When the specifications are put together, the conflicting paragraphs may be many pages apart. Finding the conflicts depends on the memory of the reviewer.

To make matters worse, it's possible that seemingly unrelated requirements are mutually exclusive when taken in sets of two, three, four, or more. The only way to avoid such possibilities is to avoid specifying products that stray too far from the performance of known working systems.

You'll be more likely to find conflicts if you use a word processing program that allows you to handle the whole document as a single file. This word processing feature will allow you to search the whole document on key words and phrases. You will be able to check all mentions of each topic in the document against each other. Sorry, not all word processor programs can handle such big files.

Some conflicts are subtle and detecting them requires detailed knowledge of the equipment design. In this case, you may be entirely dependent upon goodwill from the contractor.

Impossibility of performance

Specifications that are not doable are not really specifications; they're science fiction.

One of your most important responsibilities as a specification writer is making sure that what you've specified can actually be done. Pay careful attention to how your words may be interpreted by someone who is actively looking for ways to take advantage of your mistakes.

When specifications cannot be met with the expected amount of effort, legal action may be taken by contractors to prove "impossibility of performance" or "commercial impracticability," and thus obtain relief from their contractual obligations. The result is nearly always disastrous. When examined by specially skilled readers, very few documents are found totally free of assertions that may be interpreted as conflicting or mutually exclusive.

Impossibility of performance is sometimes caused by a lapse in the front-end analysis.


A requirement in a specification or SOW to agree about something at a future date often causes trouble. Avoid such provisions whenever possible.

Agreements-to-agree in specifications usually mean that the writer did not know what to specify or how to specify it. To correct such an error requires revisiting the front-end analysis to fill in the needed information.

Commercial and Non-Developmental Items (CANDI)

The terms "Commercial Item" and "Non-developmental Item" are given formal definitions by the Federal Acquisition Regulations.  They are Government jargon for something we can obtain off the shelf.  In short, a Commercial Item is just what its name implies, while a Non-developmental item is something already being made for a government agency, but not necessarily sold to the private sector. The FAR's definitions cover all sorts of details about availability. Those formal definitions supersede all former usage of the terms, as well as the term "Commercial-Off-The-Shelf (COTS), which is still often used erroneously. The terms were formalized in response to complaints from contractors, who had to deal with numerous locally drafted, and often highly restrictive, definitions.

The need for such terminology arose in the 1980's, when the Government came under fire because the public came to believe we were buying only custom-made products, even when something was already on the market that met the need. The public perception was correct in a few well publicized cases, but probably unfair on the whole, since we've always tried to use off-the-shelf items when we could. In response to such criticism, we are now forbidden to specify newly developed products unless we have thoroughly investigated and have found no other way to satisfy the requirement.

The existence of commercial and non-developmental items that can do the job should be discovered as a part of the front-end analysis that must be done before the specifications are written.

Remember, you can run into serious trouble specifying equipment by make and model. Don't do it unless you're sure the CANDI is fit for the application.

Hazardous materials

hazardous materials It's common sense to avoid using hazardous materials whenever possible. Many laws and regulations govern the use and marking of such materials, and there are many reasons why they may be hazardous. Even if no harm may be done by the material itself, designers still care about the cost of obeying all the rules.

MIL-STD-961 tells what you need to do when you specify hazardous materials.

Approval and authorization

When you approve of something, you're saying that you like it in every way. Contractors may take the "approval" of a part to mean that the approver has warranted it suitable for the application in which they intend to use it. If it turns out that the "approved" part is not suitable, then be prepared to pay for those parts, along with additional labor and material to change to a different part.

It would be much wiser to AUTHORIZE contractors to use the part if they see fit. Then it remains the contractor's responsibility to decide whether or not the part is suitable.

This word may also be associated with an "agreement to agree", which is not good contracting practice.

Also be careful about saying things like "submit for ________ approval," and "will be approved by ______," since the logic of the words does not allow disapproval.

The Contracting Officer

When you mention a Contracting Officer in specifications or in statements of work, you should be sure to tell your Contracting Officer about it and get permission. Besides common courtesy, there are some good reasons why it is necessary.

First, mentions of the Contracting Officer may be part of an agreement-to-agree.

Second, you may be unknowingly assigning a duty that is illegal or against regulations. Acquisition regulations are exceedingly complex and frequently changing. The person to decide how the contractor and the Government will interact must always be a professional contracts specialist who knows the rules and keeps abreast of them.

Data requirements in specifications and SOWs

The only data a contractor is required to deliver is the data specified in the Contract Data Requirements List (CDRL) and described in the Data Item Description (DID) that each CDRL item cites.  Certain other items of administrative data may also be bought, but they are generally not of interest to engineers. According to the Paperwork Reduction Act, Government data requirements that are not stated in the CDRL are not enforceable. Also, data requirements that are not stated in an approved DID are not enforceable. This means you can not specify data in excess of what is described in the DID.

You may, however, specify a reduction in requirements from those described in the DID. If you intend to do so, you must do it on the form 1423, not in the Statement of Work (SOW) or the Specifications.

Specifications and SOWs may, however, state requirements that result in the creation of data. Hence the section entitled "Documentation" in some standard specification outlines.

Technical Data Management Program

Time pressure and professionalism.

If you anticipate difficulty in completing your specifications by the scheduled time, it is your responsibility to notify your supervisor in a timely manner and work together to solve the problem.  It's highly unlikely that you have anything to fear, since in thirty years of working as an engineer, I have never once heard of a case where action was taken against a working-level engineer for finishing something late. As long as you're working hard, the responsibility is on the managers to allocate sufficient time and assign a sufficient workforce to complete the job on time.

TBD's and authors' notes are not wrong in themselves when found in drafts. But when they are numerous, and are still present when the deadline arrives, they tend to indicate that something is wrong with the way the project is being run. TBD's are not authorized in finished specifications.

Remember, it's ALWAYS cheaper to do the job right the first time.

Property disposal

When writing statements of work, occasionally there is a need to tell the contractor to dispose of something.  This usually happens when equipment is being modified or replaced.  In such cases, you must indicate that the disposal should be done in accordance with all the applicable regulations.  You can't just tell them to throw it out or haul it off.  In general, excess items of any value whatsoever must be turned over to the appropriate property disposal agency, from which it may be sent to some other Government agency to be reutilized, or perhaps sold in a public auction.

Training System Disposal

Last Update: 25 June 2015