Software Management Plan
(part I)
Software management’s 7 deadly sins
The “3 P’s” of software management
Why big software projects fail: the key 12 questions
Software management’s 7 deadly sins
• Conducted fact-finding using email
• Senior managers from 20 organizations
responded to the questions
• To cope with software crisis, software initiatives
were pursued
• Most embraced the three-pronged attack:
– Standardize the process
– Standardize the product
– Professionalize the workforce
By Donald J. Reifer, Software Management, 7th Ed., pp. 5-8, 2006
Software management’s 7 deadly sins
Software Management Straw Poll Findings
Questions
Yes (%)
No (%)
Are your software organizations perceived as well managed?
18
82
Do these software organizations deliver what they promise when they promise it?
34
66
Do your customers and users view the products you deliver as high quality?
25
75
Do you employ classical management tools and techniques to manage software
deliveries?
55
45
Does your senior management view software organizations as contributing to the
bottom line?
30
70
Are software people treated as professionals within your firm?
85
15
Is your firm actively pursuing some form of software improvement strategy?
68
32
By Donald J. Reifer, Software Management, 7th Ed., pp. 5-8, 2006
Software management’s 7 deadly sins
• Sin 1: volatile requirements
– Succeeded only marginally when the organizations let
requirements change whenever marketing staff,
customers, and users recommend new features
– Better requirements-management
• Sin 2: poor planning
– Aim to shorten time-to-market interval by scheduling
tasks in parallel using iterative and spiral techniques
– Plans should be living documents, iterating and
evolving over time
By Donald J. Reifer, Software Management, 7th Ed., pp. 5-8, 2006
Software management’s 7 deadly sins
• Sin 3: unrealistic schedules and budgets
– “We will try our best” instead of “No! based on our
experience, it will take more resources to do this job”
– Still need better requirements and detailed plans to
estimate more accurately
• Sin 4: inadequate controls
– Inadequate tracking and measurement techniques
– “We cannot properly control what we have not
properly planned”
By Donald J. Reifer, Software Management, 7th Ed., pp. 5-8, 2006
Software management’s 7 deadly sins
• Sin 5: undercapitalization
– In the late 1980s, Japanese introduced software
factory concept
– They designed and built software facilities with
software development in mind
• Increased budget for software tools, embraced process
improvement technology
– Most firms are heavily undercapitalized; they focus on
marketing the product with only available resources at
hand
– Lesson learned: put an effort today into the
developing the necessary infrastructure to build
products tomorrow
By Donald J. Reifer, Software Management, 7th Ed., pp. 5-8, 2006
Software management’s 7 deadly sins
• Sin 6: “We’re different” syndrome
– To get management off the developers back
especially when schedules are aggressive
– Lessons learned: better to focus on explaining
why software is no different than other
technical disciplines
• Sin 7: lack of focus on quality
– Nobody wins when the defective products are
released to the market
By Donald J. Reifer, Software Management, 7th Ed., pp. 5-8, 2006
The “3 P’s” of Software management
• The software management must perform
the following activities:
– Planning
– Organizing
– Staffing
– Directing
– Controlling
– Integrating
By Donald J. Reifer, Software Management, 7th Ed., pp. 15-19, 2006
The “3 P’s” of Software management
• The “3 P’s” of software management:
– Processes
– Products
– People
By Donald J. Reifer, Software Management, 7th Ed., pp. 15-19, 2006
The “3 P’s” of Software management
• Maturing the process
– Principle 1: recognize that good processes add value
• Having either good process or good people is not enough
• Getting people use the process is a challenge; it can be
resolved by making your process the preferred way of doing
business
– Principle 2: use your processes to share your lessons
learned
• Direct your process-definition efforts to institutionalize a
preferred approach for doing business
• Learn from both positive and negative
By Donald J. Reifer, Software Management, 7th Ed., pp. 15-19, 2006
The “3 P’s” of Software management
• Focusing on product issues
– Principle 3: stress continuous process improvement
• Ensure that process that you improve is the one that your
people use
• Be flexible and build on the past in a way that allows to address
the future
• Include both people and products into account
– Principle 4: recognize that performance is always the
issue
• Performance is what makes or breaks the product from
customer’s view
By Donald J. Reifer, Software Management, 7th Ed., pp. 15-19, 2006
The “3 P’s” of Software management
• Focusing on product issues
– Principle 5: realize that quality makes the difference
• Quality is the differentiating factor when the functionality and
price are almost the same
– Principle 6: emphasize that the customer is always right
• Involve customer in the process, milestones, tap into their
knowledge and experience
– Principle 7: avoid gold plating and feature creep
• No matter how much you try, it’s almost impossible to deliver
acceptable product on time with negotiated price when
requirements are changing
By Donald J. Reifer, Software Management, 7th Ed., pp. 15-19, 2006
The “3 P’s” of Software management
– Principle 8: eliminate unnecessary paperwork
• Understand the needed documentation
• Differentiate between deliverable and nondeliverable documents
• Addressing people oriented needs
– Principle 9: reward your top performers
• Know who they are and do everything to keep them satisfied
• Nearly 80% of work is done by the 20% of your staff
• Do not stretch them too thin
– Principle 10: commit to personal growth
• Help your staff achieve their personal goals through work-related
training, mentoring, job assignments
By Donald J. Reifer, Software Management, 7th Ed., pp. 15-19, 2006
The “3 P’s” of Software management
• Addressing people oriented needs
– Principle 11: recognize what motivates performance
• Interesting work, growth opportunities, feedback, praise,
recognition for a job well done, ability to excel
• Recognize, respect and respond to people’s needs
– Principle 12: build bridges through open communications
• Stimulate a free exchange of information and ideas
• Allow your interdisciplinary and integrated product teams to work
across the organization
• Information flow up, down, and across the organization
By Donald J. Reifer, Software Management, 7th Ed., pp. 15-19, 2006
The “3 P’s” of Software management
• Addressing people oriented needs
– Principle 13: the equality principle
• Reward competence and incompetence equally
• Help your people set up aggressive but realistic goals
and hold them responsible for the results
• Do not hesitate to terminate an employee for poor
performance after trying everything to help him/her to
succeed
By Donald J. Reifer, Software Management, 7th Ed., pp. 15-19, 2006
Why big software projects fail:
the key 12 questions
• Question 1: are all large software projects
unmanageable?
• Question 2: why are large software projects hard
to manage?
• Question 3: why is autocratic management
ineffective for software?
• Question 4: why is management visibility a
problem for software?
By Watts S. Humphrey, Software Management, 7th Ed., pp. 21-25, 2006
Why big software projects fail:
the key 12 questions
• Question 5: why can’t managers just ask the
developers?
• Question 6: why do planned projects fail?
• Question 7: why not just insist on detailed plans?
• Question 8: why not tell the developers to plan
their work?
• Question 9: how can we get developers to make
good plans?
By Watts S. Humphrey, Software Management, 7th Ed., pp. 21-25, 2006
Why big software projects fail:
the key 12 questions
• Question 10: how can management trust
developers to make plans?
• Question 11: what are the risks of changing?
• Question 12: what has been the experience so
far?
By Watts S. Humphrey, Software Management, 7th Ed., pp. 21-25, 2006