Creating Standards, Part 1

Build your standards and develop great support documentation at the same time.

In this installment I'll focus on a different way to build up your standards. I tackle this task differently from most CAD managers, but I believe that you can benefit from this approach.

What is a Standard?
A standard is really just a way to use software to get a desired result. Be it how to create standard layers in AutoCAD or naming protocols in SolidWorks assemblies or using the correct style in Civil 3D, a standard tells a user how to use the software to get good results.

I'll make the creative leap here that if a standard is a way to use software, then a good standard essentially doubles as a training tool. After all, why write a bunch of standards that people have trouble following when you can actually create standards documents that teach people how to follow the standards?

Capturing Your Standards
So if a standard is also a training tool, let's author our standards like a training document and we'll actually get two jobs done at once! First, let me discuss the process I use; then we can dig into some greater detail.

Get a rough outline. Let's say you want people to insert xref files at the right point, scale them correctly, set the visibility correctly, set the pathing mechanism, and more. Write down the list of things that the standard will have to address in order to get the process nailed down.

Expand the outline. Take the rough outline and note any system parameters that must be set, network folders where xrefs are located, any template files that will need to be used, and any other details. This step simply ensures that all the technical details you'll need to track are in the same order as the parameters you're trying to control.

Imagine a training class. Now image what you'd do in a training class to show people how to follow the standard procedures you want to document. Take the time to get some example files that will illustrate all the standard parameters using your actual files in their correct network locations. Now run through a practice version of your training class and note the order in which you do everything.

Bonus: Use a screen/audio capture tool like Camtasia Studio to record your training practice so you can replay it later.

Write the standard. Now, using your expanded outline as the starting point, write down all the steps in the standard in the exact order that your practice training class used. The benefits to this approach are that you'll never miss anything, you'll get the topics in the right order, and you'll automatically check the standard for accuracy as you run through the training practice.

Turn the standard into a training guide. Take the standard document you wrote in the step above and add screen captures taken from your training practice, and you'll have a high-quality training document. If your power users understand the standard, they won't need the training guide, but other users may need it.

Bonus: Run through your training exercise again and capture a final version of it via screen/audio capture, and you'll have a training video that users can watch!

Attack Problems in Order
Now that you have a method to create standards and standards training documentation, you've got to get to work creating the files and documents. But which standards should you work on first, second, and last?

I always focus my efforts on the things that are most problematic in the office. If plotting is the number-one thing that causes problems and rework, then that should be the first standard you tackle. This prioritization obviously requires some thinking on your part, but it guarantees that you'll spend your time on the most pressing problems and then get the best results for your company.

Now you continue to capture and revise standards until you've got the tough stuff covered. I think you'll find the approach cuts down the amount of total time you'll spend on standards and training as you do so.

The Simple Stuff
For simple things like lists of layers, naming conventions, or other items that only need to be defined and written in a table, you can simply list them in standards documents without the overhead of training. The rule of thumb is that if you can write a standard in text form and all of your users will understand it, then there's no need to work up training examples.

Wrapping Up
Now that you've got a method for capturing standards and documenting them, you should take the plunge and start writing standards with an eye toward producing great documentation. Once you dig in and learn the process, it becomes easier and your high-quality standards and training guides will get everyone's attention.

In the next edition of the CAD Manager's Newsletter, I'll continue to look at standards from the angle of distribution in electronic formats. Until then.