There is a subtle difference between Risk and Cost that often gets over looked. The reason for this is that the cost of something usually contains a risk component. For example, when someone lends you money, they expect you to pay it back with interest. Part of the interest is to cover the risk of you not paying back the money, in affect they have put a price (or a cost) on the risk. The subtle difference between this cost of risk and actual risk is that this price is just an estimate. The risky situation may or may not happen in the future.
A quick anecdote:
I once had a conversation with a brilliant financial analyst regarding Fixed and Floating rate Mortgages. I was pleased with a realization that I had come to after looking at the two types. The realization was that the *overall cost* of a Fixed vs a Floating mortgage was comparable. Sellers of mortgages are so good at pricing a fixed rate mortgage, that the overall difference in cost between a fixed and a floating rate would be minimal.
The response from the brilliant financial mind was simply 'Yes, but the Risk is not the same'.
Duh, I hadn't been thinking about that. To me, the 'Risk' was choosing the higher priced mortgage, not the possibility that a floating rate mortgage could move outside the bounds of what was expected. It seems obvious now.
This brings me to the topic of this post. Cost vs Risk in Software Contracts.
Software Contracts
Recently I have been about thinking the Cost vs the Risk of Fixed Price and Time and Material contracts. These contracts are another example where cost can often work out to be the same (as vendors get better at estimating and pricing Fixed Price contracts the price will converge) but the risk is different.
Because software is a risky and unpredictable business, buyers naturally prefer Fixed Price contracts. Generally they cost about the same, but the vendor owns the risk instead of the buyer. However, the software world is starting to understand what those in the Agile community have known for a long time, that an iterative and adapting software process is ultimately the better way to build software. The problem is, that by definition, an iterating and adapting project can not be Fixed Price and therefore the buyer must absorb the risk.
Kent Beck and Dave Cleal wrote a paper called Optional Scope Contracts that proposes a fixed cost, fixed time frame, floating scope approach. The basis of the proposal is that with a Fixed Price (ie Fixed Scope) contract the first thing to be compromised is quality and that just transfers the risk and in some ways makes it even more unpredictable.
This is certainly a move in the right direction. It recognizes the need for flexibility. It says it how it is. Unfortunately, it still has the buyer assuming the risk.
Check back here soon for a continuation on the theme including ways for the vendor and the buyer to share the risk.
Subscribe to:
Post Comments (Atom)
5 comments:
Thanks for pointing out that subtlety. I agree with Kent Beck's approach of transferring the risk to the customer with the agile iterative approach of development.
Sometimes I wonder though whether the customer is willing to accept an iterative contract with an agile shop when they can find someone else who would do the job for a fixed cost.
Even if quality ends up suffering and costing the customer a lot, it seems like without proper education and buy-in, the customer may still elect to go for a fixed cost contract.
Is it better for the agile shop in that case to revert back to traditional methods of software estimation? Or is it better to learn the best ways of conveying Kent Beck's views on iterative development to the customer?
And, when the price of something (financial instrument, etc) does NOT factor in an appropriate risk premium, you have an arbitrage opportunity.
Nice post, but you are missing out one huge risk - that the software does what it is supposed to do.
In a fixed price, fixed scope project, the buyer takes on the risk that the scope is correct when specified at the start. There is no room for negotiation later on.
OTOH, agile projects allow the buyer to constantly see progress and change the scope, thus reducing this risk significantly.
IMHO, eliminating (or at least reducing) this risk is the single biggest reason for a buyer to go in for an agile approach.
You are absolutely right Siddhi. Reducing the risk of not building the right software is the key motivation for delivering iteratively.
When I said 'buyers naturally prefer Fixed Price contracts', I was referring to the fact that most buyers at least think that they know what they want and therefore don't perceive 'not building the correct software' to be a risk.
Generally this means that they know what they want at a high level and disregard the details.
I use the analogy, that for the buyer, buying software is like buying a car. They want leather, navigation system, third row and 20+mpg, but they don't care about all of the little details. They trust that someone else will take care of them. They just want a vehicle that gets them from A to B in a certain way.
Of course, those of us that build custom software know that the 'devil is in the details'. Decisions need to be specified and made at every level from 'where to best position the cup holders to the complex design of the drive system.
So yes, there is a huge risk in not building what is actually wanted in a fixed bid contract, but the buyer often doesn't perceive it.
And even when they do perceive it, and decide to proceed iteratively, they get stuck with all of the risk as my article suggests. The right approach is an iterative approach where the buyer and vendor share the risk.
Another important point, fixed-price contracts also leave a lot of room for leeway, in fact the only way most fixed-price contracts are successful from a vendor point of view is by mastering the Art of "change management" and "contract interpretation".
Of course what this really means is that a vendor practices change prevention and will reinterpret/negotiate contract scope to reflect the vendor's changed understanding of effort.
I've played both the supplier and customer during these kinds of situations, and it's not pretty.
Agile techniques can be applied in fixed-price contracts, in fact I would say that they are vital to making a fixed-price contract successful. Agile supports a collaborative client relationship, which is essential when trying to survive nasty contract negotiations\renegotiations.
I've recently posted on how to apply agile during fixed-price negotiations.
http://agileconsulting.blogspot.com/2007/10/how-to-make-agile-development.html
Post a Comment