1. Dr. Rob Hasker

2. Avoiding failure  Standish Report, 2014 Standish Report 31% projects cancelled before completion 53% projects ~190% of original estimate Only 16% on-time, on-budget But note this research is controversial ○ Must purchase the raw data  Examples Denver baggage system ○ Final system: $441 million; initial cost $250 ○ 2005: system abandoned(Risks, Jan 9)(Risks, Jan 9) Will paying $60 million/yr for “maintenance” until 2020!

3. Effective software project mgt  How to avoid becoming a statistic?  4 P’s: 1. People: who’s involved 2. Product: objective, scope 3. Process: framework for project plan 4. Project: getting the job done

4. The People  Primary – all stakeholders  Leadership: MOI Model Motivation: encourage results Organization: mold process: concept => product Innovation: encourage creativity  Critical: avoiding team toxicity frenzied work atmosphere: working in quicksand high frustration caused by environment (manager, business, technology), leading to friction between team members poor procedures that block progress unclear definition of roles leading to lack of accountability, finger pointing recurring failures leading to loss of morale

5. The People  Primary – all stakeholders  Leadership: MOI Model Motivation: encourage results Organization: mold process: concept => product Innovation: encourage creativity  Critical: avoiding team toxicity frenzied work atmosphere: working in quicksand high frustration caused by environment (manager, business, technology), leading to friction between team members poor procedures that block progress unclear definition of roles leading to lack of accountability, finger pointing recurring failures leading to loss of morale How does Scrum address each?

6. Product  Key: establish objective/scope Determining highest need Can automate a lot, but which is worth doing?  Issue: people want to know costs up front  Solution: Determine context: how SW fits What information needed? What are the function, performance reqs?

7. Process  establish effective customer communication, get good requirements  plan define resources, timelines  analyze risks technical, managerial  engineer build "representations" of application  construct, release build, install, support system  evaluate obtain customer feedback

8. Project  Tracking, revising plans as needed 90-90 rule: 90% of project absorbs 90% of resources, other 10% absorbs another 90%  Risk management Can we eliminate risk? Elements of risk: ○ Loss ○ Uncertainty: a risk may or may not happen ○ 100% certainty: project constraint

9. Risk Management  Categories Project risks: threats to project ○ budget, schedule, resource, customer, reqs ○ essentially: more work than thought Technical ○ design, implementation, verification ○ problem harder than thought Business ○ market: building what no one needs ○ strategic: product doesn’t fit business plan ○ sales: staff can’t sell product ○ management, budget: lost support Unpredictable: can’t predict everything! ○ Former student: the risks that come with be alive!

10. Sample risk checklist 1. Internal managers formally committed to support the project? 2. Are end-users enthusiastically committed to the system to be built? 3. Are requirements fully understood by developers, customers? 4. Have customers been involved fully in the definition of requirements? 5. Do end-users have realistic expectations? 6. Is project scope stable? 7. Does the software engineering team have the right mix of skills? 8. Are project requirements stable? 9. Does the project team have experience with the technology to be implemented? 10. Is the number of people on the project team adequate to do the job? 11. Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built?

11. Analyzing risks 1. Identify the risks 2. Assign each a probability of occurring 3. Determine the impact: negligible/marginal/critical/catastrophic 4. Sort by probability and impact; high values to the top address high-impact risks with moderate to high probability and low-impact risks with high probability remaining risks will not be addressed!

12. Risk Exposure  RE = P * C where P = probability of occurrence, C = cost to project if risk becomes an actuality  Example Plan: reuse 60 modules from previous project Risk: only 70% can be reused Cost to project if can reuse just 70%: ○ Will develop 18 modules (30% of 60) ○ Cost per module: $1400 – total $25,200 Estimated risk probability: 80% RE = 0.8 * $25,200 = $20,160  Compute RE for each relevant risk Use to adjust final cost estimate Build plan for addressing (all) risks as they occur

13. Project  Tracking, revising plans as needed 90-90 rule: 90% of project absorbs 90% of resources, other 10% absorbs another 90%  Top 10 signs project is in trouble 1. developers don't understand customer's needs 2. project scope poorly defined 3. changes managed poorly 4. chosen technology changes 5. business needs change or are ill-defined 6. unrealistic deadlines 7. resistant users 8. lost sponsorship 9. team lacks people with appropriate skills 10. managers avoid best practices, lessons learned

14. Project  Tracking, revising plans as needed 90-90 rule: 90% of project absorbs 90% of resources, other 10% absorbs another 90%  Top 10 signs project is in trouble 1. developers don't understand customer's needs 2. project scope poorly defined 3. changes managed poorly 4. chosen technology changes 5. business needs change or are ill-defined 6. unrealistic deadlines 7. resistant users 8. lost sponsorship 9. team lacks people with appropriate skills 10. managers avoid best practices, lessons learned How does Scrum address each?

15. Project  Tracking, revising plans as needed 90-90 rule: 90% of project absorbs 90% of resources, other 10% absorbs another 90%  Top 10 signs project is in trouble 1. developers don't understand customer's needs 2. project scope poorly defined 3. changes managed poorly 4. chosen technology changes 5. business needs change or are ill-defined 6. unrealistic deadlines 7. resistant users 8. lost sponsorship 9. team lacks people with appropriate skills 10. managers avoid best practices, lessons learned How does Scrum address each?

16. Review  Standish Report: claimed 84% failure rate  4 P’s People Process Project Product  Risk assessment, management  10 signs project in trouble