Fixed Price (Big) Contracts Considered Harmful ... Essays Home
Fixed price contracts are not the Silver Bullet
I have had some experience (on both sides) with medium to big fixed price software projects. I have come to realise that some people (and unfortunately senior management are amongst them) think that negotiating a fixed price contract is some silver bullet, that will kill most of the risk for the buyer, and remove most of the need for intensive management action. I'd like to explain why I think they are wrong.
There's enough risk to spread around ...
One mind-set I have noticed among Government service staff associated with software procurement is that "all the risk lies with the contractor". Of course, the industry experience with big software contracts is that there is more than enough toxic fallout from a big project going bad to blight careers and make aggravation for everybody even a long way from ground zero. In fact you could make the case that because enough big projects go bad, relying only a fixed price contect as a risk mitigation strategy is clearly negligence.
The most pathological extreme of this mind-set is when the staff on the buyers side feel they have very little responsibility to help push the contract to a successful conclusion, but instead use every possible opportunity to document their concerns and disagreement with the contractors work. This is to provide an audit trail that will absolve them in case anything goes wrong. This approach is all the more effective if the concerns are with the trivial or with the esoteric; this ensures that the contractor will be unlikely to ever have the time or energy to address these concerns, which provides the perfect excuse "If only they had listened to me".
Even with the best will in the world, without strong and pro-active management action from their management, buyers staff will fall into the mindset of "what can I find wrong with what the contractor is doing?". While this may be appropriate in buying a house or some other tangible easily defined asset, it can be deadly for software. What is needed is the mind-set "is this system going to achieve it business purpose?". A typical example: one small part of the specification call for a time-zone display of 20 characters, and a proportional spaced font is used in a commercial GUI-builder package that assumes some average width of a character. So of course, attempting to display 20 "W" characters fails (but it can all be read by scrolling the field). To the glee of the tester, this can be recorded as a System Level Error.
You pay peanuts, you get monkeys ...
The other disasterous side effect of large fixed price contracts is that it is well kown that software estimation is in-exact at best, and woeful at worst. The Government agencies that I've had experience with in many cases reveal a fairly low level of appreciation of practices in the commercial arena. In many cases, the selecting for the lowest bidder automatically selects either the company who knew least about the job, or who was the most optimistic. Even if there is a company who wants to "buy the job", the buyer is far better served by selecting a contractor who has quoted a more accurate price.
The most inspiring case of "best practice" that I have ever read about was when Boeing was looking at sub-contracting out its 777 software development. Boeing reviewed all estimates, and advised potential contractors to increase their team sizes (in some cases, by factors of three). The attitude was not "how can we hold a contractor to get the most value", but "how can we get the job done right".
Contracts are written in stone, Software is written on water ...
One contributing aspect to a potential disaster is that usually the contract is administered on the buyers side by staff that have nothing to do with the business of the organisation, and no experience at the sharp end (in the Defence business, the sharp end can get pretty sharp). Sometimes they are genuinely unable to tell the difference between a trivial and system level requirement. This is compounded if the contract is administered from the seat of Government, the buyer's technical advisors are in another city, and the real users are scattered around the country.
From the contract administrators point of view, the situation described above is ideal. It is common for a function to be "captured" by the bureaucracy set up to administer it. This means that the contract will be administered in the manner most appealing to the bureaucracy. Changes will be resisted, firstly because they represent work, and secondly they present necessity for making a decision, and taking responsibility for it. Again, without strong management action, the contract administration will fall into the mind-set of "I have to administer this sacred contract to the letter", rather than "I have to use this contract to achieve a business purpose". If you set up a very long and complicated communication and reporting channel between end-users and the contract administration, then you can successfully defend changes against specifications that can be up to nine years old.
The biggest enemy of business satisfaction is time; a big contract takes time to specify, time to draft, time to call for tender, time to evaluate responses, time to negotiate the final contract. During this time, the world moves on, and the drum beat of the IT world is now at a frantic tempo. Microsoft doesn't produce extensive design material for its code, because it knows that most of it will be rewritten to address new market needs in three years.
Technology is too important to be left to the Contract Administrators ...
Any organisation that uses IT in a strategic sense (and very few large organisations escape this category) must have an overall technology plan, which must be updated at least yearly. Technologies can change so quickly that attempting to pick winners must be matched with a lightness-of-foot in abandoning loosers. An example that may appear ludricrous now is WAVELL (the British Army Command and Control System, that had the ignominious fate of being left at home in favour of PCs when the British Army went to war in the Gulf).
Remember magnetic bubble memory; probably not. It was going to be the memory technology of the future (in the late 70s), and it was attractive to the British Army because it was EMP resistent. It was (in hind-sight) the wrong decision, but one that was very hard to change. By all accounts that project spent considerable effort in getting bubble memory to work, while the price of semiconductor RAM kept going down, down, down.
The strategic business needs of an organisation will not change rapidly, but the means of satisifying them will. This means that someone attuned to the business needs must be assessing the capabilities that are coming up. In the main the capabilities will be developed by the commercial world, and not by the fairly static and insular research and development agencies that Government usually run. Part of the assessment must include the ways that the organisation must restructure and re-shape itself to take advantage of a new technology, or even the reduction in cost of a previously expensive capability. This is too much to ask a contract administration team to do.
This means that to be successful both the contractor and the buyer must be flexible in recognising in advance that the specification may need to be recast,and the scope of work changed. In most contracts I have had experience with, Contract Changes were regarded as the abnormal case, and were very expensive to raise. The buyer should be aware of these costs and budget appropriately to recompense the contractor. Again, it requires determined buyer management effort to get the contract administration team not to regard these changes as "rocking the boat", and resist them.
The Solution? Lots of hard work, and lots of little contracts ...
The solution to the difficulties above is not a "Silver Bullet", but a lot of hard work. Big contracts must be broken down into many small contracts, with some assurance of preference for the original contractor, but with contract review implicit at the end of each mini-contract. The buyer, in conjunction with the contractor, should develop a technology insertion plan, in which potential new technologies are identified and their use planned should certain criteria be satisified. Even if significant up-front work must be done (for example, in implementing a security infrastructure), the buyer should plan on delivering something to real users every six months. It may be necessary to recall and upgrade hardware over the life of the series of mini-contracts. If this is a "greenfield" development, the first mini-contract should be to develop a system architecture capable of technology insertion, and capable of supporting a family of products, not just one system.
This means that the buyer must be involved at all times, at a high level within the organisation, and not just at a high level in the procurement, but at the sharp end. It means that the buyer and contractor must regard renegotiating the contract not as sign of failure, but as an opportunity for success. It means that the buyer's contract administration teams must be able to respond to change circumstance rapidly, and set up streamlined procedures.
© Don Cameron. www.net-analysis.com