I came across an important point when reading InfoQ’s interview with Paul Oldfield, titiled Doing Agile Right (it is an excellent interview, I highly recommend reading it.)
In an earlier post I refer to cost-plus contracting as a way to align the demands of lean software contracting with the demands of a client. But Paul brings up a very important point:
I commonly come across people who do not make the distinction between manufacturing and development. They see the best practice and highly automated production line processes, and want to apply the same sort of processes. Mentioning no names, I have come across situations where payment was for time and materials. Profit was related to head count. Here, efficiency meant reduction in profit, and was only attempted when the customer could no longer accept that the head count was necessary.
This reveals the problem with cost-plus contracts, namely, how does one calculate the “plus” part, the profit? Relating profit to head-count creates the problem Paul speaks of. Linking it to time causes problems as well. (I should note that I have seen cost-plus contracting referred to as creating “gold standard” work – the best money can buy, which is what we are trying to create with lean methods. By contrast, with fixed-price work the incentive is to cut corners whenever possible.)
Lean processes, particularly Scrum, have checks that can prevent intentional waste by the contractor. Transparency plays a large role here. Idealy you get a constant time-effort tradeoff from the velocity calculation. But that assumes that the original estimate is in-line. For example, I have heard that in some professions it is common to bill 125% of your time to the project, as a matter of course. On a lean contract one could inflate the estimate by 125% and not work as quickly as possible.
Some food for thought.