1. System Engineering • Guidant • Cardiac Rhythm Management INCOSE Presentation Nader Kameli Manager, Software Engineering

2. Desire • Speed up the product development process • Commissioned by management team • Members of management team

3. First Step • Before speeding up the process … • Need to understand the current speed … • Analysis of past projects

4. Analysis • Problem: • Did not complete projects “on plan” • Completed project on Plan - Completed project on time, with budget, effort and functionality identified in the functional plan at the time of contract.

5. Assumption Validation • Assumption: • Loosely defined system definition at the start of contract causes resource/schedule impact downstream • Methodology • Survey cross functional areas for input

6. Department Dependencies Advanced Tools, IC Design, Hybrid Design, Reliability System Requirements System Design Marketing, Regulatory, SW/HW Design, SW IRV, SAM, Research, Technology Quality System Services, AEG, Supplier Development, AME/Test Eng, Clinicals, Manufacturing Components, Manufacturing Process, or Schedule

7. Unstable System Definition At Start System not well defined at start Late Requirements Changes Late Design Changes Impact of New Process Technologies not well defined Impact of New Component Technologies not well defined Project Management Constraints Proof of concept Prototyping not completed Experienced Technical Staff not Available Low Confidence Schedules Needed Resources are not available on time Shifting Project Priorities Survey Results • Responses to “top 3 issues affecting your plan”

8. Survey Conclusion • Assumption: • Loosely defined system definition at the start of contract causes resource/schedule impact downstream • Two Major Impactors • System Definition • Project Management • Assumption validated

9. Industry Best Practices • Purpose • To identify challenges with RNPD outside Guidant • Methodology • Literature Search • Industries • Software intensive systems • Mission-critical systems • Complex systems

10. Lessons Learned by NASA • “Mistakes that have been repeated • Lack of clear definition of requirements early in system design phase: • Starting design before requirements were known • Vague Specifications • Design from the bottom-up rather than top-down • Incomplete documentation of requirements • Lack of early and Thorough requirements analysis prior to the start of a design” NASA Space Engineering Lessons Learned, Nov 1989

11. Lessons from NASA “…if the expenditures on the system design phase (up to and including the preliminary design phase) is less than 5% of the estimated cost of the project, vast cost (and schedule) overrun can be expected…” NASA System Engineering Handbook, 1995 “Up to 15% of the estimated total development cost may need to be spent on project definition in order to reduce risk.” System Engineering Management Guide, Defense System Management College, 1993

13. UK Civil Software-based System Development • Study on over 14000 organizations showed: • 80-90% of the systems did not meet their goals • Around 40% of the developments failed or were abandoned • Less than 25% fully integrated business and technology objectives • Only 10-20% met their success criteria Critical System Thinking and Information Systems Development, 1997

14. Standish Group’s Research in US • Standish group is a research and advisory organization specializing in mission-critical software intensive systems • Research of 365 US organizations covering some 8380 applications grouped projects in 3 categories:

15. Standish Group’sProject Outcomes Categories

16. Standish Group’s Success-Potential Metric

17. Recommendation for Success • “For Practitioners: • It is imperative to understand what is needed by all stakeholders • The user focus must be captured in a clear, traceable and testable set of requirements • Attention to interface definition and management is vital for project success” System Engineering and Evaluation Center, 2000

18. Recommendation for Success • “For planners: • Adherence to systems engineering principles and processes across organization will save money. • Insufficient investment in the early design phases (5 to 15%) is likely to lead to project cost overrun of between 50% and 100% for both hardware and software projects.” System Engineering and Evaluation Center, 2000

19. Typical Process

22. Application • Received High Level Support • Piloted on a project • Learned and improved • Standardize the Process

23. Conclusion • Better system definition • Higher confidence & Less Risk plan • Less chance of overrun • Lower cost of rework • Improve organization’s marketing and planning • Will increase resource availability for redeployment to other projects

24. Questions and Answers