In PRG’s most recent panel, experts shared their perspectives on how best to manage risks in the hardware development process.
PRG’s Michael Keer moderated the discussion. The panelists included:
- Wayne Firsty, Sr. Director Product Engineering, Manufacturing and Test, Nutanix
- Ken Kapur, Director Global Product Compliance, Thermo Fisher Scientific
- Wayne Miller, Former VP of Product Design & Development, Wonder Workshop
- Geetha Rao, CEO, Springborne Life Sciences
What does the “X” mean in DFX1 given your role and your background?
When asked what “X” means to them, the panel almost universally concurred with Wayne Miller’s conclusion that “X” means everything including:
- Assemblability
- Cost
- Manufacturability
- Serviceability
- Supply Chain
- Regulatory Compliance
Whatever it takes to get from prototype into high volume production. However each panelist had input on a particular area of “X” relevant to his or her role and experience. For Ken Kapur, his “X” is compliance. “My focus in terms of DFX is how do you work through the development processes early and make sure that you’re hitting the right milestones and including compliance into those deliverables.” As a medical developer, Geetha Rao designs for FDA compliance. Her focus is to design to control risk: “I look at what are [my] risks, what are [my] processes, what are [my] processes for identifying and managing those risks– and then which of these can come back to get [me] later, and make sure [I] have processes in place for this now.”
Wayne Firsty also focused on the importance of processes in place to manage the “X” factors. “Since there are more ‘X’ factors than you can think about, you must focus on what is important.” But he also warns that you can’t ignore what you can’t immediately touch. You must consciously defer and track them, not ignore them. Wayne also uses and 80/20 rule: “In some cases look at the 80/20 rule and say, you know what, for 20% of the effort I can get most of what I need to accomplish in that area.”
What are the biggest risks you see that impact the product development process?
Don’t Know Square
Coined by Wayne Firsty, this is the “You don’t know what you don’t even know” risk. You are better off when you know what you don’t know, so that you can go outside and seek for some help.
Requirements Documentation (PRD, MRD, TPT, etc.)
- If you haven’t properly developed requirements documentation, you can spend an awful of time and money working on a product that isn’t relevant because of something that you missed.
- Because they are needed for compliance!
The Silo Approach
- When there is singular strong focus on one piece, with too much disregard for the other pieces that are needed to make the product puzzle come together.
- Note: Requirements documentation forces the communication between silos!
Schedule Risks
- Conduct a really good risk assessment. Identify challenges and gaps and how to address them.
- Comprehensive Plan: include schedule and all program components and have outsiders review it for completeness.
Compliance Risks
- Apply the same risk assessment for compliance risks!
Total Cost
- Focus on Total Cost instead of Price to avoid short-sighted decisions.
What are some of the emerging risks you see in your areas of expertise?
Human Resources
One of the biggest challenges in Silicon Valley is the availability of the right human resources for your project. The result is that many work teams are dispersed, making use of global resources. In some instances, whole areas of projects are outsourced, which presents a risk of its own. As Wayne Firsty points out, often a company outsources an area of core-competency, which lessens the company’s future strategic advantage in that area.
Interconnectedness and Interoperability and Unintended Uses
The medical and health fields present risks and challenges in the areas of interconnectedness and interoperability, as well as cybersecurity and privacy. Another issue that Geetha Rao identified for medical is dealing with the emerging risks from the way a product might be used in a plug and play world: theoretically, it may get used in ways that were never intended or were never envisioned that raise safety, medical or clinical issues.
Developing products for the global market
The product that you develop for the North America and Europe market is designed for different certification and compliance standards than what you will face in Asia and other markets.
How do you keep product development projects on track? What are the tools, techniques that you use?
Keeping product development on track requires active management. Whether it’s a large company or a small scrappy startup, you need a framework for product development. The former may have a sophisticated and formal NPDI process, while the startup simply uses a checklist for each product milestone. It is critical that each company works through their process, whatever it is, checking the boxes and verifying that the product requirements have been fulfilled.
A Technical Program Manager (“TPM”) can be useful to keep things on track. Wayne Firsty warns that as you’re thinking of putting together a plan, you must be careful of what they call “drinking your own kool-aid–” that is, “the euphoria that it’s all going to work and it’s going to work the first time. the parts are all going to be there… ” In reality, it doesn’t happen that way and you need to understand the potential pitfalls.” An experienced TPM can provide that background and understanding. Firsty also recommends to have someone in your meetings as an appointed devil’s advocate who asks “what if this happens, what could we do differently?” The devil’s advocate helps you understand risks up front when they do happen.
Finally, Geetha Rao suggests teams to be mindful of the differences between tasks and deliverables. “Sometimes we define tasks as delivering a deliverable and sometimes we define a deliverable but think about all the tasks to get to that goal.” She stresses that you must see them as 2 different dimensions upon which you layer the schedule and all of the risks.
How many build cycles are typically required to get a product successfully to scale? What are the critical areas that need to be validated?
Whether you call it EVT, DVT, PVT, Proto or whatever, the consensus is that you will need more than one build cycle to validate and scale your product. More likely, you will run 3-5 cycles.
- Make sure your specifications are clear.
- Build processes in as early as possible.
- Plan for an iterative approach.
- Do an early release at the lowest risk, for example, a friends and family release. But make sure not to confuse this release with product!
- Software heavy products are using more of an agile approach, doing continuous development, working in sprints.
- At the end of each sprint, take stock of your progress toward release targets.
- Manage your development within each cycle!
- Another build tip from Ken is to test your product through a subsystem component program to reduce risk. If components are compliant at the subsystem level, the final stage of your product is just putting it together, making sure the system works, and checking the system specification. Testing subsystem components helps accelerate development.
5 Tips to help Mitigate Hardware Development Risk
- Create a clear Product Requirements Document (PRD)
- Set realistic timeframes and costs for development, testing and transfer to manufacturing
- Plan to meet regulatory, safety, and compliance requirements
- Avoid last minute changes in product features and functions
- Get visibility for production yields and perform root cause analysis for failures early
(1) Under the label design for X, a wide set of specific design guidelines are summarized. Each design guideline addresses a given issue that is caused by, or affects the traits of, a product. The design guidelines usually propose an approach and corresponding methods that may help to generate and apply technical knowledge to control, improve, or even invent particular traits of a product. https://en.wikipedia.org/wiki/Design_for_X
