A recent report in The Australian (17/12/13) newspaper into the Air Warfare Destroyer (AWD) debacle states that the project is already $106M of its $618M budget for 2012-13 (a wastage of over $2M a week). The article states that the project delays are a combination of “shipbuilding bungles, infighting between partners, Defence budget cuts and a cultural clash with the ship’s Spanish designer, Navantia.” Poor efficiencies at the ASC in Adelaide and little coherence in the support phase are also contributing to the mess but the AWD Alliance still maintains it is on track because its emergency funds have not been exhausted.
The AWD Alliance is the “unwieldy and largely unaccountable” body responsible for the AWD project. The alliance is made up of ASC, the Defence Materiel Organisation and Raytheon Australia. The “secretive” alliance is apparently fractured by internal disputes, with the DMO blaming the ASC. The ASC, in turn, blames Navantia. Further still, the ASC is also blighted by a “poisonous” relationship with its primary subcontractor, BAE Systems.
This is a contracting issue:
- There is no issue with the Spanish design. This design was picked as part of a strict and comprehensive procurement process. If the ASC did not perform the requisite due diligence on the engineering then it should not be in the game of building ships.
- In multi-party construction contracts poor site efficiencies are largely a result of (i) cumbersome management, and (ii) poor depth of vision into the total supply chain. Both issues should have been obvious and ironed out at the contracting stage.
- There is no doubt that budget cuts and legislative change pose a high degree of risk. However, if the revenue curve of the corporate entities were subject to ill winds from Canberra then those teams did not do their jobs.
- Lastly, if a project is eating its emergency/contingency funds then it is an emergency and it is definitely not on track.
So, what’s wrong with Alliance contracting?
John Cooper, writing in the journal of Building & Construction Law (2009 25 BCL 372) notes that alliance contracting is increasingly popular in Australia. Promoted by contractors and adopted by some state governments it is seen as a way to overcome the problems said to be associated with “more traditional forms of contracting”. From this I assume he is including PPP contracts and their PFI/PF2 subset.
Alliance contracts are supposed to be more conducive to collegial management and better outcomes because:
- They are governed by a charter of principles and not the black letters of a strict contract.
- Each party (theoretically) operates in good faith (although, unlike German franchise law, not necessarily to the mutual benefit of the project).
- There is an understanding of “collective responsibility”
- There is a socially enforceable culture of “no-blame, no dispute”.
In fact, all of these points are patent nonsense and the article in The Australian and the Australian National Audit Office report on the same project clearly highlight the complete ineffectiveness of an Alliance contract in this instance.
At the heart of the problem is the risk model. Alliance contracts are popular for Defence because (i) the government underwrites the requirements risk (i.e. future requirements creep), and (ii) they do not have to expose this as an additional cost. So, the project appears to be good value for money. In fact, DMO is to blame here because it knows that it would never be able to get the AWD it wanted if it had to expose/pay for the risk. This is standard Defence sharp practice and to my mind borderline procurement fraud. By getting the government to underwrite the risk the DMO ends up getting the ship it wants at a bargain price. It ends up paying way over the odds but the project would never have been approved if the risk had been exposed. The price would simply have been too high.
In a standard construction contract the client would not underwrite future risk. So, the builder would cover this through (a) additional systems engineering to uncover and cost future dependencies, (b) they would insure against certain risks, and (c) they would then add this into the cost model, i.e. the customer would end up buying the risk back. In the end, the customer always pays for risk. Even if the builder has to absorb hefty liquidated damages for lateness the customer will still pay for them down the line in more aggressive management practices or exorbitant extension-of-time claims and even larger margins on acceleration costs. The customer always pays for risk.
The primary cause of these problems is an unsophisticated and uneducated approach to contracting. Underlying these is the simple fact that risk cannot be allocated if the allocatee does not endorse the allocation. In fact, I would posit that risk cannot be allocated at all. Risk must be bought and sold in order for (i) a party to be truly incentivised to deal with risk, and (ii) the risk to go away. The last point is critical. In standard risk flow-down models risk never goes away. Rather, it simply flows down to the party with the least bargaining power to offload it. In the end, the customer always buys the risk back. In a network model, risk is sold to the party who wants it the most. In the end, they absorb the cost (or a certain percentage) based on the value they will reap in the event the risk is realised.
For instance, the network model below at Figure 1 is based on a large outsourcing contract. A multi-divisional outsourcing company won a contract to deliver products and services to a government body. Part of that contract was the hosting of IT infrastructure, a portal for public access and a billing application. The latter of which was being coded from scratch. In this model, the risk that the code for the billing application is held in escrow and the risk that the billing application will not be ready or fit for purpose (significant) is sold (i.e. the contingent risk) to another company in the model. In this way:
- the purchaser of the risk get a (partially finished) billing application at a knock-down price (if the risk is realised).
- the primary outsourcer can simply pass the application on to the former without having to find a suitable programmer in mid-flight, and therefore
- the primary outsourcer does not need to insure this risk (so much), and
- the original application company are greatly incentivised, lest they lose their R&D costs.
Additional vehicles (other than escrow) for contingent risk may be:
- Step-In Rights
- Holding other titles and licenses in escrow
- contingent transfers of other property.
In all the cases something happens automatically. There is no better way to make this happen than for someone to profit from another’s poor performance. In such cases, the vampiric action of the vestee is swift justice for sub-standard management. When risk is realised, the vestee swoops and kills. There can be no greater motivation for either party. The primary question is whether a business has enough faith in its management to set up contracts in this way. Although a network model of risk is, technically, the best means to manage risk in large and complex contracts the businesses need to decide whether they have the management sophistication and the stomach to deal with risk in this way.
Figure 1 – Model of “Derived Risk” in a large outsourcing contract.