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

1. Speed and Quality of Development Product Development as a Problem-Solving Engine DA Johnston 12 March 1999

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…” “ Didn’t realize the customer would…” “ Need to run some more tests…” Unexpected logistical issues “ We’ll 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…” “ Isn’t 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 “ We’ll need to develop specs…” “ We’ll need to validate limits…” “ We’ll need to check feasibility…” “ We’ll need to submit PMA…” “ Spec issued” “ Process Validated” “ Option is feasible” “ PMA Submitted” Development At the Project level

9. It may be obvious, but… Problems Problem-Solving Solutions A program domain contains N issues/problems, and y don’t need solutions. If N-y is defined then a large portion of uncertainty is limited.

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

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 don’t know right now (TOC approach is one way)