McKinsey – Why the Customer pays for Risk Reply

In the forthcoming McKinsey Insights article “Avoiding Blindspots in Your Next Joint Venture” the authors point out some of their recent research into the failure of JVs. Further to my previous post about the need to design accurate risk models into a JV/Alliance/PPP, the authors note:

“At the beginning of any JV relationship, parent companies naturally have different risk profiles and appetites for risk, reflecting their unique backgrounds, experiences, and portfolios of initiatives, as well as their different exposures to market risk. Parent companies often neglect this aspect of planning, preferring to avoid conflict with their prospective partners and getting to mutually agreeable terms—even if those terms aren’t best for either the JV or its parents. But left unaddressed, such asymmetries often come to light during launch, expand once operations are under way, and ultimately can undermine the long-term success of the joint venture.

Certainly, some JVs must be rigidly defined to be effective and enforce the right behavior. But when that isn’t the case, JV planners too often leave contingency planning to the lawyers, focusing on legal protection and risk mitigation without the business sense, which shows up in the legalese of the arbitration process and exit provisions. Both tend to be adversarial processes that kick in after problems arise, when in fact contingency planning should just as often focus on the collaborative processes that anticipate changes and create mechanisms or agreements that enable parent companies to adapt with less dysfunction. As the head of strategy for one insurance company noted, “If a JV is set up correctly, particularly regarding governance and restructuring, it should be able to weather most storms between the parents.” Such mechanisms might include, for example, release valves in service-level agreements, partner-performance management, go/no-go triggers, or dynamic value-sharing arrangements and can allow a joint venture to maintain balance in spite of partners’ different or evolving priorities and risks.”

Designing proper risk models need not be adversarial. In the hands of a skilled lawyer or commercial manager it is a sharp and powerful weapon at the negotiating table. This does not mean that the contract is not a win/win deal. On the contrary, insight into the proper and necessary allocation of risk is essential for a win/win deal. Anything else is simply wilful blindness. In fact, a more mathematical approach to risk modelling lays the foundation for a negotiating process that is more inquisitorial rather than adversarial. The primary questions remain: is the management sophisticated enough and does the business have the stomach for it?

The Customer Always Pays for Risk: risk allocation in large and complex contracts Reply

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. They are governed by a charter of principles and not the black letters of a strict contract.
  2. Each party (theoretically) operates in good faith (although, unlike German franchise law, not necessarily to the mutual benefit of the project).
  3. There is an understanding of “collective responsibility”
  4. 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.

Top 4 Ways to Assess the Viability of a Deal Reply

Does a deal have architecture?

The simple answer is:  Yes.  If a deal is to be viewed holistically with a view to assessment or organically with a view to development then it must have architecture.   More importantly, if a deal is to be assessed then some form of structure must be found.

Stop focusing on the system

Therefore, focus on the revenue model NOT the architecture.  The architecture is absolutely vital but the fact that you’re going to deliver a fantastic, value-adding system is a given.  It’s the reason you were invited to tender. Stop patting yourself on the back for being so good at your core business and now focus on how you’re going to make money out of it.  Critically, how you are going to sell transformation to the client?  Why should they buy into a target-architecture plan and why is it going to take so long to transform their business?

The first dimension of a deal, therefore, is “throughput”:  the ability for the deal to be able to process business and create revenue.  More importantly, it is possible to have a fantastic system and not make money (just ask Fujitsu ref their NHS UK deal).

The key to answering these questions is in assessing the 12 key variables of system viability.  Here at Precision we adapted them from Jamshid Gharajedaghi’s system dimensions and variables in his seminal work “Systems Thinking” (Butterworth-Heinemann, 2006).

1.   Capacity.  Can the system cope with the expected demand and use? This is purely structural question:  are the “pipes” big enough?  More importantly, is the architecture able to expand and contract cost effectively  to accommodate demand?  Do the ‘joins’ and ‘bends’  suffer from fragility?  Are the components ubiquitous enough?  Scalable business models seem great but the architecture to empower them is more complex.

2.   Performance.  Will the system outputs always be of the highest quality? Many longer term outsourcing contracts are 5+5 years so this addresses whether the system will function as designed, well into the future.

3.   Access & Demand.  Are your assumptions of access to markets and customer demand correct?  As the deal progresses will the business be able to expand and take advantage of peripheral value chains?  Will it be able to turn cost centres into profit centres once they are mature? Can the business protect its intellectual property as it becomes more valuable?

4.  Throughput Capability.  Does your organisation have the know-how to keep developing the capability at the optimal rate?  Does your business have the information management skills to be able to develop the knowledge to retain a very high capability?  Take BP, for example, they outsource most things but their information productivity remains very high.  They are still able to access the knowledge needed to develop their core capabilities.  Many companies, however, outsource but cannot take advantage of the better employee-to-revenue ratio.

In summ, a deal is far more than the technical architecture, products or physical structures on which it is built.  Focusing on these 4 key elements of a revenue model well into the future will give the business a realistic view of a deal’s viability.

How to do “Anti-Law” (What is “Anti-Law” – Pt 2) Reply


Designing legal clauses should be an extension of the architectural process.  The contract then should be about 75-85% by design directly from the business and technical architectures and the taxonomy (terms).  The rest will be terms of art (contract construction, jurisdiction etc).


The first thing people say to me when I set out this proposition is that it’s obvious and sensible.  So, why isn’t it done already?  Well, to a certain extent it is, we just don’t know it.  Secondly, it’s not intuitive – it’s not the logical next-step when we’re doing the work.  Firstly, we do already do it:  most commercial and technical managers already understand a great deal of the law surrounding their areas and simply design around it. Secondly, commercial architecture – cost models, program plans etc which are just the attributes of the other architectures – have no spatio-temporal extent.  We can’t see, feel or touch them like we can the stuff we’re engineering and therefore our understanding is governed by how we construct these concepts and thoughts in our mind (Wittgenstein).


The counterintuitive bit is that many commercial entities are actually separate things  – they are relationships to an entity.  In ontological terms they are ‘tuples’ and instantiated on their own.  In the same way that a packet of cornflakes has a cost and then the manufacturer puts a price on it.

The price is a different thing but related to the cost. We know that the price, in turn is related to their profit margin which in turn is related to their overheads which in turn are made of R&D costs, admin, advertising etc.  All these elements are part of the business architecture which influences the commercial (financial and legal) architecture of the given project.


Risk is the key relationship we are modelling.  It is best to see risk as a relationship rather than a property.  Widget A does not have risk in and of itself.  Widget A does have risk when used in a certain machine, in a certain contract.  This is important to note because in later whitepapers I will talk about the need to separate the logical and physical commercial architectures in order to make trade-offs and impact assessments.


Risk links to architecture through a series of relationships.  Ultimately, if we look at components in a database then the relationships I would draw would be:


In the above the ‘context’ is the domain architectural instantiation (the physical architecture) we are modelling, for instance, Architecture A or 1 etc.  This allows us to compare risk profiles across different possibilities and then make trade-offs.  The difference between the ‘mitigation’ and the ‘mitigation instantiation’ is merely logical v physical.  Logically we might wish to insure against a risk but when it comes down to it physically we are insuring part, funding part with a bond issue and hedging against the rest. The point is to identify clearly in the model what is mitigated and what is not.  In a large and complex model of thousands of elements we will want to make sure that all mitigations are accounted for and their are no overlaps.  If we’ve overlapped mitigations (insurance, loans etc) on a number of parts then the cost could be astronomic.  The calculations will be clearer in later whitepapers when I explain how to aggregate derived risk.


The physical mitigations are the most important things to agree on.  These are the processes and the structures that the business must agree on.  This will be a collaborative effort of legal, financial, technical and programmatic.  They must be realistic, sensible and accounted for in the program plan.  Once clearly set out then a precise and specific contract clause (not a mopping-up clause) can be tightly crafted around each and every one.  These clauses must have triggers built into the program plan and each trigger must have adequate information derivation for decision making (ie, you need to know when the clause might need to be used).

The trick in all of this is not in deciding what to do but in identifying the risks in the first place but that is for examination another time.


Repackaging risk to mitigate effectively will be the topic of another blog.