Pattern: The Never-Ending Story

[Adapted from Patterns in IT Litigation: Systems Failure (1976-2000)]

Summary: The client contracts with the manufacturer to develop and install a system. The project starts. The completion date slips. It keeps slipping. Each time the adjusted delivery date approaches, the project slips yet again. At some point, one of three things happens: the manufacturer/vendor abandons the project; the client cancels the project; or the manufacturer delivers a system that the client terms wholly inadequate and unacceptable. In some cases, the effort has gone on for years, with millions of dollars spent and little to show for it.

Causes: This is actually one of the most well-known patterns in software development, particularly for large, in-house projects. Entire books are devoted to this subject, so it’s hard to summarize the causes here. Two factors show up time and again, though. One is a lack of clear, stable, and constrained requirements on the part of the client. The other is a lack of qualified technical managers and developers on the part of the manufacturer. Chances are that both factors occur in a given project failure, giving each side plenty of reason to point fingers at the other.

Recommendations: To use one software engineering maxim, “Start out stupid and work up from there.” Most failures of this type come from attempts to implement large, complex systems from scratch. Experience has shown that success in building such systems comes more often from implementing small, comprehensible systems that work, then evolving them into the desired large systems.

Beyond that, you should do a thorough risk assessment of the entire project at the start and take steps to reduce any risks and protect your interests accordingly. Again, this may sound obvious, but many system project failures, large and small, have come about because no one with sufficient authority was willing to raise risk issues at the start. Risk issues that should be addressed include the scope and inherent feasibility of the project, the stability of the client requirements, the development and quality practices of the manufacturer, and how realistic the estimates are for time, money, and other resources allocated.

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.