SE 3800 Note 10 Project Management Dr. Rob Hasker SE 3800 Note 10 Project Management

Avoiding failure Standish Report, 2014 Examples 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) Will paying $60 million/yr for “maintenance” until 2020!

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

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

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?

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?

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

Project Tracking, revising plans as needed Risk management 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

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!

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

Analyzing risks Identify the risks low impact high high probability Identify the risks Assign each a probability of occurring Determine the impact: negligible/marginal/critical/catastrophic 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! low

Risk Exposure RE = P * C where Example 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

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 (though team doing their job) developers don't understand customer's needs project scope poorly defined changes managed poorly chosen technology changes but little time to rework existing parts business needs change or are ill-defined unrealistic deadlines resistant users lost sponsorship team lacks people with appropriate skills managers avoid best practices, lessons learned Explain: these are the top 10 signs that things are going wrong even when people are still doing their jobs and covering the basics. How does Scrum address each?

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