SCENARIO-BASED MODELLING: Storytelling our way to success. 1

“The soft stuff is always the hard stuff.”


Whoever said ‘the soft stuff is the hard stuff’ was right.  In fact, Douglas R. Conant, coauthor of TouchPoints: Creating Powerful Leadership Connections in the Smallest of Moments, when talking about an excerpt from The 3rd Alternative: Solving Life’s Most Difficult Problems, by Stephen R. Covey, goes on to note:

“In my 35-year corporate journey and my 60-year life journey, I have consistently found that the thorniest problems I face each day are soft stuff — problems of intention, understanding, communication, and interpersonal effectiveness — not hard stuff such as return on investment and other quantitative challenges. Inevitably, I have found myself needing to step back from the problem, listen more carefully, and frame the conflict more thoughtfully, while still finding a way to advance the corporate agenda empathetically. Most of the time, interestingly, this has led to a more promising path forward and a better relationship, which in turn has made the next conflict easier to deal with.”

Douglas R. Conant.

Conant is talking about the most pressing problem in modern organisations – making sense of stuff.

Sense Making

Companies today are awash with data.  Big data.  Small data.  Sharp data.  Fuzzy data.  Indeed, there are myriad software companies offering niche and bespoke software to help manage and analyse data.  Data, however is only one-dimensional.  To make sense of inforamtion is, essentially, to turn it into knowledge. To do this we need to contextualise it within the frameworks of our own understanding.  This is a phenomenally important point in sense-making; the notion of understanding something within the parameters of our own metal frameworks and it is something that most people can immediately recognise within their every day work.


Take, for instance, the building of a bridge.  The mental framework by which an accountant understands risks in building the bridge is uniquely different from the way an engineer understands the risks or indeed how a lawyer sees those very same risks.  Each was educated differently and the mental models they all use to conceptualise the same risks (for example)  leads to different understandings.  Knowledge has broad utility – it is polyvalent – but it needs to be contextualised before it can be caplitalised.

Knowledge has broad utility – it is polyvalent – but it needs to be contextualised before it can be caplitalised.

For instance, take again the same risk of a structural weakness within the new bridge.  The accountant will understand it as a financial problem, the engineer will understand it as a design issue and the lawyer will see some form of liability and warranty issue.  Ontologically, the ‘thing’ is the same but its context is different.  However, in order to make decisions based on their understanding, each person builds a ‘mental model’ to re-contextualise this new knowledge (with some additional information).

There is a problem.

Just like when we all learned to add fractions when we were 8, we have to have a ‘common denominator’ when we add models together.  I call this calibration, i.e. the art and science of creating a common denominator among models in order to combine and make sense of them.


Why do we need to calibrate?  Because trying to analyse vast amounts of the same type of information only increases information overload.  It is a key tenent of Knowledge Management that increasing variation decreases overload.

It is a key tenent of Knowledge Management that increasing variation decreases overload.

We know this to be intuitively correct.  We know that staring at reams and reams of data on a spreadsheet will not lead to an epiphany.  The clouds will not part and the trumpets will not blare and no shepherd in the sky will point the right way.  Overload and confusion occurs when one has too much of the same kind of information.  Making sense of something requires more variety.  In fact, overload only increases puzzlement due to the amount of uncertainty and imprecision in the data.  This, in turn, leads to greater deliberation which then leads to increased emotional arousal.  The ensuing ‘management hysteria’ is all too easily recognisable.  It leads to much more cost growth as senior management spend time and energy trying to make sense of a problem and it also leads to further strategic risk and lost opportunity as these same people don’t do their own jobs whilst trying to make sense of it.


In order to make sense, therefore, we need to aggregate and analyse disparate, calibrated models.  In other words, we need to look at the information from a variety of different perspectives through a variety of lenses.  The notion that IT companies would have us believe, that we can simply pour a load of wild data into a big tech hopper and have it spit out answers like some modern Delphic oracle is absurd.

The notion that IT companies would have us believe, that we can simply pour a load of wild data into a big tech hopper and have it spit out answers like some modern Delphic oracle is absurd.

Information still needs a lot of structural similarity if it’s to be calibrated and analysed by both technology and our own brains.

The diagram below gives an outline as to how this is done but it is only part of the equation.  Once the data is analysed and valid inferences are made then we still are only partially on our way to better understanding.  We still need those inferences to be contextualised and explained back to us in order for the answers to crystalise.  For example, in our model of a bridge, we may make valid inferences of engineering problems based on a detailed analysis of the schedule and the Earned Value but we still don’t know it that’s correct.


As an accountant or lawyer, therefore, in order to make sense of the technical risks we need the engineers to play back our inferences in our own language.  The easiest way to do this is through storytelling.  Storytelling is a new take on an old phenomenon.  It is the rediscovery of possibly the oldest practice of knowledge management – a practice which has come to the fore out of necessity and due to the abysmal failure of IT in this field.

Scenario-Based Model Development copy

Using our diagram above in our fictitious example, we can see how the Legal and Finance teams, armed with new analysis-based  information, seek to understand how the programme may be recovered.   They themselves have nowhere near enough contextual information or technical understanding of either the makeup or execution of such a complex programme but they do know it isn’t going according to plan.

So, with new analysis they engage the Project Managers in a series of detailed conversations whereby the technical experts tell their ‘stories’ of how they intend to right-side the ailing project.

Notice the key differentiator between a bedtime story and a business story – DETAIL!  Asking a broad generalised question typically elicits a stormy response.  Being non-specific is either adversarial or leaves too much room to evade the question altogether.  Engaging in specific narratives around particular scenarios (backed up by their S-curves) forces the managers to contextualise the right information in the right way.

From an organisational perspective, specific scenario-based storytelling forces manages into a positive, inquistive and non-adversarial narrative on how they are going to make things work without having to painfully translate technical data.  Done right, scenario based modelling is an ideal way to squeeze the most out of human capital without massive IT spends.






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.

PHANTOM RISKS: what to report in a risk register 2

phantomPhantom risks are, technically, unproven or unprovable facts which, if true, would pose as risks.  At the macro level they are an issue for western societies as they generally arise from poorly made scientific inferences which are hijacked and used to legislate pet projects.  Think of the religious right in the US trying to use scientific quackery to get creationism taught in schools.  Dangerous stuff.

Equally so for the corporate world.  Phantom risks are poorly made out inferences or assumptions, when misapplied, have teams chasing them for the life of the project.   This is commercially dangerous for 5 key reasons:

  1. It is a dangerous absorption  of executive time.
  2. It causes unnecessary management hysteria.
  3. Phantom risks fuel pet projects and hidden agendas.
  4. At best they increases drag on project, and
  5. At worst they dangerously misappropriates essential liquidity by artificially inflating the need for contingency.

More importantly, without an accurate, precise and robust quantitative methodology for identifying, defining and quantifying risk it is most likely that the corporate risk register will be full of phantom risks.


The purpose of a risk register is to define the amount of liquidity needed to cover unexpected project risk.  This means:

  1. Risk register risks must be below 50%.  If they are over 50% then they have a better than even chance of happening (i.e. they are expected) and therefore they should be managed in the baseline project cost model.
  2. Unexpected project risks – truly unexpected – should have liquidity assigned from outside the project budget.

The last point is a hugely contentious issue.  Logically, a project should not be saddled with the financial burden of improbable risks not of their making, i.e. if a project did not bake in its own risks by its own poor design and management then it should not have to pay for them when they occur.  The necessary contingency funds should come from Treasury.  This means that project teams are encouraged to sail as close to the wind as possible and are not penalised for doing so.


In most cases, however, savvy project teams will artificially inflate risks in order to create the greatest possible contingency.  These funds, held outside the project budget, then act as a black-budget slush fund for the project.  The nett result is a project which is more likely to hit its margin targets but an unhealthy corporate balance sheet.


A risk is not a risk when it is an issue.  Much of the difficulty in generating real risks is that most risk register risks contain elements of risk.  They allude to risk and there is usually a gold nugget in there somewhere.  However, until there is a quantifiable financial impact they cannot be used to determine liquidity requirements and they should not be included on a risk register.  They may be pressing issues for the business but they are not risks. The difference is key:  Risks require liquidity.  Issues require analysis.

quopteMost risk registers contain risks which have no business relevance.  These things are, technically, risks but they are usually so remote or unprovable that they (i) are hard to argue with, and (ii) obfuscate the real risks often hidden within their confused semantics.  Most of these things are pressing business issues but issues require further analysis and planning.  They do not belong in a risk register.


  1. Firstly, to be a risk a thing must satisfy the following criteria:
    1. it must be derived from a structural weakness, i.e. a design flaw in the program plan, the technical architecture, a contract clause, a cost model imperfection.
    2. there must be a threat/disposition.  For instance, a chair with the broken leg might highlight a structural weakness but it does not represent a real risk until someone becomes disposed  to sitting on it.
  2. Secondly, in order for risks to be commercially relevant they must satisfy the following criteria:
    1. they must be HOT:  They need to part of an emerging or ongoing adverse variance in the costs.
    2. they must be VALUABLE:  these variances must show high volatility in the cost model, i.e. if the risk is realised there will be worrying financial implications.
    3. they must be WEAK:  they need to be part of something (or dependent upon) that the business often gets wrong.  This is critical because adverse variances and financial volatility might merely represent the natural trajectory of a cost variance in a project.  There is often little cause for concern.  Unless, however, these variances are part of a statistical problem within the company’s projects.

If all the criteria above are satisfied and a relatively accurate number can be used to quantify the financial impact of the risk, then it is a real risk.  If it has high probability and was found during the estimating process then it probably needs to be managed as part of the Baseline and not the risk register.  If, however, it’s a low probability risk and not something the project team should be held responsible for then it likely belongs on a risk register (the funds for which should come from Treasury).

When done right this method usually reduces risks by 80%.  What is left are real risks which point to real liquidity requirements and the need for real action plans in order to minimise real legal exposure.  A risk register of such quality is useful and practical not only to Operations but also to Legal and Finance as well.  Most importantly, no one is chasing phantom risks.

Measuring Legal Exposure Reply

Mind the gapThe function of a contract is to cover legal exposure.  It does not, by and large, govern the relations between parties.  Those are already established by the community and contracts merely document well established facts.  The way the parties will behave will already be a an established reflection of their education, training and previous business experience.  It is naïve to think, for instance, that a contract will be used by engineers to help manage the construction of a building.  On the contrary, the contract will present a myriad of hurdles, obstacles, impasse and problems as the workers try to get on and do their job – build.  It is a truism to say then that almost all litigation is a function of poor contract management rather than poor contract design.  Indeed, I have never met a client who had either fully read OR fully understood the contracts they were in.

A contract, rather, seeks to cover the inevitable areas of risk when two parties necessarily compromise to enter into an agreement. as my father used to say, ‘there are two parties to a contract – the screwor and the screwee.  One party is always disadvantaged.  The lesser party needs to cover their legal exposure and the greater party needs to ensure that not so much risk flows down that the lesser party is overloaded with risk, making the contract unworkable. Picture1Legal exposure is derived from financial risk.  Contracts will generally cover most financial exposure.  However, in Westminster-based systems much of the law of contract is still based in Equity.  Usually, there is still some degree of exposure that remains.  A party can only be forced to  indemnify so much; can only warrant so much and not beyond the reality of the exposure

Most contracts, however, do not measure the legal exposure a party faces.  Most contracts stick with the standard blanket coverage formula, i.e. zero exposure.  This approach is unhelpful and in many cases counter-productive, because namely:

  • Phantom Exposure.  contract negotiations become unnecessarily bogged down over non-existent risk.  Arguing for 100% coverage when the risk is well covered already is just chasing phantom risk.
  • Lazy.  Quite frankly, the body of knowledge which exists in each sector, the sophistication of clients and the modern quantitative tools which exist to make contracting easier give no excuse for legal laziness.

Measuring legal exposure is both qualitative and quantitative.  Firstly, deriving financial risk is a mathematical function.  Secondly, as exposure is derived from the limitations of contractual coverage then legal exposure is a function of qualitative assessments.

My own method uses a threefold approach, namely:

  1. sensitivity analysis to measure financial risk, and then
  2. three separate qualitative measurements to define whether an element is a legal risk, then
  3. a legal assessment to determine if the remaining elements are covered (i.e. measure the exposure) and to what degree.

All of this is done as a collaborative process around a single bubble chart (shown below).  As is shown in the chart,

  • the bubble size (Z ‘axis’) relates directly to the mathematical analysis of financial sensitivity.
  • the X-axis is a qualitative scoring designed to assess the relative complexity of each item of volatility.
  • the Y-Axis is another qualitative scoring to determine just how close the item is to the project team, i.e. can they actually do something about it?  The less a team can influence a risk the more such risk needs to be pushed upwards so that the corporate functions of a business (Legal, Finance) can act upon it with centralised authority,
  • the colouring, lastly, deals with the notion of immediacy, i.e. prioritisation.

In this way, if a risk is both very complex and not able to be influenced by the project team (i.e. cannot be mitigated) then it, most likely, needs to be dealt with by the Legal function as there will be no way to otherwise influence it when the risk is realised.

Risk-Based Bubble Chart to engender cross-functional collaboration

Once legal risk is conceptually isolated in the upper-right quadrant of the bubble chart then lawyers may make a qualitative determination as to the amount of legal exposure.  For instance, a builder may warrant the quality of workmanship on a specific structure and cover it with insurance.  Legal may determine that there is virtually no statistical evidence that such risk is likely to be realised.  Therefore, the existing premiums easily cover the risk highlighted in the chart.

Alternately, the chart may have defined financial risk beyond, say, the indemnities provided by a firm’s subcontractors.  In such a case insurance or contractual renegotiation may be necessary.  It is important to know that in such circumstances it is precisely targeted cross-functional management energy that is being expended to determine, define and collaboratively deal with specific  financial risks.  Indeed, there is little more any business could hope for.

Governance is More Than Openness 1

In a recent blog Richard Sage (@BakedIdea) points out that governance is just a matter of openness and sharing.  If only life were so simple.  If this were the case then what of Enron?  What of the whole global financial crisis?  These people were open?  These people shared?  They had GAAP reporting duties – So what went wrong?

The simple fact of the matter is that (i) governance is more than just sharing, but (ii) less than the full apparatus of conformance which Richard sets out.

More Than Sharing

Governance is more than sharing.  It is about design and flow.  Financial institutions shared information internally and reported it externally but this made not one jot of difference to the near collapse of the global economy.  Collateralised Debt Obligations (CDOs) were so complex that it would take a long time to unpick each one.  It is essential to understand that if an organisation actively conspires to confound regulatory procedures then there is no governance structure that will catch it.

“Governance without design is somewhat akin to looking at a ball of multi-coloured string and trying to guess what the pullover will look like.”

Organisations (here I extend the net to government and not-for-profit) need to design for misuse.  Understand that cross-functional information flows require some degree of architecture.  Without the necessary degree of design in governable artefacts (e.g. cost models, delivery schedules and contracts) it is impossible to unpick them.  In fact, it is somewhat akin to looking at a ball of multi-coloured string and guessing what the pullover is going to look like.

Governance Is Less Than You Think

I believe that governance is only the set of structures necessary to give confidence to institutional shareholders  that their interests are being well looked after.  The functions are the business processes and technical systems which enforce and deliver them.  This is why corporate governance speaks only of Directors Duties and not of business process.  The how will be forever changing in our modern and dynamic world.

In the end, governance is counterintuitive to business.  Good governance is seen to reduce profits, to close off avenues of growth and to burden management with bureaucracy and nugatory process.  Yet good governance should clear the way.  It should lower the bar and reduce the hurdles.  In concert with a stringent and effective assurance process governance becomes light yet effective.  It delivers confidence without suffocating the organisation.

Risk Management is a Team Sport Reply

Good financial risk management requires a high level team team effort and cross-functional collaboration.  Risks, by their very nature,  are highlighted precisely for the reason that the project team is unable to do anything about them.  If they could be effectively mitigated or avoided by a single function (e.g. Legal, Finance, Operations etc) then they would/should not have been placed on a Risk Register.

If the project were able to mitigate the risk themselves, alone, then it wouldn’t be a risk.

Dealing with these risks, therefore, requires not only close collaboration from multiple functions but it also requires the delegation and intervention from pay-bands which are at a higher level than the project, i.e. effective management of financial risk is expensive.  The corollary is that project teams should ensure that whatever risks they have identified are very important and cannot be dealt with by the project team.


Traditionally, risks that populate project risk registers will be well-known risks.  To be unkind, these will be statements of the blindingly obvious.  A menagerie of opinion, Google hits, speculation and wild guesses.   In the absence of an external assurance function, risk managers work for Bid Managers or project teams.  They are not incentivised to look too hard or too deeply at risk.  The last thing that either of these roles want is prying executive eyes or torches shined into dark and dusty corners of the business.

Most risk registers are populated with a menagerie of opinion, Google hits, speculation and wild guesses.

Future blogs will go into this area in greater depth.  However, in the absence of an external assurance function curious risk managers can assuage their intellectual integrity as well as supporting their boss by deriving their risks statistically.  By going back through 6-10 similar projects they can analyse, categorise and classify risks by a variety of quantitative and qualitative measures.  In this way, the Risk Manager will bring cross-functional experience to the project team and, hopefully, become a catalyst for inexpensive, collaborative risk management.

Benefits-Led Contracting: no immediate future for outcome based agreements Reply

The IACCM rightly points out that key supplier relationships underpinned by robust and comprehensible contracts are essential to the implementation of significant strategic change.  Their research identifies a 9.2% impact on bottom line from contract weakness.  Top 5 causes being:

  •      Disagreement over contract scope,
  •      Weaknesses in contract change management,
  •      Performance failures due to over commitment,
  •      Performance issues due to disagreement over what was committed,
  •      Inappropriate contract structures or responsibilities.

Two things are given in this mess:  (i) Firstly, that contractual structures are weak and inappropriate to deal with high levels of operational complexity and technical risk, and (ii) secondly, that legal means of enforcement are cumbersome, expensive and ineffective.

That business is ready to solve this legal problem by contracting for outcomes is (a) nonsense and (b) missing the point.  Business is already dealing with the operational and technical risk of large and complex contracts.  Business is already structuring many of its agreements to deal with outcomes.  Large prime contracts,  alliance contracts and performance-based contracts are already commonplace in PFI/PPP and Defence sector deals.  That neither are wholly efficient or effective is for another time.  It is, however, for the legal community to devise more sophisticated ways of contracting in order to solve their side of the problem.



The primary reason for not being able to contract for outcomes is that the vendor doesn’t own the people.  This is critical because without the ability to control and intervene in the delivery of work the risk increases exponentially.  Consequently, the risk premium paid for outcome-based contracts will either make them (a) prohibitively expensive, or (b) impossible to perform (within parameters).  So, a business which offers you an outcome-based contract is either having you on or just about to charge you the earth.



INFOGRAPHICS: the worst form of risk management Reply

Aristotle wrote that “metaphor is the worst form of argument.  He’s right.  If you have something to show/prove, then do so precisely and in a way which is meaningful and useful to your target audience. 

Recently the guys at Innovation of Risk posted an article on the use of infographics to analyse risk.  I don’t know who coined the term “PowerPoint Engineering” but most infographics fit neatly into this category.  Infographics can save presentation or they can sink it but mostly they are used to convey ill conceived and poorly thought out ideas which snowball into worse run projects.  The best advice is to take these bath-tub moments (why do people think they have great ideas when they’re washing?) and run the analysis with an expert using an expert system.  If you can’t do that then (a) you’re in the wrong department for having the idea in the first place, and (b) chances are that there is a tonne of minute but important detail you missed out.

Whilst I think that visual display of graphics is vital to achieve stakeholder buy-in, it is also clear that imprecise PPT-engineering masquerading as infographics is the worst form of management snake-oil there is.  An erstwhile systems engineering mentor of mine used to say, “if you think they’re BS’ing you then ask them what the arrows mean”.  9 times out of 10 they won’t have a clue. 

Competitive Advantage in IT 1

Although a recent article in SearchCIO alludes to competitive advantage by IT departments, arguments like this can take the CIO down a dangerous road.  The holy grail of many CIOs is to run a department which is both profitable and also increases business capability.  Mostly, however, IT departments are costly and the subject of constant complaint.

Can IT ever be a profit centre?

Economists have long argued that businesses should strip away overhead (i.e. not included in the cost of goods sold but pure overhead) cost chargebacks from business verticals and their processes in order to gain a clearer view of what is profitable and what is not.  If they don’t then smaller, profitable processes are often in danger of being swamped with overhead.  In this way, many businesses often outsource or cut the wrong activities.

It is notoriously difficult to cost IT chargebacks so that market verticals are charged just the right overhead.  Should businesses charge their verticals for email?  They often do but isn’t this just a cost of business that the centre should absorb?  Isn’t the burden of communication and reporting largely placed onto verticals anyway?  So if they could run their business units in a more entrepreneurial way wouldn’t the cost of IT be significantly reduced? 

What if we extend that argument and let IT be a profit centre?  Why don’t we let business units find cheaper ways of doing business and compete with the IT department?  Security/integration/management time arguments aside – it is likely that if IT departments were able to charge for the thing they were really good at, this would be a source of competitive advantage within the business.

So, there is a good reason why IT departments aren’t profit centres but, of course, this doesn’t solve the problem of the high cost of IT inside business.