Project Scope Creep and Failure

Amazon #1 Bestseller in Business and Technical Project Management!

Back from the brink... the first fail-safe recovery plan for turning around troubled projects and keeping the problems from reoccurring.

When budgets are dwindling, deadlines passing, and tempers flaring, the usual response is to browbeat the project team and point fingers of blame. Not helpful. For these situations, what is needed is an objective process for accurately assessing what is wrong and a clear plan of action for fixing the problem.

In Rescue the Problem Project, Todd Williams, President of eCameron, describes how projects go wrong and what to do to fix them. It focuses first on people, then process, and finally technology. By doing this it helps you find the root cause of the failure and helps you prevent it from happening again.

We have all noticed how there is never enough space, money or time. It escapes no one and nothing. If there are two weeks to do a task it will take two weeks, if there is a $10,000 budget it will take $10,000 to do whatever it was. It is human nature. The goal has been set, it must be acceptable, so we strive to meet it. I refer to it as the "Garage Syndrome"—junk swells to fill the space in the garage.

Not too long ago 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.

"Technology... is a queer thing. It brings you great gifts with one hand, and it stabs you in the back with the other." This quote, delivered by C. P. Snow, is one we should all live by. Mr. Snow was a physicist, a novelist and a bit of philosopher. Technology brings about great benefits that many of our projects rely upon. We are using it right now. However, take pause to reflect on how technology is also our nemesis. It haunts our projects with its false promises and lures us into implementing superfluous functionality.

Yes, I am on that soapbox. Ensuring that maintainability and adaptability are part of a system is a "best practice," extensibility is not. To the extent that a highly structured system is extensible, that is the end of any commitment to building for the future.

Adding hooks and stubs for something that may not happen, confuses and clutters the design of the resulting system. Building and running prototypes wastes time. Making a system extensible adds significant undefined scope. The reason is that no one knows what the future will bring. Furthermore, how can it be tested if the systems it is interfacing with are not defined?