An IT project is very different to building a house or bridge where a large number of shared preconceptions help shape the result. Not so with IT; as the possibilities change year-on-year, so does the technology we use. This means that at the end of the project the IT provider delivers their conception and the customer expects their conception. The difference between them is then subject to resolution.

The old methodologies rely on "blame assignment" - the contract, specification and documentation are interpreted to see who should have to pay to make up the difference at the end. Generally this results in compromise, but is not good for the project as it usually stalls waiting for resolution.

We prefer to avoid this destructive process and so we build in the understanding that things will change from the outset. During the project, the aims will become clearer to both parties and the result will get better and better. Why set down the specification at the beginning of the work when we know least about the problem?

The solution is to divide the project into a number of self-contained, complete and smaller projects called "iterations". Each iteration solves a real business problem and delivers value in itself - they should not rely on future iterations to realise the benefit. If the analogy is writing a book, then the iterations are not like writing chapters of the book. Each iteration writes a full story, but each further iteration fleshes out and extends the story, making it better than it was at the end of the last iteration.

We structure the project so you commit financially to iterations only as you evaluate previous iterations. If the project stops delivering value then the maximum value at risk is one iteration; the completed iterations are still as valuable as they were.

This means you don't pay for features you thought you wanted but didn't need, and we can focus on making the necessities as good as they can possibly be.