|
If you're involved in awarding contracts, you'll be
involved in writing specifications. Likewise, if you
want to win a contract you'll try to interpret some
customer's specs (that's "specifications" for short).
When you're writing specs, here are some important
points to remember:
- The scope of the job must be
completely described. How will we all know when
the job is done?
- Don't take any details for granted
-- unless you can afford to have them ignored by
whoever wins the contract.
- Give whoever's doing the job freedom
to decide how it's to be done, which employees will
do it and what tools they'll use.
- Be clear -- make sure everyone
involved knows what you mean.
Not only do you have to be clear to everyone involved,
you also have to consider multiple bids on some jobs.
When you're vague, you give an advantage to bidders who
know you better. If they know you better, does that make
them more likely to do a good job?
- If something is required, say so.
Some bidders have analysts who work full-time looking for
ways to interpret what you said in a way different than
what you meant. This gives them the chance to penalize
you for "contract modifications." You thought the detail
was required; they read the contract and found the detail
optional as written. For them, it's a gold mine!
Writing specifications requires you to be specific. This
sounds obvious, but the analysts mentioned above will tell
you it's not. :-) To be specific, you
have to avoid:
|
Behavior
|
Example
|
What Behavior Makes
Readers Ask
|
| Abstract statements |
"Complete the task in a
timely manner." |
Whaddaya mean by that? |
| Comparisons to nothing |
"The system works relatively
well." |
Compared to what? |
| Universalities |
"The component must never
fail." |
(scoffing) Who can be so
perfect? |
| Unspecified classes |
"They should take immediate
action." |
Who is "they?" |
| Unlinked
cause
and effect |
"Magnets will destroy your
data." |
How? How many magnets?
Where? |
A related issue:
A large number of people think that only sentences
containing the word shall can express requirements,
and their belief is reinforced by an ANSI/IEEE standard,
830-1984. Some contractors are even using software
based on that standard to decompose specifications
into a databases of individual requirements. Hence,
if your requirement does not contain the word "shall,"
it will not become an entry in the resulting database
of requirements.
- The specs aren't the right place to talk
about what kinds of people will do the job.
You use a Statement of Work (SOW) for that. In a SOW
you specify the capabilities workers must have to do
the job according to the specs.
- Government purchases require competition.
This means that government specs can't reflect that only
one brand from one source will meet requirements unless
- it's true, and
- the writers can demonstrate that it's true -- both
in terms of brand and source.
The lowest bidder meeting the requirements will win. So if
you know a certain bidder has all the requirements met, that
bidder can still lose if another bidder responds to what you've
specified at a lower price. This means you have to sweat
the details:
|
Purchasing products
|
Contracting jobs
|
- performance measurement
- physical characteristics (e.g. size, shape, strength, etc.)
- compatibility with existing equipment
- ease of use
- maintenance accessibility
- clarity of instructions/manuals
- useful life
- availability of parts, service, tech support
- warranty
|
- performance measurement
- worker qualifications
- conflicts of interest
- recommendations
- company stability (!!!)
|
References
The University
of New Mexico on writing specifications
The
US Navy on writing specifications
Sherwin-Williams
on writing specifications
Brooks, B., J. Pinson, and J. Wilson
Working
with Words. NYC: St. Martin's Press, 1999.
ISBN 0-312-20176-1
|