CASE 2- A Control System Out of Control

The developer: John Brozovich, advisory project manager at a large data storage company. (Brozovich requested that the name of his company not be used.) The project: Storage management software.

The damage: Seven years, "tens of millions of dollars", 35 programmers.

Brozovich's data storage company wanted a new program to control its systems. At the same time, it seemed like a good idea to redefine the requirements of the original software, since the program to be replaced was written in 1974.

The project started in 1991, before Brozovich joined the company. When he came on in 1995, not much had been accomplished other than some new requirements having been loosely defined. In late 1996 a department formed around the effort and gave the software a name: Library Control Systems. More requirements were gathered. Six months later, the name changed to Library System Support. Nine months after that, the team gave the project a code name, Python, and received 18 months of funding.

By then, the team had swelled from 10 to 35 developers. And when the requirements were finally finalised, there were 1800 of them. Half were engineering requirements written to make the other 900 customer requirements work.

"Right then was about early '98, I think, and I can't imagine how many millions of dollars were gone," Brozovich says.

Brozovich estimates that the team was only about 18 months from a product release when executives decided that they couldn't wait any longer.

On April 1, 1999, the executives gave the Python team 30 days to finish whatever they were working on, at which time the developers would hand it over and lose their jobs.

Happy April Fools'.

"It's a painful process," says Brozovich, who divvies his blame pie four ways.

Sponsor apathy. Brozovich is bemused by the fact that the project's requirements phase dragged and then bulged. Everyone had a requirement to add. No one ever said no, because no one on the business side ever took ownership of the project.

Lack of focus. The sheer number of requirements should have raised a red flag.

No deadlines. The first deadline on the project was the last. Not forcing deadlines fed the lack of focus.

Erratic executives. The project never had one set method of funding. And then executives started reacting to short-term market forces. "The end was in sight. Then a budget cycle comes up, the stock goes down, and they decide they can't wait," Brozovich says.

The Agile Analysis.

An Agile project sets a minimum number of requirements and turns them into a deliverable product. If more requirements are wanted or needed, they can be added later to a finished product.

The 1800 requirements and the fact they took years to define are clearly anti-Agile. The whole project -the budgets, deadlines and the size of the team -became bloated.

"For 20 years we've trained [executives] to expect a document that lays out the plan," says Brozovich. "Minimalism suggests you don't have that detailed a plan." Instead you have a memo or a diagram on a sheet of paper, like DePauw at Caterpillar Financial Services.

"We need to educate CIOs and CEOs on Agile methods if they're going to work. Otherwise, they'll be pounding their fists asking where the hell the requirements document is," Brozovich says.

The project was ultimately killed because executives simply ran out of patience. If Agile methods had been used, Brozovich believes, the project would have been completed before that had a chance to happen.