If you train a bunch of AutoCAD using folk in AutoCAD Civil 3D you get some common questions. Errr. Actually these questions are usually formed as a statement. For example:

“We make a lot of stuff in our drawings that isn’t Civil 3D stuff. Civil 3D also seems to need lots and lots of Layers too. All these Layers are confusing. We probably don’t need them. Can we do anything about that to simplify things?”

Sure you can do that. You may actually end up working harder because you do.

Backwards Management

You might want to consider that you’re looking at the whole CAD management and publish thing backwards. Civil 3D in a very real sense turns these things upside down.

In AutoCAD, the ONLY things that make something mean something in your drawing is typically what Layer the thing is on and/or what the graphic specifics of the Block are.
You must worry about Layers because for the most part Layer Management the only way to get what you need to print out the door. In the AutoCAD world, you have to worry about all the silly little details ALL the time, because the sum total of all those many little details pile up on you in the end.

Aren’t you tired of that? Doesn’t that seem like a waste of time?

Civil 3D is NOT AutoCAD

Civil 3D employs a Style based management approach. Layers, blocks, and all that AutoCAD stuff is just something every Civil 3D Feature uses to “express” itself.  Get the Style, Label Style, or Set “right” and you get exactly what you want.

But there’s just regular AutoCAD stuff that isn’t Civil 3D stuff?

Really? Like what?

They say, “Familiarity breeds Contempt.” It’s an oft studied neuroscience fact that we believe that others around us don’t get it as well as we do.
On the road to work everyone else is a bad driver.
The illusion is one of the most common failures of managers.
Ok. Translate “manager” to human being.

I Know Better

This seemingly twisted personal perspective (in psychology it’s called a “false frame”) isn’t always the purely “negative” thing it’s made out to be by the purveyors of popular better management and leadership messaging. We do need to keep it in mind.
However, you can argue this personal bent has a certain survival benefit built in. Human beings don’t appear have the natural tendency to follow others over the cliff. Systematic group hunting and many knock down drag out death matches probably taught us something.

"I Know Nothing"

This famous line from Hogan’s Heroes and spoofed again by Laugh-in is too telling. I trust you recall the dress in which it was delivered.

We’re all skeptics until we believe we don’t know.
Then the Stupid Switch gets thrown.
We’ll buy the most cockamamie and irrational of arguments backed up by pseudo-fact, accusation, and rumor. Unfortunately, and all too often, most of that stuff of argument is internally generated. It’s just our brains trying to connect dots that have nothing to do with the unknown, incomprehensible problem we face.
People make sense out of nonsense which is both truly amazing and utterly terrifying depending on the context, the results, and our expectations.

The Aurora Borealis

Yeah. The northern lights and the current event reference may be a somewhat tasteless but poignant pun.
Perhaps the more substantive issue is that “Familiarity leads to Complacency.”
The familiar cannot matter to us as much as the exceptional.
This is built into how our brains are wired. It’s our real world need to depend on our Human Autopilot to handle 99% of the decision making process most of the time. We must unconsciously reconstruct reality on a minute by minute basis just of have a chance of making it through the next Dark Night or Night of the Living Dead.
Worrying about the details except where they differ just doesn’t pay, but the mental phenomena of the familiar can lead you to do a bunch of unless work in AutoCAD Civil 3D.

The Familiar History

Can you convert the Jump to run in CTB?

Yes. But why bother?

It’s what everyone knows and does now.

Ok, CTB is familiar but STB is a lot easier to employ and a lot easier to maintain. Like the rest of Civil 3D, STB is named Style based.
Realistically anyone can understand “Medium” or “10% Screened” a lot faster than color number 172 (a shade of dark blue) that translates to .35mm.
Changing how the colors appear on the screen hardly matters in the Jump Platform solutions. By default we even supply both light and dark background schemes and multiple Layer States to maintain them in InstantOn Basic. Color doesn’t matter except what your USERS care about.

The Case of Intelligent Publish On Demand

But they don’t believe STB is easier. They don’t understand how it works.

So, have you had them use it? To use creates belief.

No. They want it converted first.

Ah. They want you to do a whole bunch of pretty much useless busy work so they don’t have to really use the new software for even longer? The unfamiliar and unexpected is overwhelming. No one likes to be made stupid by a piece of software. Civil 3D can do that.

That’s not it exactly. Some of the Project Managers are also worried that their contracts might require CTB deliverables.

Ah. Maybe they don’t want to risk their project on the next new thing with untrained people? Can’t say I blame them.
Ok. That’s a lot easier to deal with and that is a reasonable and valid concern. Maybe other contracts will require the company publish to ACAD, DGN, or something else too? All of that has NOTHING to do with STB or CTB, a Layer scheme, or any other graphic standards preference decisions the must be delivered to either.

Huh?

You can build a Publish on Demand (POD) template to get them what is exactly and specifically required by your client.
That’s much less work. It’s specific. You KNOW where you must end up. You have a very limited set of controlled and manageable conditions to meet.
The number of Styles or Sets you need to do a specific POD is much, much smaller than what you really need to do the civil engineering or survey work faster inside Civil 3D in any release or version.

In unfamiliar times and with new and growing software capabilities we need more potential choices and expanded flexibility. It makes more sense.

Don’t Stop...Thinking About Tomorrow

Taking that POD approach doesn’t stop the rest of the folks from getting to work on the project and learning how to use the software. The approach also gives you time to learn how to build POD templates.
Learning to build a template “translator” to a specific set of standards is not rocket science. It’s a learnable skill, but it takes time because all things take repetitions for all people.
We must recognize it is a process to develop. It is not a “thing” or a magic button. In older software the process was more complex, mixed together, and that muddied the waters a great deal.
We’re all too familiar with THAT.
We're justifiably concerned.

Getting the project data built inside of AutoCAD Civil 3D is another set of skills that everyone must learn anyway.
That includes how the Project Managers learn to deal with allocated and estimated man-hours, quality assurance, and all the rest.
That includes USERS understanding how to construct, manage and maintain the Dynamic Model. You’re much better off learning together as a team than everyone waiting for you to KNOW what they may never need to understand.

The boss signs the check. Whatever he wants is what I’ll do.
You bet.

The Familiar is Not Right or Left to its Own Devices

People wave their hands and talk about "Model Based" software, "Model Based" design, and BIM. What do these words really mean where the rubber hits the road?

Maybe the answer is simple, but it sure appears that takes a while for people to get the unexpected consequences. 

Model-Based is Simple and Elegant

We build a "reasonably realistic" model of what we want BEFORE we attempt to actually construct it. The phrase "reasonably realistic" means "suitable" from my perspective, but that's the subject for another post.

Hopefully, our model building isn't too time-consuming. At first, learning the model-based structures and processes will unquestionably make our model building consume More project man-hours up front. If that doesn't change pretty quickly, you are probably doing some basic things "wrong" or at least incorrectly. If it keeps happening, please get some help and a change of perspective. It's really not supposed to be or work that way.

Hopefully, our model is good enough and the design software is also robust enough to actually help us construct, quality assure, and publish the model in multiple ways too.
All these three parts are essential and equally significant to our success. 
Our skill and experience, our understanding of the design discipline(s), standards, and real world systems, AND our Civil 3D usage skills all are put to the test thoroughout these processes.

More Ain't a Joke

The problem of More than one process going on at once isn't a joke. Simultaneous multiple processes confuse us personally and corporately. They upset our old school CAD workflows, and our habitual way of working (what always worked before) most of all. Personal task accountabilities get all mashed up and mixed together in new, and perhaps, unforeseen ways in the new environment.
The basic questions and answers to What, Where, When, and How simply are not the same anymore.
Those uncomfortable and overwhelming facts can and do produce negative expectations and More. Maybe we REALLY didn't want anything to change in the first place. But it did, it will, and it must. Complex socio-economical realities we don't and cannot control make that so.

We Can and Do Miss the Forest for the Trees

At the beating heart of "model-based" design is the core concept that the model and it's managed "data" will produce the published results we will require.
Yippee! The end of drudgery is on site!
Civil 3D actually can do this remarkably well today. But on a practical level, to many Civil 3D users and organizations it sometimes feels like Elvis left the building or never showed up at all.

The model building/publishing problem and the complexity of the output publishing processes can easily become a beast all by itself in these multi-process muddied waters. 

Here's why. Our decades of previous CAD experience teach us to go back and focus ALL the time on the details present in the "model" to solve the problem.  That makes sense because this focus was absolutely necessary when the CAD software was primitive based NOT Feature-based (model-based).  Put another way...
We won't and can't throw away our previous "investments" even when they may no longer apply or actually require some additional investment to again become even More useful.

Recently, I heard a telling example of this kind thinking , "All our details are in CTB format so we can't use STB or we have to "convert them all". They employ old school .shx font files in the details; have their own internal detail Layer scheme; historic hatch patterns, etc. Who doesn't? Converting all that to the any other standards will "take forever" and be a waste of resources that are currently "in short supply". So

"We'll have to keep doings things the same way."

Huh?

Aside from the fact that there are a number of ways to automate and/or systematize a conversion process for this kind of stuff, (they do own AutoCAD Map 3D and AutoCAD after all) there is another More significant issue.

Ask Another Question

"What are you publishing? Are you really handing over digital "drawings", your complete project models (Yes there can be More than One), or just submitting a dwg based plan set?"

To them their "project", the "drawings", the "model", and even their deliverables were all the same thing. To be honest, they probably DO know better, but that has been their world in LDT since the early nineties. By now they "know" Civil 3D is different, but they still can't quite break the old mold and reengineer the new machine they need. A some deep mental level Civil 3D was just replacing the old software. Changing how and what they were producing as work wasn't being questioned in any real depth by anyone except maybe some of their customers. These were just tired of converting the "old" dwgs to get backgrounds to use in their own deliverable plan sets.

The Critical Issue and Our focus must be

Make Publish on Demand Real

The model is the Model and that is all it is.

Good models don't and shouldn't care what they "look like" in a Feature (data) based world. The model and its data structure(s) should be stable, but remain malleable, flexible, and able to be validated first and foremost. Civil 3D is NOT perfect at this without some informed user hand holding, a known structure, and some organizational maintenance and publishing processes in place. 

From a historical perspective CAD looked like it could do Publish on Demand. People promised it (and continue to promise it) today. Technically, CAD by itself could NOT perform because of its fundamental CAD primitive only definitions. CAD is like stacking concrete blocks on the ground by themselves and saying or thinking you've constructed a retaining wall. 

Ordered pictures of parts by themselves do not make systems. However, the old school CAD "device" did allow us to create an acceptable illusion of the real world system(s).

Please note that you have to work on the PARTS and their careful arrangement in detail to make the end published illusion work.

Maybe it is still called "AutoCAD" Civil 3D for a reason?

NOT

We know Civil 3D employs Feature (model-based) "representations to display and annotate the data buried in a Model's Features. Yes, if you explode the Features you'll get simple CAD primitives. Dumbing down to CAD into any format is not rocket science today, but that is only practically useful if you view the acts as a linear publishing one way output process. That means that the "Export to" process REALLY is a separate and discrete process triggered by a known event and performed from a known checklist.

All forms publish and reporting processes in Civil 3D need to be seen and dealt with this way. It maximizes the use of your real world resources to do this. The More you can move and concentrate publish details into a one-way OUTPUT process the faster it works, the easier it is to maintain, and the cheaper it becomes to perform. That is basic process engineering and mechanics 101.

Work the Same and Publish on Demand or NOT

Publish on Demand (POD) is something you must work on ALL the time in your project. You will and MUST fail and then learn and improve to get better at it.

How Do You Do That? 

The specifics and details of the output POD process must NOT get mixed up with the model building, QA process, etc either. This is HARD to do because of our detail centric CAD experince is focused on what we see NOW or in other words - the CURRENT state of MY drawing.

STOP

In a model-based world, ALL publishing ALWAYS happens from an OUTPUT drawing specifically built and designed to help us perform the specifics of our Publish On Demand process.

That means there WILL be More than One Publish On Demand drawing doesn't it?

That also means that our all important MODEL should eventually become the replaceable and almost disposable object in our project structures.

That is what "Model-Based", "Feature-based", and/or "Data based" really means.

BIM IT

Now if we want to talk about BIM in a substantive way, we must introduce continuous feedback loops into those external publish processes too. 
We must have those basic loop structures and methods already in our internal processes to get to functional Publish on Demand and do our internal QA well anyway.

Can you say, "How would you like your ______ today?"

InstantOn Basic and the Jump Platform exists to help you focus on that More Important Work. That happens to be what you get paid for.

Flip the Mindset