What is it about running in and saving the day, like in old Westerns, that individuals and companies enjoy? We may say that we would rather not have such drama on the shop floor, but all too often we set ourselves up for it in the end.

The automotive industry describes its approach to product development and manufacturing in the advanced product quality planning (APQP) process.

The story I am going to relate is true. However, since it is not very flattering, it has been sanitized to prevent finger-pointing. I’m telling this story because you may find yourself in the same circumstances when managing your supply chain, especially one distributed across the globe.

If you have been around for a while, you may recall the "Parts is Parts" commercial from the Wendy's fast-food chain. As bad as the "parts is parts" idea is for chicken sandwiches, it's equally bad for manufacturing.

In an earlier article, we dissected the project scope and explored the work breakdown structure (WBS). The WBS is the disaggregation of the scope into the work products that are required to meet the defined scope. Now, we are going explore setting about doing the work, from a schedule, or perhaps we will not even build a schedule.

The fundamental start of any project is a scope of work document, which specifies what we want the project to achieve. The project scope may start out broadly described based upon business objectives, but it will become increasingly detailed over time.

Raptor Performance in Concord, NC, designs and manufactures custom electronics for racing motorcycles and automobiles. The company's products are not for hobbyists, these are professional-grade parts.

In my first job after I received my engineering degree, I was designing hardware and writing software for embedded products for industrial applications. I had a simulator for the microcontroller.

Despite a persistent and incremental march toward automation, people are still necessary for much of manufacturing. Perhaps that will always be true for certain segments.

Project quality and product quality are different things, but they are inextricably linked—or they should be. It is possible for a project to seem successful and deliver the anticipated result, only to find out later the product is not what was expected.