I have a new appreciation for the people who do project management. Writing code may be scary, and there are technical challenges involved... but at least you get the respect that comes from incomprehension. Project managers have it much tougher, because everyone can see the project plan and the timeline.

So I've been spending my time lately trying to understand project management. I've come up with some interesting references, but probably the primary one is Steve McConnell. In Professional Software Development, he confirms a long-held suspicion of mine that doing it the right way is the fastest way. This is because any attempt to push development time results in more bugs. Fixing the bugs then wipes out any time savings made in doing it the "quick and dirty" way.

The great thing about McConnell is that he doesn't just blindly assert this. He can back it up. He has ties to the IEEE and Microsoft, and he has the studies and can provide data to support his assertions, line for line.

Having said that, he's not the only person who says this. Tom DeMarco's novel The Deadline also spends most of chapter 14 saying that "There is no way to get projects to perform substantially beyond the norm without making large reductions in the total amount of debugging time." And the corollary, which is "High-performing projects spend proportionally far more of their time in design."

And then again, from a third source. This time, from Christopher Duncan, in The Career Programmer, a very funny book about ways to survive the software industry. In between talking about attack Chihuahua and dodging arbitary deadlines, he has an anecdote in the beginnings of Chapter 6. He talks about a system where he "designed the entire system on paper, down to the function level, complete with all parameter passing, and debugged it in peer meetings before we ever got near a compiler. Seems like it took forever at the time, but in retrospect the design and coding phase together took about half the time it would have taken with the typical shoot-from-the-hip-and-debug-all-night approach. [...] Everything that they tell you in these methodology books about the benefits of following an analysis and design approach thoroughly, in great detail and by the book, is true. I've seen it work."

The interesting thing is that on most software projects, the default path is the one which has the least likelihood of success. The "aggressive" or "ambitious" schedule is a synonym for "risky." "Risky" is a synonym for "likely to fail." And many software projects do. Death March goes into in some detail on the horrors of aggressively scheduled projects, while Waltzing With Bears gives us the hilarious analogy of a project manager trying to catch a plane:

"An IT manager and a normal person are both working in Chicago on a Wednesday afternoon when they learn that they have to be in San Francisco for a noon meeting on Friday and it's imperative to be on time."

[Description of normal person's schedule skipped.]

"The IT Manager, Jack, has booked himself on the 8:40, Friday morning. He catches a cab midtown at 7:05 and runs into a traffic jam on the Eisenhower. He complains angrily to the cabdriver all the way out to O'Hare. The stupid drive just can't be made to understand that it is essential that Jack make this flight. When he checks in at United, he tells the check-in clerk rather forcefully that the flight must take off and land on time, no excuses. He tells her that he will be 'very, very disappointed' with any lateness. When a gate hold is announced, Jack jumps up and objects loudly. When a revised departure time is announced, he digs deep into his bag of managerial tools and delivers the ultimate pronouncement: 'If you people don't get me into San Francisco in time for my noon meeting, HEADS WILL ROLL!'"

The ultimate validation behind Waltzing With Bears is the province from which it originates. The authors (one of them Tom DeMarco again) use litigation information from failed projects to show the consequences of late projects. The book not only talks about risk management and the dangers of not including a complete picture of risks to the project, but they bring out an idea that I haven't heard in a long time: A realistic estimate is one where a software project has a 50% chance of being late, and a 50% chance of being early.

Early. I haven't heard that word in a long time. Who delivers software early? In what organization do project managers have the political will to define a schedule that could be early?

At the very least, accurate project management as they define it makes no bones about uncertainly. If there's a window for lateness or failure, an accurate project plan will include it in the window. Just that idea alone would be wonderful -- a project plan that didn't have to be revised or thrown out the window entirely because it encompassed the idea of risk.

Amongst other things, Waltzing with Bears is worth buying just because it exonerates the infamous Denver International Airport failure. Viewed by Demarco and Lister, the true failure was not the bugginess of the baggage-handling software, but the failure of the management to even consider an analysis of the risks involved, and plan accordingly. In fact, when the DIA board of governors put the job to bid, no-one would accept it. The company which did accept the bid, BAE Automated Systems, only did so on a best effort basis, and, from the very beginning, stated loudly and repeatedly that the delivery date was in jeopardy. And it was possible to mitigate that risk: the tunnels that were meant to serve the automated system could have been built so that people and vehicles could navigate them, so the luggage could have been delivered manually. The lack of a fallback plan if the software failed is what led the airport to be charged delay fees of over $500 million dollars.

In addition to these books, I've also found some useful software. The most useful one has to be Estimate, by Construx. Here's a screenshot of Estimate:

You can set up parameters, and watch as Estimate will run your project through a Monte Carlo distribution to find out what your deadline is mostly to be. It's calibrated with industry data, so it already knows how long most other projects of that nature takes, and it agrees with other models and (more importantly) my internal intuition of how long projects take.

In addition to Estimate, there's also a spreadsheet model called Riskology. This is the model that's used internally by Waltzing with Bears. I didn't find this quite so useful myself, but then I'm not a project manager.

Finally, there's an industrial strength software model called COCOMO II. This beast has been around for almost 30 years, and has a large amount of military and academic history behind it. However, it has a terrible user interface, and I'm not sure if I even understand half the things it's trying to tell me.

In addition to the published resources, I'm trying to get a handle on the day to day struggles of a project manager. For this, I've found the weblogs of Johanna Rothman, Laurent Bossavit, and Esther Derby to be most helpful. YMMV.

All in all, it makes me very aware of how much I don't know. If you know more than I do, please help me add to this list.