Skip to content

How to use agile methods for the fixed price contracts

November 30, 2007 by Artem

Agile software development methodologies discourage the use of the fixed price contracts. When forced to commit to the fixed price, agile approaches advocate unfixing the project scope. However, even if it is impossible, there are still ways to realize the benefits of agile methods.

Poorly predictable complexities

Sydney opera house, a beautiful piece of art, the Sydney's best known landmark and international symbol was started as a fixed-price, fixed-date project. Unfortunately, since it was no standard building time, it was impossible to estimate all the difficulties and complexities in advance. As a result, it took 13 years and 102 million Australian dollars to build instead of 3 year and 7 million estimated - 330% time overrun and 1350% costs overrun!

Software development is almost always to some extent a creation of something new, that nobody built previously. Therefore fixed-price and fixed-date contracts for the software development are known to be imprecise and incorrect. Nevertheless, despite the frequent and virtually normal cost and time overruns, in many IT organizations, especially in the big ones, it is often required to put a quote upfront in order to get funding secured. It is even more common in the subcontracting or offshore environment.

Agile fixes

An agile solution for such a fixed-price situation would be to unfix the schedule corner of the time-cost-quality triangle. It typically means establishing either a form of time & materials contract or gated financing. In the time & materials case the customer pays for the development month by month or iteration by iteration. Usually customer has the right to terminate the collaboration after any iteration, possibly with some premium. In the gated financing case, the product is agreed to be developed and delivered in several phases with the first phase fixed priced and the following phases fixed, when they are about to be started.

In both cases the solution has to be trust based as unfixing any time-cost-quality triangle variable naturally reduces the customers ability to force the implementor take the risks and pay for the estimation mistakes. Some clients, especially the ones working with the particular software development organization for the first time cannot agree to it. Is it still possible to apply the agile software development methods then? It is. Even though agile methods allow for the dynamic adjustment of the work scope to what the client actually needs, they also iteratively increase the efficiency of the team to the highest possible level. If you anyway have to work on a fixed price, fixed scope contract, it still makes sense to utilize the method that helps the team be most effective and as a bonus allows to see the danger of cost or schedule risks as soon as possible.

Further links

Comments

What about finding anothe commitment instead of scope?

November 30, 2007 by Sebastien Arbogast (not verified), 1 year 5 weeks ago
Comment id: 1392

See here.

other aspects

December 3, 2007 by Rob W (not verified), 1 year 5 weeks ago
Comment id: 1396

There are other aspects of agile programming that can be applied to fixed-price contracts, on a broader scale -- for example, minimize the scope of the contract as much as possible, to reduce the risks and enable you to much more accurately price phase 2, 3, 4 and so on (which will be there if you do a good job on phase 1).

Another example -- the agile programming approach will help you keep your finger on the pulse of the project much better (instead of the "save the testing for the end" approach, most notably...), so you'll know early on if you're running into problems -- and you can respond immediately (renegotiation, design changes, even canceling the project)... instead of finding yourself at the end of your budget and schedule with no end in sight to the bugs and the "minor" bits of the project that remain incomplete.

PS: if you get a sec, double-check your calculations for the Sydney opera house overruns; the percentages seem low for the numbers you gave.

Our organization has to deal

December 3, 2007 by R James (not verified), 1 year 5 weeks ago
Comment id: 1397

Our organization has to deal with this problem daily - and is typical for any Professional Services organization that wants to practice Agile.

We generally handle it by not fixing scope (or more importantly, the deliverables), and focus on making it a time-boxed exercise. The customer is then able to control their destiny - this is because in Agile, there is a committed Business Lead Decision Maker that determines, on a day-to-day basis, how they will be spending their money on their project.

This can obviously be a slightly 'hairy' way of managing things, because the customer must trust your organization (but, when is that not the case). So the other step we take is to run workshops at the start of the project where we drive features from the business and get the business to prioritize the order. This is not the scope - but it implies an importance on certain features being delivered.

At the end of the day - it is an education issue, and the business must WANT to run a project Agile. Most organizations that are seeking to go Agile, have had little success with traditional methods, and are looking for a better way. And therefore, traditional projects are constantly overrunning budgets and time. In our methodology, this is fixed, so we can always guarantee that a project will be on-time and on-budget. But what is delivered, will be up to the customer working in the project.

@Rob W I also like the

December 3, 2007 by Artem, 1 year 5 weeks ago
Comment id: 1398

@Rob W
I also like the phased approach for being an "easy transition step" towards agile development.
As for the percentages, I checked those and they look fine to me except for some rounding.

@R James
The education is one of the most important issues, true. However, at times you (or your management) just have to accept the fixed scope-price-time contract before you get a chance to educate. You are lucky if in this case you manage to get the phased delivery contract.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.

Best of AgileSoftwareDevelopment.com