Originally published in September 2017 at The Lean Post
Design reviews are a common process in product and process development. They can enable knowledge sharing across an organization and prevent the same mistakes from happening across different groups. But not all design reviews are effective and how and when they are conducted varies widely across different companies, and even within a company. To have more effective design reviews that enable real-time innovation we can learn from Jim Morgan and the tips he shared in one of his e-letters, The Crucible of Innovation.
We can also learn about the process of improving design reviews from the experience of one organization that recently did that. The lessons learned include both tips for successful improvement projects along with specific learning on conducting more effective design reviews to enable better product and process development.
Prior to the improvement project, different groups used different processes for design reviews, which were inconsistently followed. Design reviews were often held close to design releases making it difficult to make changes based on what was learned in them without negatively impacting the project schedule.
The planning phase of the plan, do, check, adjust (PDCA) cycle was very important for changing the design review process. This started with creating a project team with a mix of the people who do the work and management that can influence and help implement the change. Management involvement was important to be able to address system-level issues. The project was also scoped appropriately to be able to manage the amount of change that would happen. The project focused on mechanical design reviews and within that had clear boundaries for what was in and out of scope.
Many of the engineers thought they knew what was wrong with design reviews prior to grasping the current condition. But taking the time was important for both understanding the problems and getting people to want to change how design reviews were done. This included surveys, case studies of problems not found, and attending design reviews. During interviews people had time to reflect on past projects and design reviews. And managers had data to make decisions rather than using opinions or gut feel. While the engineers were initially right on approximately 60 percent of the problems, they would have missed the other 40 percent of problems if they hadn’t taken the time to understand. It became clear that when design reviews failed to identify a problem, 70 percent of the time someone else in the company knew that it would be a problem. The organization had the knowledge, but it wasn’t easily accessible. Effective design reviews and/or design guides could have caught these problems.
A root cause analysis was used to better understand repeat issues. Some of the issues found in that analysis were:
- Teams were not set up to be able to follow the design review process effectively.
- Vague expectations led to everyone interpreting them differently, doing different things with different results.
- The teams didn’t have the right knowledge of who the appropriate people to attend the design reviews were.
Countermeasures that were put in place were:
- Defining design review timing in a template – ensuring there is sufficient time after the reviews to mitigate identified risks prior to milestones including design freezes.
- Creating a design review template with standard content – providing clear expectations of what should be reviewed.
- Creating a standard template for attendance at design reviews. Attendance includes both reviewers who are consistent across all projects to facilitate organizational learning and key cross-functional point people to determine who within those functions has the appropriate knowledge to contribute to the design reviews.
- Creating a design review process flow, including a follow-up template. This ensures there is consensus on the risk mitigation plans with monthly follow-up to close the issues.
The benefits of changing the design review process have been realized relatively quickly. Identified risks are resolved earlier in programs, preventing late tooling changes. And knowledge is more effectively shared across projects. After the success in mechanical design, the organization intends to expand the improved design reviews to other functions and to the system level design.