Fred Brooks was in charge of a big software development project for IBM in the late sixties. As usual with big projects, the product came in late and over budget, it didn't quite perform as well as had been hoped, and by the time it was on the market there were new technologies coming up that would soon make it obsolete. Rather unusually for a manger, Brooks decided to devote some serious thought to why that had happened, and the result was this little book, in which he lays out some basic principles of project management that have application far beyond the (now largely forgotten) world of big mainframe computing.

The two big quotable ideas in the book are things you've probably seen on a Powerpoint slide if you've ever done project management training.

Firstly, the one that gives the book its title, the idea that real life jobs don't work like those famous maths problems where one worker digs a ditch in ten days and ten workers can therefore dig the same ditch in one day. In real life, the bigger a team gets the more complex the interactions between team members become, and the more time is consumed in internal communication, meetings, paperwork, administration, etc. This seems a very obvious point, but it's one I've often seen overlooked in real life. Senior managers love the idea of big, complicated teams, and it always ends in long delays and mountains of paper...
(It being 1975, Brooks talks about "men" and "man-months" throughout, except in his example of a non-divisible job: "If it takes nine months for one woman to produce a baby...")

Secondly, as a kind of corollary to this, he proposes Brooks's Law: “Adding manpower to a late software project makes it later.” This is a kind of paradox, of course, but the phenomenon it describes is one that probably happens in every workplace. You're overloaded with work, so your boss recruits someone to help you, and the backlog initially gets worse as you have to divert time into training and supervising the newcomer. In a fairly generic job that soon gets compensated as the new person becomes productive, but in a complex project it can rapidly turn a small delay into a catastrophe.

Beyond these headline ideas there is a lot of sound advice about what works and doesn't work in terms of team-structures, meetings, intermediate goals, and effective documentation strategies, all of which is readily portable outside software development (and a lot of which also seems to have survived into today's formal project-management systems). Specific to computing projects, he talks about the importance of focussing design effort on specifying what the product should do, and making sure that that fits within a unified vision, preferably defined by a single architect. The nuts and bolts of how the specification is implemented will take far less time to design than the specification itself.

The 1995 edition comes with a couple of follow-up essays looking at responses to the book, with some thoughts about what he would revise in the light of the unexpected ways computing has evolved. The personal computer revolution, with the consequent shift from expensive custom software to commercial "shrink-wrapped" solutions, has taken him by surprise, as has the rise of object-oriented programming, but neither of these things seems to invalidate the basic principles he set out. ( )

Excellent Project Management Theory

Fred Brooks was a software engineer at IBM for some decades and later chair of the UNC CS department. His experience and study makes this recounting invaluable. I felt like I highlighted a sentence on every other page. You must get the second edition and if you read nothing else in it (though it is a short book), you must read the 18th and 19th chapters. The 18th chapter is a summary of all prior chapters while the 19th chapter reflects on the book 20 years later in 1995 -- what changed and what hadn't. ( )

Good start, loses some insight later on due to age. Overall I liked it. ( )

Very good. Another one of those pretty amazing books that has relevance far beyond it's specific scope and time. Some of the chapters were also interesting just as a window into the big issues, challenges and concerns that have since been completely overcome.

The part that really most interested me was about the productivity of the great being ~ an order of magnitude better than even the good, and on top of that the fact that adding people has far from a linear impact. It's all about the right people.

Might have been a useful read 20 years ago, but any pm of more then a couple of years experience and worth a fraction of his salary should be already aware of the major points in this book. ( )