The Art of Project Management

Wednesday, September 21, 2005

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's "The Art of Project Management " 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!". "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, and very little real creative thinking. 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 "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

Use Cases: Requirements in Context

Friday, August 19, 2005

"Use Cases: Requirements in Context", by Daryl Kulak and Eamonn Guiney, professes to present a radical approach to gathering and defining software requirements, employing only Use Cases. Whilst many other writers embrace Use Cases as an important part of a requirements engineering process, here the authors take it all the way, and claim that not only is there no other workable alternative, but that any dilution by including other methods, such as narrative based approaches, is unacceptable. They take no prisoners, stomping all over Alistair Cockburn's notion of Use Case hierarchies (which I've always found a bit clumsy, to be honest), and generally being irreverent about everything else. It is quite entertaining, and presents an interesting thesis. Unfortunately, it is also appallingly edited, inconsistent, not terribly well written, and lacking in detail at crucial points. For example in section 2.3.4, the text refers to a sample Use Case which has nothing to do with the scenario under discussion, nominally based on this Use Case. However, on the next page, the discussion abruptly switches to something which seems relevant to the Use Case, but is a total non-sequitur in the text. There are many such examples of bad editing throughout the book. A really serious snafu comes on page 85: "NOTE: In the first edition of this book, we advocated a tool called system context level use case ? we formally disavow this technique in this new edition". Rather a pity, because in Section 4.4, Deliverables, we're told that the Facade iteration is complete when, amongst other things, a system context use case is documented. Whoops! In section 5.2, we're told that system context use case diagram shows the big picture, and each package's diagram will contain the detail for each set of use cases. Try "Find and Replace" in your word processor, chaps. It can be a surprisingly useful tool. Another irritating habit found in several places is introducing an interesting sounding concept and then failing to explain it properly. For example, the idea that non-functional requirements can be captured as Use Case stereotypes is, well, interesting ? but just one single example might help to convince the more sceptical reader. Equally, the much heralded "hierarchy killer" tool remains a complete mystery to me. It could be an interesting idea, but the author's writing skills do not reach a level where the odd example or diagram would not help a bit. However, if you are interested in the sharp end of requirements engineering, I do recommend you read the book, with the proviso to not treat it as gospel. It is provocative, sometimes funny, quite often entertaining, but the various errors and inconsistencies are jarring and left me rather disappointed. I did not believe that Use Cases offer a 100% proof solution to requirements definition, and I still don't, but in at least 80% of situations they work well, and this book provides some very valuable insights into applying them effectively. Publisher: Addison Wesley Pub Date: July 25, 2003 ISBN: 0-321-15498-3