I'm afraid I'm going to have to go against the flow here. I really wanted to like this book. There is most certainly a place for a different angle on project management, other than the usual "how to use Microsoft Project" or other dry-as-dust doorstops, and Scott Berkun enthusiastically tries to fill it. However, the informal, rambling and slightly egocentric style that he deploys to very good effect on his website writings gets irritating and doesn't scale to a book. I kept finding myself quietly screaming "Get To The Point - if you have one". "The art of project management" really boils down to a thinly disguised autobiography of Scott's time with Microsoft. From other articles it seems that either his heart wasn't really in it at Microsoft, or he has resolutely moved on, realizing that to deny his creative side was getting him nowhere (and apart from the paycheck, what satisfaction could anyone derive from managing a piece of such insipid bloatware as Microsoft Internet Explorer ?). I fully empathise with him on this, but not to the extent that I'm going to read his book with blinkers on. The main problem is that there are far too many glib, superficial observations on the dynamics of software development teams dressed up as profundity (actually, this reminds me of a far better book, also from a Microsoft staffer: Jim McCarthy's classic "Dynamics of Software Development", which should be required reading for anybody in any software company anywhere).
There are just too many "so what" moments in Scott's book, things which he seems to think are great insights, but which are just plain everyday life in most companies. There is very little real creative thinking, very few ideas or solutions on offer.
I could take specific issue with a number of points - just one example would be that the "basic" functional requirement he uses to illustrate a point, "There will be a barn and it must be green", it just wrong. It describes an implementation, not a user need. It would be better expressed as a series of statements "there shall be a covered space", "the covered space shall not be heated", etc, which would then lead to the solution space he talks about. But in any case, this is in the domain of requirements management, not project management, and it is hardly the only substantive digression.
The text itself is full of minor digressions and little jokes, which start off ok, but get a little old very quickly. It is also illustrated with sketchy type diagrams, which look cute but convey nothing, and random photographs, a bit like Phil Greenspun's timeless "Phil and Alex's Guide to Web Publishing", but nowhere near as good - or indeed upfront (Greenspun declares openly that the photos are totally irrelevant). Actually, I get the feeling that Scott is a bit of a Phil Greenspun wannabe - well so was I once, and there are plenty of others out there.
Clearly Scott wanted to write, and the most marketable topic was going to be something like this that he could flog to O'Reilly. And clearly, there is a subject here to be written about in a new way. But to be honest, whilst I find his website very useful, and inspirational in places, and I'm sure I'd like him personally, I'm afraid the book is a total dud. With firmer editing and mentoring from a stronger publisher, he might have turned out a classic, but then again, since one gets the impression that despite what he says he couldn't wait to escape from Microsoft, I have my doubts. Perhaps he'll write the Great American Novel one day, but he'll have to tidy up his prose first
