Category Archives: Estimation and Pricing

Estimation of effort, and costing/pricing, for software development projects

Fallible estimates + Competition = Winner’s Curse

Some time ago Steve McConnell and I had an interesting debate, via his blog.  I suggested that when we combine estimates such as those we have in software (which have high uncertainty early in the project) with a competitive market containing price-sensitive customers; then market forces conspire to bias customers’ choices towards those supliers who have accidentally under estimated.

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.

Target Cost Contracts

This page outlines one way to formulate Target Cost Contracts for agile software development.

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

Continue reading Target Cost Contracts

Estimation in a Competitive Context

I’m debating an issue with Steve McConnell, over on his blog, and I’d like to hear what others think of the issue.

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 some very good research papers from the Simula Research Lab in Norway.  They’re 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!]

Continue reading Estimation in a Competitive Context

Cutting Scope is Not the (Whole) Answer

Many agile proponents advocate the “Cancel-After-Any-Phase” approach. Work is prioritised by business value and the customer can halt the project after any phase.  You can fix price or scope, but not both.  Most commonly, the price is fixed and scope is cut if necessary.

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…

Continue reading Cutting Scope is Not the (Whole) Answer

Effort Creep

While scope creep is doing more work than you expected, due to added scope; effort creep is doing more work without added scope.  You’re just taking longer to do the same stuff.

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.

Continue reading Effort Creep

Contracts for Agile Projects

Do agile processes need flexible contracts? What about fixed price contracts?

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”…

Continue reading Contracts for Agile Projects

Leading by Example – why governments should prefer flexible IT contracts

“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…

Continue reading Leading by Example – why governments should prefer flexible IT contracts