DriveWorks Lessons Learned Over 12 Years
•Download as PPTX, PDF•
1 like•1,660 views
Presented by Paul Gimbel
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to DriveWorks Lessons Learned Over 12 Years
Similar to DriveWorks Lessons Learned Over 12 Years (20)
More from Razorleaf Corporation
More from Razorleaf Corporation (12)
Recently uploaded
Recently uploaded (20)
DriveWorks Lessons Learned Over 12 Years
- 1. A Bakers' Dozen of Lessons Learned over a Dozen Years Implementing DriveWorks for Fun and Profit (Thatis,I Have Fun So Our Clients CanProfit)
- 2. Paul Gimbel, DWCP, CSWP Business Process Sherpa • 12 years DriveWorks experience • 21 years SOLIDWORKS experience • yadda yadda yadda, I’ve been doing this for a long time, I know what I’m doing Slide 1 of 209 A services organization providing Implementation, Support and Training for DriveWorks, PLM, SharePoint, and more!
- 4. #1: Process “It’s All About The Process.” - Sherpaism #1
- 5. Flexible Process, Flexible Tool FLEXIBLE PROCESS RIGID PROCESS FLEXIBLE TOOL MUTUAL ADAPTATION REPLICATION RIGID TOOL TECHNICAL IMPLEMENTATION NON- IMPLEMENTATION From “The Line Manager and Systems-Induced Organizational Change” by Eliot Levinson, Ph.D.,
- 6. Flexible Tool, Flexible Process
- 7. #2: Plan and Plan For The Unplanned "If you fail to plan, then you should plan to fail.” - Not a Sherpaism, but I’ll steal it anyway
- 8. #3: Start End Middle “There are three components to every DriveWorks implementation: Capturing the complete, accurate, manufacturable information, outputting what information your customers need, in the right format for them, and connecting the two with your design intent.” - Sherpaism #9
- 9. #3: Start End Middle
- 10. #4: Don’t Panic “100% Design automation is generally unachievable.“ - Sherpaism #2
- 11. Simple Drawings are Happy Drawings
- 12. #5: Let DriveWorks Do The Work “I don't care how much work is involved, as long as I am not the one that has to do it over and over.” - Sherpaism #5
- 13. Added Reference Geometry and Sketches For Drawing Stability
- 14. #6: Your Users Determine Your Success “The biggest indicator of success in any technical implementation is user acceptance.” – Sherpaism #7
- 15. Customer-Focused UX Developed In Collaboration with Cadineer
- 16. #7: Sure, SOLIDWORKS is Cool, But It’s Not Everything “You can’t save yourself into being a millionaire. If you want to make more money, you need to bring in more money.” – Sherpaism #8
- 17. There’s More To Life Than SOLIDWORKS…Really “SOLIDWORKS is just another output type.” – Sherpaism #17
- 18. #285/38: Learn Improper Fractions Least Common Denominator 285 19 * 15 15 1 38 19 * 2 2 2 = = = = ___ ______ __ __=7
- 19. #8: Brute Force Can Be OK “It’s a one-time effort. Suck it up, buttercup.” - Sherpaism #12
- 20. #9: Get Something In Place Quickly “Let’s get DriveWorks in place and paying for itself and for the development of our next phase.” - Sherpaism #19
- 21. Small Project, Big Results
- 23. #11: CTO
- 24. Can We Ship Today?
- 25. #12: Yes, We Know You Can, But Should You? “Given enough time and money, DriveWorks can do anything.” - Sherpaism #13 …But just because it can, that doesn't mean that it should.
- 26. Hey, Look What I Can Do With DriveWorks!
- 27. #13: Standards Can Be Good Select your motor brand:
- 29. Final Lesson “Know when to shut up.” - Sherpaism #11 …and that would be right now.
- 30. Paul Gimbel, DWCP, CSWP Business Process Sherpa Razorleaf Corporation paul.gimbel@razorleaf.com www.razorleaf.com @TheProcesSherpa (Leave out the 3rd S, that’s for “Savings!”) Proud sponsor of DriveWorks World 2016!!
- 31. Sherpaisms • 1. It’s all about the process. • 2. 100% Design automation is generally unachievable. • 3. Automating and inherently flawed process just makes more of the same crap faster. • 5. I don't care how much work is involved, as long as I am not the one that has to do it over and over. • 7. The biggest indicator of success in any technical implementation is user acceptance. • 8. You can’t save yourself into being a millionaire. If you want to make more money, you need to bring in more money. • 9. There are three components to every DriveWorks implementation: Capturing the complete, accurate, manufacturable information, outputting what information your customers need, in the right format for them, and connecting the two with your design intent. • 11. Know when to shut up. • 12. It’s a one-time effort. Suck it up, buttercup. • 13. Given enough time and money, DriveWorks can do anything. • 17. SOLIDWORKS is just another output type • 19. Let’s get DriveWorks in place and paying for itself and for the development of our next phase. • 21. That would be a colossally bad idea. • xx. If you fail to plan, then you should plan to fail.
Editor's Notes
- Before I get started, I need to apologize for my voice. I woke up this morning with a really bad…American accent. I’ve tried to get rid of it, with no luck. So you’ll have to bear with me. I've been working with DriveWorks and SOLIDWORKS for a fairly long time. I know you wouldn't think it possible, looking at my boyish appearance, and the fact that I act like I'm seven years old. But I started with DriveWorks version 5 and the very first version of SOLIDWORKS, SolidWorks95. Which was the year, 1995. They hadn't had 94 other attempts at it by that time.
- So over the years, first as the owner and Chief Tech Dude at a SOLIDWORKS reseller, then in my current life with a DriveWorks Services partner, I've implemented DriveWorks at a good number of companies and the experience is rarely the same. So I would like to impart unto you the lessons that I've managed to learn, in most cases the hard way, to help you avoid the pitfalls that I've discovered.
- My official title is Business Process Sherpa. Now for those of you that don't know what a Sherpa is, they are the Himalayan mountain guides that take people with too much time and money, but have no business being on a mountain, up the largest climbs on the planet. When you see the carefully orchestrated and staged photos of these intrepid "explorers" in their seventeen layers of high tech Patagonia gear, oxygen tanks and twenty one safety devices, you will typically see, in the background some local in shorts and a yak skin hat carrying all 487 pounds of their gear rolling their eyes. This is the Sherpa, whose job it is to navigate these people that don't have experience in this rugged and challenging terrain, to guide them past the pitfalls, show them where to step and where not to step, and generally, get them to survive through these ordeals that are not meant for the corporate executive-type. My job is the same, albeit slightly warmer, and for the implementation of technical design engineering tools. I am known for wearing shorts year round, even in the snow, but I don't own a yak fur hat…yet. Now being known as “the Sherpa” I have accumulated a number of, I guess you can call them catch phrases over the years. All of my students will say, “Oh yeah, he’s the ‘It’s just that easy’ guy” and they’ll remember, “Minus 15 style points” and of course, “pips!” So I’ve collected a bunch of those “sherpaisms” to share with you today.
- The "Business Process" part of the title refers to my belief that it is All About The Process. New tools beget new ways of working. The technology that we bring into our organizations provide us with new capabilities. In order to take advantage of these new, well, advantages, we need to look at the way that we work, find those “well, we’ve always done it that way” things that we do, those sacred cows, and fire up the grill to make some steaks. We need to understand that there are better ways of doing things with these new tools. Software developers here and across the pond have found new and exciting ways to use computers to make our jobs better and easier. But as prescient as the DriveWorks development team is, there’s no way for them to know what is best for your business. So to blindly change the way that you work to suit the way that DriveWorks was designed is, as sherpaism #21 would say, “a colossally bad idea.” Luckily, DriveWorks Pro is designed to be customized to meet your needs. So your job (or ours, if you hire us, not a commercial, I’m just saying…) … Your job is to determine how to customize DriveWorks to leverage the best practices that you have developed over the years, while updating your processes to take advantage of what DriveWorks has to offer.
- This chart from a Society of Manufacturing Engineers publication is one of my favorite ways to show what happens with regards to the flexibility of you and DriveWorks. If you have a tool that's not capable of fitting the way that you work and a process that's not willing to be flexible to take advantage of the new tool, don’t bother. If you're not willing to update the way that you work, and you’re just going to bend DriveWorks to your way of working, realize that “Automating an inherently flawed process just makes more of the same crap faster (Sherpaism #3). In the opposite direction, if you just let the tool dictate how you are going to work, then you’re just going to get an instance of the tool and lose all of your competitive advantages. A customizable tool plus a team willing to understand how the tool works, yields that magical combination that we call Mutual Adaptation. You can just call it success, but we’re a consulting firm, so we need to call it “mutual adaptation.” The key is to understand your competitive advantages, what you've built in to make your products better than anyone else, keep those and understand what makes DriveWorks so phenomenally effective, and leverage and customize DriveWorks to accentuate or add to your competitive advantages while updating the way that you work to take advantage of everything DriveWorks has to offer.
- The classic example is if you replace your trusty axe with a brand new chainsaw. You’ve spent years perfecting all of your axe skills. <CLICK> You know where to make the cuts so the tree falls exactly where you want it to, how deep to make your wedge and when to get the heck out of the way. But when you move to chainsaws, some things are different. <CLICK> You have a new tool that you need handle differently <CLICK> You need to change the way that you handle it, a new process <CLICK> You may need different accessories and techniques and safety gear. You learn not only how to use the tool, but how this new wonder augments the way that you approach dropping, chopping and splitting the tree into firewood. Not to mention how you carve wooden sculptures and your juggling act.
- There's the old axiom, "If you fail to plan, then you should plan to fail." This is certainly true with any technical implementation, design automation included. But with DA (that's our shorthand for Design Automation, because we're big on efficiency, as you would imagine) we have to add a corollary to that, which is, "Even if you have a &@$*ing plan, plan to say '&@$*, I forgot about that!!! Now I need to go back and change it." These mid-course corrections primarily comes from three sources. The first is your customers changing the specs on you once they find out, "Wow, DriveWorks can do THAT???" In most cases, your customer ends up being top management because what started out as a simple tool to get SOLIDWORKS drawings out faster proves to be an invaluable tool all the way up the process. Which is odd that it becomes invaluable once it proves that it really does have value, quite a bit in fact. Scope creep is incredibly common, and something that we as an implementation firm try to manage very closely. Source 2 involves the realization once you start to dig into your design that you really need more information than you thought, or conversely, you don't want the end users to be able to change some of the options that you were originally going to give them. Absolute power corrupts absolutely. And if the people ordering your custom products aren't willing to pay an up charge for the power to make those changes, well then, fewer options they shall have. And the final source is once you dig really deep into documenting and building your design intent that some of the design wisdom has been lost to the annals of time when “George the 2nd” left the company in 1874. We look and see that the reason why we use a certain component or calculate a value a certain way is completely bonkers, or that some of these design practices predate the pyramids of Giza. Time to exercise that process flexibility and update things a bit.
- So we then come to the planning itself. At the beginning of every training class, I always start with this sherpaism, and the lessons always follow this format. We develop the forms, figure out what we need from the outputs, then figure out how to get from A to B.
- Steven Covey says to start with the end in mind. You can certainly do that. But we've found that it is actually easier to start with the beginning, because understanding what your users will know really determines how much work you’re going to need to do under the hood. It helps you start to step away from your role as an engineering product specialist and start to understand what it takes to configure one of your products. One client of ours in Georgia makes outdoor steel structures. And when we looked at what information they needed to design their product, they came up with roof pitches, snow loads, and a bunch of other information that they needed, but realistically, their users wouldn’t know. Then you can look at what information your end users are going to need – drawings, quotes, ERP BOM - figure out what information YOU need to generate and in what format, then go and connect the dots with your design wisdom, creating variables, determining what tables you need and finding the gaps in your knowledge.
- I start every class with Sherpaism #9, but every prospect and client hears this one even before we get to that point. 100% design automation is generally unachievable. Don't take it personally, I can rarely achieve it either. There are either going to be design options that you will never be able to anticipate, options that occur so rarely that they're just not worth implementing, or you're trying to create a perfectly usable SOLIDWORKS drawing. None of those scenarios are generally completely achievable. But that's fine. Using DriveWorks to get you 30, 50, 80, 90% of the way there will still pay for the investment in software, time and effort many times over. So keep this in mind when you start to go down a rabbit hole, asking yourself, “how much time and effort is this small task really worth?” Is it worth spending months working on annotations on a drawing that would take a drafter 3-4 minutes to clean up?
- We struggled with this concept with a company in Rhode Island. Their drawings were very complicated, very crowded and very hard to automate without overlapping dimensions, annotations or views. The question that we asked was, “OK, what drawings do we really want to get out automatically, and what information do those drawings need?” We ended up creating a set of simplified drawings that only showed the information that each of their customers needed (clients, inspection, manufacturing). These drawings were simplified enough that we could get them to be touch-free.
- CAD users can be an interesting bunch. Back when I would demo SOLIDWORKS, there would invariably be one cad jockey who would say, "Really? What took you five clicks, I can do in three clicks in AutoCAD." To which I would always politely reply, "Oh yeah? Go get your computer, big mouth, well race to build the same part and I'll bury you in the concrete!" Did I mention that tact has really never been my strong suit? Well, at any rate, with automation, we need to suspend our need for efficiency on several fronts. My mantra is, "I don't care how much work it takes as long as I don't have to be the one doing it over and over." That's why we buy computers. They don't get bored. And if they do, they don't complain about it constantly. And most of all, they don't get paid overtime. So when it comes to driving output documents or even SOLIDWORKS models or drawings, we shouldn't be afraid to have DriveWorks drive 10 dimensions that could be tied together somehow. If it gives us more flexibility, or it's more reliable by not relying on a new feature, go for it. As long as the extra workload is not impairing your Autopilot or your system's performance, don't worry about it.
- For this client in Wisconsin that made custom steel buildings, we were driving reference sketches to locate drawing dimensions, anchor annotation blocks, lock in detail and section views, and so on that requires DriveWorks to drive a larger number of inefficient or even redundant dimensions or features. Top-Down Modeling is designed to make building and modifying models easier for the user, but creates its own issues for automation. It’s inefficient and a maintenance nightmare to drive the same dimension in multiple models and levels of the assembly. But since these models and dimensions get created by DriveWorks and saved as a PDF, I don’t care how many times DriveWorks has to drive the Wall A panel widths.
- After the first few years, we were finally forced to admit that the best way to get users to love their new automation tool turned out not to involve beating them into submission. I know, I was shocked, too. The biggest indicator of success in any technical implementation is user acceptance. No matter how brilliant, clever, slick or beautiful your solution, if people won't use it will die a slow agonizing death. Remember that you are changing the way that people will do their jobs every day. Telling someone, "this is how you should work because I know your job better than you do" or "because I know technology" will not go over well. They've been doing their job successfully in most cases for quite a while. Remember that balance between flexibility in process and in tool. Ask these people how they work. Don’t replace their process, augment it by leveraging what DriveWorks brings to the table. If they use a form today, whether its paper, Excel, email, web or even ERP or SFA, find out what they like and don’t like about it and start by replicating that form with a few “upgrades.” This will help them feel comfortable and ease into the change. You can then start rolling out new functionality a little at a time. As we get older, we become more resistant to change. Change is inevitable, with the possible exception of dealing with a vending machine. But that doesn’t mean that people like it.
- With your UX and your documents and your spec flow, think about your users and ask your users for input. You need to design your forms to collect the information that they know, not the information that you need to drive your SOLIDWORKS models. For outside facing systems, the UX has to deliver your corporate image. It has to say, “we're easy to work with, we're flexible, we're ahead of the curve” or whatever message your corporate marketing folks have developed. For this customer in central California, we worked alongside Cadineer to provide a user experience that is familiar to anyone that shops on the web.
- DriveWorks started as design automation for SOLIDWORKS, and that's typically how it's still viewed, because that obviously sets it apart. But even though the return on investment is most frequently calculated from time savings in engineering. And that's fine. And you can pay for DriveWorks that way very easily. But Sherpa-ism #8 says, "you can't save yourself being a millionaire. If you want to increase your bottom line, you need to do it by boosting your top line." Pushing DriveWorks upstream to allow sales or customer service or our customers to even just capture complete, accurate, manufacturable information can directly lead to money by getting more, better quotes out faster with more accurate and competitive pricing will lead to closing more business. More revenue will mean more profit which will directly translate into more holiday time for you.
- For us, SOLIDWORKS is just another document type. We balance the value to the customer, whether that's internal or external. And when we look to implement, we focus on what will provide us with the better effect towards our end goals.
- Lesson number seven and a half is to refresh yourself on how to calculate improper fractions. I learned this one when going to my son’s school for a parent’s visitation day.
- Now I have been accused of creating some DriveWorks techniques that can seem to the outsider as maybe a bit of a technological Rube Goldberg solution to automation. And that can stem from a focus on making tools that are valuable to as large of an audience as possible. Now while these accusations may have been occasionally based in truth for tools that I have developed for my own…academic curiosity? Ok, fine. I do it because I'm a DriveWorks nerd. There, I said it. But when it comes to providing practical solutions for our clients' implementations, we recognize that the generic and elegant are great, but sometimes, brute force is a perfectly fine option. If you need to create dozens or even a few hundred rules, variables, controls, etc. then yes, you can write a macro or use the Scripting API, but there is a balance point in there somewhere. Doing the same thing is not always so critically disastrous. When you're building an implementation, you're typically doing it once. If it's just a couple of hours of work, it's probably not worthwhile to fire up Visual Studio and write code. By the time that you get to debugging, you could already be done. Yes, I know, it's not glamorous or even terribly interesting, but as they say in Alberta, Canada, "Suck it up, Buttercup."
- When you start to implement DriveWorks, it’s easy to get excited and have a huge vision of what can be done. And considering that you just spent a “not insignificant” amount of money to get your full DriveWorks Pro setup, you’re probably very interested to prove yourself to your management and the rest of your company. The best way to do this is to get something into production as quickly as possible. You want to make sure that what you put up there is of good quality, so the key is to start off with a relatively small, focused tool that addresses one issue within your process. When selecting your first phase project, there are some important things to consider: Do not underestimate the power of the user interface to collect complete, accurate, manufacturable information. DriveWorks generates real, live, intelligent SOLIDWORKS models (well, as intelligent as you build them). This means that even if DriveWorks doesn’t drive every option that you are planning to offer as custom, it can still start to get you along the path. This not only saves you some time getting you up to speed, but it also provides a very consistent base for everyone to build upon. This includes using model replacements in DriveWorks. Trachte, LLC is a DriveWorks and Razorleaf client in Oregon, WI that makes steel buildings. We built for them an implementation that takes their standard wall panels, including panels with doors, HVAC units, cable risers, intake and exhaust units, and more. Currently, their clients can configure which wall panels they want where and what sizes of doors, exhaust fans, etc. That they want. With that now in production, they are working on one wall type at a time to make them completely customizable. So they are configuring their T-RAMS units and making money, while they add customizability to the system incrementally. Documents like Word and Excel are very quick and easy to build into DriveWorks. And again, having the consistency of these documents is very valuable. The ability of DriveWorks to quickly and easily handle and manage tabular data can make light work of otherwise difficult or tedious data research tasks. And finally, remember that moving from Phase 1 to Phase 2 and beyond should rarely require any rework. So there’s no downside to building the functionality one step at a time.
- And even if you are already well into your implementation, you can still look for these small victories. Picture if you will, Minneapolis, Minnesota. A city so cold that even their cheese takes until mid May to thaw. While knee deep in an implementation of one product line, we were asked to knock out a quick configuration tool. This company, had just purchased another company and inherited a new product line and a new salesforce. The problem that they had was how to take their existing salesforce that had no idea of how to sell the new product and bring them up to speed as quickly as possible. So we designed a DriveWorks tool that would walk the salesperson through the sales process without requiring them to have significant product knowledge. At the same time, the tool provided shortcuts so that the salesfolks that were already familiar with the project could simply type in a part number and get quality, consistent outputs on new letterhead.
- Nobody wants to make custom products. Everybody wants the extra money that comes with it, but it brings up a lot of issues with ERP and PLM and reuse and revisions and all of hose software straightjackets that we engineers are locked up in. … I'm not the only one with the straight jacket, right?...um, ok…well what we started to see happen was hat some of our clients were starting to realize that making custom products is not the same as making standard products and that the systems and tools were not right. It started when one of our clients in Holland…Holland, Michigan, decided that all of the automated products should be treated as truly custom orders, every time, no matter how many times they've made the same part. But ERP and MRP save so much time and effort, I hear the corporate-trained side of your brain screaming. Well I shall refer you back to lesson #5. You may be saving effort, but it's effort that a computer is doing. So it doesn't cost me time and I'm not concerned about it. We term this approach "The ETO mentality." Their products were primarily welded structural members, so the shop knew how to cut and to drill and miter and weld with a very small amount of input required. So there was no revolt from the shop, they didn't care if they'd done it before, they always look at the print and make the part. They don't say, "Oh! It's a 22987-91, I made twenty one of these three weeks ago, I'll get his out extra fast." There are arguments against this ETO mentality, but I challenge you to seriously consider it before you say, "Oh, our business is too complicated to work that way." Because I am willing to wager that at each and every one of your DriveWorks demos you said, "Oh, our products are too complicated to be automated." Yet here you are.
- And for those that are limited by standards or government regulations or just IT people with bad attitudes, we still see a lot of benefit from our clients simply by utilizing existing, engineering reviewed, approved and checked in parts to create configured solutions. In the states, the oil and gas industries are highly regulated. This means that our clients Weir SPM in Ft. Worth, TX use DriveWorks not to drive parts, but by utilizing the value of their DriveWorks forms, a lot of SQL tables that allow DriveWorks to find the best and available components, and SOLIDWORKS models that are predominantly full of instance and replacement rules. Their clients quickly receive customized, serialized drawings for each and every pump while their ERP system gets the information that it needs to create the job and item masters, and their salespeople get the proposal materials that they need to bring in the sale.
- And another oil and gas company in Oklahoma City is implementing DriveWorks. Companies like this can drive replacements and instances for products like this as well. In most cases, they do custom work, but the first phase of their implementation is usually for fast ship products. Here, we will use DriveWorks to collect all of the information required to specify a product. And through a combination of ERP data, calculations and logic, DriveWorks determines if a product can be built from existing parts that have been through engineering review and approval and are in the vault and have been tested, and so on. If it can, the client will get a quotation with pricing and assembly drawings. If the unit is not able to be created with currently approved parts, the user will be told why, given the option to change their choices, or submit a request for custom engineering.
- DriveWorks 14 has a lot of power, functionality and flexibility Built into the core product. Add onto this what can be done with the DriveWorks API and you can do anything. One of our programmers and DriveWorks guys is fond of saying, "given enough time and money, anything is possible." I love programming with the DriveWorks API, well, until I get to the debugging stage, but the reality is that just because we can do anything that we want with DriveWorks, that doesn't mean that we should. This means two things. First, it means that we should always strive to tackle any design or automation problem that we encounter with the toolkit that DriveWorks provides us. It's fun and many people that come from a programming background will say that it's easy to just whip out some code to do it. And in some cases, it might be. But as soon as you do this, you're introducing maintenance issues like requiring plugins to be installed on all DriveWorks machines, and you're taking away the huge benefit that DriveWorks provides, namely, the ability for non-programmers to capture their design intent and maintain it without the specialized skills of a programmer.
- Secondly, the "just because we can doesn't mean that we should" school of thought extends to the functionality that we add into our implementations. We need to remain focused on and constantly re-evaluate what is going to have the most impact on our company's profitability. We can do incredibly powerful and cool stuff with forms, but once they are beautiful and fully effective, we may need to focus on supporting more of our products rather than supporting more web color themes. Yes, these are projects that were done with DriveWorks. The Space Invaders (not an actual screenshot) was done to test out the new UI features in DriveWorks 7 by our very own Phil, yes? And the Back to the Future UI was something that I did at the same time to test out the DriveWorks 7 form enhancements and timer functions. Good practice? Yes. Fun? Heck yeah. Worthwhile? Probably not.
- And finally, let's take this one step further and expand the last two lessons by saying that even though DriveWorks can give you infinite flexibility to create customized products, that doesn't mean that you always need to do that either. When training a new client last week, we found several times when options were made available to the user that really provided no benefit, but just made things more complicated for everyone. For example, The user can choose a brand of motor. There's really no advantage of one over the other. And nobody really has a strong preference for one over the other. If we standardized on one, and don't offer the other, it will be a lot easier for everyone. Procurement will have one part number instead of 1…2…3…lots. Mountings would be easier with only one hole pattern to worry about, and on and on. So we just decided, “OK, we’re only going to have DriveWorks support one motor and if they want another, we’ll call that a special request.
- And one other quick lesson about scheduling development and training. Do not develop any custom specification task plugins or custom functions in project extenders, or even architect a new implementation in the month of February. The new release of DriveWorks is bound to make a bunch of your work obsolete. I spent the past few weeks under Non-disclosure being asked so many questions where the answer I wanted to give was, you do it in DriveWorks 14!! That's how you do it.
- And this one final lesson is something that I learned over the years of doing these types of presentations at DriveWorks World and SOLIDWORKS World and other places. And that would be to Stop talking when you can see people need to take a break and get more coffee. (Especially that guy in the 4th row). And that time would be now.