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

2. 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!

3. 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

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 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

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
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?

11. 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

12. 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

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 (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?

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