Changing Landscape
It seems like every manufacturer wants to have their widgets to be able to communicate through the Internet. In our Digital Condo i have 11 different digital apps controlling various functions from Nest looking after my HVAC, Kohler Konnect for my plumbing, Legrand for lighting and of course Spotify to keep me calm with soothing music. Why many of these digital apps require updates and this means i need to reconfigure my Google Home app.
What this really means is that companies are integrating new technology without having a solid infrastructure to support this feature expansion. My plumber (who only knows that water runs downhill) was completely lost when trying to connect my plumbing through an app. Similar, we have a client who decided to go the route of automation because getting labor was virtually impossible.
So just like we preach about building an FMEA during New Product Introduction, we cannot stress enough that you focus on "De-Risk" your engineering especially if adding a new dimension. And as part of De-Risking you also need to focus on the capability to Service the device.
Modern Products Are Complex
Modern connected products require close coordination of multidisciplinary engineering teams during development. Mechanical, electrical, and firmware engineers, industrial designers, and engineering technicians all need to be on the same page in order to integrate their work into reliable, functional products that are also manufacturable.
The demands of coordinating these teams put a heavy burden on technical program managers and other engineering leaders. Despite the proliferation of advanced engineering tools within engineering sub-disciplines (i.e. topology optimization, etc.), managers of complex engineering efforts are left using the same set of project management tools to coordinate more work than ever before. If you’ve ever spent a day making a Gantt chart only to find it is woefully out of date by the end of the first week of your project, you know this pain.
Let’s explore a fundamental principle for managing complex electromechanical engineering efforts, what I call risk-first engineering management. The teams that figure out the most effective way to reduce development risk as early as possible are the teams that get to market faster and deliver better products.
Risk-First Engineering Management
Technology Development vs. Product Development
Depending on what kind of product one is developing, there may be large differences in research and development (R&D) burden and risk. It’s useful to think of this in terms of two distinct phases: technology development and product development.
Technology development is focused on the development of new capabilities through novel technology. It is greenfield, exploratory, and crucially it is not driven entirely by requirements. All of your effort should be directed at answering one question: “Is this even possible?”
Product development is focused on meeting a need in the market, as embodied by product requirements. For example, if you are developing a smartwatch for scuba divers, your watch design must be waterproof to 100 meters for 10 hours. Broadly speaking, you know what the product needs to do, and development is about engineering execution to meet those needs.
It’s crucial to understand where your engineering effort is directed. If you are in technology development, the core focus needs to be on developing the technology to a point where it can be productized. Without this, you don’t have a product. Focusing any engineering effort on downstream refinement before the fundamental technology has been proven is incredibly risky.
Stack Rank Your Big Bets
Once you’ve advanced to a state where fundamental technology has been de-risked, you need to chart a path that meets your product requirements.
At this stage, it is equally important to think risk-first. Look at your product requirements and segment them by risk. Summarize these risks in terms of your “big bets.” In our watch example, one important big bet is that the product “must function flawlessly underwater.”
The plan you develop should de-risk these big bets in a prioritized order that considers both the degree of risk and impact. This kind of prioritization gives development teams the most design freedom early in order to de-risk the most important requirements when the cost of development is still low and the design is not fully integrated.
Organizational Risk Should Also Be Considered
In addition to prioritizing product requirements, engineering leaders should think critically about team structure as it relates to development goals.
The coordination costs of smaller, cross-functional teams are lower relative to large but siloed engineering teams. Structuring teams cross-functionally and giving them both a mandate and the freedom to focus on your prioritized big bets reduces the communication burden across the entire engineering organization.
Fewer people in the chain of decisions and approvals means faster risk reduction and iteration. Some of the most incredible engineering programs were accomplished with surprisingly small, cross-functional, and tightly integrated teams One example of this is Lockheed Martin’s Skunkworks P-80 aircraft program.
Delay Integration As Long As Possible
This may sound counterintuitive, but when tackling your big bets, consider also how hard they are to test and de-risk. Do you need a fully functional prototype made with production processes, or can you 3D print a subassembly and evaluate it independently?
It can be tempting to try to make deeply integrated prototypes as early as possible because it can give you the illusion of progress. (Look at what we’ve built. It’s so close to done! It does everything we want…. except x,y,z…etc.)
It’s better to think about your product maturity in terms of requirements de-risked instead of the level of product integration. Proving that subsystems function on their own by using breadboards, subassemblies, and road-kill prototypes allows risk to be retired without establishing engineering and design dependencies that can cripple the development pace.
Plan for the Worst: You Won’t Get It Right Every Time
With complexity, comes both opportunity and unforeseen challenges. It’s just part of the game.
At some point, you will encounter engineering issues that throw off all of your plans. Get it wrong and you risk major delays, or even worse, never getting to market. But with a risk-first engineering management approach, you can be sure that these interruptions will happen earlier in development when the cost of recovery is orders of magnitude cheaper and the design is flexible enough to adapt.
コメント