Dr Rob Hasker SE 3800 NOTE 10 PROJECT
Dr. Rob Hasker SE 3800 NOTE 10 PROJECT MANAGEMENT
Avoiding failure � Standish Report, 2014 � 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: 1. People: who’s involved 2. Product: objective, scope 3. Process: framework for project plan 4. 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 How does Scrum � poor procedures that block progress address each? � unclear definition of roles leading to lack of accountability, finger pointing � recurring failures leading to loss of morale
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 � 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? 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? 1.
Analyzing risks high probability low 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 1. �address high-impact risks with moderate to impact low high probability and low-impact risks with high probability �remaining risks will not be addressed! high
Risk Exposure � RE = P * C where � P = probability of occurrence, � C = cost to implement a fix 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 5. business needs change or are ill-defined 6. unrealistic deadlines How does Scrum 7. resistant users address each? 8. lost sponsorship 9. team lacks people with appropriate skills, no plan to train 10. managers avoid best practices, lessons learned 1. 2. 3. 4.
Review � Standish rate � 4 P’s Report: claimed 84% failure �People �Process �Project �Product � Risk assessment, management � 10 signs project in trouble
- Slides: 14