McConnell also offers some great ideas like keeping a project history to record lessons learned and actual project data (time to completion, lines of code, etc.)
He talks about Quality Assurance practices and team development. Interestingly enough, his book starts with a diagram and commentary on Maslow’s human needs heirachy, and how the needs of a software development group are similar. He proposes a Bill of Rights for the project team, and a Bill or Rights for the customers.
He offers a project health quiz–allowing you to measure your project to see how probable it is at succeeding.
McConnell ends his book with a chapter on project do’s and don’t, borrowed from NASA. These are:
Software Development Project Do’s:
- Create and follow a software development plan.
- Empower project personnel.
- Minimize the bureaucracy.
- Define the requirements baseline, and manage changes to it.
- Take periodic snapshots of project health and progress, and replan when necessary.
- Re-estimate system size, effort, and schedules periodically.
- Define and manage phase transitions.
- Foster a team spirit.
Software Development Project Don’ts:
- Don’t let team members work in an unsystematic way.
- Don’t set unreasonable goals.
- Don’t implement changes without assessing their impact and obtaining approval of the change board.
- Don’t gold-plate (don’t add features no customer asked for).
- Don’t over-staff, especially early in the project.
- Don’t assume that a schedule slip in the middle of a phase will be made up later.
- Don’t relax standards in order to cut costs or shorten a schedule.
- Don’t assume that a large amount of documentation ensures success.
Overall, this is a great book for new software development managers, and software development mangers who have chosen SDLC, or other non-Agile development methods. Published in 1998, this book came out before the Agile software development movement. Regardless, it’s a good book to refer to occasionally.
Mike J Berry