Back in my first blog, I reminisced about my days as a draftsman. For this topic I am going to do the same. Back then we used lead pencils on paper or vellum. When we needed to share drawings with the shop, we made blueprints of them using a very large ammonia based blue print machine that looked like it would as soon eat you as make a copy of your drawings.
I remember being mentored by the senior engineers. One of the things they use to tell me was I needed to always consider how something I was designing would to be made. To make sure I did this, they would have me spend time in the shop. While I would help where appropriate, my main goal was to observe how things were being manufactured. I would watch everything from machining to assembly. This was invaluable experience, as from that point on I would do my best to always ask myself on new designs or design change, “Can this really be made?” And for the most part, I could answer that question. If I couldn’t I would be sure to get with the appropriate people in manufacturing to find out before calling my design complete.
In my current position I now get the opportunity to see various engineering departments. In many places I see a big disconnect between engineering and manufacturing. There seems to be this big virtual “Wall” between the two departments. The engineering group develops a new design. They usually run through a very formal design process. And with new CAD tools like PTC offers in Creo 2.0, they can run through various analyses, simulations and interference checking all from their desk. This new capability as proven to help reduce the number of pilot runs and rework required due to design flaws. Unfortunately, with all this new automated checking, I think sometimes the engineer loses sight of how their design will actually be manufactured. In many cases I have noted that the designer really has no idea how manufacturing actually gets their designs built.
Too often a design goes through a rigorous design process, only to be “thrown over the wall” to manufacturing. Once there, the manufacturing engineer often would require changes. Best case, if they had a good PLM system like Windchill, they would start a formal change process, asking engineering to make the required changes and send the design back to manufacturing. This still costs time and money, but all CAD models will stay in sync with how the product actually gets built. However, in many companies, I see manufacturing modifying the CAD models or assembly to reflect their needs. Usually they then save their version of the objects on a local drive or network drive. These files are then completely uncontrolled files outside the companies PLM system. However, without them the product could not be manufactured. Just as important these manufacturing files do not match the designed version of the CAD files. I am not talking the “as designed” to “as manufactured” bill of materials. These often are different, and they should be. I am talking the CAD models themselves being different. This potentially is throwing all the analysis and testing done in design out the window.
I am sure for most of you I do not have to explain the risk of having uncontrolled manufacturing version of CAD files. Why don’t more engineering departments and individual designers today take manufacturing more into consideration when designing? I have a couple of opinions on this. One possibility could be the shorter and shorter design timelines engineering has to work with. They just don’t have the time anymore to research their companies manufacturing practices. Once again I challenge management to truly consider the time they supposedly save in engineering, to the risk with how things truly get manufactured. Another very good possibility is more times than not manufacturing does not happen anywhere close to the Engineering group, many times in completely different countries. What I used to be able to do when I started out, is no longer an option for many engineering departments.
I can’t say I have a complete answer to this growing problem in our industry today. However, one thing I have seen work well is a true design review meeting that includes representatives from manufacturing. Before releasing any design, it must go through one of these reviews. Any concerns with how the design will be manufactured can be brought up during this meeting, and addressed prior to design release. Another option I have seen is creating an “As Manufactured” or “As built” version of the CAD files in a PLM system. Sometime the manufacturing engineer makes the changes, sometimes they are sent back to the design group to be made.
Let’s tear down that wall! If you’re in engineering, consult the manufacturing group about your designs. If you’re in manufacturing, let engineering know you need to modify files just to get them built correctly. Talk though it, bring attention to it. If you don’t, no one else will. You may not think it affects you leaving things function as they are. But, if you are not helping you company become the best it can be, in the end it will be the employees that inevitably suffer.
How does your company deal with changes required to a design so it can be manufactured? Does your engineering group consider manufacturing during the creation of their designs? How do you train new engineers/designer’s manufacturing methods? Specifically, if your manufacturing facilities are offsite. Does anyone else feel this is a growing problem in engineering/manufacturing companies today? While I get to see many companies, I obviously do not have visibility into every company in the country. So, please, respond with your thoughts, opinions, and how things are done where you work.
During the 2013 PTC Live Global event in Anaheim, CA, I was able to make it to a morning keynote by Curtis Strong, the Director of New Product Development at Britax. His presentation discussed the fundamental differences between process & innovation, known results & experiments, recipe & discovery. He talked about how true innovation doesn’t come from following a process. It’s unpredictable, which can be frustrating, but with good systems in place and adherence to timeless principles a company can successfully tackle and profit from real innovation.
At the beginning of his presentation, Strong compared innovation to a chocolate chip cookie. Each year people come up with “new and improved” chocolate chip cookies. Are those cookies innovative? Strong’s argument was “No.” They’re tweaking a recipe. It’s easier to build off previous innovation than it is to be truly creative. The real innovator was Ruth Graves, the person that made the first chocolate chip cookie.
Ruth Graves didn’t have a known result. I can imagine there were a lot of failures, flops, and a very messy kitchen. With each failure something is learned. After gaining, capturing, and applying knowledge you eventually get the winning result; a proven recipe.
True innovation is more achievable when the right systems and principles are in place. Product development methods like Lean product development and technologies like Windchill PLM and PDM provide an environment where innovation can flourish.
Have you or your company ever been the innovators and the first into a market that didn’t exist? Let me know in the comments.
BONUS: Here’s an adorable Britax commercial that Curtis showed during his presentation. It doesn’t have anything to do with innovation, but I figured it’d be a nice distraction on a Friday afternoon. You’re welcome 🙂
“I’m just too busy.” I hear this phrase every single week from my customers and prospects. That followed by, “There’s no time for another meeting, we’re up to our neck in new design projects, it’s our busy season so we can’t even think about implementing another system, and we’re way too busy for training.”
For so long, I’ve equated success with being busy until I read this quote by Friedrich Wilhelm Nietzsche, “A man who is very busy seldom changes his opinions.” I’d like to think there is a parallel between being busy and product development. Professionals in Product Development are paid to change things, to push the envelope, and to challenge the cadence of our weekly schedules.
EAC offers LEAN Product Development seminars in different cities throughout the year. These seminars are packed with executives eager to learn the latest and greatest in LEAN theory. The executives in the room listen attentively as they begin to imagine how their organization can operate as a learning organization.
I often wonder what would happen if our keynote speaker (our fearless LEAN evangelist) stood up in the front of the room and told the audience to focus on learning for the remainder of the week. He would order VPs, Directors, and CEO’s to take their teams offsite while putting their backlog of projects, design review meetings, and production schedules on hold. Of course, that’s neither reasonable nor realistic. But what if?
According to Michael Kennedy, “the greatest waste in the enterprise is the absence of sustained, real-time organizational learning, and very little effort is being applied for resolution.” Why aren’t we all working towards becoming a learning organization? By definition, a learning organization is one that has a heightened capability to learn, adapt, and change. Isn’t that what product development should embody?
I see mission statements that claim a commitment to continuous improvement yet haven’t invested in a class in years. We find the money for new tools, but we can’t take time to learn how to use them. We invest in new product development, yet we don’t educate our people on the fundamental process behind it. Most importantly, we don’t take time to learn from our own mistakes. Why? I think the answer is our own perceived success, our busyness!
As we begin the lazy days of summer, I encourage you to start small and embrace each day. Focus on one area of your work or personal life and take some time to learn how to improve. Invest in yourself, because you are your own most powerful tool. As Dr. Seuss taught us so well, “The more that you read, the more things you will know. The more that you learn, the more places
you’ll go.”
In the last 6 or so months, I have had the honor and privilege of interviewing some of our customers. At EAC, we are dedicated to continuous improvement and one way we gain perspective of where we stand is by capturing voice of customer metrics and case studies. It not only validates how we operate, but it also gives us an opportunity to share our customer’s successes with other companies that might be facing similar challenges. These customers are real, industry leaders who are PTC software users and cheerleaders for EAC. I hope you can relate to our customer’s stories and enjoy reading how they worked through their business challenges and objectives with the help of EAC and PTC.
For today’s voice of customer bit, I’d like to highlight FSG Design (Pennsylvania). They produce innovative solutions for a variety of industries, including: robotics, military, automotive, and medical. Because of the strict tolerances within these industries, FSG’s projects require a CAD tool that is powerful, adaptive, and has the capability to create pristine surfaces.
CEO & Principle Frank Glogowski has found that using Creo Parametric 2.0 along side the Interactive Surface Design Extension (ISDX) has increased his overall productivity by a whopping 25%. Glogowski also said that ISDX meets 98% of the surfacing needs for his organization.
Glogowski has also used other tools like ICEM-Surf, which is for highly complex surface modeling geared toward the automotive industry. My favorite quote from the interview came from his experience. “There is a direct connection with the ICEM-Surf data and ISDX data and I am able to work bi-directional which is really nice. Once one surface is set in, I can take care of all engineering with Creo and the ISDX Module.”
In the grand scale of company size, FSG Design is considered a Small Business. It is worth pointing out that world-class tools are not out of reach for smaller companies. FSG was looking for a way to adopt and upgrade to great software while keeping the budget in check.
If you’ve got comments about how ISDX is working for you, or have questions, get the conversation started below.
The process of capturing, documenting, and agreeing on requirements for product change or development takes on an entirely different scope for companies engaged in Engineered to Order (ETO) businesses. While these requirements are generated internally for Make to Stock (MTS), Assemble to Order (ATO) and Configure to Order (CTO) product lines the ETO business relies on external sources. While everyone is familiar with the formal Request for Quote (RFQ) process, very few engagements will adhere to this. More likely, is a process of starts and stops requiring many man-weeks, months and years. The ability to efficiently; quote, process, develop and ultimately deliver an ETO solution is dependent on the enterprise’s ability to capture just enough information at the project’s inception to describe the product criteria, but not overly constrain the design team. Many a post-mortem analysis has revealed very small or non-existent margins from “specials”. By attending to the requirements at the project’s inception and ensuring that those requirements are of sufficient depth and breadth to quote and create specifications, scope creep can be prevented and margins preserved.
A requirement is a capability which the product or project needs to incorporate. For standard products, these are developed over time by internal teams during the ideation phase of product development. The design and associated intellectual property are then developed as the project moves from ideation to fulfillment. While this may describe the development of Intellectual Property (IP) for an ETO business, a different front-end is followed for ETO solution delivery. As soon as the opportunity is identified by the sales team data (requirements) capture begins. At an advanced maturity state, this data will be entered into the Customer Relationship Management (CRM) application with the correct associativity and visibility to the downstream (application engineering, procurement, etc) functions. More often than not the customer contact data and a subset of the original notes will be entered. Another set of data is now stored in notebooks from phone calls and meetings. As more people become involved during the wooing and quoting phase more set of notes are created and NOT captured or associated formally to the opportunity. Eventually, a quote is generated for the solution and delivered to the potential customer. It is at this point where the troubles can really begin. As the quote is iterated the data behind the iterations and the associated cost implications do not have as stringent review as the originals. When the project is finally won the margin has usually been eroded significantly from the original intent even before development starts. During the quote iterations, technical oversight of the requirements is minimal. This causes the potential solution being quoted to deviate from a variant of a previous design to the requirement to develop entirely new designs. The effect is that the time estimates for the original design are now terribly inaccurate and the project won have been underbid. If aware, most companies will choose to “eat” some of this as development time. The problem is that most companies are not aware of this and schedule resources around original project estimates instead of the last iteration of the quote. Now the pressure on the development team is substantial, to meet the new product deliverables at the same time allotted for the original quote.
To combat this, rules and guidelines governing the boundaries for the solution need to be put in place. These guidelines can be as simple as size and complexity constraints or for often quoted, complex designs, configurators can be employed to accurately capture application data. At the very minimum templates for customer data need to be developed and used to accurately capture the customer’s data. The templates need to be established with clear boundaries so that the correct oversight is employed as the quote is developed. As important, is maintaining the data as the quote is iterated. All data needs to be readily available to the enterprise for use during all phases of the project as well as reference material for similar projects. Associating the original customer data to the quote and any subsequent design files will enable the organization to comprehend the effects changes will have on the overall project. This data associativity and transparency will help to maintain the intended margin and ensure the project stays on track.
If you’ve seen the television ad for Reese’s Peanut Butter Cups where the peanut butter and chocolate trucks collide to produce a novel tasty treat, then you’ll understand the basis for this blog entry.
In our case the peanut butter truck is a dialogue that has become a standard part of our engagements with consulting clients. After seminars or during product development system discussions, we are often asked who are the major product development thought leaders who we most admire and who serve as strong influences on our own thinking. The chocolate truck counterpart is the parlor game in which people name the three people that they would like to invite to a dinner party. A group of my friends recently enjoyed this game, and yes, there was drinking involved, and yes, it is in my own career’s best interest not to go down the path of their interests!
But when I apply the question to my professional interest, and allow myself to expand the dinner group to four, I was able to come up with my own personal Fab Four of Product Development. In no particular order here they are. They are all respected authors so you should be able to find lots of follow up material if your interest is piqued.
First invitation gets sent to Durward Sobek. Durward is a professor at Montana State University and a humble, focused thought leader in the world of Lean Product Development. Durward was the lead on-the-ground-in-Japan researcher for the first foreign team allowed behind the curtain that cloaked understanding of Toyota’s closely guarded product development system. Durward is co-author of the Shingo Prizing winning book, Understanding A3 Thinking, which gives a full and clear understanding of how Deming’s teaching have been applied and practiced with great success in Japan. On first meeting Durward and then reading his book, there was immediate recognition of how the tool in the book’s title was a potential game changer for Western product developers.
Second invitation goes to John Shook. Like Durward, Shook is a Shingo Prize winning author, who also focuses on the A3. Durward, I know personally, as well as through his various writings; John Shook I know just through his writings. Shook’s book, Managing to Learn, doubles down on the belief that product development is about the generation and application of new knowledge, innovation, but he also importantly charts out how the A3 process is used as a cornerstone of the ongoing professional development of engineers at Toyota. Shook’s writing is deeply insightful and resonates with authenticity, being based on his own experience as an early Western manager within the ranks of Toyota both in Japan and subsequently within the US. Toyota does a lot of things well; Shook helps us understand their important investment in people.
The third invitation goes to Don Reinertsen. I’ve only had the pleasure of meeting Don Reinertsen once, but it was after having followed his writings since the late 1990’s. When I met Don, I was in the middle of reading his latest book, The Principles of Product Development Flow. He told me it is a difficult read. It is. It is also worth the effort. Reinertsen uses communication theory and practice as a framework for considering product development, in that both systems are characterized by high variability and both have as a necessary goal, the flow of information. Reinertsen’s perspective on product development, his multi-decade promotion of Queuing Theory which challenges self-defeating behaviors in product development, and his emphasis on the economic consequences of our current “best” practices are all valuable contributions to efforts of improving how we operate.
The final invitation goes to Mike Kennedy; last, but in fact perhaps most significant and influential. I attended a seminar Mike gave in the early 2000s, and it was an epiphany. It began my conversion from corporate executive to a product development consultant focused on Lean Product Development. Mike has been the major voice articulating both his own and the late Allen Ward’s understanding of ‘a better way of doing product development’. EAC has an ongoing partnership with Mike. He is a champion of the LAMDA process (the PDCA process as practiced at Toyota, interpreted and recast by Allen Ward to suit Westerners), and the developer of Learning First Product Development. He is also the first author to elaborate the theoretical framework for Lean Product Development and then follow it up with a guide to its pragmatic implementation in Western environments. This latter contribution is captured in his book, Ready, Set, Dominate. Mike now travels the world as an evangelist, or perhaps better, as the Johnny Appleseed of Lean Product Development.
So that’s my dinner party. For me it would be a slice of heaven. I should probably start a bucket list and get this on line 1.
