Sunday, 01 August 2010 00:00

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

Rate this item

(0 votes)

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.

**Want to read more?**

Business environments change daily making it difficult to keep initiatives aligned with the corporate goals. Without alignment the projects and initiatives fail to deliver value. Our Strategic Alignment: The Key To Project Success white paper addresses these issues and what need to be done to thwart them.
Look at the White Paper

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.

**The Mythical Man-Month: Essays on Software Engineering**

Add to Cart

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

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.

Read 9855 times

Tagged under

Related items

Transform Your Project Leadership: For Professionals Leading Projects or Company Initiatives
Todd Williams contributed Chapter 7, "Leaders Listen." You can buy it on Amazon.

More coming soon!
Filling Execution Gaps: How Executives and Project Managers Turn Corporate Strategy into Successful Projects

What Filling Execution Gaps Covers

Filling Execution Gaps

by Todd C. Williams
ISBN: 978-1-5015-0640-6
De G Press (DeGruyter), September 2017

Project alignment, executive sponsorship, change management, governance, leadership, and common understanding. These six business issues are topics of daily discussions between executives, middle management, and project managers; they are the pivotal problems plaguing transformational leadership. Any one of these six, when improperly addressed, will hex a project's chances for success. And, they do—daily—destroying the ability companies to turn vision into value.

Check it out on Amazon or the Filling Execution Gaps website

Without the foundation of a common understanding of goals and core concepts, such as value being critical to success, communication stops and projects fail.

Without change management, users fail to adopt project deliverables, value is lost, and projects fail.

Without maintaining alignment between corporate goals and projects, projects miss their value targets and projects fail.

Without an engaged executive sponsor, scope increases, goals drift, chaos reigns, value is lost, and projects fail.

Without enough governance, critical connections are not made, steps are ignored, value is overlooked, and projects fail.

Too much governance slows progress, companies cannot respond to business pressures, value drowns in bureaucracy, and projects fail.

Without strong leadership defining the vision and value, goals are not set, essential relationships do not form, teams do not develop, essential decisions are not made, and projects fail.
Kill The White Knight
There is a reason we hesitate to teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptoms and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.
December 2015 - Vision to Value eJournal
Happy Holidays! Whether you are into Christmas, Hanukkah (yeah, I am about a week late), Winter Solstice, or nothing at all, I hope you are enjoying December. Since my family celebrates Christmas and we have little kids it is a very fun time of year. I simply hope is that your December is peaceful and relaxing.

Calling all Leaders! Do you live or work in the Portland/Vancouver Metro area? How about a taste of RLF? Mark your calendar for the morning of January 21 and join us for a taste of breakfast and RLF!

Speaking of Regional Leadership Forum (RLF)... registration is still open, but time is running out for the $500 early bird discount and the runway is even shorter to get it charged against the 2015 year budget! This is a great 9-month program put on my SIM (Society for Information Management) in nine regions around the United States. If you are in the Pacific Northwest and a member of PMI, we are also working on a chapter sponsored discount of an additional $500. Between these two discounts you could save as much as 14% on the total cost! Please drop me a note, give me a call, 360-834-7361, or visit its web page.

This month's Vision to Value eJournal covers:
- Continued conversation on Organization Change Management (OCM).
- The challenges of communications with leadership and with PMOs.
- Part II of a case study on what kills you if your project ends up in court.
I hope you enjoy them!

Cheers,
Todd C. Williams
President, eCameron
Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)
Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.