The effectiveness of “Design for X” (DfX) methodology is often limited by the non-negotiable “freeze” gates in the product development process.  Freezes become points of negotiation instead of directing scheduling and resource decisions.  Design changes continue past “design freeze” commonly resulting in an inefficient multi-iterative process.

A design freeze is the wrong tool for the job.  Design Freeze is a “Put your pencils down” methodology.  This leaves no room for input to the decision to halt activity other than what was available when the freeze gate was set.  Often a good deal of new information about the design and program has been created between the program creation and the freeze.

The “design freeze” principle is driven by the proposed benefit of increased efficiency through reduction of schedule creep.  Both time and money can be lost as serial program phases are stalled due to incomplete predecessors. Common freeze gates are “Specification Freeze”, “Concept Freeze”, “Design Freeze”, and “Tooling Freeze.”

It is important to distinguish between internal freezes that are the result of dependencies, and external freezes like lead times that are imposed on the design process.  Quality control norms like ISO 9000 require a freeze point for change control to distinguish between the design phase and change implementation afterwards.  Certifications like UL and FDA are also often positioned post freeze.

There are phases to freezing.  The program leadership will begin to express restrictions on changes as the freeze approaches.  This may be called a “Chill” phase. It is marked by an increasing needed justification for design and process changes. As the actual freeze gate is approached it will take higher authority to approve activities that threaten the planned schedule.

I believe DFMEA’s offer an interesting structure to approaching how to take action based on risk that may apply here. All the risk that is captured in a Design Failure Mode Effects Analysis (DFMEA) is associated to risk to the product or the end user.  The “Severity” score relates to event in the field, injury?, inconvenience?, loss of revenue?  The “Occurrence” ranking correlates to either a speculated likelihood or a projected percentage of failure based on test or analysis. What about using that methodology of creating a quantifiable measurement of risk factors and applying it to decisions on program schedule and budget?

Previous to the introduction of the DFMEA method teams still accessed severity of failures and the likelihood of occurrence. This happened in informal conversation, special meetings or simply by the coffee pot.  By acknowledging that this process of accessing risk through metrics, instead of informal discussion, then driving actions a new tool was created.  The Failure Mode Effects Analysis not only ensures this process occurs in a program, it improves it.  Efficiency is created due to the inclusion of a multi-disciplinary team in all portions of the analysis.  Endless debate is truncated by quantitative analysis, resources are directed to areas of the product and program that will mitigate the most risk.  Actions to address issues don’t “fall through the cracks” of the program because they are captured in a live document.

The program activities are impacted by design failures as well.  A design issue that is identified in development now requires previously unplanned schedule, resource, or both to be mitigated.  The impact to the program is discussed to select the most optimal solution.  But just as previous to DFMEA it is typically done in an informal manner.  Design failure driven program decisions occur with undetermined team members and the critical decision factors change.  A method to guide this process is needed, the same as affect to the product decisions needed DFMEA.

I am developing a process called Program Risks Effects Analysis (FMPEA).  This create a quantitative method to determine if the risk associated to a found reliability risk should be mitigated or addressed in a later stage.  By including input from both the technical and business sides of the program a well informed estimation for risk to the program can be made. The decision is calculated, not estimated by individuals, and the risk calculation process is documented. It’s a DFMEA for the risk to the program of found and hypothetical design issues. I am looking forward to seeing it in action soon.

-Adam

It’s early in the boating season.  It’s a beautiful Saturday and wee’re wakeboarding, My wife is driving.  I am getting ready to line up to jump the wake and all of a sudden she cuts the throttle and then guns it again.  I just let go of the rope and wait for her to come around so I can find out if it was the dirty dishes left on the  couch or beard shavings carelessly sprinkled on her face soap.  She said the boat just stuttered without her touching the throttle.  Hmmm  really? As we are talking the boat just stalls. Ughh!, and we are not close to the house.

[Read more…]

The challenges of keeping reliability at the resource and schedule negotiating table mid-program  can be greatly helped by a solid effort to connect it to the business case when the product program is created.

It’s the ambiguity of how reliability makes the company money that makes the case in live negotiation so difficult.  Everyone knows that reliability affects sales, marketing, warranty expense, future development.  But how do you compare that to the urgency of time to market or cost point?  If you, as the reliability representative, can point to a specific quantitative connection made to the business case for the product you have one.

[Read more…]

Mercedes used to be known for their outstanding reliability. They were the benchmark for 80 years ,no exageration.  The new CLA250 model which is their base model has a reliability that is 140% less than the average rated car.  What???  [Read more…]