It’s an evergreen question: Why do so many software engineering and information technology (IT) projects fail to meet schedules and budgets, or simply get cancelled? The answers offered include everything from the complexity of the task to the uncontrolled optimism of project managers, but most often the focus ends up on the requirements generation part of the process.

Venugopal joins this venerable discussion by referring to a 1986 article [1] comparing bridge building with computer systems design. He infers that most civil engineering projects are successful because they focus mainly on a single goal, safety, subordinating others. For bridges and roads, safety is paramount. For the National Aeronautics and Space Administration (NASA) moon program, getting there and back safely was the main issue, with cost overruns soon forgotten.

So Venugopal asks whether or not we can use a similar philosophy with software projects. He acknowledges, as Frederick Brooks observed, that software is inherently complex, and methodologies don’t scale, but Venugopal feels that he can overcome this with a methodology he calls single goal set (SGS).

SGS separates requirements into three levels: a summit goal (only one), key process goals (two or three maximum), and other goals. Venugopal fleshes out the methodology with ten steps that define how to get to the summit and key process goals. He then states that we should “focus the implementation team only on achieving the SGS. Subordinate goals are not addressed at all in the first iteration” (page 50).

Venugopal does not give any examples of where he has tried this approach, so his work seems academic at this time. He did, however, survey five failed projects from companies in various industries, and offers suggestions on what an SGS statement that might have prevented these failures would look like.

I’d be interested in hearing how this methodology works in practice. My experience with IT projects suggests that requirements are inherently subject to change and reprioritization. The only methodology that I’ve seen work frequently, and then not always, is rapid prototyping, which adapts to changes in business, to the software and data, and to the company’s IT infrastructure. This approach is worth trying; I hope Venugopal gets a chance to do that, and then tells us all about it.