Roundtable on Project Management

By Gerald M. Weinberg

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.

• Language: English
• Publisher: Gerald M. Weinberg
• Release date: Jul 14, 2011
• ISBN: 9781465803184

Gerald M. Weinberg

Gerald M. Weinberg (Jerry) writes "nerd novels," such as The Aremac Project, Aremac Power, First Stringers, Second Stringers, The Hands of God, Freshman Murders, and Mistress of Molecules—about how brilliant people produce quality work. His novels may be found as eBooks at or on Kindle. Before taking up his science fiction career, he published books on human behavior, including Weinberg on Writing: The Fieldstone Method, The Psychology of Computer Programming, Perfect Software and Other Fallacies, and an Introduction to General Systems Thinking. He also wrote books on leadership including Becoming a Technical Leader, The Secrets of Consulting (Foreword by Virginia Satir), More Secrets of Consulting, and the four-volume Quality Software Management series. He incorporates his knowledge of science, engineering, and human behavior into all of writing and consulting work (with writers, hi-tech researchers, and software engineers). Early in his career, he was the architect for the Mercury Project's space tracking network and designer of the world's first multiprogrammed operating system. Winner of the Warnier Prize and the Stevens Award for his writing on software quality, he is also a charter member of the Computing Hall of Fame in San Diego and the University of Nebraska Hall of Fame. The book, The Gift of Time (Fiona Charles, ed.) honors his work for his 75th birthday. His website and blogs may be found at http://www.geraldmweinberg.com.

Book preview

Roundtable on Project Management

A SHAPE Forum Dialogue

edited by James Bullock,

Gerald M. Weinberg,

and Marie Benesh

SMASHWORDS EDITION

PUBLISHED BY:

Weinberg & Weinberg on Smashwords

Roundtable on Project Management

A SHAPE Forum Dialogue

Copyright © 2011 by James Bullock, Gerald M. Weinberg, and Marie Benesh

All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of both the copyright owner and the above publisher of this book.

Smashwords Edition License Notes

This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person you share it with. If you're reading this book and did not purchase it, or it was not purchased for your use only, then you should return to Smashwords.com and purchase your own copy. Thank you for respecting the author's work.

APPRECIATIONS

No book is a solo project. This one is less so than most.

Unlike most books, this one was written by a Web-based community. This community, called SHAPE, provided a collection of real insights, well put and grounded in experience. The Shapers who contributed their words to this book put their trust in the editors. Any would-be editor would be lucky to have content like this to work with.

Throughout this process, I've had two coeditors, and frankly, either or both should probably be listed as the lead editor of this volume. Aside from their patience, they provided confidence and moral support, as well as good judgment and occasional insistence. If you ever have to do something that scares you to death, choose Jerry and Marie as your colleagues.

If I have done my job well, with all this help around, the insights and the individual voices of the SHAPE forum contributors will come through in this book. If they don't, the fault lies with the messenger, not with the message.

CONTENTS

CHAPTER 1 • INTRODUCTION

CHAPTER 2 • GETTING STARTED RIGHT

CHAPTER 3 • HOW BIG IS IT?

CHAPTER 4 • ESTIMATING

CHAPTER 5 • WHAT WILL IT COST?

CHAPTER 6 • PLANNING FOR SUCCESS

CHAPTER 7 • MANAGEMENT FOCUS

CHAPTER 8 • KNOWING A PROJECT IS IN TROUBLE: PROJECT INDICATORS

CHAPTER 9 • KNOWING A PROJECT IS IN TROUBLE: PEOPLE INDICATORS

CHAPTER 10 • PEOPLE AND PROJECT CHANGE

CHAPTER 11 • BEING A CASSANDRA

CHAPTER 12 • DEALING WITH IMPENDING DISASTER

CHAPTER 13 • DOING SOMETHING DIFFERENT

CHAPTER 14 • DIGNIFIED PROJECT DEATH

CHAPTER 15 • PROJECT LESSONS

CHAPTER 16 • PERSONAL LESSONS

BIBLIOGRAPHY

CONTRIBUTORS

FURTHER READING

PREFACE

To me, SHAPE is the Algonquin Round Table of systems development. For a period of years, Dorothy Parker, Alexander Woollcott, Heywood Broun, and Robert Benchley gathered for long lunches at the round table in the Algonquin Hotel in New York City. They would gossip, trade quips, and chatter. They'd talk about their work, and their work was better for it. They pushed each other by being worthy colleagues and worthy competitors. During those long lunches, seeds were sown that became columns, essays, and plays. I am regularly struck by the quality of insight and advice that shows up on the SHAPE forum. The high quality of the writing matches the high quality of the content. I've found less wisdom in week-long expert training or in months-long mentoring than in one morning when I log in to read SHAPE. Its power, I think, comes from

• the breadth of the participants' backgrounds

• the participants' depth as individuals

• the grace of the interplay between the participants

• the interplay itself

We are not a group of Manhattan writers—though a few of us write from the Big Apple—and the common discipline is systems (Jerry says software), not literature. However, the conversation certainly is literate, challenging, and enlightening. On SHAPE, there are dozens of authors, consultants, managers, and workers from every IT specialty and every kind of organization, spread over five continents. This community isn't available in my city, my school, or my company, and never has been. Like the Algonquin Round Table, SHAPE is a high quality community that pushes one to do better—it pushed me to find the Algonquin analogy itself. SHAPE is a very big roundtable.

We Shapers are familiar with the entire existing canon of systems development. (In fact, we wrote some of it.) We don't limit ourselves, however; the conversation includes psychology, anthropology, operations management, math of various flavors, physics, science fact and fiction, history, music, literature, and training—of people, dogs, and even horses. Even better, we use our own experiences. Hanging about on SHAPE are a couple thousand years of system-building experience.

This richness leads to tremendous signal to noise—part of Jerry's description of SHAPE. Whatever I read on SHAPE is relevant, informed, and always worth my time. Building systems is, I think, one of the hardest, most human activities. Why spend hours discussing hard problems on the SHAPE forum, with people who can't advance your career—and who don't even pay you? For me, the joy of the association and of what I learn is reason enough. I believe the Algonquin Round Table made those writers' work better. To do my work, I need all the help I can get.

SHAPE supports my urge to get better at this thing I do—yet I think it's bigger than that. Systems come from individual experts inventing and creating in concert, rather like SHAPE itself. As the useful objects in our world are less made of stuff and more made of thought, more activities become like building systems—people creating by thinking together, versus making together. (That's just my opinion. Some folks on SHAPE will disagree, but that's okay. We'll talk about it.)

The Internet enables communities that are independent of space and time. The Internet lowers the cost and expands the reach of each community's vanity press. Some social critics argue that Net addiction attracts people who lack social skills and have nothing to say. I wouldn't know about that. I've become addicted to a community of people with more insight and grace than I have found by any other means. The wired world allows a small minority to reach critical mass by having access to more people, across broader time. I've found a community of sincere intention (a phrase I learned from SHAPE) that is also a living example of what it takes to build good systems. It's the people thing, not the Net thing, that matters to me.

I wanted to extend this community even further, so I asked about it on SHAPE:

How do we share this with the rest of the world?

Jerry replied: I often think about that question. After all, we Shapers are trying to change the world.

What we've done—Marie Benesh and Jerry and I—is take part of two years' worth of the discussions and shaped the threads into a series of books. The shaping process was mainly a matter of organizing what people posted on the forum. It really couldn't be any other way. After all, how could a few of us duplicate or even represent two millennia of refined experience? We didn't even try.

- James Bullock

CHAPTER 1 • INTRODUCTION

The Story of the Failed Success

BRIAN CROOK

I was a consultant hired to coordinate a simultaneous upgrade of AIX (IBM's UNIX for the RS6000), Oracle, and a proprietary customized package I'll refer to as SAM.

The main players were Jim, the user champion; Tony, the IT manager (my client); Tom, the SAM project leader; George, the sys. admin.; and me. I drew up the project plan based on meetings and my expertise as to what needed doing, published it, and asked for feedback, especially with regard to my time estimates.

Things went well at first, even though one day Tom called to ask what work comprised certifying SAM for the new AIX/Oracle platform. I explained that this item was an event, not an activity, and that it consisted of the SAM group's certification to the client that SAM would run on the new platform. It was up to him as SAM project leader to decide what work to do in order to be able to say that.

Then came crunch time. SAM came up three weeks late and short all deliverables except the code itself, so George and I had no detail for our test suite. (The concept of a test suite was itself poorly understood, no matter how I explained it.) What followed was a Keystone Kops movie, played wearing snow-shoes.

The players were under personal and professional stress. Jim was sweating his wife's difficult pregnancy, and she actually went into labor in the middle of this tragicomedy. Tony got the promotion of his life and was working ten hours a day while trying to stay in control of the SAM project. They both panicked.

Out with the test plan—no time to develop a test suite—don't wait for the rest of SAM's deliverables—full speed ahead—and damn the torpedoes! They basically ignored my presence, except when I tried, and screwed up, some sys.admin. duties. George was committed to another project because we were late. Moreover, he was carpooling and not available in the evening when I was trying to do what Jim and Tony had planned.

Jim and Tony never really bought into the project plan.Tony, especially, preferred to wing it. He had a loud, basso voice that he used to dominate meetings. Many meetings revolved around technical points, where Tony would show off his so-called brilliance. We had people problems all the way,and I was one of the people.

Did I get fired? Well, yes and no. I was moved to another part of the client company to make room for an employee on the SAM project, but I got the warmest send-off from Jim andTony—lunch at my favorite place and a deluxe pen engraved with the SAM project logo!

CHAPTER 2 • GETTING STARTED RIGHT

What Choices Are You Making?

JERRY WEINBERG

In Brian's story, I have identified several choice points:

• choosing to handle so many changes at once (that is,violating the Edsel Edict, as stated in The Secrets of Consulting: If you must have something new, take one,not two.) [see The Secrets of Consulting in Further Readings]

• failing to make a big deal about being sure everyone understands his or her part of the plan

• not adjusting schedules for, or leaving slack for, such events as difficult pregnancies, birth of babies, people being promoted

• allowing executives to introduce changes (like promoting project people) without adjusting project expectations

• permitting an environment to develop in which the only communications were negative

• planning on regular evening work, and then not following up on the plan

JAMES BULLOCK

There were clearly several decisions made behind the scenes in Brian's story:

• Decision before the project: There were some undiscussable and unchangeable things in the project environment that perhaps led to, certainly increased the chances of, a difficult project. The decision was to accept these risks and limitations. (I would say the decision was to let them slide, but sometimes you're-stuck.)

• Decision during planning: Make a PERT without carrying around all the various sundries associated with a plan: assumptions, definitions of deliverables, known risks, and so on. A plan is a triplet of concerns: results,resources, and methods.

• Decision about what to manage: The project was managed to time and tasks, not to deliverables. If the project were structured on deliverables, the concept of a code only delivery couldn't even get in. Tasks and burn rate (and, God help us, dates) are the wrong measure of progress. They measure investment.

Does Your Project Fit Its World?

DAVE KLEIST

Does the project support a strategy that is compatible with the stated business strategy or position in the marketplace? For example, trying to provide functionality comparable to the best of market while