Will We Ever Learn? Lessons from The Mythical Man-Month

Last week I had coffee with fellow tweep, Peter Kretzman, at the Zeitgeist Coffee in Seattle. We had a wonderful conversation and shared stories, philosophies, and impressions. In the process we stumbled upon a common literary love—The Mythical Man-Month by Frederick Brooks. I read it for the first time last summer and Peter reads every few years. We both extolled the virtues of the book and lamented at the fact that so many of the items Brooks brings up continue to plague us today.

If you have not read the book (I strongly recommend you do), it discusses the lessons learned from building the IBM System/360. Yes, the 360. I was still in grade school, and many readers were less than a glimmer in your parent's eye. Amazingly the book continues to sell, topping over 250,000 copies in print, and is still perfectly relevant. That is also the sad part, it appears we have not learned from past failures.

Silver Bullets

The core to building systems is making sure the requirements meet the business needs. Tools can help with the coding and even aligning requirements but none of them will improve productivity an order of magnitude. Neither can they ensure the requirements are the correct. This is the most difficult, time consuming, and error prone portion of any system development project. It still takes people talking to people, gathering the correct requirements, and turning them into a usable system.

Case Study: Internal Scope Creep

People often make feature suggestions while defining the implementation details. Because it is part of implementation, there is an implied justification on being outside the governance of a scope management process. One example was on a data entry system. There was a requirement that no data would be committed to the database until the entire four-page data entry from was complete. Since canceling the entry could be a mistake, the user should confirm that they wanted to cancel before their data was lost. The person designing the implementation asked if besides the confirmation (i.e. "Are you sure you want to lose your work?") the user wanted an option to print the data entered. This would make it easier to reenter. He had a print function that had been implemented in another system and it could be easily reused. This was a noble and valuable offer. However, the request was more than a simple print function. It required report design (always emotional due to layout preferences), unit testing, system test modifications, training enhancements, and additional maintenance. The logistical questions, though, were the real issue—did all users have a printer and was there personally identifying information (addresses, phone numbers, tax identification numbers, etc.) whose printing would compromise security? The latter concern killed the option and required disabling it. Even then, there was long debate about the plethora of ways to determine who was eligible to print in order to attempt to retain the out-of-scope feature.

The moral is that there are no simple solutions. They are always bigger than we first expect.

Silver-bullet tools cannot solve issues on a project. They can address some area but leave others exposed and vulnerable. As the colloquialism goes, they are just trading the devil we know for the devil to be reckoned with.

Progressively Sliding Schedules

"How does a project get to be a year late?
...One day at a time"

A day here, a day there, projects slowly drift later and later. Eventually, someone looks to see the project is months or years late. Realization that the project is late only happens after senior management has the epiphany there is an issue. They set off the alarms as if it happened overnight. However, a project timeline jumping by months on a single problem is rare, if non-existent. Even then, the issue that caused the delay does not manifest without warning—it is a risk that should have been known well in advance. People did not properly identify and understand the threats in the project.

Internal Scope Creep

Scope creep introduced by the project team, not the customer, is the stealthy stalker, prowling inside the project ready to swell scope. A form of this, the second system effect, Brooks defines as when a team working on a product for the second time includes "frill after frill and embellishment after embellishment that occur to" them in the first pass of working on the system. At which time the features were only noted, their implementation delayed due to the newness with the product. The second system will bear the brunt of the additional scope as team members add it devoid of any formal change process.

People

Delicious

It all boils down to people. People cause the schedule to slide, they add scope, and they are over-optimistic. The solution is a team that can realize there is a problem, identify a solution, and implement a solution. Teams need leaders, guiding them through difficult decisions and defining what is needed rather than what is wanted.

Tags: Frederick Brooks, IT Failure, Mythical Man Month, Project Management, Leadership