1. Slash the budget.

Small budgets force developers to focus on the essential. Small budgets also make it easier to kill failing projects. For example, imagine a project that has already cost $US20 million. Imagine it's going down the tubes. With that much skin in the game, it's tempting for the CIO to invest another $US10 million in an attempt to rescue it rather than take a huge loss. All too often, he ends up with a bigger one.

Jim Johnson, chairman of The Standish Group, says he forced the CIO of one Fortune 500 company to set a $US100,000 ceiling on all software projects. No exceptions without approval from the CIO and CEO. Johnson claims the company's project success rate went from 0 per cent to 50 per cent.

2. If it doesn't work, kill it.

Bring marketing, program and project management, and IT executives together at the beginning of a project and as it progresses to evaluate every piece of code in development. Is it doing what the business wants? Is it working? Any code that isn't should be mercy killed.

This is called triage, and it's "the perfect place to kill a software project", says Pat Morgan, senior program manager at Compaq's Enterprise Storage Group. He holds monthly triage sessions and says they can be brutal. "At one [meeting], engineering talked about a cool process they were working on to transfer data between GUIs. No one in the room needed it. We killed it right there. In our environment, you can burn a couple of million dollars in a month only to realise what you're doing isn't useful."

3. Keep requirements to a minimum.

Don't start with everything you want the software to do; start only with what it absolutely must do. And don't worry about writing all your needs down, because requirements change.

Every software project traditionally starts with a requirements document that will often have hundreds or thousands of elements. But The Standish Group estimates that only 7 per cent of the features of any given application are actually needed. And a major reason for software failure is feature overload -when a programmer adds a feature that interferes with an essential process. Fixing that disconnect in turn creates another disconnect, and so it goes.

Tom DePauw, manager of IT at Caterpillar Financial Services in Nashville, is using Agile Development to build Cat FinancExpress, a massive Web-based system that integrates three older software systems used for helping customers finance heavy equipment purchases.

"When the project started, Caterpillar Incorporated [the parent company] wanted to see the book," DePauw says, referring to the requirements document. "I held up this single sheet of paper with a diagram on it and said: ‘This is it'."

4. Build on success, not hope.

As often as once a week, and not less than once a month, complete a piece of software. Then have your business deciders test and approve it.

That doesn't mean the software is shipped or deployed, but it must work and it must be bug-free. This is the Agile concept's most radical departure from traditional development. In some software projects, no one shows working code for years.

Ken Moskowitz, CIO of New York City-based Standard & Poor's, dictates weekly builds of his company's software. Every week, the pieces being worked on are compiled and tested. "We've had a great deal of success with it," Moskowitz says of this rigid weekly schedule. "I don't want things thrown across the transom. I don't want: ‘Here, I think I need this. Go and build it, and we'll see if it was what I really needed in the first place'."

5. Keep your development teams small.

The fewer developers the better. Developers should team code.

Proponents of Agile Development swear that team coding is more efficient and produces stronger code than solo efforts. But even Fowler admits that this is one of the harder tenets of Agile Development to accept. Who is teamed and why? How do you budget their time? Expect a learning curve.

Caterpillar's Agile project (in progress for two years with a core team of 15 developers) encompasses 200 distinct financial screens and contains 1.5 million lines of code.

6. Assign non-IT executives to software projects.

Non-IT execs should coordinate with the technical project manager, test iterations to make sure they're meeting user needs, and act as liaison between executives and IT.

With business involved full time, "It's hard for us to say after three months of iterations that we didn't really know how it was going," says Chris Colleran, CTO of a Salt Lake City market research outfit called SpreeRide. Colleran is using Agile Development to set up his company's Web site and some back-end applications and has business executives full time on the project.

"Emotionally it's hard to commit businesspeople to the development process, but it's only counterintuitive because of the way it has always been," he says. "If you think about it, the perfect developer would be half a businessperson and half a programmer."