It turns out the concept has a name, “The Winner’s Curse”, and it’s been known to economists for over 200 years!  

I’ve updated my original post with details and a link to an excellent article from the Simula Research Lab in Norway.

The goals of this approach are to:

• Share risk fairly between Customer and Supplier
• Give the Supplier the peace of mind of being protected from significant cost overruns
• Offer enough flexibility to get the best out of an agile development process
• Align goals by giving both parties an incentive to minimise scope

The ideas here are still under development, having only been used on a small number of projects so far.

Overview

The contract is based on two figures: the “target price” and the “cap”.  The cap is the maximum that you (the Customer) will pay. The target is lower than the cap and the contract gives both parties a financial incentive to meet the target.

If we (the Supplier) come in under the target, the savings are shared equally between both parties.  Likewise, if we come in over the target, the extra cost is shared evenly – but only up to the cap.  If we reach the cap, it acts like a fixed price.

Benefits

This approach gives you certainty about the maximum that you will pay (the cap), while still sharing risks and benefits fairly.

As explained below, both parties have a financial incentive to minimize the scope and cost.  Minimizing scope and cost reduces overall project risk.  Contrast this with standard fixed-price or time and materials contracts, where one party has an incentive to increase scope and the other has an incentive to decrease it.  Only a target cost contract incentivizes both parties in the same direction.

Details

There are two ways do formulate a target cost contract.  Both are mathematically identical, they are just different ways to describe the same thing.

Formulation 1:

1. Up to the target cost, you pay our standard rate of $x per hour.
2. If the project comes in under the target, we split the savings evenly.  For instance, if we come in $10k under budget, you pay us half of that (5k) and keep the other half yourself.
3. If the project goes over the target, we split the extra cost evenly. In effect, that means you pay half our standard rate ($x / 2) for any hours between the target and the cap.
4. Your total payment (for full-rate work up to the target plus any half-rate work beyond) will not exceed the cap.

Formulation 2:

1. Payment is composed of two elements.  You pay half the target as a fixed fee.  You also pay us on an hourly basis, as we work, at half our standard hourly rate.  For instance, if the target is $100k, you’ll pay a fixed fee of $50k plus half our standard rate ($x / 2) for every hour that we work.
2. Again, your total payment (fixed portion plus hourly portion) will not exceed the cap.
3. The fixed portion can be paid in several instalments, with timing negotiated up front .  The last instalment will typically be on completion of User Acceptance Testing.  For small to medium projects, two instalments is the easiest approach – one at the start and one at the end of UAT.  So for a project with a target cost of 100k, the two fixed payments would be 25k at the start of the project and 25k at the end of UAT (giving a total fixed payment of half the target, as always).
4. The per-hour portion will typically be invoiced on a month-by-month basis.

Graph

This graph shows how the contract works.  (Both formulations result in the same graph, because they are just different ways to describe the same thing).

Note that if the project completes exactly on target, working exactly the target number of hours, then total billing is exactly equal to what it would have been under a Time and Materials (T&M) contract.

Also note that there is no hard and fast rule for the gap between target and cap – it depends on the degree of risk in the project, with the gap being bigger if there is more risk.  One guideline is that the gap should be big enough that neither the supplier nor the customer expects to hit the cap.  (Since, if the cap is expected to be hit, the situation degenerates into a fixed-price contract.  When that happens, the beneficial effect of aligned incentives is lost).

Incentives

Under a target cost contract the customer has an incentive to minimize scope, because that minimizes the total cost.  The supplier also has an incentive to minimize scope, because under this model lower scope means higher profit.  (The supplier maximizes profit by minimizing the number of half-price hours they must work.)

Sample Wording

Here is sample wording for a project with a target of 100k and a cap of 115k. The wording is based on formulation #2.  Bold sections may vary for projects of other sizes or at different charge-out rates.

Target Cost: $ 100,000

Payments will be as follows:

$25,000 at the start of the development and $25,000 on completion UAT

Monthly payment of actual hours worked at $xx/hr until the development is complete or yyy hours of effort has been expended.  [yyy * xx = 65k.  That 65k plus the 50k in fixed payments = the cap of 115k]

Total payment of ($25,000 x 2 + $xx per hour) will not exceed the cap of $115,000.

In the event that the capped price is reached <supplier> will complete the development without billing <customer> for any further hours (other than agreed change controls).

Change Controls

The contract is based on an initial agreed scope.  If you want to add to that scope during the project, you can do so using an agreed change control process.  (Just like you can under a fixed-price contract.)  In such cases we will negotiate an appropriate change to the target and the cap.

We recommend that the following approach should be taken to change control:  if it is a brand new requirement, a change control must be raised.  However, if it is simply a question interpretation of an existing requirement, no change control is necessary.  The cap and target are not changed by issues of interpretation; only by brand new requirements.  We make this recommendation to preserve the flexibility and collaboration that is offered by agile processes.

Conditions Under Which this Approach Can be Used

Note: this approach can only be used where all of the following are true:

• The up-front scope can be identified and written down well enough to serve as the basis for any future discussions of what is, and isn’t, a change.  (The scope definition doesn’t have to be perfect, just good enough to be used as a baseline for telling the difference between what does, and doesn’t, require a change control)
• All parties agree that if changes are identified then either the cap will increase or something else must be removed from scope.
• The key stakeholders in both organizations truly understand the model.  (Don’t want nasty surprises where, for instance, customer is surprised to receive final fixed payment because they thought they were just paying by the hour!)
• Key stakeholders in both organizations know how they will process the payments through their respective billing/financial systems (since such systems tend to assume either fixed price OR hourly rate, but not both).

Ideally, the upfront scope will be accurate enough to serve as basis for future discussions, but loose enough leave room for refining the details, agile-style, during the project.  The level of detail depends on the organizations concerned, and the risk level of the project.  In some cases the level of detail required for this approach may be excessive, leading to too much Big Design Up Front, in which case this contract structure is probably inappropriate. In such cases, other contract structures should be considered instead.

We do not mandate any particular way to document the initial scope, as long as it meets the needs above.  E.g. index cards or other simple formats may be appropriate, depending on the situation.

Payment for Change Controls

The following approach is suggested:

Firstly, the size of the change is estimated by the development team.  Then, based on that estimate, two things happen:

1.     The capped number of hours is increased.  This is the figure yyy in the example above. The increase is equal to the estimated hours to implement the change, plus an appropriate contingency buffer.  AND

2.     An additional fixed payment is made.  This fixed payment corresponds to half the target cost of the change. For a small change this can be a single payment at a time agreeable to both parties.  For larger changes it can be broken into instalments, with the final instalment being due at the end of UAT.

The net effect is as shown in this graph:

[Update June 09: a similar approach is described here]

I have a theory that, when multiple suppliers are competing for the same contracts, market forces encourage selection of those suppliers who have under estimated (either knowingly or unknowingly).  It’s some kind of “reverse natural selection”, where the market tends to select the least fit proposals (those that are most underestimated).

“…market forces systematically bias the winning bid [towards under-estimation], even when the set of all bids is not biased at all…”

[Update March 2009:  I have found the name for this phenomenon.  It is an effect well known to economics, and first mentioned over 200 years ago!  It's called the Winner's Curse.  Very little has been written about it in software, although I did find this very good paper from Magne Jørgensen and Stein Grimstad from the Simula Research Laboratory in Norway.  The linked page has both text and PDF versions of the paper.  It's well worth reading.  As Jørgensen and Grimstad write, the winner's curse can easily become the customer's curse - so it is the interests of both parties to minimise it's effects!]

Steve McConnell and I discuss this at some length on his blog. He suggests that, while my logic is interesting, it cannot possibly be true — because if it was true all such suppliers would go out of business.  My reply is that my logic is still correct; they do struggle on projects with early fixed prices, but they stay afloat on revenue from other sources:

• One source is change requests and follow-on projects, which I believe can (and should) be done more ethically than this all-too-common-common model.
• Another source is competitive projects won by more realistic means.  Steve mentions things like two-phase contracts and delaying final fixing of price until later in the cone of uncertainly.   Ayende advocates competing on quality rather than price. I completely agree, and advocate some of the same ideas here and here.
• The final source is projects which simply never went through a competitive bid process.  There are many reasons why some projects do not go through competitive bid processes.  Such projects are a perfect opportunity for the customer to choose a supplier who they already know and like.

I believe that these three sources help to sustain many outsourcing companies.  If not for these three sources, things might get ugly.  I wrote:

“…selecting the lowest bid has been blamed for creating unsustainable markets in traditional (construction) engineering…

To me, the experience of the construction industry offers some indication that price-based selection can indeed skew the winning bids downwards, to the detriment of an entire industry.  If it is documented in traditional construction, perhaps it possible in IT too.  Perhaps it hurts all outsourcers…”

What do you think?  When prices must be fixed early, does a price-sensitive market make it “impossible” to win profitable work?

This approach is a natural fit for most agile processes.  However, other options should also be considered, because:

• Firstly, Alistair Cockburn points out that methodology and contract type are not tightly linked.  Like many people, I initially made the mistake of bundling “agile” together with “flexible contracts” in my mind.   He points out that the two issues are virtually independent.  His comments prompted me reconsider my own views, and to write about fixed price contracts here on this site.
• Secondly, I doubt that Cancel-After-Any-Phase, on its own, can satisfy customers’ concerns about cost overruns…

A Weakness in Cancel-After-Any-Phase?

Consider this scenario:

The project is about 25% complete.  It has become clear that the amount of work required will significantly exceed the initial estimates.  The customer can cancel after any phase, but will they really cancel at this stage just to get a “cheaper” supplier?  Will they carry on, and cut scope to fit the budget?  Can they really cut the scope that far, or do they have to find additional funding?  Is any additional funding possible?

Customers have a legitimate interest in protecting themselves from problems like this.  A good process will seek to meet that interest.

Conclusion

There’s a limit to scope cuts.  Cut too much and customers are bound to be disappointed.  Many customers can’t take that risk. So, it makes sense to look at other contractual options, such as Target Cost or Two-Phase Contracts.  These can be combined with Cancel-After-Any-Phase to offer better risk protection.

Finally, even the best contract in the world is no substitute for trust and collaboration.  That’s what we really need, and our contracts mustn’t stand in the way.

Background Reading

Martin Fowler, on fixing price but not scope.  This is Cancel-After-Any-Phase, but with a pre-arranged maximum expenditure.

By the way, he says you can’t fix both price and scope.  So why do I say you can?  Because Martin’s describing reality, and I’m describing contracts ;-)  Traditional contracts are not about reality, they’re about a plan, and about making the supplier responsible for the inevitable difference between the two. That’s OK, as long as you understand the downsides.  See this page for more discussion of Martin Fowler’s comments.

Finally

No contract can fully protect you from a supplier who makes promises they can’t keep.  Therefore selecting a supplier must be about finding a competent partner not just a low bidder.

Like scope creep, effort creep is inevitable and manageable.  To manage effort creep we need to understand what causes it.  Three major causes are underestimation, over engineering, and discovering implicit requirements during system design.

Underestimation

I once helped convert a complex Windows application into a giant ActiveX control.  (Kids, don’t try this at home.) Our beta release had a huge memory leak.  Our memory management architecture worked well in stand-alone apps but broke down in ActiveX (it couldn’t cope with page re-loads).  As I recall, we leaked over 10MB per minute.

We never saw that coming.  It was what Robert Read calls an unk-unk, a problem so unforeseen we never even imagined it might exist.

I know what you’re thinking – we made a stupid mistake and we should have seen the problem coming.   Yes, perhaps we should have.  But we didn’t.  And that’s the way it is.  There’s always something unforeseen.

How do you plan for unk-unks, when you don’t know what they are? You simply have to include a bucket of time in the schedule to cover the things you haven’t thought of yet.  How big should the bucket be?  I know of no better answer than to look at past projects of similar size and complexity.  How much time did you spend on their unk-unks?

In the early phases of a project, there’s no such thing as perfect estimation.  You need to allow time in the schedule for unk-unks, and also for overrun on known tasks.

Over Engineering

Some developers tend to over-engineer solutions, building in extra complexity because “someone” might need it “later”.  I think we all have that tendency, to some degree.

XP addresses this issue with the slogan You Ain’t Gonna Need It.  Personally, I’d phrase it differently, although I do agree with the idea. I’m all for creating solid implementations of features that we know are needed; but I’m against speculative implementations of things that “might” be needed “later”.

It’s important to realise that this form of effort creep is completely different from underestimation.  If the customer asks for a Toyota Corolla, then the estimate should be for a Toyota Corolla.  It shouldn’t be for a giant SUV just in case we accidentally build one of those instead.

I don’t have a silver bullet to combat over engineering.  Two things seem to help: discussing ideas with other developers before you build them, and making the true project status visible to everyone.  Often developers don’t really know where the project stands in terms of progress and budget.  When you’ve got nothing but a few dates in a Gantt chart, it seems easy to justify extras that “might” be needed. It’s harder to justify them when everyone sees the full project status, including “budget burn”.   (You can also chart effort creep itself.)

Explosion of Implicit Requirements

When moving from requirements to design, there is an explosion of ‘derived requirements’ … caused by the complexity of the solution process.  The list of these [derived] requirements is often 50 times longer than the list of original requirements…. What may have seemed straightforward from a problem point of view explodes into something quite complex from a solution point of view. – Robert L. Glass, in Facts and Fallacies of Software Engineering

We unearth numerous details and special cases when we take a human-readable problem description, and turn it into a solution so precise that even a machine can execute it.  Were all those special cases (implicitly) included in the original scope?  Customers tend to say “Yes” while suppliers tend to say “No”.   In reality, some are effort creep and some are scope creep, while many others lie somewhere in between.

Fuzzy Grey Boundaries

There’s no clear line between scope creep and effort creep.  Implicit requirements are hard to classify; there’s no precise definition of over engineering; and even the best estimates are never perfect.  If we find ourselves doing something we hadn’t planned, is it:

Here’s what I think: In the very best projects there’s something special about the relationship between customer and supplier.  It’s a working relationship that fairly shares the costs of scope creep and effort creep, and avoids squabbling over which is which.

• Firstly, you have to give up certain agile techniques when working on fixed price projects.  For instance, you can’t use “just-in-time” requirements definition [1].  However, even though you have to give up some agile techniques, you don’t have to give up all of them.  You can still use iterative delivery, automated testing, close communication and most other agile techniques.
• Secondly, we must consider what a fixed price contract really is.  A fixed price contract is based on an estimate of the work required.  Customers don’t want fixed contracts because estimates are good; they want fixed contracts because estimates are bad.  The actual effort never matches the estimate, and fixed price contracts are simply a way of making the supplier responsible for the difference.

So, as long as the requirements are stable – stable enough [and sufficiently well-understood] for the supplier to accept responsibility for the cost difference — a fixed price contract is OK.   (Do suppliers accept such responsibility too willingly?  Do price-based procurement processes encourage them to do so?  How accurate can estimates actually be, when requirements are stable?  These are all excellent questions, which I hope to write about some day…)

As Alistair Cockburn suggests, the supplier can follow the fixed quote with an agile process.

Everything changes if the requirements are not stable.  As Martin Fowler suggests, changing requirements need agility and a flexible contract.

I’ve written more on this subject here.

There are many reasons.  To pick just one: we believe it works in “real” engineering – making bridges, roads and buildings.

But it doesn’t.  Although it is widely used in engineering; it’s not widely successful!

The Truth about Engineering

The latest issue of e.nz, published by New Zealand’s Institute of Professional Engineers, reports that “the indiscriminate urge for lowest price” leads to “late and unsatisfactory completion, disputes and litigation”.  (Almost sounds like software!)

The New Zealand Construction Industry Council says that “the lowest-bid approach is compromising design quality and integrity, health and safety, training, the environment… [Furthermore,] the lowest bid approach encourages unsustainable markets” [1].

Discussing solutions to these problems, e.nz explains that: “A substantial culture change is involved in progressing towards best practice in procurement.  All stakeholders must accept that they have a duty to collaborate towards a common objective: the full satisfaction of the project’s objectives, in exchange for fair rewards for all who contributed.” [2]

Why is the Lowest Price Dangerous?

The lowest price is dangerous because you don’t know why it’s low.  In the software industry, a company may offer a low quote for any of the following reasons:

1. They have misunderstood the difficulty of the task [3]. (See these posts too)
2. They understand the task; the estimate is low simply because software estimation is inherently difficult.
3. They understand the task, and are deliberately bidding low because they’re eager (or desperate) for your business.
4. They understand the task, and have outstanding skills and technology which will allow them to complete it quickly.

Only the last reason is a good one.  The others, to greater or lesser degrees, may all threaten your project.  Yet in terms of price, they look the same.

So How Do You Tell the Difference?

You have to base your decision on assessments of the supplier’s capability: the quality of their staff, the quality of their technology, and their track record.

Price tells you nothing about capability. A low price may signal superior capability (reason 4), inferior capability (reason 1), desperation (reason 3), or nothing (reason 2).

A Better “Real” Engineering Practice to Emulate

If we want to emulate “real” engineering, we would be better to take our lead from the US federal government. Since 1972, price-based selection for engineering services has been prohibited for federal government agencies, with selection being based on supplier quality instead [4].  The approach has proved highly successful and has been widely emulated by state governments.

I believe the US approach reflects an understanding of the risks noted above – that price tells you nothing about capability.

The US approach may also reflect an awareness of just how embarrassing price-based selection would be after a major engineering disaster.  Imagine a TV interview shortly after the collapse of a bridge:

Reporter: So how did you award the contract?

Official: We… errrr…chose the cheapest.

Indeed.

Why don’t we ask the same question after a software project collapses?

[1] The Construction Industry Council (CIC) document is available here (700k PDF file):  http://www.nzcic.co.nz/CIC_Procument_document_internet.pdf Although it is entirely about construction, it makes interesting (and surprisingly relevant) reading for IT professionals. The CIC points out that government, as a major purchaser in the sector, must lead the way. The same applies in IT.

For another perspective, see this Canadian document: http://www.peo.on.ca/publications/DIMENSIONS/marapr2001/ma01price_consult.pdf Like New Zealand, Canada has experienced a “leaky building” scandal in which price-based procurement was a contributing factor.

[2] Ernesto E. Henroid (FIPENZ, FICE), writing in the March/April 2005 issue of e.nz.  Magazine web site: http://e.nz-magazine.co.nz/main.htm.

[3] Well-known author Steve McConnell documents a case study in which the highest bid was actually the best, because the other bidders misunderstood the task. Needless to say, the high-yet-accurate quote wasn’t chosen and the project went on to overrun its (unrealistically low) budget by 1400%. His description covers many relevant issues and can be found here: http://www.stevemcconnell.com/sg-complit.htm

[4] Price-based selection for engineering services was banned by the 1972 Brooks Act (the second Brooks Act). I was going to ask my American readers why the same rule was not applied to IT but a little research unearthed a surprising fact:  for IT, price based selection was required by the federal government.  The legislation was the 1965 Brooks Act. Yes, that’s the same congressman Brooks!   It seems Brooks had a very active interest in procurement, an interest which he expressed in two quite different laws.  The earlier (IT) act was designed to promote competition to break IBM’s stranglehold on the industry.  It achieved that goal, became widely disliked, and was repealed in 1996.  The second (engineering) act still has widespread popularity and success – and that’s an important lesson for today’s IT industry.

More on the Brooks Act(s):

http://www.asce.org/pressroom/news/grwk/event_release.cfm?uid=1777

http://www.gcn.com/21_33/community/20522-1.html

http://www.fcw.com/fcw/articles/2004/0315/pol-reform-03-15-04.asp If you’re interested in the fact that the (engineering) Brooks Act covers design, but not (as far as I know) construction, read these articles by Jack Reeves: http://www.developerdotstar.com/mag/articles/reeves_design_main.html See this page on my site too.

Yes, you can use agile processes on fixed price projects.

For instance, Crystal Clear was developed and tested on fixed price projects:

“Unlike most of the other authors of the Agile Development Manifesto, I came to the agile principles through the need for efficiency, not the need to handle rapidly changing requirements.” – Alistair Cockburn, in Crystal Clear (emphasis added)

“Efficiency” is about making software rapidly with good quality.  On a fixed price project, speed and quality are exactly what you need!

Like other agile methodologies, Crystal Clear does include techniques for  handling changing requirements.  But you don’t have to use those techniques!  It’s perfectly acceptable to fix the scope up front, and then use the rest of Crystal’s techniques to deliver the software on time.

What’s the Catch?

Under a fixed price contract you may not get all the benefits of agility.

Firstly, while agile processes improve developer productivity, some contracts may limit the productivity gains.  The limit is not a direct consequence of fixed price and scope; it results from the “waterfall” mentality implied by some contracts.  For instance, compare these agile techniques with your typical fixed-price contract.

Secondly, agility allows the team to change direction, for the better, when the opportunity arises.  (E.g. a beneficial change, either to technology or functionality, is identified part-way through the project.)   Such changes are harder to make under a fixed contract.

How to Decide

If a fixed price contract is mandatory, as is often the case in government circles, here are some things you might like to consider:

• Firstly, does your project suit an agile process?  (Some don’t.  For instance life-critical software is a poor candidate for most agile processes, since they don’t take verification and testing to the levels needed when life and limb are at stake.)
• If your project does suit an agile process, choose your agile methodology carefully.  Some may fit fixed price contracts better than others.  For instance, most advocates of Extreme Programming (XP) favour flexible contracts, while Crystal Clear was created under fixed contracts.
• Remember that its safest to choose your supplier by capability, not price.
• Finally, bear in mind the downsides of traditional contracts, and try to avoid as many as you can! :-)

Further Reading

Many Agile authors assume the use of flexible contracts for agile projects, most notably Martin Fowler.  I’ve discussed his views here.

References

Comments from Alistair Cockburn in the on-line Crystal Discussion Group and in Crystal Clear.

Fixed Price

You actually can use traditional “fixed price” contracts on agile projects.  The catch is, they’re not necessarily the best option.

Simple Time and Materials

“Time and materials” contracts are another option. The customer pays by the hour, with no pre-arranged limit. This works well in some situations, but in others it shifts too much risk to the customer.

Agile processes allow a refinement of the traditional Time and Materials contract, to give an approach that’s widely recommended in the agile community.  It doesn’t have a recognised name, but I call it “Cancel-After-Any-Phase”…

Cancel-After-Any-Phase

The customer still pays for the time worked, as in a Simple Time and Materials contract.  Unlike Simple Time and Materials, the work is ordered by business value so that the most important features are finished first.  The customer has the right to cancel at the end of any phase, receiving the working, tested software from all phases completed so far.  I have described the details here.

Two-Stage Contract

In this approach, the project begins with a “scoping phase” which is covered under a separate contract.  The team examines the requirements and technical issues during the scoping phase, then quotes a price for the rest of the project.

Target Cost

The customer and supplier agree on a target cost.  During the project, they negotiate the details each feature — adding some, removing others, and simplifying where possible –  always aiming to keep the project within the target cost.  The contract is structured so that both parties benefit if project is completed under budget, and both parties suffer if it runs over.  (Details here , in pdf format). Here is one way to do it.

Target Schedule

Similar to Target Cost, but aiming at a specific delivery date instead of a specific cost.

Notes

These are not mutually exclusive options.  For instance, one project may:

• Begin with a paid “scoping phase”. (Two-Stage Contract), and…
• Negotiate features to stay within budget. (Target Cost Contract), and…
• Prioritise work by business value (Cancel-After-Any-Phase)

This page explains the key differences between fixed price contracts and the flexible alternatives, particularly Cancel-After-Any-Phase.

This page explains why some agile authors say fixed-price contracts can’t be used, but others say they can.

“Conventional wisdom holds that specifying and controlling scope in a contract is necessary to protect an organization from self-serving behavior on the part of the other party. However, the effect of this protection is a sub-optimized value stream… The bottom line? Organizations that use outsourcing as a way to save money will save more money overall if they collaborate with vendors by using some form of optional scope contract.”
– Lean Software Development, by Mary Poppendieck and Tom Poppendieck

Collaboration, under the framework of a flexible contract, delivers the best outcomes for both customer and supplier.  This concept is described in the book Lean Software Development.  The book quotes a powerful example from the automotive industry –Toyota pioneered a new level of close collaboration and went on to great commercial success.

Toyota, as a major industry player, was pivotal in reshaping the culture of the auto industry.  Who could play the same role in IT?  Who is a significant buyer of IT services, with the market influence to lead the way? Government departments.

Why?

Why should we even imagine that the public sector, with its reputation for caution, should lead the way?  Because the benefits are too good to ignore…

• It will save money.  As explained in Lean Software Development, if an organisation (such as a government department) wants to save money through outsourcing, they’ll make the biggest savings if they collaborate with suppliers using flexible contracts.
• It will boost the local IT industry.  Trust and flexibility don’t just help the purchaser, they also benefit suppliers.  Which government doesn’t want to boost its local IT industry?

If these benefits sound implausible, I encourage you to read this sample chapter from Lean Software Development.  The authors explain the benefits far more clearly than I can. (See this page too.)

Will This Ever Happen?

Realistically, I won’t hold my breath waiting for government departments to start insisting on flexible contracts.  However, wouldn’t it be great if they did!

Where I live, in New Zealand, we pride ourselves on innovation.  What a great opportunity for our public sector to express our innovative spirit, save money, and boost our knowledge economy!

Update 8 May 2005: Even more important than flexibility in contracts is the need to stop awarding contracts on price.  This outdated practice is causing grief in our construction industry, and the same problems exist in IT.  I’ve written about the issues and solutions here.  Again, government should lead the way.

Update 17 Oct 2007: Rod Drury has posted an excellent page on government IT procurement.