Software Management Plan (part I)

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

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

3. Software management’s 7 deadly sins By Donald J. Reifer, Software Management, 7th Ed., pp. 5-8, 2006

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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