The design plan is the path you expect to take in creating the design. Given your knowledge of the product’s complexity, what tasks will need to be involved? Who will need to take part and how long will the process take? What resources will be needed? The design plan will be your road map for the remainder of the process.
9001:2015 states that planning must consider the nature, duration, and complexity of the design-and-development activities. This means that the design plan for a manned space rocket is going to be much different than a design plan for a plastic toy. The trick is to match the design plan to the nature of the product being designed. Some design plans are little more than a memo or a flow diagram. For more complex products, the design plan may comprise many documents, including a Gantt chart, critical path, work breakdown structure, and other project management tools. ISO 9001:2015 doesn’t explicitly require the design plan to be maintained as documented information, but it would be difficult to communicate and manage without it being documented. Only use as much planning as you need. Remember, the purpose of design planning is to help you manage the design process, and there’s no extra credit for being fancy or using complicated tools. The way you achieve design planning is completely up to you. Your design plan will typically address a number of variables: Duration of the project. When does the design start, and when do you hope to have it finished? Does the expected duration match the nature and complexity of the design?
Design stages. What major tasks must be performed to produce the design? In what sequence should these tasks be performed? Design reviews—where you review progress and address obstacles—must also be planned.
Verification and validation. Verification is where you check the design outputs against design inputs. Validation is where you check the design under conditions of actual use. Both of these must be planned.
Responsibilities and authorities. Who will be involved with this design? What will they be expected to do, and what do they have the authority to do? Do the participants understand and accept their responsibilities?
Resources. What funds, facilities, equipment, supplies, and other resources will be needed to complete this design? Have the resources been secured? If not, where will they come from? Make sure to address resources from internal sources, as well as external sources.
Interfaces. With whom should the persons with design responsibilities interface or interact? Nobody works in isolation (or at least they shouldn’t), and it’s important to drive as much communication and interaction as possible.
Involvement of customers and users. Not all designs require the involvement of customers and users, but this kind of interaction must be carefully planned when needed. Many consumer products make use of customers and users at various stages of design.
Requirements for production. You must plan for how the design might affect other parts of the organization. Are there safety issues that must be considered?
Are there environmental issues? Are there implications for packaging, storage, and transportation?
Level of control. It’s safe to assume that the organization will be expected to have primary control over its design process. There may be certain aspects of design outside the organization’s control. It’s possible that customers and interested parties may have certain roles to play in design, such as participating in design reviews, design verifications, and validations. The levels of control and responsibility for all activities should be defined during the planning process.
Documented information needed to demonstrate requirements have been met. During planning, you must determine which documents and records will be needed during the design process.
For some organizations, the design plan is basically the same each time they design something. It’s a routine process, with the only difference being the specific timing of the tasks. Organizations that design variations of the same kind of product often fall into this category. In these cases, there’s no reason to make the design plan any more complicated than it needs to be. A simple template with spaces for the dates to be filled in works very well.
8.3.3 Design and development inputs
Inputs tell us what design and development must satisfy. The inputs may come from market research, customer feedback, sales reports, or pure speculation. Regardless of the source, ISO 9001:2015 outlines five areas that must be included as inputs:Functional and performance requirements. How should the product function? What must it be able to do? What resources must be available to support it? What are the product’s limitations?
Information from previous designs. There is a chance that your organization has designed a similar good or service in the past. Apply lessons learned in the earlier design to the current project.
Statutory and regulatory requirements. What laws govern the production and use of your product? Are there any regulatory guidelines related to your product? How do these issues affect the design process?
Standards or codes. These might include internal requirements and industry standards to which the organization subscribes.
Potential consequences of failure. If we failed to accurately identify all the design inputs—or failed to execute the inputs—what bad things could happen?
This is risk analysis applied to the design process itself.
Design inputs are often captured in meeting minutes, memos, design worksheets, market summaries, and sometimes on cocktail napkins. Wherever they are captured, they must be complete, unambiguous, and reviewed for adequacy. As part of this review, inputs should be analyzed for requirements that conflict with one another. Any conflicts in design inputs would need to be resolved. The design inputs are considered by ISO 9001:2015 to be retained documented information (i.e., records), as they indicate what the organization required at a particular time.
8.3.4 Design and development controls
This subclause of ISO 9001:2015 combines a number of separate activities into a single element. This is where the requirements for design review, design verification, and design validation now live. A number of controls are listed here: Results to be achieved are defined. The objectives of the design are the design inputs, which we discussed in the previous section. Design reviews are conducted. Verification activities are conducted. Validation activities are conducted.Actions are taken on problems discovered during review, verification, or validation. The whole purpose of these activities is to verify that you’re meeting design requirements. If you fail to meet requirements, then action is certainly necessary. Documented information of all these activities is retained. Records must be kept of reviews, verifications, and validations. Design review, verification, and validation are potentially complex processes. For many organizations, they warrant more than a one sentence explanation. Let’s talk about each one of these in more detail.
Design and development review
Design reviews are the way you make sure the design is proceeding according to plan. All designs have at least one design review, and complex designs may have many more. There’s no particular magic to the number of design reviews. If the design process has significant complexity and risk, there will need to be more design reviews.One of the key planning activities is to decide how many design reviews are appropriate for the particular product being designed.