Tuesday, November 03, 2015

First post from YII2015

Dateline – London 11.03.15

The Bentley Year in Infrastructure (YII2015) 2015 conference is in full swing at the London Metropole hotel.  Yesterday’s industry press briefings are what the term information overload is all about.  It will take a few days after all this is over to sort through the wealth of information that was presented. The big new is that MicroStation Connect is a living breathing product with two companions – ProjectWise Connect and Navigator Connect. 

The announcement that is getting the most buzz is the acquisition of Acute 3D and the Context Capture technology that it brings.  Context Capture could be a revolution in live data capture possibly replacing, Photogrammetry, Lidar, Laser Scanning and Point Clouds in one fell swoop.

The coolest thing so far is Frank Conforti’s DYI digital sand table.  This is something that the kid in everyone wants – an adult sandbox.  Check out my video for a sneak peek.  That is it for now.

Monday, May 18, 2015

14 years and it still resonates

In my last post, I reposted an article I wrote for PC Trans Magazine 14 years ago.   One of my favorite things about writing that column was the feedback I got from the readers.  It always amazed me that they took the time not only to read my column but to send me comments via email.  One such email that I have kept for all these years was one from Charlie Hodge in reply to my “Back to Basics Puhleez” article.  It resonated with me for two reasons.  One was that I had heard Charlie speak at the first engineering/computing conference I ever attended in the late 80’s.  Second and most important was he concisely explained what I had always suspected but could never quite put into words.  I have re-read the email numerous times over the past 14 years, and it is still as true today as it was then.  Possibly more so if you just change the word CADD to BIM.   I hope it resonates with you as it did me. 


I always enjoy reading your columns in PCTrans. I read with wonder and amusement. Wonder, because I wonder when you'll reach the threshold of knowing "No one gives a damn." Amusement because I’ve been saying the same things for much longer (I'm a quarter-century older than you), and I reached that conclusion several years ago.

But your latest "rantings & ravings.'' "Back to the basics. puhleeez," hit a special note with me. I discovered long ago. civil engineers don't engineer: they managed, it doesn't matter where they work, public or private sector, when they reach the position of "responsible care" they no longer design things…they manage projects. This was a great personal disappointment to me: I spent four years of my young life getting a civil engineering education because I wanted to design things, and found out that civil engineers grow up to be "suits."

But I'm not about turning that around: no, no, no! That's the career path that is set out for them and they have little control over the way things can get changed. That's why your call for staff engineers to get involved in CADD falls on deaf ears: it's not their job! They are not judged on their engineering skills They are judged on their ability to bring the project in on-time and under-budget. To that end, they get others to do the engineering -- they don't have the time, nor the inclination: their bosses don't care who does the engineering, they want successful projects.

(As a personal Note. I did modify my personal career path very early (within two years of graduation) to work with computing in civil engineering and avoided the civil-project management role altogether. That decision didn't effect my career too much, I suspect, since I recently retired as the CIO of a West Coast consulting firm.)

I have spent nearly 30 years talking to the civil engineering community about the benefits (and pitfalls) of computing in civil engineering. And mostly, I feel they don't care. You were about five years old when I programmed a COGO-like program for the IBM 1620. Management didn't care. The project managers didn't care. Those that did care were the people that did the real design the designer-technicians. We were doing ROW for NYDOT interstate projects and this program saved thousands of hours. I was a hero with the ROW guys, but the PM's could care less. Some of the right-out-of-college engineers were eager to learn how to use the computer, but when they got their Professional Engineer licenses, they staged "shuffling paper rather than doing 'real engineering '" as you so clearly put it.

So this leads to, at least in my mind, the obvious: Computers are for specialists who can use them to the best advantage for their organizations. CADD will be done by those that can do CADD. PM's may use computers to track their projects and communicate with others (email. memos, etc.) but it's not in their best interest to do CADD. It's not in the organizations best interest for PM's to use CADD.

In my efforts to educate the civil engineering community, someone raised the question: Who uses CADD? This is really an easy question to answer. CADD users are those people who need CADD to do their jobs! Well, who are those people? This question is a little harder. If an engineer is doing design layout, in other words, creating drawings, then the engineer will use CADD. If engineers are managing projects, then they won't use CADD. In my personal observations of several public and private organizations, right-out-of college engineers will use CADD because they are responsible for the engineering and for creating drawings. Once the graduate engineer gets responsible-charge of a project, then someone else gets to do the engineering, and he/she no longer uses CADD. (I suspect that most architects use CADD because they do create drawings. But as you suggest that's probably for another magazine).

However. I have observed there is a cadre of designer-technicians (para-professionals if you like) that are the keystone of the CADD effort in their organizations. Wherever I go, I see these CADD users editing CADD drawings from hardcopy blue/lines just as you describe. In my own experience. I could never get any PM to use a mark-up or so-called red-lining program, though I tried several. This leads me to the rest of your column: CADD standards.

The reality is that the PM's and other "suits" of organizations don't care about CADD standards. Oh you may get lip-service, but they really don't care. CADD standards improve the working conditions of the CADD designer-technicians, not project managers. It's obvious to you and me that PM's and the whole organization will benefit if CADD standards exist and are used properly. But who will pay for them? PM's can't take time away from managing their projects to put them together. Upper management never budgeted for them. The real authors of CADD standards should be those people that are responsible for creating the drawings but they have no authority!

And so it goes. I have no cure for our plight we'll be decades before we have meaningful CADD standards for general civil engineering projects such as roads and bridges, water/waste/storm water transport and treatment, and civil site development. Despite all the noise about NIBS and their efforts to bring about the National CADD Standard, it has little to do with much of the civil engineering community (here we go again with the architect jokes).

But I don't want to discourage you. You need to keep lifting that bale and toting that barge. You need to keep ranting and raving. Maybe someday there'll be a killer-app that'll bring the PM's into the fold.
Charlie Hodge

As always I would love to know what you think, feel free to leave a comment or drop me a line at randerobinson@gmail.com.

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.

Wednesday, March 18, 2015

21st Century Software - SITEOPS

To paraphrase Monty Python -" now for some completely different design software".  Check out my Review - SITEOPS: Engineering Software for the 21st Century

Over at CADdigest.com.  Let me know what you think, leave a comment below or drop me a line at randerobinson@gmail.com