Whether you've been doing design review for days or decades, you've probably put lots of thought into the designs you’re reviewing—but how much time have you spent thinking about the review process itself? After all, although it’s a necessary and common practice within the engineering design process, there’s no single standard or official classification system for design reviews. While different teams and organizations can have fairly defined or standardized reviews, it’s a topic that deserves close attention from companies that want to stay competitive in a quickly-evolving industry landscape.
Design reviews happen at various stages, in various formats, for various reasons. But at their core, design reviews are the main source of collaboration in engineering design. Whether it’s between internal team members or along with external stakeholders, vendors, or suppliers—reviews are how input on a project is gathered from everyone who needs to give it. When design reviews are executed better, it leads to stronger collaboration. In turn, stronger collaboration leads to better products, better execution, and better results.
For product development projects, timelines can range from weeks to a year or more. So it’s crucial to be strategic and intentional about when and how to best involve which people in the many decisions that need to be made over the course of a project. Doing this requires thinking deeply about design review, the ultimate goal of the process, and the different ways reviews can happen. Before you’re able to improve your review processes, it’s crucial to be able to take a step back and understand how they currently work (versus continuing with the “that’s just how we’ve always done it” status quo).
This post explores how and why design reviews happen, different ways to look at design reviews, common review types, and how these types are distinct from each other.
Why Design Reviews Happen
There are countless specific reasons why a design review might happen and countless specific ways that review could be executed. Overall, though, design reviews happen when different people involved in a development project need to come together somehow and share information, engage others in providing their expertise to the problem, and decide on the next best course of action. As mentioned above, it’s how design collaboration actually happens.
But who are the people involved in design collaboration? The answer to that question is going to change across project stages. Yet for typical product development, there are key groups that will be part of the project at some point (and, depending on the project and organization, some collaborators may be part of more than one group). There can be different language used for these groups, but essentially any given engineering project likely includes:
- Design teams: Those directly involved with the design efforts
- Project leaders: Those responsible for directing the efforts of the design teams
- Subject matter experts: Those with applicable expertise, but not directly involved in development
- Testing/QA teams: Those responsible for ensuring the design satisfies requirements
- Manufacturing teams: Those responsible for production
- Service/sustaining teams: Those responsible for the product once it’s delivered
- Customer/sponsor/end user/other stakeholders: Those whose needs define the requirements that drive the product development efforts
Deciding who needs to participate in which reviews depends on why that particular review is needed. Ultimately, the reasons for conducting a design review can be categorized into three main buckets. Reviews happen in order to 1) provide answers to questions, 2) provide clarity around assumptions made, and/or 3) to solicit guidance from subject matter experts. But once it’s understood why a review is needed, there are still other elements to be considered.
Formal vs Informal Design Reviews
One way to think about design reviews is to distinguish between formal and informal reviews. It’s possible for a formal design review and an informal design review to be conducted in very similar ways. What differentiates these two review types is not always the structure or format, but rather who is participating and why.
A formal design review involves stakeholders from outside the immediate design team, such as subject matter experts or customers. These reviews are scheduled in advance and follow a well-structured format with an agenda, meeting minutes, etc. They also have specific rules—usually outlined in a project charter or plan—regarding who must participate, and how.
Informal design reviews are usually scheduled on shorter notice or could be completely ad-hoc. Informal reviews often bring together cross-disciplinary teams working on the same problem, such as a mechanical engineering team and electrical engineering team, and address aspects of the design which require expertise outside of the immediate design team.
Technical vs Project Design Reviews
Another way of thinking about design reviews is whether they’re a technical review or a project review. Distinguishing between these two types of reviews comes down to the nature of what is being discussed. Technical reviews often mean looking at certain aspects of a project on a micro level, whereas project reviews tend to take more of a macro-level approach.
A technical review will usually involve a specific set of design team members and subject matter experts. This is where the review participants take deeper dives into technical content, maximizing the collective expertise of those involved in design and development efforts. Technical reviews can be formal or informal, and tend to produce actions at the individual task level.
Project reviews involve a larger set of participants than technical reviews, perhaps including the customer or other stakeholders. There may be some technical discussion in a project review but ideally these would be limited in scope—often this is where major points from technical reviews can be brought forward. Project reviews are usually formal reviews due to the participants involved, and typically include discussions on budget, schedule, resources, etc.
Common Design Review Types
Although the specific language and phrases used to describe a certain type of design review can often differ between different teams or organizations, there are some common review types that have distinct purposes and/or goals. This is by no means an exhaustive or authoritative list. Rather, it’s meant to be a helpful resource for anyone giving critical thought to the current design review processes on their own team. Even if all these review types are familiar to you, it can be useful to look them over in the context of evaluating how your organization works together—and where there might be room for improvement.
The review types listed here are described in the broadest terms. As with terminology, the specifics of what’s involved in different review types can also vary across different companies. And in some cases, these reviews may be conducted during the same meeting or they may happen in parallel to each other.
Here are seven common types of engineering design reviews:
- Requirements Review: Ensures requirements have been captured appropriately and that stakeholder needs have been adequately described.
- System/Conceptual Design Review: Assesses system level tradeoffs and feasibility of design concepts and seeks buy-in from stakeholders to proceed with detailed design.
- Preliminary Design Review (PDR): Focuses on technical matters, discusses strengths and weaknesses of design concepts and proposals, and leads to project updates.
- Critical Design Review (CDR): Includes thorough review and analysis and typically happens before handoff of design from one phase to the next.
- Test Readiness Review (TRR): Verifies requirements, test plans, and test apparatus designs in a specialized review prior to handoff for testing.
- Final Design Review (FDR): Evaluates test results and addresses any issues that arose during testing.
- Production Readiness Review (PRR): Includes review of first article inspection (FAI) results after initial manufacturing runs and informs revised manufacturing cost estimates.
Design Review = Collaboration
Michael Dell once said, “Collaboration equals innovation.” The engineering teams that innovate bigger and faster are the same teams that make collaboration a top priority. When designing and developing complex products, the old adage that two heads are better than one becomes highly relevant. And within the engineering design process, design review is one of the most important ways to ensure collaboration has a place to happen.
Understanding the value of robust and effective design reviews is simple—but that doesn’t make them easy to execute. Complex design leads to complex projects with long timelines, multiple phases, and many stakeholders. Getting (and keeping) everyone on the same page is no small piece of the puzzle.
Yet with advances in technology and software, engineering teams have a greater ability than ever to update and improve their design review processes. While the nature of complex mechanical design has previously made it challenging to solve design review problems with generic project tools, CoLab’s purpose-built and web-based application is already transforming how engineers and teams around the world execute on design review. (You can get the details by browsing these customer case studies.)
But before adopting a new tool, it’s valuable to start by looking at how and why design reviews currently happen in your organization. Once you do, you’ll be able to pinpoint what’s working and what’s not so that you can move toward finding solutions that will work for your unique needs. By updating your design review processes, you’ll drive more collaboration—which is ultimately what will lead to true innovation.