Gated development processes have been around for over 25 years now, and I rarely come across a company these days that does not have some form of a gated process in place. A gate review process, when well implemented, allows leadership to evaluate projects from a business perspective at critical junctures, leaving day-to-day project execution to an accountable project team. Then why are so many of these same companies falling short of their innovation goals?
Kalypso conducted a study of 30 companies across multiple industries and found that, while all claimed to have a gate review process in place, few went very far beyond a list of phase objectives and deliverables. Their project teams lacked sufficient guidance and tools needed to plan, monitor, and successfully execute product development projects. They were missing the “how”. In other words, guidance on what happens “between the gates”.
This viewpoint is the third in a series that explores key steps in the product development process. The series covers opportunity proposals, product requirements and high level design, with a focus on execution and practical tips for project teams.
High Level Design
High level design, sometimes referred to as system design or design architecture, is the first step in developing a solution to address the functions and features described in the product requirements. If the product requirements describe the “what,” in terms meaningful to the customer, the high level design begins to describe the “how” in terms meaningful to the engineer, industrial designer, scientist, or manufacturer who is tasked with creating a producible solution.
Of the companies we studied, most struggled with three aspects of high level design:
- How to do it well
- Where it fits in the product development process (relative timing)
- How much or how far to take the high level design before beginning detailed design
How? Incorporate a System Approach
High level design starts with an analysis of the preliminary product requirements. Different design approaches are considered as you start to define how functional and other product attributes map to a system, product architecture (platform architecture in the case of new platform development), or formulation that is further divided into subsystems (or ingredients in the case of a formulation or drug). A design approach is described from a system point of view before being broken down into subsystem definitions. Throughout this process, you might develop system simulations, performance budget calculations, subsystem interaction analysis, technology feasibility assessments, and early customer interaction through use of rough prototypes. This is also the place to begin reviewing manufacturability, reliability, testability, serviceability, and product cost requirements.
Companies who incorporate a system approach will lay out a high level design that provides leverage for multiple product generations. Thinking strategically about those common design elements and the core, differentiating technologies (or chemical compounds) that carry forward from product to product can yield substantial R&D productivity, cost, production, and market benefits.
Where? Develop in Conjunction with Product Requirements
It is not wise to develop a set of product requirements without considering solution alternatives. As stated in Between the Gates, Volume 2, effective product requirements development requires a careful balancing of customer needs against technical, market window, schedule, product cost, production, and resource considerations. Creating a high level design in conjunction with product requirements allows development teams to assess the inevitable trade-offs that come from different design approaches. The knowledge gained from high level design will impact the feature and function requirements described in the product requirements document. At the same time, the relative importance of product features and functions will impact the design approach. For this reason, we recommend starting high level design in the early stages of product requirements generation - after a first draft is complete - and working through both of these highly interdependent steps in together.
How Much? Understand Trade-Offs, Set Guidelines and Leave Room for Judgement
The “how much” question is the source of endless debate in many organizations. The engineer being held accountable for a delivery schedule will want to work with the detailed design while the marketer ultimately responsible for ensuring that the product meets customer needs will want to conduct additional primary research to validate attribute preferences. If too much design work is completed before the product requirements are validated and locked down, companies run the risk of having to re-do the design. Successful companies understand the trade-offs involved, employ a clear set of guidelines for high level design scope, and leave room to the judgment of an informed cross-functional project team.
High level design is another central, integrative step that takes place prior to full scale development. Companies that do it well understand the interdependencies with product requirements development and are able to make appropriate trade-offs, giving project engineers, industrial designers, scientists, and manufacturers with a path to an easier solution.