Success
in Software Project
Management
Presented by
Lawrence Peters PhD, CSDP
Software Consultants International Limited LJPETERS42@gmail.com
Your Presenter
• 40 years in software (analyst, SW engineer, project manager, consultant, educator (e.g. professional development seminars, & universities)
• Worked in defense, telecommunications, banking, insurance, aerospace, manufacturing, PC graphics, business process reengineering, simulation
• Clients: include IBM, Fujitsu Management
Consulting, Siemens, US Department of Defense, Boeing, Canadian Defence Establishment, Xerox,
| | | | | | | | |||| | | | | | |
Today’s Agenda
• About Software Project Management • What constitutes success & why is it so
difficult to achieve?
• What have we tried so far? • Where have we looked?
• How did successful software projects do it? • How to increase your chances of success
Software Project Management
• “Management, not technology, determines success” [1]
• “It includes the processes concerned with identifying, analyzing, and responding to project risk. It includes maximizing the
results of positive events and minimizing the consequence of adverse events” [2]
Success
• Is, “Subject to change”
• Depends on:
– Meeting requirements – alone, not enough
– Organizational politics (subject to change)
– Budgetary and schedule changes
– What the competition has done or is doing
– Ability to negotiate/compromise
So, what’s the problem?
• Software Projects
a) Consistently deliver quality results on time b) Rarely overrun cost estimates by >10%
c) Are never cancelled
d) Are well received by sponsors when done
e) None of the above
• Plus, Software Project Managers often operate
Some Common Misconceptions
• Software project manager – no longer “the boss”
– To be successful, a coach/servant-leader not a dictator
• Technology will save the day
– More than 3 dozen software methods, languages,
development environments, employed in the last 50 years [4] with little improvement
• Start with more people
– Using larger teams is a fallacy [5]
• Pay more money, that will motivate them
– People do not work for money [6]
• There are a lot of “anti-patterns” [7]
Some Project Management Variables
• People – personality compatibility,
communications skills, motivation - almost disregarded
• Process – CMM, CMMI, others emphasized
• Technology – we rely on this the most
Why Rely on Technology?
• That’s where most of us started • Old habits are hard to break [8] • We ignore reality,
“The project manager has a greater impact on project success than all other factors
Where We Look For Solutions
• Inside the software domain – why not outside?
• To improve our chances of success, checkout what successful software projects have done • Some recent findings [11]
Recent Findings Background
• The goal: Document what successful software projects had in common
• The method: analyze 589 successful
software projects appearing in refereed publications worldwide from 2000 to 2010 • These were filtered down to obtain
consistency and completeness of what was reported on
The Findings
•
In whatever way it was deemed
successful, none of the projects
attributed their success to:
– Development approach (e.g. Agile, Extreme)
– Software development lifecycle
“Success” Factors Present Prior To
Project Start
• The following 6 factors were present to start:
1. Well stated, unambiguous requirements – i.e. agreement on what constitutes success (with the understanding that it may change)
2. User involvement throughout the project
3. A competent project manager (more on this next) 4. Project was adequately been planned & scheduled 5. Appropriately skilled team members
A Competent Project Manager
• Wants the job & is trained to do it – including:
– Knowledge of important factoids
– Psychology of software engineers
– Insight into motivating individuals and teams
– Basics of accounting
– Communications skills
The Estimating Challenge [12]
Type of Project Worldwide Average % Overrun Overrun % Range Railways 45 7 to 83Bridges & Tunnels 34 -28 to 96
Roads 20 -10 to 50
Estimating (continued)
• Why do we miss the target (applies to all
industries, everybody) [13]?
– Over estimate project team abilities, benefits
– Under estimate risks
• To correct for this – use Reference Class
Forecasting [14] – the American Planning Association told its members to never use
The Team Sizing Fallacy
• Given that adding people to a late project makes it later,
• Software Project Managers should start with larger teams, right? – Wrong [5]
• The bigger the team, the more
administrative & coordination effort is required reducing performance –
Evaluating Individuals & Teams
• A very uncomfortable task
• Not often trained to do it [15]
• Some Software Project Managers avoid it • Software Engineers hate it, misinterpret
“Success” Factors Present Upon
Project Completion
• These are essentially project “goals”
– Schedule & budget estimates were maintained
– Customer and user needs satisfied
– Job satisfaction
– Product quality, functionality and performance
were acceptable
Job Satisfaction
• If software engineers do not find the work satisfying (i.e. interesting, significant,
challenging, something colleagues would be impressed by), productivity is lower and
they may abandon the project [3,15]
• Up to 60% of the cost of a software project can be attributed to personnel turnover
Observations
• Software project success:
– The result of competent project management
– Only somewhat dependent on technology
– Results from a collaborative effort among all
How Can You Achieve Success?
• Train Software Project Managers how to manage people [14,15,17]
• Complement the software technology focus with training in:
– Communications skills
– Interviewing, evaluating, motivating
Conclusions
• Our success rate would be greatly improved if we had better software project managers • Competent software project managers are
not born, they must be trained
• Focusing our attention on improving software project management skills in
planning, scheduling, controlling, staffing and motivating is the most cost effective means of achieving
SUCCESS!
References
1. Cusumano, M., “The Business of Software: What Every Manager,
Programmer and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad,” Free Press, New York, New York, 2004
2. Duncan, W.R. “A Guide to the Project Management Body of Knowledge,” Project Management Institute standard committee, 1996.
3. Peters, L.J., “Getting Results from Software Development Teams,” Microsoft Press Best Practices Series, Redmond, Washington, 2008
4. Rico, D.F., “Short History of Software Development Methods,” posted 2010. 5. Staats, B.R., Milkman, K.L., Fox, C.R., “The team scaling fallacy:
Underestimating the declining efficiency of larger teams,” Organizational Behavior and Human Decision Processes, 118(2012), pp. 132-142.
6. Herzberg, F., Work and the Nature of Man, World Publishing Company, New York, N.Y., 1966
References (continued)
10. Boehm, B., Software Engineering Economics, Prentice Hall, Englewood Cliffs, N.J., 1981
11. Ghazi, P., Moreno, A.M., Peters, L.J., “Looking for the Holy Grail of
Software Development,” IEEE Software, January/February, 2014, pp. 92-96. 12. Flyvberg, B., “From Nobel Prize to Project Management: Getting Risks
Right,” Project Management Journal, Volume 37, Number 3, pp. 5-15, August, 2006.
13. Lovallo, D. and Kahneman, D., “Delusions of Success – How Optimism Undermines Executives’ Decisions,” Harvard Business Review, July, 2003. 14. SCI Limited, “Successfully Managing Software Projects,” Two day
professional development seminar, 2013.
15. Katz, R., “Motivating Technical Professionals Today,” IEEE Management Review, Volume 41, Number 1, March, 2013, pp. 28-38.
16. Cone, E., “Managing that Churning Sensation,” Information Week, May, 1998, Number 680, pp. 50-67.
