I often see questions in my Facebook group asking, “How should I setup the standards for Civil 3D, Revit, or Solidworks,” amongst others. Sometimes there are details, but the questions are often surprisingly open-ended and assume there is a single right way to create standards. I’ve found that creating standards is easy — it is getting people to follow them that is tough — so I’ve learned what works and what doesn’t. The trick to avoiding problems from the beginning is to avoid what typically doesn’t work. By using this contrarian view — how NOT to create CAD standards — you’ll find your greatest chance for success.
So, in this edition of The CAD Manager’s Newsletter, I’ll cover my mental process for creating a standards framework in chronological order (which may seem backward to you) along with tips, tricks, and talking points you can use with senior managers, project managers, and users alike. Here goes.
Image source: Funtap/stock.adobe.com.
As the CAD manager I often believe my ideas for standards are best, but are they really? I may believe that I know how best to attack a CAD management problem (and that may even be true), but is it more important to do it my way or the right way? Over time I’ve found that emphasizing the need for an easy-to-use standard that works for everyone helps users buy into the standards and feel like I’m not being dictatorial. My talk track is, “We’re all going to use this standard, so let’s get involved and make sure it’ll work for all of us.”
So, don’t push for your standards, make sure the standards you create are crafted via consensus and are broadly supported so you can push for the group’s agreed upon standards.
When I say “the end result,” what I really mean is the deliverable file sent to the customer or another department/group in your company. Whether this is a Revit model, DWG file, mechanical design, a set of PDF documents, or any other digital file set, matters not. What matters is that you understand the formatting of the file that the customer expects and deliver it to them conforming to those expectations. The process of devising your in-house standards is then a matter of backward engineering your workflows to achieve the desired output. While this may seem logically inverted — working backwards — I find that this process helps me think more about how I need to work rather than fixating on specific technical parameters.
So, don’t start the standards discussion with a rigid idea of what you think is important. Rather, have the customer clearly define their expectations so you can figure out how to meet them.
As alluded to above, the process of how one works to achieve a standardized result (the workflow) is what matters. As an example, a written standard might say “all dimensions in DWG files should reside on the layer AR-DIM” but the workflow might be that a template DWG file is provided where those layers and entities are already populated. Further, the workflow would explain where the template DWG file is stored, how to access it, and have a brief example of how to use the file in a project context.
Using the above scenario, I’ve found that CAD users instinctively understand that a given entity should be on a certain layer, but there will always be disagreement about how best to comply with the standard. Standardizing the workflow solves both problems.
So, don’t simply make a technical requirement and hope that users comply. Rather, create a workflow that standardizes the entire process so compliance is bult in.
Sometimes it is easy to think that everyone’s work environment is the same as your environment, but that is almost certainly not the case. CAD teams perform differently if they’re all in a single office compared to if they all work from home, right? CAD teams that must share data across slow WAN environments face different challenges than those near a data center with extremely high bandwidth, right? So, doesn’t it stand to reason that the CAD workflows required to control these different teams would also be different?
As an example, I’ve found that crafting standard workflows based on the minimum bandwidth and network ecosystem parameters allows all users to comply with standards. But, if I create standard workflows based on the high bandwidth network enjoyed at the main office, remote workers will be unable to function.
So, don’t assume that standard workflows will work at remote sites just because they work on your workstation. Rather, design for and evaluate your workflows based on worst case ecosystem constraints.
In any CAD standards endeavor, the problem isn't defining the standard, it is making sure users comply with it. There will always be someone who says they don't want to use the standard because they have an easier way to undertake things, but their way is usually not easier for everyone else. This leads to my often-times quoted expression, “Standards are great, so long as they are mine.” So, how can you combat this problem?
Compliance can be naturally maximized by making standard components and automation so ingrained in the standards workflows that it is easier and faster to use the standard workflow than to not do so. Often, simply having template files, logically organized standard parts/families, predefined Word, Excel, and PDF files, and any other project required documents easily available will drive compliance. I mean, who wouldn’t use an available solution that already works?
So, don’t assume people will comply with your standards. Rather, assume that people are busy and would love to use the predefined files you’ve given them to save time. (We can keep it our dirty little secret is that you gave them the predefined files to drive standards compliance!)
I've seen way too many companies produce thick written documents of standards only to be surprised by the lack of compliance. It simply isn't reasonable to expect someone who is busy and struggling to get their workload complete to read through a technical document, then try to figure out how to make it all work. Companies that define standards without defining workflows are doomed to fail before they even start.
Companies that are successful implementing standards achieve their desired workflows by training users with real world examples that demonstrate actual use of those standards. This hands-on training can be done in a classroom, at a kickoff meeting, or by producing your own short video segments. The point is you must show someone how to use the standards rather than make them guess. After all, if you show someone the easy way to accomplish a task, they’ll do so. And, isn’t that what we want?
So, don’t invest time and effort into designing standards and skip the training. Rather, use training to demonstrate ease of use and drive compliance.
Over the years I’ve totally changed my approach to CAD standards to be far less technically based and much more workflows driven. My goal now is to get all the technical issues solved behind the scenes and create simple workflows that include all the templated example files for users to make their lives easy. Along the way, I’ve found that the easier I make things for users, and the more I train them, the more likely they are to listen to me and follow the standards. My hope is that you can use the strategies I’ve outlined to change the way you approach standards.
If you have any other ideas you’d like to share on dealing with standards, please email me. Until next time.