A surprisingly pragmatic book on managing software projects, The Art of Project Management by Scott Berkun contains practical suggestions and clear-headed explanations without getting involved into methodologies or buzzword-compliant processes.
I’m very sceptical about project management books, as most that I’ve seen have sort of a gospel feel, preaching how to behave and what to do, without any proof that it actually helps. I always try to challenge and test any advice, and I really have a hard time believing blindly. After reading this book, I did not feel like I’ve just spent three hours in a boring lecture of some crazy academic, so Scott Berkun must have done something right. Unavoidable bullet-points of dos and don’ts are nicely reinforced with examples and thought-provoking questions, and the author gives quite a few stories of how he burnt his fingers and learned from the experience. Considering that his projects included development of Internet Explorer, Windows and MSN, those experiences are quite valuable to know.
In addition to typical project management topics such as scheduling, leadership and moving the project along from start to finish, author devotes a big part of this book to subjects that are rarely discussed in the open, including what to do when things go wrong, how not to annoy people and how to get a better picture of workplace politics.
I generally consider money well spent if I find one or two useful tricks in the book, and I found quite a few useful ideas and pointers in this one. My personal favourites are key topics that should be covered in specifications and various plans, which I use all the time as templates. Scott’s insights on how things are done in Microsoft are also very interesting.
The book has about 370 pages, which is a bit over my usual threshold, but it’s still very readable. I think that this book will mostly appeal to people coming from a technical background into project management, or those that play both project management/technical leader roles. However, chapters on writing specifications, communication and politics should be quite useful to anyone involved in software development, from programmers and technical writers to managers.
