Standards for Developing Standards: A How-To for Busy CAD Managers

CURT MORENO: Welcome to the standards for developing standards, a how to for the busy CAD manager. My name is Curt Moreno, and I am going to be your presenter today. So thank you for joining me this year at Autodesk University, 2021. Let's go ahead and get started.

Now, this is a virtual conference. So I assume that all of you have done the necessary preparatory work to get the full experience out of this year's AU. And that of course, means that you have already walked approximately 173 miles. You've probably already, just today, consumed over 41 cups of coffee. And if you're really hardcore, you haven't slept in two days.

So now that we've got all the prerequisites set aside and you are bleary-eyed, tired, and aching, let's go ahead and get ready to enjoy our virtual conference. First of all, let me introduce myself. My name is Curt Moreno. I am an IT manager, freelance content creator, and long time lurker around the AU hallways.

You've probably seen me with a top hat, a page-boy hat, or some other kind of hat. In fact, I do have hair. I just choose not to show it. I've been in the CAD community for more time than time has had time. And I have been an award-winning Autodesk University speaker, and a long time presenter on topics involving management, customer relations, and of course CAD.

So let's go ahead because as interesting as that might have been, what we're really here to talk about is who you are. So I'm going to make some assumptions. I think that if you're taking this course, you are an IT manager, or you are a CAD manager, a business owner, maybe a leader. Or maybe you're just a licensed professional individual who is working in a larger organization.

But regardless of who you are, I think we can safely assume that you're somebody who appreciates the need for CAD standards. , Otherwise you're just here to take part of my melodious voice. Now you've already read the class summary. I know all of your literate. I'm not going to read from the screen.

Basically, we're going to talk about how to create standards, identify standards that need to be there, and how to deploy your standards. Again we're not going to read this word for word, but we're going to go over to the topic of how to develop-- or, I'm sorry, who should develop a standard, what the necessary milestones are. We're going to talk about the importance of stakeholders in the process. And then of course we're going to identify some major pitfalls.

Now you may have already noticed that I talk fast. That's because we have a lot of information to go over in a limited amount of time. And thank the good Lord he invented rewind.

So let's start with the importance of CAD standards. In my 30 years in the CAD world, I have come to the conclusion that when you say, who wants CAD standards, everybody wants CAD standards. They all know that they want CAD standards, especially this guy right here.

Over the years that I've shown this picture I like to think of this as CAD Standard Steve. This guy is so excited. He is hyped. He has just been waiting for somebody to bring up the topic so he could jump on board. And it's a big topic.

I have the good fortune of being able to talk to people in a wide range of companies, in a wide range of disciplines, literally from all over the world. And the desire and need for CAD standards is nearly universal. OK. Whether it be a case of, I need it, or good Lord, I'm glad we finally did it; CAD standards is definitely a topic that is discussed in almost every corporation of any size that I've ever spoken with.

And there's a lot of good reasons for that. There's some great benefits from creating a standard for your company. You get sustainability of design quality.

Well what does that mean? That means that we don't turn out a good set every once in a while, we turn out a good set every time. That's how you build a business with-- on reputation.

You reduce your training time. If you have a standard that's similar to the national CAD standard, then when you onboard people, you're going to find that their experience at previous companies easily parlays into your company, and they're going to be not just able to work sooner than somebody who has to learn everything new, they're going to be profitable sooner.

We have cross project participation. Very often firms, especially firms with multiple disciplinary groups, are not able to share work, because the standard is so different from group to group. By establishing a common standard within the company, you're able to share, collaborate, and accelerate your production.

Of course, document control-- a lot of people don't consider document control to be part of a CAD standard. I consider it to be absolutely vital. And we're going to cover that a little bit later.

You have reduced IT cost. You have a significantly shorter production time, because everybody is able to work faster. You have reduction of duplicated work.

Nothing infuriates me more than when I visit a production facility and I see that two people are drawing the same fire hydrant, just because they don't know how to xref. They don't know that there's already a fire hydrant block. Every time we duplicate work we might as well just walk to the window and throw dollar bills out, OK? And I would be happy to facilitate that, and be under your window to catch every one of those dollars, you just let me know.

And then of course, and this is a ancillary effect, is that as we improve our production quality, and sustainability, and efficiency, our company and our coworkers develop a higher confidence in the production staff. Everybody wants to feel as if their peers think they do a good job. That might seem kind of soft and squishy, but it's the truth. You want to do a good job. And you want to feel that others know that you're capable of doing a good job.

So are there other reasons that we should invest in developing a CAD standard? Well my little dog Trixie says if there's treats involved, she's there. And I would love to give you all treats. I really would. Twinkies, Ding Dongs, Ho Ho's, whatever it is that you want, Curt would love to mail them to you.

But what I'm going to talk about right now is my two favorites and those are efficiency and continuity. Now efficiency, again, I think that most people, while it may not be the main reason you develop a standard, understand that efficiency is an effect of having a standard. As everybody begins to come into line and is using the same shared resources, is working in a way that you can easily collaborate and hand work off in case of PTO or illness, efficiency is a inevitable byproduct of developing a standard.

So what about continuity? Continuity is something that we all appreciate, but maybe we don't actually verbalize. Again, it is the ability to turn out identical plan sets-- project, after project, after project. Does that mean that you should never improve, you should never evolve? Well, of course not.

We want to all continuously improve and evolve. But the fact is that, if you have let's say, a large corporation with offices in multiple cities, those plan sets should look similar whether they come from San Antonio, or they come from San Diego. You should be able to look at those plan sets and definitely see that they come from the same company.

If you work in a single office with multiple discipline groups, even though one group may be architecture, one may be municipal water treatment, you should be able to look at those plan sets and definitely tell that they come from the same company. OK? And then of course, within the groups, if you have multi-phase projects, if you deliver a plan set for phase one in 2010, and deliver a plan set for phase two in 2020, there should definitely be continuity between those plans sets.

These are very important things. Our clients do notice this. You might not think they do, but it's definitely something that registers on the smallest level, and increases that level of reliability that these people feel they can depend on you, because you're a known quantity.

So one of the questions that I get asked a lot is, who should develop your CAD standard? Before we talk about who should lead your effort. Let's talk about who should develop a CAD standard at all. Because the fact is, that some companies either think that they're too small. Oh, well, Curt, I've only got one draft or what does it really matter?

Or they think that they're too big, and they've come too far to turn around. At this point, Curt, we just could never establish a company wide standard. We have offices in seven different states. You know, I've got 300 people. It would be a nightmare. There's no way we could tackle that. We're just going to-- what we have got us here, and it's going to get us further.

Well, maybe it will, and maybe it won't. I'm going to lay down a very rare quote. I don't like to say, this is what Curt thinks, and I'm going to foist it upon you very often. But the fact is that I think that, "any organization, large or small, employing any number of CAD professionals who produce designs or plan sets will benefit from cat standards."

Now, hey, that sounds really great. And it sounds like a news bite that should come up on somebody's YouTube video, but the fact is that, if you ask me that, I'm really just going to say, "everyone." Everyone should develop a CAD standard. So who is everyone? Well everyone is everyone. You can't be too small, and you can't be too big.

So this actually leads us to another question. OK, let's say that I buy your line and I, as my company-- which is medium size that falls between too big and too small, it's the Goldilocks corp that is just right-- what are CAD standards, exactly? I mean we talk about them, but you know, they're like shoes. When you talk about shoes, you say shoes, but there are boots, there are high heels, there's crocs. What exactly are CAD standards?

Well for the purposes of this discussion, CAD standard is an umbrella concept that encompasses any number of specific facets of design. Now some of the most common ones that I have encountered, and then I feel that are fundamental, are uniform layer configurations, documented production processes, block assets, and then of course, again, document control. I feel universal naming conventions are essential to do in your work.

So if we know what CAD standards are, and we know the company, the Goldilocks corp should develop them, what are the stages of developing a CAD standard? So a lot of people have very good intentions to say, I'm going to develop a CAD standard. And then they grab their sword and run right across the drawbridge.

And not only are they not prepared to fight the dragon, they don't even know which direction the dragon is in. Because the truth is that a CAD standard project is like any other project. So what are the milestones, or stages?

If we were going to do a construction project, we would have our pre-project launch. We would have preliminary design. We would have, maybe a 50% or 60% submittal. We would have final design.

We would have-- no construction or design project would ever come to life without known milestones, or stages. And your CAD standard is the same. In this particular strategy, I preach three stages-- the meta stage, the development stage, and the execution stage. OK? So let's dig deeper into those.

Beginning with, of course, the meta stage. So there's some really good news, and some really bad news about the meta stage. And I'm just going to lay it on you straight up. This is Curt bomb-- if this was an after school special, I would turn my chair around, I would sit on the back, and I would rap with you.

Because the good news is, that the work that you do in the meta stage is not only applicable for what you're focused on at the moment. It lays the foundation. And in many ways, a multiple use foundation for what you're going to build across your corporation.

OK, there's a lot of things that we develop and identify in the meta stage that are going to be useful throughout your effort of standard development, and ongoing development, and execution. The bad news is that it's hard work. And we have to ask ourselves a lot of tough questions.

And the first question is, well, who should lead our effort in developing a CAD standard? And that's where I really advocate that one person be designated as the coordinator for this effort. OK? One person has to be a leader. One person has to be accountable.

And while we all wish that we could have a qualified person who would be progress-oriented, and focused, and say, I volunteer, like our good friend Mia here. The truth of the matter is, that the boss is probably going to walk in one day, and point at someone, and say, you're the guy who's going to work on this. You're the lady who's going to lead this effort.

And you're probably going to end up something more with this fellow. Over the years that I've shown this picture I've come to think of this guy as George. I don't know why he-- he just looks like a George. So now that George is in charge of the effort, let's talk about some important traits of George.

What would make George successful? Well a coordinator has to have a management aptitude. OK? I really I think all of these are important, but in practical application, the management aptitude might be one of the most important facets of what makes a good coordinator.

Because a CAD standard is a large-scale project. It requires a lot of attention to a lot of detail in a number of different areas. And it really, really requires the ability to work with others. Just because you're the fastest drafter, just because you're the most senior EIT, or the most experienced person with pressure water systems, that doesn't necessarily mean that you have good management aptitude.

There could in fact be somebody who's a lot less experienced, or may even not have design experience, but is a very proven project manager that would be a better choice. Adaptability is important, because everything about developing a standard is literally about change.

OK, we are either going to change the way we do the work, or we're going to change the way we consistently do the work. Something is always going to be in the move, and you have got to be able to take that, and roll with it. And then, of course, and I think this might-- it's hard to decide between adaptability and enthusiasm for the second most important, but if you're not excited about the change-- about the CAD standard changes, nobody else is going to be.

The person who takes on this role has got to be able to keep themselves afloat and not become depressed when things get kicked back for modification, not get depressed when you go off schedule, which you will inevitably. And just keep a good upper lip, and keep everybody else convinced that this is the way to go. Enthusiasm cannot be underrated. All right?

So what is the progress once we've identified our coordinator? Well the coordinator leads a project through what I call the collaboration funnel. Now marketing in your company has a marketing funnel. So why shouldn't design have a collaboration funnel when it comes to projects?

It seems only natural, but nobody does. And the reason I say a funnel is because in the beginning, we should get everybody's input, OK? Everybody in the company, the drafter, the CAD manager, the accountant, the designer, the PE, the project manager, the principal-- anybody who lays eyes on the set of plans has the potential to bring valuable information to the party.

And the first days, the first hours are where we want to gather as much of that as we can. Because we have to think of it as, this is a raw material. Once we've collected our raw material, as you can see, we narrow just a little bit. And we talk about just the design staff.

OK, thank you, accounting person. Thank you, admin person. Thank you, even the principal, in a lot of cases. We've taken your raw material and we're going to begin to sift through it. Because if we're trying to make a paper set, we're going to take out all the pieces of glass. We're going to take out all the pieces of steel, that just have nothing to do with our standard.

Then when we've done that initial first cut, we're going to talk to the CAD's leaders-- the actual people who work every day in the applications. Now this is going to exclude a lot of EIT's. It's going to exclude most PE's, most project managers. Because now we're talking about, not how things should look, but we're beginning to talk about how we achieve that.

What are the settings for corridors? What is the proper height for text? What is the proper line thickness for a border? Should we use this font? Should we use that font? These are the things that can only be achieved in the software most of the time. By people who work with the software.

We don't need to cloud this process with interjections from people who are not experiencing the software. Now at the bottom of the funnel is the CAD coordinator, which is probably also leading this effort as a standards coordinator. That person, after they take the input from the CAD leaders, we're going to end up with a lot of instances of, well I think we should use Arial. No, I think we should use Arial Black for the title. Well, I think that the line thickness should be 0.01. Well I think it should be 0.015.

All of those types of decisions, which are both-- I mean, 0.01 and 0.05 would both be valid. There's no reason that we couldn't go with one or the other. Somebody has to make a decision. Somebody has to cut that pie in half. That person is a CAD coordinator.

It's the person who is going to take responsibility for that decision, OK, because if there's no accountability, and no responsibility, you're not going to really achieve anything. I want to play a little scenario for you.

Timmy, Timmy, you didn't get the CAD standard ready when we wanted. OK, why was that? This is going to be on your next review. Versus, well boss, the drafters didn't do the CAD standard. OK.

In one scenario, Timmy is responsible for the CAD standard. Timmy was responsible for meeting a deadline, and reporting to the stakeholders. In the other, a department as a group of people, who are basically anonymous, didn't achieve something that was loosely defined. So we'll just roll it over onto next year's to-do list.

One group under Timmy, because he is the front man of this band, is going to get something done. One group is just going to roll that to-do from year to year. OK, so that's why the role of the coordinator is so important as the arbitrator of final decisions. Beyond him, the standard goes out the door. It comes right out of the bottom of the funnel.

So it might seem like a lot. And you're saying, OK, at the beginning of the everyone stage, what do we start with? Well the good news is that the fact-- the truth is, you already have a CAD standard. Everybody does.

Anybody who has been in business for any amount of time, whether it be five years, 10 years, 40 years, you have a standard. But you don't call it a standard, you call it the way we do things. This is how we do it. That's not how we do it.

And if you look through your plan room at those hundreds and hundreds of sets of rolled up dusty paper, and start taking some of your best examples, the jobs that look the best. You're going to see that you've already executed what you think should be the standard. You really just have to document it. OK?

So at this point, we're at the end of our meta stage, and we've accomplished a lot. We know who's responsible for the CAD standard. We know through-- because of our structure of the collaboration funnel, we know who's at the top in terms of designers and principals, and who's going to review and approve a CAD standard. We know who's going to help with the CAD standard, which of course are our cat leaders.

We've identified and formulated, a formalized the path of participation, to let everybody know, hey, we're past the everybody stage. I'm really glad that you're excited about helping us, Mr. Water Guy, but you should have been here yesterday. We've already moved on.

And then we know what already exists, which is our current standard. That's coming from our current assets, our existing assets, that are in the file room. So that's going to lead us to the beginning of the development stage.

And you can't talk about the development stage without your support staff. And I love this picture, because what we have here is three guys that are really in there. And they're working to get this personnel mover working. We have a supervisor. And then of course, we have an officer.

Now if you'll notice, three guys are really working. One guy is actively looking over him, has gloves on, and is ready to jump in. And then we have a guy in a very clean uniform. Does that sound familiar to you at all? Because it should.

Now what this represents is we have our people who are actually going to create the CAD standard. We have our CAD coordinator who is overlooking that and is ready to make final decisions, hard decisions. And then, of course, we have stakeholders who are-- may observe the process, may occasionally have a comment, but really and truly, they're part of the game has long since passed.

They've already gone through those stages of being a support team, a coordinator, and they moved on up. They're part of the upper echelon, so we call them stakeholders. So in the beginning, what do you do?

Well, the first thing you do is you hash it out. And you let everybody know that we're going to be working on a CAD standard. And you have to stop and start saying, again, in the everyone stage, where do we begin? What are our what are our high points of friction?

And let's take an example, because at this point, we're going to have to start asking ourselves some tough questions. Let's say that we say, hey, Goldilocks go we're going to develop a CAD standard, where do you think we should start? Because you have to start somewhere. You can't just say, well, we're going to do at all. You can't eat an elephant all at once.

So let's say somebody says, well you know what, our print sets really aren't coming out very consistently. We have a problem with the printer. OK? Which, OK, our print sets, our final product, it's not coming out consistently. Let's ask ourselves about that.

Should we start with looking at the printer or maybe deciding if we need some new hardware? That seems like a valid question, but if we ask ourselves some questions, we might actually come to the true cause of what's going on. OK, what's the problem?

Prints are not consistent. Why are principle not consistent? The line width coming out of the plotter doesn't seem to be the same from printer to printer. OK, now, is this a matter of standard plot styles and practices to produce identical plan sets, or is this a function of the fact that we don't have identical hardware in every office?

If I've got an HP in one office, and an Oce in another office, sending the same drawing with the same PLT file could produce different physical sets. OK, you have to ask yourself questions to get to the heart of what is the real answer. Let's say that we decide, yes, in fact, we do have the same hardware in every office, but what happened is that we're not using the same PLT file.

We do a little bit of digging and we find out that our Washington office is using a PLT file that's a little bit older, and not quite up to date to what our Los Angeles office is using. OK, we need to formalize that. We need to standardize that. Are there things we can improve while we're doing this?

You can't just take what's obvious. You can't-- if you just look at your coffee cup when you walk out of Starbucks, and you take the lid off and you look at the top, all you have is a cup of foam. You have to look below the foam to see the coffee. That's really good. I'm going to have to remember that.

So at this point we've known we're at the stakeholder report. OK, we have a list of people who were going to discuss the issue with when we're ready for final approval as stakeholders. We have a good list of areas to focus on for development of your standard.

We've talked about a general breakdown of how the standard is going to be developed. And we've identified the cause of the greatest friction in CAD production. And we've asked ourselves the tough questions to get to the root of what that actually is.

OK, do we need to replace plotters? No. Do we need to replace files? Maybe. We've asked ourselves whatever it is that's causing a problem, and we've gotten to what we think is the real cause of the problem, not just what came off the top. This isn't about foam, this is about coffee, OK?

So beyond the beginning. This is where a lot of things are up to you. OK, now that seems like a cop out. It's almost as if I wrote a book and the middle 100 pages were blank for you to write in. But the truth of the matter is, that this is a discussion of how to develop standards, not a discussion of developing a standard.

Because there is no way that one person could say, this is a tried and true method that will work 100% for 100% of companies, all across the world. There are too many nuances, too many difficulties. OK, every office-- one office might be absolutely fantastic at dividing up the work, but might be horrible at actually sharing work, actual collaboration.

So it's up to you to decide what the next step is going to be beyond the meta stage in the very beginning of your process. But I am going to share some tried and true elements of standards. OK, these are things that I think every CAD standard would be useless without. And of course, document control, I think that your server file structure is a very important point to begin your discussion and effort on, OK?

Where do people find files? Are they all under mechanical for your mechanical discipline? Are they all under projects? Are some under projects, because they came directly from the client? Or do we have project-- actual production information in our marketing directory, because we started it as a marketing job, and it stayed right there?

What if we start a marketing job and it goes to production? Do we move it? Do we leave the marketing effort here? Do we start the production new over here?

These are all things that you should know. You just have to document. And this is a good time to stop and say, I never liked that. That never made sense, OK?

Which leads directly to File Naming Standard. Now I'm going to give you-- I'm going to give you an example. Project number 001WTR, OK, if you see that, you would know that that file belongs to this project. It's the first drawing in maybe a series of 10, or it's the 10th drawing, so you should know that you have to look for nine more. And we know that it's water versus pipe, or water or gobbily goop, or Curt.

What is in CurtDWG? I don't know, but it could very well be my title sheet. It could very well be my PMP for a road. It could be anything, but without proper file naming in a standard structure, we don't know. Now why does that matter?

OK, I'm going to tell you exactly why it matters. Because let's say that you work for a medium sized company, and you've got an OK computer, but you happen to deal with some really big base files. If it takes you 30 seconds to completely open a file with all of its xrefs, OK, and it's the wrong file, and that happens let's just say, twice a day, you've wasted a minute a day.

At a conservative billing rate of $60 an hour for CAD staff, you've wasted $1 a day. At the end of the day that individual has wasted over $200 in billable minutes, times how many drafters do you have, times how many people that you-- or how many years this has gone on. The numbers really do add up.

Wasting 30 seconds twice a day, just $1 per person, because you didn't know that Curt was the cover sheet, instead of Curt2 being the PMP, will add up. Then, of course, once we find the file we're looking for, we want a good layering standard. Layers are very important, especially as we begin to have data shortcuts, xrefs, more advanced, complicated drawings. Layers are very important.

And of course, we need an annotation standard. All of our documents need annotation, otherwise what's the point of having them? What do we include? Do we have a standard general know sheet? What is the font that we use? What is the nomenclature we use?

Here is my absolutely favorite one. And I cannot imagine how many millions and millions of dollars of productive time have been wasted on this question. Is waterline one word, or two words? And I'm going to tell you why this is so insidious.

When I ask that question, I'm not just wasting my time, I'm wasting the time of the person that I asked. And then I'm wasting the time of the person who walks by that desk and says, oh wait, that's not right. Or, yeah, didn't you know that? Now I've got four people standing around talking about the word waterline, all because we didn't have a standard. How ridiculous is that?

External reference standards, where are they kept? How are they linked? How do we name them in? Are they overlays? Are they not?

And then of course, we have to ship whatever it is that we have, so we have to have a plot standard. All of these things contribute to the shape of standards, OK? And we have to understand that to get this information and start to process it, we're going to develop some what might seem like silos, but I like to think of them more as LEGO bricks, OK?

One LEGO brick might be a plot standard. One LEGO brick might be the annotation style. And they all come together to form whatever project it is that we're designing. So let's talk about some common components of a standard, OK?

Again these ideas apply to whatever it is that you're working on, in whatever discipline you work on. OK, drawing templates-- now drawing templates, as you know, are the seed files that are used to create initial standardized configurations. Are our drawing tablets up to date? When was the last time we looked at them?

Did we create our drawing templates in 2002, and we've just been updating them ever since? Maybe it's time to create new drawing templates. Even if you are the very rare company who has their drawing templates completely laid out and up to speed, maybe they're old and fractured. An old file is a file that's waiting to corrupt on you. That's not what you want, OK?

Let's talk about some best practice documents. Now a best practice document-- the reason I say best practice is that in reality, it gives you a little more breathing room. Every project has its own nuance, and its own complications.

It needs to be something that we can say, all right this is what we're aiming for. But we know that we might have to go a little bit to the left. We might have to go a little bit to the right. But we are going to keep the same direction. OK, we might have just a little bit of variance to make this particular project work.

Those are written documents that catalog details, and organizations, and the methodology, that's used to create the direction that your project is going in. And then of course, detailed libraries. Standardized detailed libraries are such a time saver, and really and truly, they're a force multiplier.

There is no reason that any company should create a fire hydrant more than once, a stop sign more than once. However, if you work in a company and you have 10 offices, I can guarantee you that you have 10 individually created stop signs. And if each one took a half hour to make, you've wasted five hours of production time creating stop signs.

In the case of fire hydrants, because there's so many different kinds and so many different little nuances of them, who knows how much time you've wasted on fire hydrants, or stop valves, or electrical conduit representations? Go through your standards. I'm sorry, go through your details. Find the duplicates.

Print them out. Look at all 10 versions of the fire hydrants to say, this is the one. This is our standard fire hydrant that best represents the generality of what we deal with, and delete the rest. Now let's say that you have a standard fire hydrant, and maybe you have a flush mounted fire hydrant for use on an airport.

Obviously those are two different things. You don't delete this because you have one, you say, OK, this is my standard, now I'm going to look at all of my flush mounted fire hydrants, all three of them. This is the best one. I'm going to delete the rest.

OK, then I'm going to take those, and I'm going to name them. So that when somebody looks at this, they know that this is a standard detail, and it is an airport detail. This is a water detail. This is an electrical detail.

And then I'm going to further document this by having maybe a sample book or a PDF where people can go through and identify what they need, what the file name, so that they can go and get it and use it. Instead of saying, oh, I looked in the detail folder, but I didn't see a fire hydrant, so I spent yesterday afternoon drawing one.

OK? Very important, very vital. So again, what I just covered was, we're talking about, especially the form of details, already existing assets. Collect multiple instances. Remove the-- review the full collection. Find the best of the best.

Now when you find the best of the best, improve it. Make sure there's no double lines. Go through the line work and eliminate misspellings. Convert lines to P lines. Check your hatches. Check your spelling.

When you're done, a detail should be as damn close to perfect as it can be. OK? Otherwise why would you re-use it? Another area of existing assets-- again, check your font sizes. Check your styles.

Is everything in amp text? Why would anything just be plain text anymore? Good Lord, hopefully nobody exploded your text. Check your call outs. Is the layering correct? OK, does it match your new standard layering?

Verify your justification. Now you see, you might think that that's a typo that I put a space there. I did that, because I wanted to visually show you that justification that's not right sticks out. And that is my story, and I'm sticking to it.

Check the layers. OK, reduce existing layers to the bare minimum, because when you start bringing in extra, soon you're going to have hundreds, and hundreds, and hundreds, of layers. Yes, you can use filters, but the fact of the matter is, that the fewer layers you have, the absolute bare minimum is all there should be in any kind of detail or template file.

Normalize your layer settings and your nomenclature. And you know what, I'm going to give you a tip. There is a-- you can't even see it most of the time. All the way to the right, in the layer palette, there's a spot for description.

Fill out your descriptions in your reusable assets, because somebody who's new to the company may not know what a layer is for. But if they can go to the description on-screen, it's going to be much faster than them looking it up in a standards guide, OK? So fill out your descriptions.

Then it's come to the time. Whatever it is that we've been working on, let's say, a layering standard, or details, it's time to deploy your standard. Now how you package your standard matters. OK?

I'm actually going to have a very thorough documented standard form that I can send to you. As a matter of fact, I'll include it with the download. Consistency matters, OK? If there's no consistency in how you develop your standards, then that's not very standard, OK?

You wouldn't want to go to the supermarket and buy a loaf of bread in a bag, and they come back next week looking for a bag, only to find out that this week they delivered it in a can. OK? Consistency matters.

The location of your standards matters. Where you store them. How accessible are there? In this example, and I really love this, if this really were how we packaged our standards and put them on the shelf, we would know that all of our blue notebooks over there represent water and wastewater standards. Maybe the green is all of our site development. The gray might be for pavement and airport projects.

I'm not saying that you have to color code these, but where you put them in your server, whether they're PDFs, they're word docs, whether they're in a intelligent format that maybe you can ask a question in it delivers a standard on your internet, you have to be consistent, OK? Now items to document in your deployment-- well what does this mean? I mean, I'm working on a standard, and now you want me to have documentation about my documentation?

Yeah, I do. What's your problem. OK? Because if you don't write notes about where you're putting things, how you package them, in two months when you finish the next portion of your standard, you have greatly reduced your probability of success, and repeating the way you deploy. So let's write down a note about the server directory locations. And maybe the last time the standards were updated.

What are the necessary paths that need to be added to workstations? Maybe you have a collection of shortcuts on people's desk. Maybe you need to make sure that everybody has permission to get to that directory and work with IT.

You need a list of what's been deployed to the people can look and see, oh well I can see that Curt's-- or Curt got the naming standard done, and it's out, but the layering standard isn't. So I'm not going to waste my time looking for that. You need to contact all of the CAD leaders throughout your organization and let them know that you've either deployed, or updated.

OK? And then any special logon requirements, maybe that you've decided that you're going to actually keep your standard in an external structure, on Dropbox, or another file storage system. You need to make sure people have the proper credentials to get into that. And then, of course, ultimately you need to let people know when they can expect in the next update, OK?

Because updating your standards is something that is going to be a continuous job. Now once you've done all of this, let everybody know. I mean climb on top of the building, start a bonfire, and dance around on it, just to get people's attention and let them know,

Howl it out. Send emails. Put it on your intranet. A standard that nobody uses is worse than a waste of time. It's a waste of money, OK? Do not waste your time, money, or sanity.

Now so you've done all this. You asked yourself the tough questions. You found some high points. You found the real cause of problems. You addressed those. You've documented your solutions and your standard. You've worked on your standard blogs. You've packaged everything and you have, basically, notes about your notes, and you've let everybody know.

Are you done? Well, disappointment dog needs to let you know that you're not. And that's a good thing and a bad thing. Because if we were actually done when everything is perfect, we would never be done. Because what we're really aiming for is called the minimum viable product.

When I say MVP, most people think of something like this. Who's the best baseball player? Who's the most valuable football player? But the minimum viable product is at its essence, something that is good enough to work. That's what we need to get out the door, especially in version one.

It satisfies the minimum requirements. It's functional, but it's not complete. Maybe your library of blocks, for wastewater and water projects has 52 different types of valves, but you know that there's another 50. Well, go in there and do your most common first.

And your first version of the standard block directory might have 50, might have 25, but they're the most common. OK? It's functional, but it's not complete. It lowers the barrier. How many of you have tried to create a standard, and said, well I'm not done.

And the boss comes around in three months, well I'm not done. I haven't got all the layers figured out. I haven't got all of the text figured out. I haven't created all of the templates that the company needs. So I haven't shipped any of them, OK?

What we want to do is perfect the first iteration, and get it out the door. Get it out the funnel. As soon as something is good enough to work, it's good enough to ship. That's why it's important that we talk about updates, OK?