Customer Reviews

Roundtable on Project Management: A Shape Forum Dialogue

5 star:		(1)
4 star:		(3)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

Disclosure: I am the lead editor for this book as well as a contributor.

I re-read the Roundtable on Project Management just the other day. There was a project problem at my J - O - B, and something was nagging me . . . there's a solution to this, I know there is. Didn't somebody explain this to me once . . . Oh yeah, it's in the project book!

We wanted to create something to have on your desk to get a pointer or a nudge toward solving the problem of the moment. Having lived with the material for almost two years (not counting the forum time) it worked that way for me. Plus I got sucked right in and read the thing cover to cover, extracting three other little nuggets along the way. Pretty cool. Seems to work.

This book works as a wide-ranging, informal discussion of projects; pith-ful and pretty entertaining. It's not a project management manual - there are lots of those. But as a source of jiggles and complementary views it works. These days I give people aspiring to understand projects three books: Dwayne Phillips' _The Software Project Manager's Handbook . . ._ (which wasn't out when we had these discussions), _Software Engineering Project Management_ part of the outstanding series of tutorials from the IEEE, most edited by Richard Thayer, and _Roundtable on Project Management_. Between them, they form a balanced view, and an entry point into more developed information on any of the several approaches to projects.

Editing this book I learned that each project is a story that people live. And every project is made of the woven stories that individuals live. So the book models projects as well as describing them: it's a story made of woven voices. This book feels the way projects really feel. That's valuable, I think.

Editing _Roundtable_ finally started coming together when I re-read _Spoon River Anthology_ - also a bunch of independent stories, each part of a bigger tapestry. I'm no poet, and certainly not the master that Masters was. I did manage to recognize the model I was trying to emulate - I stole from the best. Successful projects are also made of woven voices, that form a whole. So the book models what project success looks like, too, I think.

If you're looking for "Tools and Techniques for Risk Management" or "MS-Project on steriods", or even "Collected Wisdom - A Project Manager's Guide" well, this is the wrong book. If you are looking for a source of nuggets for that nagging problem, and for a compelling story, one like the story you're living, well, this is very probably a good book for you.

And if I contributed to the quality of this book, it's mostly just what good project managers do: let the stories happen. I'll be a good project manager one more time and say that the four stars I gave this book belong to the voices in it - to the contributors. The one star missing is mine. I could only manage to get out of the way four stars worth.

SHAPE is an acronym for Software as a Human Activity Performed Effectively and is also the name of a web based discussion community devoted to issues in project management. The participants in the discussion are some of the leading figures in the area of the management of software projects and this book was constructed by selecting some of the more profound points made in the online debate.
What is most interesting about the discussion is that it deals with management situations rather than being restricted to software projects. The point I found the most useful is the description of serious failures that have occurred. Generally, when the problem begins, the decision makers are receiving accurate data that clearly indicates that a failure is imminent. However, it continues to progress and become critical because those receiving the data find it difficult or impossible to believe the data until it is too late. This is a very common occurrence in the software development world, as often everyone from the senior managers on down choose to ignore the warning signs that the project is moving towards failure. Even worse, anyone who breaks ranks to raise the issue is censured or even terminated. Finding a solution to this category of problem is probably the most difficult of all managerial problems to solve. Such a complex problem is not easily resolved, but the advice here will certainly help.
One other discussion that was of great interest is the one about the sinking of the Titanic. In fact, I learned some aspects of that most catastrophic of failures from the SHAPE discussion that I was not aware of, although some of the discussion is a bit unusual. It turns out that the limited lifeboat capacity was due to a redefinition of their purpose. Since the ship was unsinkable, the only possible use for the boats was to ferry passengers off in the event the engines were to quit. The most unusual point in the entire book was a dialog thread where the debate point was whether the attempt to avoid the iceberg was a mistake. It is argued that it would have been better to have rammed the iceberg, which would have severely damaged the ship, but not enough for it to sink. At first hearing it may appear absurd, but the point is a sound one. When catastrophe strikes, sometimes the best long term solution is to accept severe initial damage and survive rather than to attempt to avoid it with a more serious result. This is directly applicable to many software development projects, which always seem to be rudderless in a sea of potential disasters.
The dialog in this book sometimes seems disjointed as a consequence of having been gleaned from many pages of online discussion, where the feedback is all dialog based. However, that is not a serious problem, it just requires a little more concentration on the points, which is beneficial. The main points show you that it is possible to obtain software development strategies from unusual circumstances, even those that cost hundreds or thousands of lives.

Full Disclosure: I am one of the contributors. My contribution to the book is just that, a case for discussion. And discuss the other contributors did. You can't read this book straight through because there is just too much insight to be absorbed at one sitting.

James Bullock's editing and contribution are central to the value of the book. Bullock is sometimes difficult to follow, his statements are often Zen-like. He always bears a close reading. Worth the extra effort to comprehend.

This is a masterful book. Kudos to all the editors and contributors (other than I).

I read 'Roundtable on Project Management' over a period of a few months. Because it is condensed from a series of discussions that took place on a web site over a period of months/years, it was easy enough to pick up and then put down again (a habit for busy software developers that can never manage to free up more than 15 or 20 minutes at a time). For the same reason, it seemed at times a bit disjoint and required some re-reading in order to determine exactly what the authors were saying.

I found this book to be informative, interesting, and useful. I especially liked the conversational style, and the humorous (although not always intentionally) nuggets such as "... the most commonly used risk management technique is denial." and "If a peer review finds zero defects, then you weren't looking hard enough." Sometimes a little cynicism creeped in, but overall it offered a pretty realistic look at software project management (a difficult balance between optimism and pessimism).

One of the most useful aspects of this book is the Bibliography, along with the various references scattered throughout the sixteen chapters. I often found my self wanting to pick up one of these other books in order to learn more. In today's age of information overload, it is extremely important to me to be able to find books that are relevant to my job and my interests without having to wade through the numerous other offerings that may be somewhat related, but often aren't.

As a software developer/sometimes software project manager, I have seen more than my share of poorly planned and executed projects over the last 13 years. And I have seen many of the same problems that the authors talked about, so I identified with them and their stories. And because I shared those common memories and battle scars, I found their suggestions and recommendations very helpful. Especially usefule were the tables at the end of each chapter, called Lessons, that condensed the useful information from the chapter into a short list (not necessarily easy to do). I will refer back to these lessons again and again.

Overall, it was well worth reading and has given me what I need - additional resources to explore as I try to resolved project problems in the future.