How to Develop Best Practice for Your Group
This is a topic I spent a lot of time contemplating when I wrote my SolidWorks Administration Bible. Every company should go through the process of writing this type of document for your CAD users, regardless of the software. It’s a concept that you can extend far beyond CAD as well.
Best practice is a concept that is widely misunderstood, and not just in CAD circles. In particular, I’ve seen best practice rules imposed on a group of people by a manager who had no idea about the technical content of what their group did. So they found a list of “best practice” rules, and imposed them on the group without modification, without consideration, and entirely without knowing why. This leads to undue restriction, causing problems where none need exist, and a lot of strife and unnatural solutions. Don’t be this person. Best practice should make things easier, not harder.
Best Practice is not Absolute
I think the first thing we have to learn about Best Practice is what the word “best” is trying to describe. There’s this temptation in our culture to understand this word as the absolute pinnacle – the top of the hill. A singular solution to the exclusion of all else. That might be the way it is if life were always a simple one-factor measure. But it never is. Try to remember that you’re not writing the Ten Commandments.
Do you measure your CAD models by rebuild time? Sometimes – in part – maybe. How about time to model? Again, maybe. Do you even evaluate your models in any way? The answer to this should be a qualified yes. Do you measure a part by the extent to which you have followed best practice? I would suggest that if you do, you have the idea of best practice exactly backwards.
The word “best” in this case I believe means an optimized balance between several factors. You get to the best idea by compromising between multiple factors. So the best is a balance between multiple factors, not an absolute single factor.
Best practice is not a yardstick to measure results, but a guide line to help you achieve your goals. And no – your goals are not the best practice list of rules.
Best practice is really a set of guidelines that help different people with different skill levels and experience to work together on a set of data in such a way that anyone can pick it up and understand what’s going on.
Best practice helps avoid problems. I usually refer to best practice as a set of suggestions. The more experienced your group is, the less you need best practice. For every rule you can write, there is almost always a time to break that rule. An experienced user will know both the rule and when to break it. Inexperienced players really need the guidelines the most to help them
Best Practice is NOT universal.
There is a reason why you cannot just look up a set of SolidWorks best practices on the internet. It’s because there is no single set that works for everybody
Best practice for a group of heavy surface modelers is different from a group of people who design stuff that gets machined from a block of aluminum. Working with splines is intrinsically different from working with lines and arcs.
Is motion really necessary for your model? Do you need in-context relations, or does a master model approach work better for what you are doing? File naming. Storage. PDM. Do you use Boundary or Loft features? How do you name features? Do you use folders for features?
So How do you Write Best Practices?
The best way I’ve found to write best practices for different organizations is to start with the problems. Where is the most pain in your process? Is it in interpreting drawings? Then you need a set of best practices to help you create consistent and easy-to-read drawings. Start with areas where you have had actual mistakes caused by miscommunication, or conflicts about how to proceed. By picking the low hanging fruit first, you tackle the problems that are on your mind, and you gain experience with the process of identifying, solving, and putting into writing those solutions. Then with that success under your belt, move on to more complex problems.
Remember that the purpose of best practice is to get all of your people on the same page, and that includes everybody who has to deal with the drawings – those who write them and those who read them.
From there, move on to parts of the process that you think are taking too much time. Collect ideas for best practice from everyone who will have to live with this document. Encourage open discussion about the various points.
Where possible, document problems and solutions with actual files from your data sets. Provide things like templates, settings files, installation recommendations, network set up, and most of all, give reasons why. A command to do something is worth nothing to thinking people unless it is accompanied by a reason why it is important. You can’t keep the spirit of a suggestion without knowing the thinking behind it.
Avoid absolute language where you can. For example, try not to use words like never or always, unless you qualify that somehow. There are very few things that you should really ban entirely. For example, although it is usually a bad idea to leave errors in the model, sometimes you have to leave the model in an error state until you come back to work on it, or leave it for a more experienced user. Sometimes the software will not allow you to correct an error, or you’ve got to use a creative method to delete the error without deleting a lot of other work. So just be careful of how emphatically you say things, because people will only take you seriously when you don’t want them to.
Because you hired intelligent people, and because you hired people you trust, make sure that they know you trust them. Where you have conflicting criteria, make sure your people know what the priorities of the business are. For example, if you say “fully dimensioned sketches are our #1 priority”, and someone runs a macro that reads 1000 points into a 3D sketch – did you really mean that fully dimensioned sketches are your #1 priority? It’s not really true, is it? Time is pretty important, and even more than that is the wise use of time. Dimensioning 1000 points in 3d space is a waste of time. Lock the sketch down, and give it a name that warns people not to edit the sketch.
One of the things you need to keep in mind as you write the best practice document is how you intend to enforce it. Will your CAD Admin go through each drawing or model and approve it? Is it self-governing? Peer review? Is there a best practice review as part of a drawing sign-off? Be aware that enforcing the best practice may itself cost you some time, but then again, catching mistakes may save you some time.
Start With a Best Practice Template
There are a few pre-existing design philosophies that you may be able to borrow from. Some people have gone to great lengths to think out a set of rules/suggestions to help people make models that are more resilient to changes. Examples of these are Horizontal Modeling, Resilient Modeling, and Skeleton Sketch Techniques. These are fairly specific in their recommendations, and mostly help you organize information. More general ideas would be things like in-context modeling, master model techniques, layout sketches, multi-body methods, and so on.
You can start by doing research and trying to understand some of these ideas, and then combining the best of each to see what works for your company’s workflow.
Establishing Best Practice is a Technical Job
Make sure that if your best practices are written by a committee, the committee at least has your user with the best technical knowledge of the settings and options and little back door tricks in the software. If your best practice committee doesn’t know about the Freeze Bar or the Make Reference Sketch options, they might be tempted to do something stupid like recommend you delete all references and save out your parts and assemblies as a Parasolid at the end of a project. I know a lot of smart people who dumb things, but it’s a huge waste of time and it kills the data design intent and re-usability. Make sure you know the difference between prudence and superstition.
If you think you really know something, you should be able to demonstrate it. Granted, there are problems in the software that only show up under special circumstances, but for the most part, you should be able to test and demonstrate your ideas.
It’s not a bad idea to have someone check your work. You might be able to run a draft of a best practice document by your reseller tech support organization. You might even consider hiring a consultant to help you find the best answers, or to settle disputes. I’ve done a fair bit of this.
Summary
- Best practice should save you time rather than cost you time.
- Best practice is a set of suggestions or guidelines rather than strict rules.
- Best practice should be flexible, as long as you know where to bend the rules.
- Best practice helps everyone in your organization work efficiently toward a common goal.
- You can borrow from pre-existing philosophies.
- You can hire in help or get help from tech support people that you are already paying to help you.