Software Management Plan (part I) Software management’s 7 deadly sins The “3 P’s” of...

Software Management Plan(part I)

Software management’s 7 deadly sinsThe “3 P’s” of software managementWhy 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 Straw Poll FindingsQuestions 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



• 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



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



• 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



• 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


The “3 P’s” of Software management

• The software management must perform the following activities:– Planning – Organizing– Staffing– Directing– Controlling– Integrating



• The “3 P’s” of software management:– Processes– Products– People



• 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



• 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



• 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



– 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



• 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



• 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


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


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



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


Software Management Plan (part I) Software management’s 7 deadly sins The “3 P’s” of...

Documents

Transcript of Software Management Plan (part I) Software management’s 7 deadly sins The “3 P’s” of...