Start with an
Introduction
The first thing you need is to have an
introduction. Why do you need this? Who cares about something that
most people won’t pay attention to anyway. It is just extra wording
that you don’t need. Or is it?
Here are some things that I think need to be set
forth before you publish your standard. You have defined how these
work, so you need to let people know.
more on the Introduction...
Include Acknowledgements
Let those who have assisted in developing the standard have their place in
the document. Mention teams and members by name. This not only produces
ownership of the document and reflects appreciation for contributing, but it
also enhances accountability.
More on Acknowledgements...
Copyright Your Standard
Who owns your CAD Standard? You do or your firm
does. Be sure to include a copyright statement on every page. It is
not a big deal to add one. It protects you from unauthorized use.
All you need to include is a copyright statement.
Update the date on the copyright every time you update the standard.
In fact, even if you do not add a copyright statement, it is still
covered.
If you publish your CAD Standard, even internally
only, how do you know your copyrights are in place? Copyrighting is
not complicated or difficult; there is a quick and easy way to
copyright anything you produce, at least in the USA.
More on Copyrighting...
CAD Standards Terms of Use
Who can use your CAD Standard? How can it be used? Will you share
it with outsiders? Will you provide it to clients? Will you share it
with consultants?
You need to define how your creation can be used.
Of course it
can be used by your staff, but what about others. You may need to
send a copy with client proposals. If you do not get the job, then
they have a copy of your standard. Are they allowed to use it
without your firm being hired? This needs to be defined.
Find out more here...
CAD Standards Distribution
Distributing the CAD Standard once it is developed
should be done via hard copy. I still think that each user should
have a copy at their desk. They can keep it open to the layer list
of the folder structure. You can refer to it when they ask a
question.
It should also be stored electronically, on your
company Intranet. In read only PDF format.
Part of your standard document should define where
users can get another copy. When someone is looking for where it is
located, it should be written into the standard in the introduction
section so that people looking at the hard copy they can find the
original.
More - plus an example...
Roles, Responsibilities and Change Management
When you are writing the standard, define what the
development teams do and their areas of oversight. We discussed who
they are
here, and what they do
here. but you need to include something that helps others know
who, where and how things are created and refined.
Include who is responsible for maintaining and
changing the document. Explain how changes are managed. Define how
the standard gets modified.
More on the topic...
Include a Revision History
When changes are made - document them in the
Standard. You could also include prior versions that have come
before, even if you were not involved. This allows people to know
how many times the standard has been improved.
You could document what was changed as an itemized
list. I have done this in the past as part of the document, but
found that most people never read it. So I just keep a copy of the
prior version to use as reference to see what has changed.
More...
Define Hardware and Software Requirements
Include what hardware and software were involved
in the deliberations of creating the standard. When you define your
standard, you have a standard hardware platform in mind. What size
hard drive, how much RAM, graphics card, etc.
Also include software versions. This will define
what the baseline is for expecting the software to act according to
the standards. Prior versions may not be able to do what the
standard requires.
You never know where a copy of your standard might
end up. A client machine may not be a robust as yours or they may
have an older software version. Stating what it takes to get the
best results from your standard may avoid getting slammed for
failures that are caused by weak hardware and old software.
Look here for an Example...
Define your Terms
Some firms have special in house terms that they
use for file types. Backgrounds, Base Files, Master Files, X files,
Sheet Files, Plot Files, CD Files, etc. Not all firms use the same
“buss words” for the same kinds of files, so if you have some that
you think are unique, include short definitions of each file type in
the introduction pages of your standard. Then when you refer to them
in the document there will be no doubt.
Include what goes into what file. What kind of
data and information in placed in each file type? If the software
defines the file type, like AutoCAD for Architecture, then still
define what is placed in each file.
More on this topic...