Art Of Project Management - Scott Berkun

Art Of Project Management - Scott Berkun

This book deals with issues of managing software project and this is an elusive subject. For programmers wanting to become Lead Engineers or even Architects there is either too much information or too little information what it takes to write good software. This book clearly defines the art of project management in a practical standpoint.

1. A brief history of project management (and why you should care) 
 I. Plans 
2. The truth about schedules

• Schedules have three purposes
• Commitement about when things will be done
• Encourage everyone to a project to see her effots as part of a whole, and invest in maing her pieces work with others
• To give the team a tool to track progress and to break work into manageable chunks.
• Methodologies
• Common Software development metodolgies are Water Fall Model, Spiral Model, Rapid Applications Development, Extreme Programming and Feature driven Development.
• Obsessing on process is a warning sign of leadership trouble. Tom Demarco in People ware: The obsession with methodologies in the workplace is another instance of the hightech illusion.
  
• What Schedules look like
• 1/3rd for Design
• 1/3rd for implementation
• 1/3rd for testing
• Applying the rule of thirds: If the project demands uneven distribution then we need good reasons for that.
• Piecemeal Development: Small projects word is done on a piecemeal basis and Agile methods are recommended. Still rule of thirds do apply.
• Divide and conquer : Big Schedules= many little scheules, which means break down tasks into smaller items and then provide schedule for those.
• Why Schedules Fail
• Shooting blind from very very far away : A shot in the dark schedule with no refinement based on requirements is a recipe for disaster.
• Schedule is probability: Schedules need not be perfect but have to be good enough for the team and leaders to beleive in.
• Estimating is difficult : Each work item is identified and distributed across programming team and tallying them the master schedule is created. It is better to involve QA team in the design process because they have insight into cases we overlook.
• Good Estimates come from good design: Good estimates only come from good designs and requirements.
• Establish baseline confidence intervals for estimates: A Guess=40%, Good Estimate=70%, Detailed and through analysis=90%.
• Lead programmers must set the bar for quality estimations by asking good questions and taking wise approaches that team can emulate.
• Programmers should be trusted.
• Estimates depend on the programmers understanding of the project goals.
• Estimates should be based on previous performance.
• Higher the quality of estimates the higher the quality of specifications.
• Theere are known techniques for making better estimates like PERT.
  

3. How to figure out what to do 
4. Writing the good vision 
5. Where ideas come from 
6. What to do with ideas once you have them 
 II. Skills 
7. Writing good specifications 
8. How to make good decisions 
9. Communication and relationships 
10. How not to annoy people: process, email, and meetings 
11. What to do when things go wrong 
 III. Management 
12. Why leadership is based on trust 
13. How to make things happen 
14. Middle-game strategy 
15. End-game strategy 
16. Power and politics