Change is sometimes the enemy of an efficient and cost effective product development process. While change is inevitable and necessary at times, minimizing unnecessary product change is important to keep the project on schedule and within budget while continuing to meet all the product specifications. There are three true and tried methods that, if implemented in a product development process, will result in a highly effective product change management process.
Communicate the Program Objectives to the Team
Product development can be summarized as a balancing act between the competing constraints of product cost, scope, and schedule. Thousands of decisions are made while a product is under development and the end result is typically a sub-optimal result of these decisions. Since optimization is impossible, it is necessary to prioritize the objectives of the project in order to ensure success. Without prioritization, the individuals working on programs will be pulled in opposing directions and will be continually redirected during the project, resulting in failure. Proper prioritization of product cost, scope, and schedule will result in successful change management.
The three objectives of a program are product cost, product scope, and program schedule.
Product Cost refers to the many financial metrics, including total budget, cost of goods sold, gross margins, or any other financial metrics used on the project.
Product Scope refers to the product features that will be designed into in the final product.
Program Schedule refers to the amount of time available to complete the project.
Unfortunately, it is impossible to change one of these objectives without affecting the others. The cost, scope, and schedule each act as constraints and therefore movement of one affects the others. Hence, to properly communicate the program objectives, a product development team should:
- Determine which of the three program objectives is the most important. This chosen objective will be the first program priority that must be constrained and cannot change under any circumstance.
- Choose one of the two remaining program objectives that can change but must be held within a range. The second priority should be thought of as an objective that can be modified but should always be kept as close to the goal as possible.
- The outcome of the last program objectives will be accepted as is.
Some hard tradeoffs need to be made when prioritizing the program cost, scope, and schedule. By performing this exercise and communicating the priorities, the product development team will be given very clear objectives that allow the members to make their own decisions on the necessity of change knowing the overall program priorities.
The management of these three constraints is sometimes referred to as the project management triangle.
The video was produced by J Scott Christianson at http://thefreerangetechnologist.com/ – He has a lot of great project management tips and information on his site.
Product Defects and Issues Drive Change
The product development team should work with the premise that product change is driven only by product defects and issues. The defects can be technical issues or issues raised by anybody on the cross-functional product development team. The technical issues found from the mechanical, electrical, software, firmware, manufacturing, or production teams are obviously product defects that need to be reviewed. Issues from other members of the cross-functional product development team such as marketing, sales, advertising, finance, or field sales need to be considered also. For example, if a new product was introduced in the market with very similar features to your team’s product, then it would be wise to raise a product issue to modify or improve some of the features to differentiate the product. If the product cost was too high and cost was a high priority for the program, it would be necessary to change the product design to minimize the cost. Defects and issues from all the cross-functional members of a product development team can influence change.
Defects and issues can be managed by a complex Product Lifecycle Management (PLM) system or a simple spreadsheet. Either way, it is important to document the root cause of the defect, proposed solution of the defect, method of solution verification, and implementation of the solution for completeness and traceability of the defect.
Establish Change Rules
The final method of ensuring a successful product change management solution is to establish rules of changes. If and when a product change is made depends on both the severity of the defect as well as when the defect is found in the product development lifecycle. Product defect severity can be broken down into four categories:
- Low: Very limited customer impact.
- Medium: Moderate customer impact.
- Serious: High customer impact.
- Critical: Safety or regulatory issue.
The program manager of the product meets with the cross-functional product development team to review each documented issues and defects. As a team, they categorize the defects as either low, medium, serious, or critical. Once the defects are categorized, the team must decide if a change should be made to the product to resolve the issue. The team should have rules in place that determine when the changes should be made depending on where the product lies in the product development lifecycle. Here are some rules of thumb on approving and allowing product changes to take place:
- Critical defects should always drive an immediate change and the production line should be shut down if the product is in production.
- Serious defects should be fixed as soon as feasible and rolled into prototype testing or production.
- Medium severity defects should drive changes the early stages of the product development lifecycle but should not be resolved during production.
- Low severity defects should only be fixed in the early prototyping phases and should be ignored in all later stages of the lifecycle.
If the product development team has a rigorous defect review process and change rules, then only necessary changes will result from the product change management system.
Need more information on product change or product development in general? Please contact us with any questions or contact me directly at joseph.donoghue ( at ) leardon.com