Product Development Systems & Solutions Inc.-click to homepage
News from PDSS Inc.
"Leading the Future in Product Development" 
October 2011- Vol 4, Issue 10
In This Issue
Uncover the Truth About How Long It Really Takes to Develop a Product
Greetings!   
This month, Skip Creveling, President of PDSS, outlines a procedure for a product development team and its' leaders to get a grasp of how long it will take to develop a successful product using Monte Carlo simulation and old-fashioned truth-telling.

-Carol
Uncover the Truth About How Long It Really Takes to Develop a Product

Reason is described as logical thinking, rational thought, use of good sense, practicality, realism, clear thinking, orderly thought, use of facts to form and guide decisions and actions...

 

Last month we looked at the macro-context of Rational Product Development. Since cycle-time is a great concern for many leaders in product development, this month we will look at a method to bring reason to phase-gate product development schedules.

 

The guiding principle is that the Project Manager (PM) and the Product Development Team (PDT) must absolutely tell the truth when they estimate how long each of their major tasks will take. Along with courageous truth-telling, the following steps known as Prevention & Impact Mitigation Analysis (PIMA) will provide a reasonable development schedule:

 

1)  Construct a Work Breakdown Structure / Task Flow Diagram of the tasks within each phase of your Product Development Process.

  • Usually takes the form of a Gantt/PERT Chart.
  • Select only the tasks from the Standard Work that add value.
  • In Lean Six Sigma terms, this is a process map with value-added work.

2)  Assess each task for potential schedule-disrupting problems.

  • In Lean terms, this is the beginning of Mistake-proofing (Poke-Yoke).

3)  Assign a value (e.g. 1=low to 5=high) to each potential problem for:

 

a) Likelihood of Occurrence,

b) Magnitude of Impact on the Schedule and

c) Ease of Early Detection.

  • Use this assessment to reduce the list to the "critical few" potential problems that are more likely to happen and/or cause significant harm.

4)  Conduct Proactive Root Cause Analysis (PRCA) on the critical few potential problems to identify the underlying causes (I call it The Problem Machine). Will it be cheaper to prevent them or monitor for early onset to trigger a contingency plan?

  • In Robust Design terms, this step identifies sources of unwanted variation, called "noises", which cause variation in the mean and standard deviation of your cycle times. The Noise Diagram is created in this step.

5)  Walk-through the value-added work flow (from Step 1) asking what tools, methods and best practices could prevent potential problems? Would it be better (cheaper) to develop contingency plans to mitigate the problem if it occurs?

  • As a rule of thumb, most tasks will only need a leading indicator and contingency plan. These are likely to be Easy, Common or Old (ECO) Tasks.
  • For far fewer tasks, it will be reasonable to prevent (or significantly reduce the likelihood of) a problem. These are typically New, Unique or Difficult (NUD) Tasks.

6)  Refine the Project Schedule (Work Breakdown Structure) to include the few Prevent-based tasks and the many Contingent-based tasks.

 

7)  Estimate the earliest, likeliest and longest durations for each major task to run a Monte Carlo (MC) Simulation on each phase of your PDP.

  • Discuss the Triangular Distributions from which your MC Simulator will draw sample task times with your Development Leaders at the Gate Review prior to beginning this work. Referring to the Noise Diagrams will help keep things grounded in reality!
  • Discussing these MC simulations will cause all to think through the detailed time lines that govern cycle-times.
  • A negotiated agreement for a Prevent-Contingent Task Balanced schedule will emerge after discussions at the Gate Review.

8)  Document lessons learned, positive and negative.

  • New PMs must be trained in the past lessons learned.

 This is how Rational Product development looks from a cycle-time design perspective. But even though it may be rational and logical, it does not assure people will actually follow through with disciplined action. This is an area of accountability that often slips away from organizations.

 

In summary, I return to the aphorisms from last month:

 

Haste Makes Waste - design contingent task flows with leading indicators of potential problems, set triggers to adjust to the right speed.

 

Do It Right The First Time - design preventive task flows for those few tasks that, if not done right the first time will have significant economic consequences, well beyond the cost of doing the NUD Tasks correctly from the beginning.

 

Tell the Truth - run Monte Carlo Simulations based on the facts, judgment and experience of team members, the project manager and the Product Development Leaders.

 

Is there a topic you'd like us to write about? Have a question? We appreciate your feedback and suggestions! Simply "reply-to" this email. Thank you!
 
Sincerely,
Carol Biesemeyer
Business Manager and Newsletter Editor
Product Development Systems & Solutions Inc.
About PDSS Inc.
Product Development Systems & Solutions (PDSS) Inc.  is a professional services firm dedicated to assisting companies that design and manufacture complex products.  We help our clients accelerate their organic growth and achieve sustainable competitive advantage through functional excellence in product development and product line management.

Copyright 2011, PDSS Inc.
Join Our Mailing List!
 
See PDSS Inc.'s Archived E-Newsletters