People organizations and make AutoCAD Civil 3D implementation too big a deal. It isn’t rocket science. Civil 3D is a software tool. It may be a big, new tool, so a bit of caution is probably in order. The fact of the matter is, we actually already know how to do it. We’re engineers.
The Mission Impossible
“Houston. We have a problem.” Yes. Barring a miracle, the astronauts on the Apollo 13 mission are dead already when they make this call. They don’t know it. They can’t see the problem - never-mind their hands on it to fix it. Their lifetimes of knowledge, training, and skill development are next to worthless.
The Successful Bumper Launch from 60+ Years ago
NASA has a BIGGER problem. NASA bet the store, the lives of national heroes, and the future of the world’s foremost engineering organization to accomplish the mission. The three astronauts are lucky. They get home alive. The mission is not exactly a complete failure. Sound familiar?
Engineering organizations are risk averse. We count every penny. We examine and avert every potential problem. Knowledge is power and more knowledge and experience will always help.
Engineers over-study problems for a living. We must use that wisely.
People First and Last
The most important thing about AutoCAD Civil 3D implementation is your people. If you have not already tried to adopt Civil 3D by now, you have a People problem not a software implementation problem. That’s a brutal way to put it. Maybe it’s even unfair. It’s real.
NASA put teams of people to work on finding solutions to their life and death problem. Civil 3D implementation isn’t a matter of life and death, but no one can argue with the productivity numbers and capabilities available. You just must learn to use the tool in a skillful way.
Actively engaged people who will work hard to retrain themselves are an adoption necessity. They need access to training resources. The basic resources are inexpensive and/or you already pay for them if you own the software.
Do all staff know and use your Autodesk Subscription benefits?
Where are the best and most informative Civil 3D sites and blogs on the web? Who specializes in what? Why do they do that? How can these people and firms help us?
Expect to pay for more substantive help. Good news. These days it’s a competitive marketplace. Help is always cheaper than trial and error.
Engineering professionals are paid for the ability to apply working skills and experience to real world problems. Continuing professional development is our personal responsibility. This is true for firm principals, project managers, and Cadpilots. The position of CAD drafter went the way of blacksmiths the day the Civil 3D software arrived. This isn’t fair. It is - like gravity or the hard vacuum of space. Until the phone rings off the hook, we all have hard work to do.
The Organization Game
Implementation is an organizational game. It is competitive. The larger the organization, the more competitive it should be. Implementation is managed change performed via process improvement to stated goals. It is not an event. This is business fact not opinion.
Well executed, the iterative engineering methodology responds to real world project changes and differences better and faster. The method accepts the notion that a linear project timeline is human expectation and perception based. These must be proactively managed.
Model-based engineering design works based on these assumptions: A representative model of the engineered can be built, maintained, and tested. Acceptable deliverables that allow the engineered to be built can be produced from the model. Your People can do this under budget, on time. Lastly, by repetition you can get better at the process of doing all of that.
Implementation is iterative engineering process too. It will follow the classic Plan|Do|Check|Act process loop. Skip steps in the repetitive PDCA loop and the process development only costs more and takes longer.
Different Business Problems
Time matters in our project. Model-based design creates a major shift in project man-hour allotments to tasks. Man-hours shift forward into projects and are reduced in later stages. The tasks change significantly. Some cease to exist. Our known project completion metrics don’t work either. Alarms will go off. Heads may roll.
Money matters. Financial, historical “truth” is a strong argument compared to an unseen potential. All adopters experience the crisis of project cost. “Why are we doing this when we know we can do it the old way cheaper?” This happens more than once. People assign actual training and process development costs to projects automatically.
Decision Frequency and Quantities matter. How fast can a senior designer make decisions? Four decisions a day become 16 or 20 or more. There is more information to process. It is expressed in new forms. Do and/or will they use the software to serve themselves?
Plan checkers may reject model publication because there is too much useful information on the sheet. “Please show only the top of pipe.” This phenomenon also happened when paper became CAD. It’s problematic when the boss is the checker.
Decisions take time. What does staff do while decisions are made? Do staff offer options or wait for direction? How will you train staff to make more decisions and improve process? Are senior decision makers updated on evolving capabilities and limitations?
Data Scope Matters - Is the Survey dept now responsible to model the existing storm systems and produce surface models? Is their deliverable to Design stylized drawings, images, and/or data and in what forms?
Model-based (data centric) design will and should affect everything sooner or later. Somehow you also have to figure out how to get paid for this while you do it. That’s intimidating.
The jump to Civil 3D isn’t a leap from a plane without a parachute. You are not sitting on top of a Saturn V rocket that has a blast radius that will kill spectators miles away. US Presidents could not attend Apollo launches for that reason. They never knew.
Engineers keep secrets, minimize risks, and never let the competition know exactly how we succeed until it serves us. Engineers are people. We also love to talk shop about what we do, our tools, and work. We avidly reengineer the tools we use and how we do our work to make it better. Where does that conversation go on? Do you pay attention? External input pays.
You know how to implement Civil 3D. It’s a project. A simple business engineering project aptly based on the engineering data you can massage in your sleep. We do need a project separate from our on-going work. Divide and conquer works.
Project It to the Future
Civil 3D is specifically built to be model and data centric and not recreate CAD methodology. It is built to improve and optimize our design and quality control capabilities and reduce the annotative CAD work. The difference is good but bad.
Many experienced people have a personal issue with this. What we’ve done all day every day for years is create, edit, and manage CAD stuff. It’s what we do –what we receive praise, pay, and value for. If the CAD stuff goes away, our years of skill and experience appear useless.
Designers, project managers, and principals are no less aware. We all want Civil 3D to still be the CAD we know – only better. Engineers are smart people. The responsibilities, tasks, and the rewards will get redistributed. To implement, we need to acknowledge the reality. Reward continuing, active, personal engagement and not passive, obstructive behavior.
No Majors in Minors
Traction, Vectors, and Velocity matter. You cannot, or should not, remake Civil 3D and recreate exactly what you do today. Why not? If you focus on that, you will get exactly what you ask for. You will spend your time, attention, and human energy in the CAD weeds. Focus on the wrong details and you ignore the productive crop.
We must be practical and employ the new tool’s built in assumptions and advantages.
Civil 3D Features Matter Most
Data centric and model-based means that Civil 3D Features are more important than anything else. That’s where the data is stored; the way it is displayed and published, and where and how we create and edit the data model.
Features matter most. Every Feature is a collection of components (objects). Features can and do interact with one another in a Dynamic Model. Some key Features are collectors and managers of the Feature interactions. All the statements are true and inseparable in Civil 3D.
CAD Layers are no longer the primary collector. Features are (usually) contained in drawings, But a Civil 3D project is not a collection of drawings like a CAD project. The Civil 3D project is more a collection of connected and/or disconnected Features. This current “state” we call the “Dynamic Model”.
The critical path task of Civil 3D project management is then about managing these critical Features and their interaction. At this point in time, the Feature interaction occurs inside drawings and/or within a one of the “collector” Features in a drawing. Users do this work. A “Managed” Dynamic Model is the real world deal. Doing that depends on people understanding and always doing that work first.
Our implementation project has a Feature centric structure and the structure must adapt to Dynamic Model changes. It must contain and track data going in and published Feature data coming out. To test we need known Feature data to test our tools and processes to our final delivery endpoints.
Identify and Track Feature Limitations
All development is a work in progress. The Features are not perfect. Feature capabilities and limitations must be assessed. Are you learning the known Feature limitations that may affect your work? Are you searching out a work-around before the limitation becomes a crisis? Do you reassess? Have CAD based expectations generated false limitations? Assumption happens to expert and novice alike.
Due to the object oriented methodology by which Civil 3D is developed and maintained our access to the Features and our ability to affect them is very consistent. Features do change, but how the Feature works and how we can get at them cannot be significantly changed without undermining the previous work. You can bet that happens rarely. Programmers are people too.
Features are not People
You can love or hate them, but Features are not people. Features don’t care if they are understood. They don’t mind being objectified. All Features suffer from the worst forms of Autism. They try to swallow what you feed them like great whites. They remorselessly reject what they don’t understand even if it makes sense to you. If you feed them in the wrong order or push them too quickly they will reject you and wreck your day. They don’t care much about their personal hygiene or how that reflects on you.
Feature fundamentals are in the project’s critical path. Assign the learning and delivery task to different Feature mission specialists. Civil 3D training includes the care and feeding of each Feature. Almost all Features have properties that can only be set on creation and every Feature has properties that can be changed later. The subtle and identifiable differences are important.
Looks Don’t Matter to Features
All Civil 3D Feature representations and the annotations are “abstracted” to named Style references. What Features look like are sets of properties collected separately and independently. There are Features that don’t separate perfectly because they are representative Features anyway. We hear the words but we may misinterpret what this means to our implementation project strategy and tactics.
Our CAD perception of Style and our immediate intent is to turn Style into what I want. Isn’t that what Style is there for? Yes and No. Features don’t care about AutoCAD stuff like Layers, Colors, and specifically how the Features and their annotations appear. You care, but they don’t at all. Used wisely our applied AutoCAD skill can pay off here.
The Power of Names
The Feature Style separation says we can redefine the displayed specifics (what it looks like, where the CAD stuff is assigned, etc.) anytime we want, if , and only if, we very careful about the Names we use. The Name is far more important than what it looks like or where the CAD stuff goes now.
Our projects must store Features separately from applied Style definitions whenever possible. This is especially critical for quality controlled (Done) Features that are referenced throughout a working project. Preserve and protect the Feature data first.
We must usually separate both Features to be published and their companion and dependent publishing Features from our Existing and Design Features too.
Our project has create and edit drawings (model drawings), reference drawings, collector drawings, and multiple forms of publish drawings.
How many Civil 3D templates do we need? One template will never work. How many Styles and Sets do we need? In practice this is potentially a staggering and overwhelming number. You don’t need all of them all at once. Process first.
The Implementation Project Definition
All the pieces of our implementation project are built into Civil 3D by the software’s own scope definition. They ship with it. The examples may be inadequate or bad from our perspective, but the parts and pieces are all there. Be wary of adding more. KISS.
The Civil 3D Project Template – this is the core working project structure, the container for your approved in-use resources, your backup and archival strategy, and ultimately your delivery method to the troops. It represents the current “approved” snapshot of our on-going implementation project. All the rest is in here.
The Sheet Set Template and Sheet Templates – these define the published model output in Civil 3D. There is a folder structure, naming conventions, standard resources, and methods to hold that buried in here. If the daily project quality control and check loops do not happen here, plans become the crisis.
Civil 3D Model templates – these contain the Styles and Set tools we need to create, edit, maintain, and publish the model Features. The Civil 3D template is the Holy Grail of implementation. The good news - You can now avoid that work as much as possible.
Engineers are smart people. Don’t reinvent the wheel. Build on known standards of your choosing. Build on the work of others. Go find that. You know more about what to look for and how to judge it. It is out there.
“We have liftoff…”