Book Review: Reflections on Management by Watts S. Humphrey

The book “Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself” is composed of papers previously written by Watts Humphrey about people and management aspects of software project management.

The people and management aspects of software development are often neglected in software project management books, and this one is a good source to start thinking about them… and improving our practice. The book is structured in four parts: managing your projects, managing your teams, managing your boss and managing yourself. In each part, the book presents both general principles and real life examples or stories taken from Watts Humphrey career. This makes the book very easy to read, as we can connect the theory to situations that we have met in our software development professional life.

My favorite part deal with negotiation and is titled “good negotiators have an effective strategy”. Whether you deal with other project managers, software developers or end-users, you will always have situations where you will try to reach an agreement in a context where people seem to have conflicting goals. This part will help you to deal better with those situations.

I will recommend this book to every software project manager, as Watts Humphrey talks not only about how to manage people, but also how to deal with managers. If you think that successful software development projects are mainly based on people interactions and communication, this book is for you. The content is also valid if you are using Scrum or another Agile project management framework.

Reference: “Reflections on Management – How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself”, Watts S. Humphrey and William R. Thomas, Addison-Wesley

Quotes

Before condemning programmers for doing sloppy work, it is appropriate to consider the quality levels of other types of printed media. A quick scan of most books, magazines and newspapers will reveal at least one and generally more defects per page while even poor-quality software has much less than one defect per listing page.

It is essential to remember, however, that until you have clear requirements, you cannot develop a quality program. While you may not start with clear requirements, you must understand the requirements before you can finish.

Think about it this way. Management has just said, “We have this key project, and the best date we think you can make it is nine months.” If you don’t counter with another date, they will hold you to nine months. Unfortunately, if you just guess a later date, they will ask you why. And if you don’t have a good answer, they will either ignore your date or get somebody who doesn’t argue. Management doesn’t know how long the job will take, and neither do you. If you knew, and if you could convince them you knew, they would accept your date. If the project really will take 12 months, the last thing most managers want is a commitment to deliver in 9 months. You work for them, and they will also be held accountable for your schedule. They could easily lose their jobs if your project fails, and all you would lose is a chance to have another disaster. That would probably be a relief, at least after this project.