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