際際滷

際際滷Share a Scribd company logo

Speed And Quality Of Development

J
johnstonda

Brief description of improving program predictability by using a problem-discovery method and metrics

1 of 18
Speed and Quality of Development Product Development as a Problem-Solving Engine DA Johnston 12 March 1999
A few principles The new product pipeline is the growth engine for a company Value potential is governed by Business, Product and Technology strategies Shareholders require predictability in financial outcomes such as growth New product development is inherently uncertain , limiting predictability in outcomes Therefore, reducing uncertainty in product development is a high priority, value-creating activity
Strategic Architecture Within the strategic architecture, Process has the highest leverage on uncertainty Programs and Projects Organizational Strategy Technology Strategy Product Strategy Business Strategy Tools Strategy Process Strategy Desired Outcomes, Objectives and Methods, Managing External Expectations and Communications Specific technologies & competencies, risk/value trades, make/buy/cooperate, practice targets, changes over time Structure, Staffing, Skills Requirements, Succession, Recruiting/Retention, Salary, Change Program Design Controls, FP&A, Project Management, Product Architecture, Requirements Analysis, Product Development Process Six Sigma, Protime, Project, Quickplace, Metaphase, ClearQuest, Doors, Rational Development, Risk/Reward Choices, Clinicals, Regulatory, Team Operations, Design Transfer, Launch Market Needs/White Space, Portfolio, Interactions, Line Extensions, Life Cycle
Process Strategy Decisions on the types of processes and linkages of process architecture to be followed in the R&D effort to implement the Technology and Product strategies in a consistent and reproducible way to get predictable outcomes
How does uncertainty manifest itself? Unexpected technical issues Higher failure rate than expected Didnt realize the customer would Need to run some more tests Unexpected logistical issues Well need to repeat Not recruiting patients fast enough Supplier failed to Overload Not enough resources Going as fast as we can Too much to do Observations Recognize that uncertainty exists and design projects around it
A Mental Model for Development: Development as a Problem-Solving Engine Problems Problem-Solving Solutions Geez, that is a real issue I wish I could Isnt there a better way to If we could only figure out how to Now, better coverage for gram-negative Announcing: Fewer side effects At last, sequencing at your fingertips Development At the Product level
Development as a Problem-Solving Engine Problems Problem-Solving Solutions Well need to develop specs Well need to validate limits Well need to check feasibility Well need to submit PMA Spec issued Process Validated Option is feasible PMA Submitted Development At the Project level
Development as a Problem-Solving Engine Problems Problem-Solving Solutions A Few Truisms: There is a finite set of problems (things to understand and fix) Not all of the problems are foreseen Not all of the foreseen problems are well-defined All problems can be solved -- but they require area under the curve (time & money) AND deferring reduces the available AUTC Every problem needs a plan to solve it (or avoid it), though not every problem needs to be solved If the biggest enemy is uncertainty & unknowns, then effort spent discovering unknowns is high value
It may be obvious, but Problems Problem-Solving Solutions A program domain contains N issues/problems, and y dont need solutions. If N-y is defined then a large portion of uncertainty is limited.
How to go faster & do better Issues-driven planning and program operations Problems define the scope focus on finding them Quickly: Identify problems (or issues) systematically Define problems and relationships between different problems Prioritize issues worst first Quickly find a way to test: For the answer For further definition To drive new issues
Project Throughput Problems Problem-Solving Solutions Treat project speed and quality like factory throughput Identify and manage all problem streams In minus out equals accumulation Re-use standard pieces unless innovation adds measurable value Product design element re-use Project process flow re-use (standard drill) Minimize unplanned re-work Use planned re-work to mitigate risk (plan for iterative solutions) De-bottleneck identify and focus on rate-limiting steps/issues in problem-finding/solving Manage bottlenecks with parallel operations
Sources of Issues Requirements Undefined Poorly defined Unvalidated Test Inappropriate method Non-specific method Misinterpreted results Design/Implementation Lack of feasibility Non-robust design Non-robust process Hint: on one recent program, Requirements was assigned as root cause on over 80% of issues
How to go faster & do better Issues-driven planning and program operations What constitutes a test? Brainstorming/sorting Asking a customer Lab experiment Market research Logic diagram Initial design, design review A test is any discriminating activity provides data to discriminate between known and unknown
Metrics Heres an insight: Issues lists are key program metrics # of new issues/period # of issues resolved/ open issues issues aging, overdue tasks % of issues w/action plans # on critical path # of issues without action plan/ project hdct % of tasks complete % of tasks overdue, risks deferred Issues are the primary drivers of plans Plans are the primary drivers of action If you treat development as a problem-solving engine: Actions drive results
What is a plan? A plan has: Defined, measurable deliverables Defined time frame Defined resources to execute Defined risks and mitigations (and the mitigation plans need to meet the definition of a plan)
By the way Using this development as problem-solving engine model, innovation is really more a function of problem- posing than problem- solving Problems Problem-Solving Solutions Cost and quantity of problems Value of solutions
Overall Direction Reproducibility in Process leads to reproducibility in results Process needs to be biased in favor of identifying and weeding out uncertainty Three critical factors in reducing uncertainty are iteration, parallel efforts and rigor Build all into process
Practical Guidance Defeat Uncertainty Implement tools that drive issue discovery and prioritization, automate problem-tracking metrics, link to requirements, testing, design, risk management Implement tools that make plans and issues universally available to all stakeholders Assure plans are driven by frequent reviews of designs, results and issues looking out well past completion Define success ahead of time, compare interim to ultimate set up to manage by measuring variances Require plans (time/resources) for undefined contingencies reject everything-goes-right-schedules, add a finite amount in proportion to what you think you dont know right now (TOC approach is one way)

More Related Content

Speed And Quality Of Development

  • 1. Speed and Quality of Development Product Development as a Problem-Solving Engine DA Johnston 12 March 1999
  • 2. A few principles The new product pipeline is the growth engine for a company Value potential is governed by Business, Product and Technology strategies Shareholders require predictability in financial outcomes such as growth New product development is inherently uncertain , limiting predictability in outcomes Therefore, reducing uncertainty in product development is a high priority, value-creating activity
  • 3. Strategic Architecture Within the strategic architecture, Process has the highest leverage on uncertainty Programs and Projects Organizational Strategy Technology Strategy Product Strategy Business Strategy Tools Strategy Process Strategy Desired Outcomes, Objectives and Methods, Managing External Expectations and Communications Specific technologies & competencies, risk/value trades, make/buy/cooperate, practice targets, changes over time Structure, Staffing, Skills Requirements, Succession, Recruiting/Retention, Salary, Change Program Design Controls, FP&A, Project Management, Product Architecture, Requirements Analysis, Product Development Process Six Sigma, Protime, Project, Quickplace, Metaphase, ClearQuest, Doors, Rational Development, Risk/Reward Choices, Clinicals, Regulatory, Team Operations, Design Transfer, Launch Market Needs/White Space, Portfolio, Interactions, Line Extensions, Life Cycle
  • 4. Process Strategy Decisions on the types of processes and linkages of process architecture to be followed in the R&D effort to implement the Technology and Product strategies in a consistent and reproducible way to get predictable outcomes
  • 5. How does uncertainty manifest itself? Unexpected technical issues Higher failure rate than expected Didnt realize the customer would Need to run some more tests Unexpected logistical issues Well need to repeat Not recruiting patients fast enough Supplier failed to Overload Not enough resources Going as fast as we can Too much to do Observations Recognize that uncertainty exists and design projects around it
  • 6. A Mental Model for Development: Development as a Problem-Solving Engine Problems Problem-Solving Solutions Geez, that is a real issue I wish I could Isnt there a better way to If we could only figure out how to Now, better coverage for gram-negative Announcing: Fewer side effects At last, sequencing at your fingertips Development At the Product level
  • 7. Development as a Problem-Solving Engine Problems Problem-Solving Solutions Well need to develop specs Well need to validate limits Well need to check feasibility Well need to submit PMA Spec issued Process Validated Option is feasible PMA Submitted Development At the Project level
  • 8. Development as a Problem-Solving Engine Problems Problem-Solving Solutions A Few Truisms: There is a finite set of problems (things to understand and fix) Not all of the problems are foreseen Not all of the foreseen problems are well-defined All problems can be solved -- but they require area under the curve (time & money) AND deferring reduces the available AUTC Every problem needs a plan to solve it (or avoid it), though not every problem needs to be solved If the biggest enemy is uncertainty & unknowns, then effort spent discovering unknowns is high value
  • 9. It may be obvious, but Problems Problem-Solving Solutions A program domain contains N issues/problems, and y dont need solutions. If N-y is defined then a large portion of uncertainty is limited.
  • 10. How to go faster & do better Issues-driven planning and program operations Problems define the scope focus on finding them Quickly: Identify problems (or issues) systematically Define problems and relationships between different problems Prioritize issues worst first Quickly find a way to test: For the answer For further definition To drive new issues
  • 11. Project Throughput Problems Problem-Solving Solutions Treat project speed and quality like factory throughput Identify and manage all problem streams In minus out equals accumulation Re-use standard pieces unless innovation adds measurable value Product design element re-use Project process flow re-use (standard drill) Minimize unplanned re-work Use planned re-work to mitigate risk (plan for iterative solutions) De-bottleneck identify and focus on rate-limiting steps/issues in problem-finding/solving Manage bottlenecks with parallel operations
  • 12. Sources of Issues Requirements Undefined Poorly defined Unvalidated Test Inappropriate method Non-specific method Misinterpreted results Design/Implementation Lack of feasibility Non-robust design Non-robust process Hint: on one recent program, Requirements was assigned as root cause on over 80% of issues
  • 13. How to go faster & do better Issues-driven planning and program operations What constitutes a test? Brainstorming/sorting Asking a customer Lab experiment Market research Logic diagram Initial design, design review A test is any discriminating activity provides data to discriminate between known and unknown
  • 14. Metrics Heres an insight: Issues lists are key program metrics # of new issues/period # of issues resolved/ open issues issues aging, overdue tasks % of issues w/action plans # on critical path # of issues without action plan/ project hdct % of tasks complete % of tasks overdue, risks deferred Issues are the primary drivers of plans Plans are the primary drivers of action If you treat development as a problem-solving engine: Actions drive results
  • 15. What is a plan? A plan has: Defined, measurable deliverables Defined time frame Defined resources to execute Defined risks and mitigations (and the mitigation plans need to meet the definition of a plan)
  • 16. By the way Using this development as problem-solving engine model, innovation is really more a function of problem- posing than problem- solving Problems Problem-Solving Solutions Cost and quantity of problems Value of solutions
  • 17. Overall Direction Reproducibility in Process leads to reproducibility in results Process needs to be biased in favor of identifying and weeding out uncertainty Three critical factors in reducing uncertainty are iteration, parallel efforts and rigor Build all into process
  • 18. Practical Guidance Defeat Uncertainty Implement tools that drive issue discovery and prioritization, automate problem-tracking metrics, link to requirements, testing, design, risk management Implement tools that make plans and issues universally available to all stakeholders Assure plans are driven by frequent reviews of designs, results and issues looking out well past completion Define success ahead of time, compare interim to ultimate set up to manage by measuring variances Require plans (time/resources) for undefined contingencies reject everything-goes-right-schedules, add a finite amount in proportion to what you think you dont know right now (TOC approach is one way)