When Fixing Hardware Defects—Collaboration Is Key

You got some defects in your hardware product. Hey, it happens. Who hasn’t made an honest mistake like spilling a glass of milk or forgetting armed robbery is illegal?

The key is you want to limit the amount of time and effort needed to identify and resolve these defects. And most importantly you want to make sure they don’t happen again.

While many blogs (including this one) obsess over “Top 10 Lists”, “How Tos” and “Best Practices”, I thought this week we’d review “Worst Practices” that you don’t want to utilize when managing your defects.

#1 Ad Hoc Spreadsheets as a Defect Management Repository

Batting lead-off for our “Worst Practices” list is using spreadsheets. Oftentimes you’re working on a new product development project so fast that the powers that be don’t have time to invest in modern defect management tracking tools or processes. The quick solution is to create a spreadsheet repository for these defects. How tough can it be — right?

Why Excel doesn’t work for hardware defect management:

You need a single, controlled, real-time version your team relies upon for current data. With Excel spreadsheets, you need key team members like engineers (and I mean all the engineers), along with quality, manufacturing, oblique team members, suppliers, and suppliers’ suppliers, to regularly open those spreadsheets to make updates and sign off on changes. A spreadsheet is only remotely effective if the defects are few, small and not wide-reaching. Perhaps you only have two suppliers right now, but as your company, product suite and supply teams grow, a manual spreadsheet approach to managing defects becomes untenable.

#2 Email as a Tool to Manage Defects

Email — which stands for “Electronic Mail” for those still using spreadsheets — is another ineffective way to track, report and manage defects.

Why email causes more problems than it solves for defect management:

Everyone on your product development team has to keep track of all copies of ongoing email threads documenting these defects. I just had an email thread 40 responses long among 7 marketing team members attempting to decide where to eat lunch today. This is no joke. I’ll tell you a joke later so you’ll know the difference. Actually, I won’t be able to tell you a joke later because I’ll still be reading this email thread about lunch. Email exposes you to various risks for defects to slip through the cracks. Email is another recipe for defect management fix failure and hence makes our “Worst Practices” list.

#3 Data Repository That Prohibits Collaboration

If you have a single repository to keep track of all related defects, documentation, and status that is NOT accessible by your entire product development, quality, and manufacturing teams then the ability to collaborate is diminished dramatically. The ability to collaborate across teams is key to resolving defects. A lack of visibility creates complications in the defect tracking history, confusing teams whether a defect was ever fixed or is still failing fix-test cycles. If the new member to the team doesn’t know about past defect test results or statuses then the defects never get fixed and consequently become repeated.

Why collaboration is critical:

Collaboration is critical to make sure that the right team member gets assigned to resolve the defect. Otherwise, you might have someone without deep enough domain expertise stumbling about to figure out something they were never trained to fix. And to quote Rumsfeld “… there are also unknown unknowns — the ones we don’t know we don’t know… it is the latter category that tend to be the difficult ones.” Outcomes are always superior in product development when all the people know all the stuff — all the time.

#4 Poor Prioritization Systems

Two outfielders watch a pop fly fall to the ground. The problem is that each outfielder thought the other was going to catch it. Sorry Giants fans, I wasn’t trying to personalize that attack… If your defect team manager is unclear who’s assigned then I can assure you that that defect isn’t getting solved.

Why formalized prioritization systems are important:

If you’re not clear about what’s being prioritized then the simple stuff may be getting fixed while the more subtle, yet still critical defects become more troubling. Additionally bedeviling is some disparate systems are uni-directional, and some are bi-directional. When multiple so-called “integrated” disconnected systems are bandaged together without a unified view, or “master” to call the ball bad things happen — particularly so with data that can be duplicated or even triplicated. Also if you’re changing defect priorities during the product development phase and everything’s a priority, then nothing is a priority.

Here’s the bottom line as you slide into Home: A hardware defect management solution that facilitates collaboration and supply team visibility into defect issues is critical to resolving potential defect issues. Ensuring everyone is literally on the same page is key. A comprehensive defect management solution that enables your product development team to stay in synch and collaborate to ensure product defects are communicated upstream and downstream across the enterprise is the winning combination.

Feel free to comment below and share with us additional “Worst Practices.” Also, consider subscribing to the blog so you don’t miss a post.