Roundtable on Project Management: A SHAPE Forum Dialogue

Rating:
Summary: Every Project Tells a Story
Review: 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.

Rating:
Summary: A Masterful Job of Editing
Review: 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).

Rating:
Summary: I'm a contributor as well, but...
Review: I have to say that I learned a great deal from the SHAPE forum, the discussion group from which these gems were selected.

As a volunteer contributor to this work, I received no compensation for my efforts, which is why I feel justified in offering a review here.

You can read how industry experts have handled difficult situations in project work:

- Getting Started - How Big is It? - Estimating - What will it Cost? - Planning for Success - Management Focus - Knowing a Project is in Trouble: Project Indicators - Knowing a Project is in Trouble: People Indicators - People and Project Change - Being a Cassandra - Dealing with Impending Disaster - Doing Something Different - Dignified Project Death - Project Lessons - Personal Lessons

My contributions, Sometimes It's Timing and Be Careful with Unsolicted Advice, tell my short stories that I wish I'd read about before they happened. Each contribution can be a learning (and laughing...and crying) experience for the reader.

Jerry, Marie, and James have done a great job of boiling down the stories and insights that were shared with the SHAPE group over several years.

This is a short work, but includes a great deal of free advice that's already been paid for.

Rating:
Summary: Sound management advice from discussing disasters
Review: 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.