A collection of essays on project management in Software Engineering. Some are standalone, but all flow neatly to convey Brooks’ thoughts and observations on issues in the project management space, and potential solutions. A good read for anybody involved in managing or directing an IT project – if you aren’t on the Software side, there are bits that won’t interest you but don’t skip over them (e.g. the discussions about thousands of lines of code – KLOC – per year per programmer!). This is not a generic project management text, and doesn’t teach you how to manage a project – but gives a history and anecdotes relevant to Information Technology projects – Software projects, specifically.
Book details
Title: The Mythical Man-Month (Anniversary Edition)
Buy Now: Amazon
Author: Frederick P. Brooks, Jr
Year: 1995
ISBN: 978-0-201-83595-3
Format: Paperback
Extras: None
What did I expect to get out of it?
Project Management theories and truths that I could apply to infrastructure design, build, maintenance, and support. People have described it as one of the “core” texts of Software Engineering Project Management, and more thoroughly, generic project management.
What DID I get out of it?
Project Management really is tackling the same issues – whether it’s Software in Brooks’ case, or a house, IT infrastructure, etc. Issues and realities I’ve observed in projects I’ve been part of are not alone, and not the first time they’ve occurred!
Interesting points
I found a lot of excellent quotes in this book – and I’ll reproduce some of them here. Context is king so make sure you buy the book 😉
The bearing of a child takes nine months
“Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth … The bearing of a child takes nine months, no matter how many women are assigned”
If you need to add more people to a project – you can’t simply divide the project effort equally among the new total headcount. Training time (to bring the new recruits up to speed) and communication (synchronising work, reviewing status, etc) needs to be added for each new person. Some of this scales linearly, and some increases in a “mesh” style, depending on whether each party needs to keep status with every other party!
The tyranny of estimation
“An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices – wait or eat it raw”
IT projects (and especially software projects) often have two dates – the first, when the product has been promised to the client – and the second, when it will actually be delivered. Brooks poses that Software project managers need to show more “guts” when it comes to standing up for a proper schedule. I think we’ve come a long way since this essay was published – software (and IT) has matured to the point where too many projects have failed, we have a vast history, and nobody wants to deliver late. We’re a lot more conservative now.
Architecture documentation is a great (and necessary) tool
“Only when one writes do the gaps appear and the inconsistencies protrude. … the documents will communicate the decisions to others. The manager will be continually amazed that policies he took for common knowledge are totally unknown by some member of the team”
This really struck home. As a solution architect, it’s really easy to make obvious decisions and have a great reason for doing so. What’s more difficult is remembering the reasoning behind the decisions at a later date, and ensuring that the reasoning is passed along to the implementation team! I’m going to step up my documentation game.
Milestones should be well defined
“Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. … Concrete milestones … are 100-percent events. … Rarely will a man lie about milestone progress, if the milestone is so sharp that he can’t deceive himself.”
I’ve been part of many a project in my career that has “fuzzy” milestones – easy to convince yourself it’s completed, easy to say that it’s almost done, easy to convince the boss that it’s nowhere near finished and you are swamped! Concrete progress and being able to say “done” is crucial to team morale – there has to be light at the end of the tunnel!
“Hustle” is something we all need
“A baseball manager recognises a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. … Hustle provides the cushion, the reserve capacity, that enables a team to cope with routine mishaps … The calculated response, the measured effort, are the wet blankets that dampen hustle”
Wow. Hustle. I’ve seen this before, but I haven’t put a name to it. I like to think I’ve got Hustle – but I also think it’s somewhat circumstantial. Even the best hustlers can get trodden down in politics and boredom. Some of the best times in my working career (and even non-work pursuits) have been with other people with Hustle. You feel like everyone is an A-player, they’ve got your back, and you have theirs. You can take on the world. Find yourself a team with Hustle – it feels AMAZING.