Why do some teams consistently meet their schedule, cost, and quality targets and others do not? There are libraries full of answers, but I will discuss two that I believe are critical for effective teams:
- Make sure all team members know the company’s Product Development Process.
- Know which deliverables all team members must provide to each other.
The first part of this article will review a typical product development process for an electronic/mechanic/software “system” product, including some of the primary tasks that occur in each phase. This article will also include a couple of examples that illustrate why #1 and #2 are essential for rapid product development.
I. Product Development Process
Every company has a Product Development Processes (PDP). The names of the phases and the number and timing of tasks in each phase may differ, but most companies break the phases into the following five areas:
- Concept Phase.
- Planning Phase.
- Development Phase.
- Mass Production Phase.
- End of Life Phase.
Figure 1:Phases and Deliverables
Concept Phase
The purpose of this phase is to investigate the feasibility of a product idea. The product idea is poked and prodded to see if a viable business case can be made. The following are some of the deliverables of the Concept phase:
- Market Requirement Document.
- Product Cost Estimate.
- Project Schedule.
- Human Resource Requirements.
- Project Budget Estimates.
- Technical Feasibility Analysis.
Participants in this phase are the Product Manager, the Project/Program Manager, and an Engineering or Operations Manager.
Planning Phase
The purpose of this phase is to build a business case to justify committing human resources, capital, and equipment resources to develop a product.
During this phase the product specification is finalized and product costs, program costs, and human resource requirements are verified and development plans are created. Plans may range from a single page overview for a simple project to a collection of individual plans created by each functional team members depending on the complexity, cost, or risk of a project.
Team members from some or all of following functional areas may be involved in writing and/or reviewing development plans:
- Program Management.
- Marketing Product Management.
- Finance.
- Electrical Engineering.
- Mechanical Engineering.
- Software Engineering.
- Software Quality Assurance.
- Test Engineering.
- Customer Service.
- Environmental Engineering.
- Packaging Engineering.
- Human Factors Engineering.
- Industrial Design.
- Compliance Engineering.
- Operations Program Management.
- Manufacturing New Product Development Engineering.
- Quality Assurance.
- Reliability Engineering.
- Supplier Management.
- Purchasing.
- Technical Publications.
Product Development Plan
This plan describes the scope of the project. It may cover the following areas:
- Product Description.
- Project Schedule.
- Human Resource Requirements.
- Project Cost.
- Communication Management.
- Change Management.
- Risk Management.
- Integration Management.
- Procurement Management.
- Risk Management.
Development Phase
During this phase the product is designed, built, tested, and readied for mass production. Primary activities include hardware and software design, fabrication of prototypes, product functional testing, design reviews, fabrication of production tooling, pre-production (Pilot) assembly builds, safety and immunity regulatory testing and approvals, and engineering documentation release to production. In addition product packaging, user manuals, and other printed material is created and marketing materials are prepared.
The product may be approved to proceed into mass production after proof has been provided that the product and the project have met all their pre-production goals.
Mass Production Phase
This phase represents the active life of the product. During this phase minor product changes may be required to fix product performance issues, solve component availability issues, improve manufacturing yield, changes to reduce product cost, or other sustaining issues.
End of Life Phase
During this phase production termination is planned and executed.
II. Example Product Development Process
The following illustrates why it is important for the team to anticipate potential problems and have backup plans ready even if implementing those means a deviation from the documented Product Development Process (PDP).
New employees typically learn their company’s PDP during their first few weeks of employment. They are told to follow it as the Gospel. In many cases their yearly evaluations may be tied to metrics associated with the PDP.
The PDP describes an idealistic process. However I have found that it often must be modified to accommodate project changes, particularly for consumer electronics and computers products, which have extremely aggressive timelines and challenging technical features. After a while deviations to the process may become the norm.
The example below describes what happens when a product fails a qualification test requiring a second unanticipated system build. But first I will describe the three typical product assembly “builds”:
- Prototype Build: The purpose of the prototype build is to verify that all the features in the system function as specified. Prototypes are usually made from temporary tooling in quantities of 1-5 units and are hand assembled by engineering.
- Design Verification Build: The purpose of this build is to verify that all product features function within specified limits and that the system can meet its environmental, regulatory, safety, etc. requirements. The units are fabricated using production tooling, and are representative of the mass produced product. Build quantities are usually 50 to 200 units.
- Pilot Build The purpose of the Pilot build is to verify that the assembly line is ready for mass production. Build quantities range from 100 to 300 units.
Suppose a problem comes up during agency testing of the design verification units. The problem prevents it from passing FCC certification for example. The fix requires a significant change to the circuit board assembly. If the product had passed FCC testing, the next build would have been the Pilot but now the team realizes another build will be required. The team gets into an argument about what to call this new build, the quantity of units required, the cost of additional testing, and of course, the impact to the schedule.
During the heated discussion the Sourcing person says that there are not enough parts in stock to support this additional build. The argument devolves into a shouting match with the engineers saying, “I told you this might happen! Why didn’t you plan for it?” And the sourcing manager yells back, “You did not tell me this might happen!” “Yes I did!” “No you didn’t!” …etc.
Why did this happen and what could have been done to avoid it? The answer to both is that the team failed to perform a comprehensive risk analysis and mitigation planning at the beginning of the project. If that had been done they may have decided to purchase enough components for an additional build.
III. Example: Team Deliverables
The following example illustrates why it is important for team members to become familiar with the requirements of all their teammates, not just the ones they interact with on a daily basis.
Each team member knows what information they require to do their work and know what the people receiving their “work product” requires from them. Those providing the input, doing the work, and receiving the output often work together on a daily or hourly basis.
Figure 2:Cross-Functional Team Interaction
However, engineers are less familiar with the needs of team members that they interact with less frequently. For instance graphic artists and engineers typically do not work with each other yet the graphic artist needs technical information from engineering in order to complete printed material such as the User Guide, marketing materials, and product packaging.
Occasionally technical information changes during development. This can occur when a product fails a test and the team decides to “relax” that portion of the specification that resulted in the test failure. These types of decisions are often made “during the heat of the battle” and sometimes not everyone on the team gets informed of the change in a timely fashion – especially those who are not directly involved in solving the problem.
Ideally, engineering changes are communicated to the graphic artist before the artwork is finalized but often errors are caught only after the packaging has been printed. The result is a scrap and schedule slip.
What can be done to avoid this scenario? Three things:
- Good process.
- Good communication.
- A good understanding of how product changes affect all functional groups.
A good product development process will include design reviews of artwork by all cross functional team members well before material is printed. Good communication between team members ensures that changes are identified and resolved quickly. Lastly, experience working with various functional team members builds familiarity with each other’s requirements.
This can also be addressed during an “Integrated Baseline Review” which is held in the Planning Phase where the schedule and development plans are reviewed. The schedule, if built correctly, not only includes tasks required for each deliverable, but also dependencies between tasks across functional groups. Similarly, development plans describe what each functional group will do, but should also include the deliverables required from other functional groups.
Conclusion
This article discusses two elements that can help teams execute quickly:
- A good understanding of the company’s Product Development Process.
- Identifying the deliverables that each team member must provide to each other.
The PDP is an ideal process but it may need to be modified to accommodate unanticipated problems – that’s OK. Lastly, everyone knows their job and what they need to do, but may not be aware of what their fellow teammates need, particularly if they seldom interact with each other. There is no substitute for experience, but a team review of schedules and plans can help uncover these interdependencies.
