Thursday, March 19, 2015

Back to Basics Puhleez…

In 2001 I wrote a column in a now defunct magazine called PC Trans.  Maybe some of you even read it.  I was re-reading it and it struck me that even though it is over 14 years old most of it is as relevant today as it was then.  While certain parts of it may be a bit dated, I think it has held up pretty well.  It could be updated by just changing, CADD to BIM.  Either I was a bit of a visionary or the AEC/Highway world really doesn't change much over time.  At least nowhere near the speed of technology. 

Let me know what you think by either leaving a comment below or by dropping me a line at randerobinson@gmail.com.

Back to the basics, puhleeeez
Is CADD doing the job we need it to do? The answer for most DOTS is yes. And no. Yes, because we all create plans electronically now. No, because we haven't made CADD pervasive throughout the organization.

We still consider it a specialized program when it should be the "word processor" of the DOT. Everyone involved in engineering--from the field office technician to the chief engineer--should be able to access and use the CADD resources of their organization. Besides helping us work smarter, this would help us solve a problem confronting every DOT and consulting firm in the country hiring enough engineers and technicians to handle the work load.

Trade and professional publications say there is a shortage of engineers. There isn't. But there is a short-age of engineers who do design work. Too many of our staff engineers (both at DOTS and consulting firms) are wasting away--shuffling paper rather than doing "real engineering.

Many DOT managers are not applying and improving the CADD skills they learned earlier in their careers. When they advance up the career ladder they forget what they learned at the bottom of it. This has to STOP. If it doesn't, DOTS will never realize the full benefits of CADD.

Consider the medical profession: The higher you move up, the more your professional medical skills are in demand. In our industry it seems the opposite is true. Just think how much more productive we would be if all of the engineers and technicians in a DOT constantly used and applied CADD. That one thing would radically streamline the design process.

Paper or plastic?
While CADD is the standard for creating plans in every DOT, there is no standard way of using or interacting with those plans. Too much time is spent plotting, copying, and distributing paper copies of electronically-produced drawings. Unfortunately we still need to have printed plan sheets, especially at construction sites where there are few field computers.

But paper plans are not always necessary. We spend a lot of time and money creating networks so our computers can communicate with one another. We need to start using our networks for the entire road design process. If you (or a design squad leader or the state highway engineer) need to look at a set of plans, you should be able to bring them up on a computer for review. Forget the paper--use plastic (your keyboard). That way, if you see something that needs to be changed, you can change it. It's a waste of time to have someone print it out, send it to you so you can mark the changes, then send it back to have the changes made by someone else...and then finally have it re-plotted and re-submitted for your approval.

Do a REAL evaluation
When was the last time you REALLY evaluated CADD use in your organization? I don't mean asking the various department heads. I mean asking the people in the trenches the users.  You will be surprised at the differences between what the management thinks and what the users know. This is particularly true in large organizations like a DOT.

To make a meaningful evaluation you need to ask the hard questions like: WHY? Just as important, you need to wait for an answer. Find out which programs or parts of programs are being used, which ones aren't, and why. For example you may find that your roadway design software can export all kinds of cool things, but the surveyors can't use the information because their survey software is three versions behind Ask your CADD users what they would like to be able to do with the program. Again, don't forget to ask WHY?

Rethink customization
I moved from a state that did very little CADD customization to one that does quite a lot. Guess what? I see very little difference in their productivity--because the more a system is customized, the more resources it requires for support and maintenance.  Every time the software is changed it has to be re-customized.

So if you customize your CADD software, ask yourself: Why am I doing this? (There's that pesky WHY question again!) Originally we customized programs to improve operator productivity. And it worked. Most of our pioneer CADD operators were tied to traditional ways of doing things and customization let them mimic familiar ways to work more quickly and accurately. But I suspect that customization is a crutch for our users nowadays, rather than a productivity booster. It's one thing to create and maintain level menus and standard cell libraries, but it's a waste of valuable time and resources to write programs that only tweak the output of our CADD products.

Here's an example: Why write and maintain a program that creates cross section sheets when our design programs can do it for us? We'd be better off changing the way our sheets look to fit the existing software, rather than creating and maintaining yet another program. Remember, we are trying to advance the science, not maintain the status quo.

It's more fun to create a program than to maintain one. The real challenge in customizing any engineering software is keeping it up to date. That's why our software vendors get the big bucks!

Create CADD standards
Standards are critical to an efficient and productive CADD operation. But then there's that saying: "The good thing about standards is...there are so many of them." A look at any engineering organization confirms this. Every section, division, discipline, and unit in the department has its own procedures and standards, and they don't always jive with one another assuming you can even find them). Most engineers think of CADD standards as a book of cells, blocks, line styles and level charts. These components are important, but to have truly effective standards, you need to go further.

Good CADD standards should have, at minimum, three volumes. The first volume should identify cells, fonts and levels used in the system and establish drafting standards for creating a set of plans.

The second volume should be a CADD plan production manual, providing the user with procedures for creating a single plan sheet and a complete contract-ready set of plans. This volume should specify when to use CADD and describe how every unit of the organization will apply and interface with CADD.

In addition, this volume should contain details about which unit is responsible for each part of a set of plans. This would help enhance cross unit understanding. While a bridge designer shouldn't be expected to create right-of-way (ROW) plans, I think she should understand what ROW is and how it relates to the project.

Finally, there should be a CADD design manual to show the users how to apply the design software. To make effective use of these standards, three things must happen:

  • They must be available and easily accessible to all CADD users.
  • They must be kept up to date.
  • They must be enforced.


I have observed that the bigger an organization, the harder it is to find basic information like standards, simply because staff don't know where to look. You'd think with the advent of the Internet and large internal networks, anyone can find anything, right? If you believe that, have several hundred acres of developable wetlands I'd like to sell to you.

Have several formats
To ensure that all users have access to your standards, they need to be published in several formats.
First and foremost, there has to be printed set. I would recommend a loose leaf format to allow for easy updating. This may sound like a step backward--didn't I just nix paper plans?--but I believe standards will be effective only if the users can hold them in their hands. In addition to a printed version, all the information should be available either on the Internet or the company intranet.

Finally I would recommend creating a version on CD that could be distributed to any interested party. I can't stress strongly enough that every user ought to have a complete set of standards at his/her desk. Otherwise they probably won't make much of an effort to use them.

Training: software meets the user
 I've heard many arguments against training (even made a few myself) but software, and particularly CADD software, is not easy to master without continuous use and training.

 An effective CADD training program must be able to teach the novice how to begin using CADD, and also provide the experienced user with new tips and ideas. It must be an ongoing process that reaches from the bottom of your organization to the top. Management needs to know what CADD can (and can't) do so they don't have unrealistic expectations of the technology.

General training is fine to get novice users up to speed, but to help experienced users improve, training must pertain to their specific work activities. The average user doesn't have time to play with CADD, so it is important to keep users up to date on what's new and how it can be applied to their jobs.

Whatever you do, don't assume you know what kind of training a person needs. Just because a person works in construction doesn't mean she doesn't need a plan production or 3D class. Telling people they can't do something is counter-productive to organization efficiency Good training should encourage people think about how they can apply a product or feature in their own work. And don't forget the basics. Make all your staff who use computers (everyone, right?) understand the basics of file management, network access and usage plus some simple computer troubleshooting. This will help ensure they know how to do more than play Solitaire.

No comments: