CASE 1 A Portal to Nowhere\nThe developer: Kent Odland, technical manager at Federal Express.\nThe project: A B2B portal for the parcel delivery industry.\nThe damage: More than $15 million over four years. \nIn 1994 FedEx conceived of a massive B2B supply chain automation system that would link order information and inventory, among other systems, in real-time. The system would link all parcel companies with all their customers, partners, banks and suppliers in real-time. In 1996 the project broke virtual ground. Then, one day in 1998, the approvals?for equipment and for consultants?just stopped. "That\u2019s when I sort of knew it was over," says Odland, the portal\u2019s technical manager. "Things just dragged. It starts with talk like, \u2019Maybe we could use this internally,\u2019 or \u2019We ought to think about how to redirect this effort toward something else.\u2019"The project limped on for another quarter until its director and chief architect finally resigned. Most of the development team followed, and eventually, FedEx was out of the portal business without ever finishing the software.Odland\u2019s blame pie reflects three key reasons why the project collapsed.Sponsor apathy. Odland remembers his team members selling C-level executives on the idea for the portal. They gained high-level sponsors by convincing management that the software could create new revenue streams.But they forgot to continue selling them. "We didn\u2019t even get a real live customer as a reference. So the sponsors don\u2019t hear from us, don\u2019t have anything to endorse or anyone to endorse it," Odland says. "At some point they just decided it was costing more than any revenue it promised to bring in."Developers\u2019 bad attitude.\nExecutive myopia. Sales executives blanched at the prospect of running a portal that was open to the competition. But up in the developer\u2019s ivory tower, that was crucial to the platform\u2019s success. Apoplectic sales executives demanded the programmers change it to a company-only B2B exchange. To Odland, that sounded strikingly like the supply chain they already had and were trying to improve upon.\n"It was too radical for them," says Odland. "What we ended up with was a bunch of great ideas for software without any real-life input."\nThe Agile Analysis \nIn theory, Agile Development is supposed to bring the business experts and the developers closer together. In this FedEx project, they were miles apart?literally. Odland was in Dallas, 1,000 miles from FedEx\u2019s Memphis, Tenn., headquarters. \nEarly on, the project\u2019s funding seemed to be unlimited. Minimal budgeting would have forced Odland to demonstrate the project\u2019s merits to business experts before his budget was simply cut off.\nEngineering set requirements. Agile developers always have business input into requirements. When people on the business side realized FedEx would be running a portal that supported packages from, say, UPS, they flinched. If they had been asked about requirements up front, this disconnect would have been discovered before $15 million was wasted.\nCASE 2 A Control System Out of Control\nThe developer: John Brozovich, advisory project manager at a large data storage company. (Brozovich requested that the name of his company not be used.)\nThe project: Storage management software.\nThe damage: Seven years, "tens of millions of dollars," 35 programmers.\nBrozovich\u2019s 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. \nThe 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. \nBy then, the team had swelled from 10 to 35 developers. And when the requirements were finally finalized, there were 1,800 of them. Half were engineering requirements written to make the other 900 customer requirements work.\n"Right then was about early \u201998, I think, and I can\u2019t imagine how many millions of dollars were gone," Brozovich says.\nBrozovich estimates that the team was only about 18 months from a product release when executives decided that they couldn\u2019t wait any longer.\nOn 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\u2019. \n"It\u2019s a painful process," says Brozovich, who divvies his blame pie four ways.\nSponsor apathy. Brozovich is bemused by the fact that the project\u2019s 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.\nLack of focus. The sheer number of requirements should have raised a red flag. \nNo deadlines. The first deadline on the project was the last. Not forcing deadlines fed the lack of focus. \nErratic 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\u2019t wait," Brozovich says. \nThe Agile Analysis\nAn 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. \nThe 1,800 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. \n"For 20 years we\u2019ve trained [executives] to expect a document that lays out the plan," says Brozovich. "Minimalism suggests you don\u2019t have that detailed a plan." Instead you have a memo or a diagram on a sheet of paper, like DePauw at Caterpillar Financial Services.\n"We need to educate CIOs and CEOs on Agile methods if they\u2019re going to work. Otherwise, they\u2019ll be pounding their fists asking where the hell the requirements document is," Brozovich says.\nThe 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.