Leardon Solutions is self-hosting this blog

Leardon Solutions will be self-hosting the blog available at www.leardon.com.

Integrating Subsystems into a Detailed Design Prototype

After management gives the approval to proceed into the Design Prototype Phase, the product development team should be ready to begin integrating the proven subsystems into a complete design with the look and feel of the final product.  This will be the first attempt to create an integrated product.  By the end of this phase, the team will have proven that the integrated product meets the product specifications generated in the Definition Phase. 

The Design Prototype Phase is a phase where program management becomes critical.  In the Feasibility Phase, the product development team was much smaller without the requirement to work as a cross-functional development team.  In this phase, the team consists of individuals with all types of skills, all of which are absolutely necessary to get through this phase.  The coordination and integration of the skills is required to have a fully functional team.  A poorly integrated team will develop a poorly integrated product, resulting in delayed schedules, higher costs, and poor quality.  

Below are the four activities that occur in the Design Prototype Phase.  A short explanation of each activity is provided below the list.

Design Prototype Phase Activities

1.  Detailed Design and Prototype

            Product design that meets form, fit, and functional requirements

            Develop packaging design

            Product design reviews with cross-discipline team

            Design margin and tolerance analysis for critical parts and assemblies

            Generate all required design documentation

            Fabricate quick-turn prototypes to validate integrated functionality

2.  Qualification, Verification, and Regulatory Testing of Prototypes

            Develop qualification plan that validates and verifies integrated functionality

            Execute first phase of hardware, software, and firmware qualification plan

            Test product under regulatory and compliance testing conditions

3.  Supply Chain Strategy

            Capacity, ramp plan, and product volume forecast

            Develop production tooling strategy and schedule

            Assurance of supply analysis for each component and vendor

            Identify key suppliers and technologies

            Initiate supplier contracts

            Develop a distribution strategy

            Develop a reverse logistics (service and support) strategy

4.  Program Management/Product Development Plans

            Align Engineering Disciplines to Overall Product Schedule

            Review Intellectual Property and File any New IP

            Implement a Defect Tracking System

Activity 1.  Detailed Design and Prototype:  The technical and engineering team must modify the designs of the subsystems and integrate them into a complete product that has the look and feel of the final integrated product.  The resulting design must be designed knowing that it must meet or exceed the product specifications developed in the Definition Phase.  Not only does the design need to meet the functional requirements, but it must also meet the form and fit requirements driven by the human factors and industrial design teams.  After generating these designs, the engineering team should perform theoretical analyses of the design.  For example, the mechanical design engineering team will analyze the design so that it will properly function with parts having a range of dimensions.   This is called tolerance analysis and the resulting performance over the tolerance range is referred to as design margin.

Once the design is complete, the team must generate documentation that allows prototype vendors to produce the parts.  The mechanical engineers will generate 2D and 3D documents.  The electrical engineers will generate gerber files that specify the printed circuit board and assembly design.  These prototype designs will be fabricated with the documentation using quick-turn prototype capabilities such as machining, stereolithography, quick-turn PCB, or silicone molded tools.  The reason for using quick-turn prototyped parts is to minimize the lead-time of the prototype as well as minimize the cost of the fabrication tooling.  The low-volume needs of this phase do not require production fabrication techniques which are costly and take time but are required to hit the production goals later in the commercialization life cycle. 

Activity 2.  Qualification, Verification, and Regulatory Testing of Prototypes:  The quick-turn prototypes are used to qualify and verify that the product design meets the product specifications.  In the previous phase, the team generated a document which stated the qualification and regulatory testing that must occur in each stage of the design.  The design prototypes should be taken through these qualification tests to verify that they meet the specifications.  Design changes should be the result of specifications that are not met.  Note that the qualification plan includes all the mechanical, electrical, firmware, human factors, and software tests.  The data generated during this activity is very critical to the success of the program.  If the team decides not to do a thorough job testing the product, the issues will only arise later when design change is harder and more constrained.  The team must be very rigorous with testing in this phase.

Activity 3.  Supply Chain Strategy:  This is the first phase where the supply chain professionals become involved in the project.  The plans generated by this team are critical for the success of the product.  The first step to develop the strategy is to communicate with marketing and understand the expected product forecast.  This will drive the required manufacturing and production capacity as well as the expected production ramp.  The product volume forecast along with the prototype design documentation is required to develop a production tooling strategy and schedule.  For each part in the design, the procurement team must evaluate how this part will be produced in high volumes and then determine what tooling is required and how long the tools will take to fabricate.  This requires that vendors are located for each of the technologies to be used in production of the product.  By the end of this phase, contracts should exist with each supplier denoting pricing of the parts to be sourced.  Note that this information will feed into the program budget and schedule. 

The supply chain team must also work on a distribution strategy.  The marketing team will determine where the products will be sold and the logistics team will use this to generate a logistics strategy.   This strategy includes in-bound material logistics and shipments from suppliers as well as out-bound product logistics and shipments from the final factory.  Finally, the team must determine how they will support and service any products that are in the field or products that fail.

Activity 4.  Program Management/Product Development Plans:  As stated in the introduction paragraph, the management of the program becomes critical during this phase.  The managers must integrate the team and align the schedules of each engineering discipline to the overall deliverables of the program.  A complete and rigorous schedule will include the dependencies from each engineering discipline.  This schedule will allow the team to function properly and understand their deliverables and deadlines. 

It is also important to go back and review the status of intellectual property on the program.  First, verify that the team is not infringing on existing intellectual property.  Second, determine if there is any intellectual property that should be filed with the new designs. 

The final objective of the management team in this phase is to implement a defect and issue tracking system.  As designs mature and qualification testing takes place, there will be a large number of issues that arise.  These issues can only be properly solved if the complete team is exposed to the list of issues and defects.  Plans to resolve the issues/defects will result from this defect list.  Also, this list will be especially important for the program manager as s/he will be able to properly focus their efforts on the largest issues.

Throughout the Prototype Design Phase, the team is developing a design that meets the product specifications.  In order to move to the next phase of preparing the design for production, the team must pass the Product Design Checkpoint (PDC).  The four deliverables that should be completed at the end of this phase are listed below.  These deliverables should be presented to the upper management team in a formal presentation.  Once the approval is given to move to the next stage, all these documents need to be approved and remain under revision control.  The format for each of these documents is at the discretion of the company developing the product.

Product Design Checkpoint (PDC) Deliverables

1.  Product Design Documentation

            Integrated product design documentation

            Design reviews sessions documented

2.  Qualification, Verification, and Regulatory Document

            Demonstrated functionality of quick-turn integrated prototypes

            Updated qualification document

3.  Supply Chain Strategy

            Tooling strategy, assurance of supply, and supplier plan

            Product forecast and capacity

            Distribution and reverse logistics plan

            Key supplier contracts

4.  Product Development Plan Document

            Program schedule, financials, and expenses approved

            Documented release criteria for ship/no-ship

Copyright 2010 Leardon Solutions

Next blog posting: Get the Design Ready for Manufacturing Millions of the Product.

Are the Product Features Feasible?

When the product development team has passed the Definition Readiness Checkpoint (DRC), the team is ready to move to the next phase of commercialization which goes by the name of the Feasibility Phase.  As the name implies, the goal of this phase is for the technical team to prove to the management team that the intended product is a feasible endeavor.  In order to exit this phase, the product development team must provide the proper deliverables to pass the Product Feasibility Checkpoint (PFC). 

The importance of the Feasibility Phase must be emphasized.  This is the stage where a creative set of engineers and technologists must prove to the management team that no further invention is required to create a commercial product.  This means that the technical team must develop proof-of-concept prototypes that act as the “proof by existence” for the performance required by the product.  When the development path is proven as feasible, the management team can better estimate the schedule and budget while providing a realistic set of product features.  Remember that it is difficult if not impossible to create schedules and budgets around invention and no management team should be willing to move forward on a project knowing that there is invention remaining.  

Below are the four activities that occur in the Feasibility Phase.  A short explanation of each activity is provided below the list.

Feasibility Phase Activities

1.  Product Architecture

              Identify functional subsystems in architecture

              Define interface between functional subsystems

              Define critical functional parameters of functional subsystems

              Define interface protocols between all functional engineering disciplines

              Develop proof-of-concept testbeds based on functional subsystems

              Refine industrial design and human factors 

2.  Qualification, Verification, and Regulatory

              Verification of subsystem functional performance parameters

              Product qualification, regulatory, and compliance testing requirements

              County ship-to list impact on qualification

3.  Program Management/Product Development Plans

              Preliminary bill of materials

              Cost of goods sold analysis

              Nonrecurring costs (engineering, prototyping, qualification)

              Prototyping strategy (methods, quantities, packaging, regulatory requirements)

              Feasibility issue tracking list management

              Update program schedule

4.  Design Review

              Review of designs relative to Engineering Data Sheet/Product Specifications

Activity 1.  Product Architecture:  The first job of the technical and engineering team is to translate the Engineering Data Sheet/Product Specifications Document developed in the Definition Phase into architectural requirements.  The product architecture essentially consists of integrated subsystems each which provide the intended function specified in the Definition Phase.  The engineering and technical team must identify all the functional subsystems of the product and describe how they interface together into the overall product architecture.  While the architecture is being defined, the industrial designers and human factors engineers must be involved to be sure that the product meets their requirements.  These requirements include the product look, the product feel, and the product operation. 

Once the subsystems are broken out from the overall product architecture, the engineers must define the subsystem performance with more clarity.  This includes defining the critical function of the subsystem and the allowable variation.  Engineers usually refer to these design outputs as the subsystem critical functional parameters.  These are the parameters that guarantee proper performance of the product and will be validated, verified, and qualified throughout the program.

The product architecture also requires that all the different technical and engineering groups define the interface protocols between their functional disciplines.  For example, the mechanical engineering group must work with the electrical engineering group to define how electrical components (motors, relays, switches, etc.) will be used to drive the mechanical design.  The interface document should define the interactions between all the relevant groups including mechanical, electrical, software, and firmware.

Finally, once the architecture and the subsystem functional parameters have been defined, it is necessary for the engineering team to develop subsystem testbeds.  These testbeds are used to prove that the subsystem can generate the proper design output or functional parameters with the constraints provided by the architecture, schedule, and cost guidelines.  Remember, the difficult part of engineering is that there are many constraints that limit the solution set of the problem at hand.

Activity 2.  Qualification, Verification, and Regulatory: The activities executed by the quality and regulatory teams require excellent planning as well as excellent execution.  The teams must work closely with the technical and engineering teams to understand what qualification, regulatory, and compliance testing will be required.  The qualification testing is used to verify that the designs meet their specifications.  The regulatory and compliance tests are those test mandated by agencies and countries in the ship-to list that, when passed, allow the sale of products in these countries.  An example of a certification is the CE marking in Europe.  Without these regulatory and compliance tests performed by these teams, the products will be prohibited from entering into countries on the ship-to list that require these certifications.  The product qualification, regulatory, and compliance testing plan must include all testing that will be done in current and later phases of the development.

The product qualification, regulatory, and compliance testing plan for this specific phase must be executed.  This usually only includes qualification tests that are run to verify that the subsystem testbeds actually meet their design output goals and specifications.  It is also expected that the testbeds meet their specifications across a wide operating range specified early in the previous phase.

Activity 3.  Program Management/Product Development Plans:  This activity is driven by the program management team and involves close communications with the technical, engineering, and quality teams.  The technical and engineering team is driving the subsystem design while the qualification team is verifying that the designs meet the required specifications.  Any issues that arise during design and test are added to a feasibility tracking list which should be managed by the program management team during weekly program reviews.  This acts as the input data required to develop an accurate schedule and engineering investment budgets.  The management team also should be working directly with the product architects in order to get a first-pass of the bill of materials (BOM) and with the manufacturing and finance teams to understand the cost of goods sold (COGS). 

During this phase, the program management team must also estimate the cost and efforts required to prototype and qualify the product.  The engineering cost, prototyping cost, and qualification cost make up the nonrecurring investment cost.  This can be used along with the COGS to analyze the financial viability of the product.   The best understand the prototyping cost, the manufacturing engineering team must develop a prototyping strategy which essentially includes everything required to properly develop and qualify the product. 

Activity 4.  Design Review: The final activity in the Feasibility Phase is to perform proper design reviews.  The process followed can either be an extremely formal process as used in medical device development or an informal process used in small teams on simple products.  Regardless of the product complexity, the design review is an important step to be sure that all the stakeholders have their say in the design and that it meets their requirements.  Since most of the requirements should be documented in the Engineering Data Sheet/Product Specifications, there should be no surprises if the engineering team is using this document to guide their design.  Unfortunately, there are surprises in these reviews which reinforce the importance of the definition phase of product development.  Any issues that are surfaced during the review should be documented and resolved prior to moving forward.

 

Throughout this Feasibility Phase, the team should be working towards the Product Feasibility Checkpoint (PFC) that occurs at the end of this phase.  As with every phase of the product development and commercialization life cycle, the checkpoint is necessary to verify that the team is ready to move to the next phase.  Without the checkpoint the program will most likely be mismanaged and the management team will not have the correct information to properly guide the development team. 

Below are the four deliverables that should be completed at the end of the Feasibility Phase.  Everyone on the management team should review and approve these documents.  If these documents are properly controlled through a revision control system, the development and management team will always know the program assumptions and status at each phase checkpoint.  The format for each of these documents is at the discretion of the company developing the product.

Product Feasibility Checkpoint (PFC) Deliverables

1.  Product Architecture Document

              Industrial design and human factors documents approved

              Product architecture and interface document approved

              Proof-of-concept testbed designs documented

2.  Qualification, Verification, and Regulatory Document

              Plan documented, approved, and under revision control

              Proof-of-concept testbed performance documented and approved

3.  Product Development Plan Document

              Updated schedule approval based on product feasibility results

              Program financials and budget reviewed and approved

              No outstanding issues on feasibility issue tracking list

              Prototyping plan reviewed and approved

4.  Design Review Documentation

              All design review sessions documented

Copyright 2009 Leardon Solutions

Next blog posting: Integrating Subsystems into a Detailed Design Prototype

Don’t Move Forward Without a Properly Defined Product

In the past two postings, the phases of product development and the required checkpoints throughout the development process were reviewed.  This overview was not meant to be thorough but in fact was meant only as a summary prior to diving deep into each phase and each checkpoint deliverable.  Here the Definition Phase activities and the Definition Readiness Checkpoint (DRC) deliverables are discussed in more detail. 

The goal in this phase is to do exactly what the title states: define the product thoroughly.  Prior to the definition phase, the marketing, business development, and research teams have been scouring the landscape to find an application for their intellectual property, to better understand the customer needs, to size the market, to define the target customer, and to define a path forward for a potential product.  All of this is a necessary starting point to kick off the Definition Phase.  Unfortunately, most of the documentation and research done prior to this phase must be translated before it can be used in this phase since much of the data is more vague that what is required to properly define the product.

The worst enemy of an organization developing a product is vagueness and ambiguity.  The engineers and designers need exact specifications to work with.  Remember that this is product development and not product research.  Research and innovation allow for ambiguity but product development does not.  At the end of this phase, the there must be clear, concise, and measureable specifications for the product which can then be fed into the engineering team.

Below are the five activities that occur in the Definition Phase.  A short explanation of each activity is provided below the list.

Definition Phase Activities

1.  Product Alignment with Company Strategy and Roadmap

2.  Competitive Analysis

              Lessons/feedback from existing products in market

             Analysis of competitor’s product functional performance and features

             Intellectual Property (IP) Landscape Search and Protection

3.  Product Data Sheet/Product Requirements

            Desired performance, functional, and interface requirements

            Industrial design requirements

            Human factors requirements

            Installation, support, service, and maintenance requirements

            Qualification, regulatory, safety, and standards compliance requirements

            Compatibility requirements

            Packaging, shipping, and labeling requirements

4.  Engineering Data Sheet/Product Specifications

            Translation of the product requirements into engineering specifications

5.  Program Management/Product Development Plans

            Program schedule

            Program budget

            Program risk assessment

            Quality system implementation plans

            Program priorities: scope, cost, schedule

 

Activity 1.  Product Alignment with Company Strategy and Roadmap: There must be a reason why the company is developing this product.  It must be aligned with the corporate mission, vision, and strategy.  Also, it should be aligned with the product line-up and vintage chart.  This activity is sometimes unnecessary for smaller companies, start-ups, or entrepreneurs since they only have one product in their line-up but it is necessary for the company to verify that the product maps to the corporate strategy.

Activity 2.  Competitive Analysis: It is absolutely necessary to know about the competition and similar products in the marketplace. Much of the competitive research should have been done prior to entry into the Definition Phase but it should be revisited since new products can be introduced in the short time between the research and the start of product development.  The knowledge of the competitor’s products will allow the team to better focus their product features. 

If the product being developed is a follow-on product, then it is necessary to get feedback from the product that is currently in the market.  These lessons will be fed forward into the Product Requirements.  Finally, be sure to do an Intellectual Property (IP) search to verify that the product will not infringe on anything currently protected.

Activity 3.  Product Data Sheet/Product Requirements: This is where ambiguity and vagueness end.  The Product Data Sheet, also referred to as Product Requirements, is a list of performance, functional, and interface requirements.  It is not a marketing or customer document.  These requirements provided here are specific and will be translated by the engineering team into product specifications.  The functional requirements specify the inputs and outputs of the product.  A functional requirement example for an automobile is that the car will operate on 87 octane gasoline.  The performance requirements call out how well the product operates in its specified operating environment.  Using the automobile example, the performance requirement would be that the car gets an average of 35 mpg under all weather and road conditions found in the U.S.  Finally, the external, uncontrollable inputs to the product are called out in the interface requirements.  Following the automobile example, an interface requirement would be the different driving styles of the operators. 

There are many other questions that must be answered in the Product Data Sheet/Product Requirements.  These include: How will the industrial design relate to the customer’s needs?; How will the customer interface with the product (human factors requirements)?; How will the customer install the product?; How will be supported, serviced, and maintained in the field?; What qualification, regulatory, safety and standards compliances are required in order to use the products in the indicated markets and countries?; and What are the packaging, shipping, and labeling requirements? 

Activity 4.  Engineering Data Sheet/Product Specifications: The Product Requirements provided earlier are the first step in specifying the product.  The next step is to get the engineering team to translate these product requirements into an Engineering Data Sheet or Product Specifications.  The engineers will use this document as they move through their design and development stages.

Activity 5.  Program Management/Product Development Plans: Aside from all the product definition activities occurring in this phase, there are many project definition activities that must also occur in order to have a successful product and program.  The program management team must work with a cross-discipline/functional team to get agreement on the program schedule.  This team must also work with upper management to define the program budget as well as determining the priorities of the program.  The task of determining the program priorities (i.e. which comes first, scope, cost or schedule?) is absolutely necessary so that future decisions are consistent.  Finally, the program management team needs to evaluate the program risk and how the quality system can be implemented to mitigate risk.

 

Throughout this Definition Phase, the team should be working towards the Definition Readiness Checkpoint (DRC) that occurs at the end of this phase.  This checkpoint is necessary to verify that the team is ready to move forward into the next phase.  Below are the three deliverables that should be completed at the end of the Definition Phase.  All parties involved in this program should have evaluated these documents and agreement must exist on both the program management and senior management levels.  Implementing document control on these three documents is always a good idea in order to minimize project scope creep.  The format for each of these documents is at the discretion of the company developing the product.

Definition Readiness Checkpoint (DRC) Deliverables

1.  Product Development Plan Document

            Preliminary schedule and budget approved

            Program priorities approved

            Strategy, cost, schedule, risks, quality expectations, and product goals aligned

2.  Product Data Sheet/Product Requirements Document

            Document approved and under revision control

3.  Engineering Data Sheet/Product Specifications Document

            Document approved and under revision control

Copyright 2009 Leardon Solutions

Next blog posting: Are the product features feasible?

Formal Checkpoints are Required Throughout the Life Cycle

In the last blog, the foundation for product development was discussed: the Seven Phases of the Commercialization Life Cycle.  It might seem as if individuals just need to follow the processes specified in each phase in order to properly develop a product. Unfortunately it isn’t that easy.  There are so many tradeoffs and partners involved in decisions that communication is one of the main requirements for successful product development.  Checkpoints are used to formalize this communication.

The figure below shows the Seven Phases of the Commercialization Life Cycle that is used by Leardon Solutions (www.leardon.com/lsclc.html) for small companies, entrepreneurs, and inventors.  Additionally, there are five checkpoints that act as a formal gate between the first six phases.  These checkpoints are required in the process of product development and commercialization.

Commercialization Life Cycle Phases and Checkpoints

Definition Readiness Checkpoint (DRC): The main deliverable at this checkpoint is referred to as the Product Objective Statement.  This statement is used to align priorities of the product strategy, cost, schedule, risks, quality expectations, and functionality goals.  These documented priorities allow the team to make decisions and trade-offs in future phases of the programs.  The marketing team must deliver a Product Data Sheet which defines the customer-facing product features.  The engineering team utilizes this Product Data Sheet to generate the Engineering Data Sheet which lists all the required specifications from an engineering perspective.  Finally, the program manager defines a preliminary budget and schedule for the program.  The team is ready to move forward when there is agreement on the Product Objective Statement, the Product Data Sheet, the Engineering Data Sheet, the preliminary budget, and the preliminary bchedule.

Product Feasibility Checkpoint (PFC): The engineering team is busy during the Feasibility Phase.  They need to use the Engineering Data Sheet and translate it into a product architecture, the industrial design, and proof-of-concept prototypes.  These prototypes are utilized to prove that this product can be commercialized and there are no existing feasibility issues that would prevent the team from hitting their future deliverables.  The team also must deliver qualification, regulatory, and certification plans that are aligned with the updated schedule and budget. 

Product Design Checkpoint (PDC): At this point in the commercialization life cycle, the team has a quick-turn integrated functional prototype as well as all engineering documentation required to start the production prototype phase.  The supply chain group must deliver an approved supplier and vendor list, production ramp and capacity plans, a tooling strategy, a distribution plan, and any key supplier contracts.  The supply chain and the engineering groups collaborate to deliver the product Cost of Sales.   The program team must have an updated and refined Schedule and Budget. 

Production Prototype Checkpoint (PPC): The end of the Production Prototype Phase results in production-ready prototypes that meet all the requirements stated on the Product Objective Statement, the Product Data Sheet, and Engineering Data Sheet.  All ‘no-ship’ issues have been resolved and any issues that remain are waived by the program team.  All regulatory and certification approvals have been received.  The program financials and product cost of sales are reviewed with agreement that it is time to start the production ramp.  This allows the marketing team to announce the product to sales channels. 

Product Release Checkpoint (PRC): The Production Ramp Phase prior to this checkpoint is critical. Orders have been placed by the sales channels and these commitments must be met.  There must be zero ‘no-ship’ issues or defects prior to releasing the shipment of products.  This is verified through all the production testing and off-line tests that occur during the production ramp.  Finally, to continue into the next phase, the team must review the product cost of sales to verify the product is meeting it’s financial commitments. 

Copyright 2009 Leardon Solutions

Next blog posting: Don’t Move Forward Without a Properly Defined Product

The Balancing Act of Product Development and Commercialization

Product development and commercialization can be summarized as a balancing act between the competing requirements of cost, quality, schedule, and functionality.  Thousands of decisions are made while a product is under development and the end result is typically a sub-optimal result of these decisions.  A consistent theme exists as a team moves through the process of bringing a product to the customer: it is virtually impossible to optimize all the requirements of the program/product.  The goal of this blog is to walk the readers through the product development and commercialization life cycle that is used at most of the larger corporations around the world.  While there are many ways of achieving the same outcome, this blog will discuss the Commercialization Life Cycle that is used by Leardon Solutions (www.leardon.com/lsclc.html).  This life cycle has been tailored for use by small companies, entrepreneurs, and inventors who typically fall trap to common product development problems and which are easily solved by experienced individuals at large corporations.  In this posting, the Commercialization Life Cycle phases will be introduced.  The life cycle phases and checkpoints will be reviewed in more detail and useful documents will be shared in future postings.

As shown in the figure below, there are 7 phases in the Commercialization Life Cycle.  A product idea exists in the beginning of the life cycle and a product in the hands of customers exists after the fifth phase.  Below is a brief description of each phase.

Commercialization Life Cycle Phases

Commercialization Life Cycle Phases

Definition Phase: This phase involves outlining the customer’s needs and wants and defining a product that meets the requirements of the targeted customer.  The product must be aligned with the company strategy and the product roadmap, which define the desired program SCHEDULE and product and program COST.  All the product requirements are translated into engineering and design specifications, hence defined as the SCOPE of the program.  Now the program management must define the priorities of SCHEDULE, COST, and SCOPE so that the team can constantly work on this balancing act until the end of the program.  Remember that QUALITY is another requirement that must also be balanced.  The team now must develop a program schedule, product cost goals, and program budget.  Finally, the program must be properly staffed prior to moving onto the next phase.

Feasibility Phase: The main objective of the feasibility phase is to develop product architecture.  This involves defining the interfaces between the software, firmware, electrical, and mechanical teams.  It also involves taking the engineering and design specifications from the earlier phase to help define all the functional groups of the product for each engineering discipline.  Once the architecture is defined, the team must build feasibility prototypes to verify that they have a design path forward that will meet the cost and schedule goals.  The architecture allows the team to provide a rough estimate of the direct materials cost and the product cost of sales.  Finally the team must determine the prototyping and qualification strategy based on the markets and customer segments that the product will reach.

Design Prototype Phase:  The earlier phase provides the fundamental path forward for the detailed design phase.  With the knowledge of what is a feasible design approach, the engineering team can move forward detailing out all the mechanical, electrical, software, and firmware designs according to the specifications that must be met.  The designs are quickly prototyped using fast methods in order to integrate all the designs from the different groups.  These design prototypes allow the team to continue development, refine their designs, and perform any qualifications required to move onto the next phase.  In parallel, the manufacturing and supply chain teams become involved to begin the planning of the prototyping and production phases.  The program management team continues to update and refine the budget, the schedule, and the product features based on the engineering results and progress. 

Production Prototype Phase: The main effort of this phase is to get the design to a level where it can be prototyped using production and manufacturing processes.  These production prototypes can then be used in the software, firmware, electrical, mechanical, regulatory, vendor, and packaging qualification.  The prototypes can also be sent to customers as alpha and beta units for feedback from the field.  During this qualification, the manufacturing and supply chain team should be finalizing their plans for suppliers and the production ramp.  The program team should be finalizing the program financials, the marketing team should be finalizing the go-to-market strategy, and the engineering team should be working on resolving all the product defects prior to moving to the next phase.

Production Ramp Phase:  Once the number of product issues and defects begins to decline and stabilize, the program team must review the status of the entire program and approve the start of the production ramp.  During this ramp, the goal is to increase the knowledge level of the product by resolving any issues that arise with both the product and the supply chain.  The team must review the cost of good sold throughout this ramp to verify that it is in line with the program financials.  Also, the engineering design team is still involved and should continue testing to ensure product quality and continue with product qualification for any changes.

Stable Production Phase: During the production ramp, the engineering design team has resolved any issues that prevent the product reaching its build plan.  Once the number of issues and defects stabilize, a handoff is made from the engineering design team to the production engineering team.  Their goal is now to fulfill all product demand and continue with stable production.  Any issues that arise during this stage are usually resolved with minimal involvement from the engineering design team.

Discontinuance Phase: When the product demands diminishes or a new product is due to replace the existing product, the discontinuance phase begins.  This phase requires that the team plan all the service and support strategies for products in the field.  Also, the team needs to minimize the inventory exposure as the new product replaces the older product.

Copyright 2009 Leardon Solutions

Next blog posting: Formal Checkpoints are Required throughout the Life Cycle.