Last week, I attended a local technology marketing event, and when the CIO of a local bank got up to give his testimonial, he said something that made me cringe:

"And if we need to get it done faster, we can just add some personnel."

In light of some current events and research, it's worth revisiting why software projects are hard and some 30-year-old lessons.

For example, the New York Times recently printed an article (free registration required) about a (nearly) failed project at the FBI -- a nearly failed $170M project. How could such a large project at so critical a government agency run awry? The choice quote, from FBI Director Robert Mueller, was:

"There were problems we did not anticipate."

At the risk of sounding like Yoda, anyone running a project should anticipate things that are not anticipated -- that's par for the course. Plenty of statistics point to the fact that most projects fall short and run long. Bad projects are like car accidents -- nearly everyone will be in one, and it's often not under your control.

A recent study of 720 software projects, published in the ACM Queue, identified key risk drivers:

The results revealed that the most critical risk driver was the choice of methodology -- a result that we were not expecting -- followed by customer involvement, use of formal project management practices, similarity to previous projects, project complexity, and requirements volatility.

The reader may find it both Ironic and instructive that even the project to study software projects had unexpected results...

Technology now is very different from 1975, but The Mythical Man Month is as relevant today as the day it was written. The author, Frederick P. Brooks, is the "father of the IBM System/360" and a Turing Award winner. The book collects his views and experiences building software, about effort and output, about teams and roles, about rookie mistakes, and about the inevitable bumps in the road. (There is a summary on Wikipedia.) Reading the book won't guarantee a smooth project, but it will reinforce the realities or software projects that are too easily forgotten -- even by seasoned professionals.

Paul Brown