Hidden Costs in ICT Outsourcing Contracts Reply


Why are IT outsourcing contracts almost always delivered over-budget and over-schedule?  Why do IT outsourcing contracts almost always fail to achieve their planned value? How come IT contracts seem to be afflicted with this curse more than any other area?


The common answer is that (i) the requirements change,  and (ii) that handovers from the pre-contractual phase to in-service management are always done poorly.  These are both true although hardly explain the complexity of the situation.  If requirements change were an issue then freezing requirements would solve it – it doesn’t.  The complexity of large ICT projects is derived directly from the fact that not all the requirements are even knowable from the outset.  This high level of unknown-unknowns, coupled with the inherent interdependence of business and system requirements, means that requirements creep is not only likely but inevitable.  Secondly, (ii) handover issues should be able to be solved by unpicking the architecture and going back to the issue points.  This too is never so simple.  My own research has shown that the problem is not in the handover but that the subtleties and complexities of the project architecture is not usually pulled through into the management and delivery structures.  Simply put, it is one thing to design an elegant IT architecture.  It is another thing entirely to design it to be managed well over a number of years.  Such management requires a range of new elements and concepts that never exist in architectural design.

The primary factor contributing to excessive cost (including from schedule overrun) is poor financial modelling.  Simply put, the hidden costs were never uncovered in the first place.  Most cost models are developed by finance teams and uncover the hard costs of the project.  There are, overall however, a total of 3 cost areas which must be addressed in order to determine the true cost of it outsourcing. 

True Cost of IT

1.  Hard costs.  This is the easy stuff to count; the tangibles.  These are the standard costs, the costs of licensing, hardware, software etc.  It is not just the obvious but also includes change management (communications and training).  The Purchasor of the services should be very careful to build the most comprehensive cost model based on a detailed breakdown of the project structure, ensuring that all the relevant teams input costing details as appropriate.

2.  Soft Costs.  The construction industry, for instance, has been building things for over 10,000 years.  With this level of maturity one would imagine that soft costs would be well understood.  They are not.  With project costs in an extremely mature sector often spiralling out of proportion it is easy to see that this might also afflict the technology sector which is wildly different almost from year to year. 

Soft costs deal with the stuff that is difficult to cost; the intangibles:  The cost of information as well as process and transaction costs.  These costs are largely determined by the ratio of revenue (or budget in terms of government departments) against the Sales, General & Administration costs, i.e. the value of the use of information towards the business.  Note that this information is not already counted in the cost-of-goods-sold for specific transactions.

Soft costs go to the very heart of how a business/government department manages its information.  Are processes performed by workers on high pay-bands?  Are workflows long and convoluted?  The answers to these questions have an exponential effect on the cost of doing business in an information-centric organisation.  Indeed, even though the cost of computing hardware is decreasing, the real cost of information work – labour – is increasing.  This is not just a function of indexed costs but also the advent of increasing accreditation and institutionalisation in the knowledge worker community.  Firstly, there is greater tertiary education for knowledge work which has hitherto been unaccounted for or part of an external function.  The rise of the Business Analyst, the Enterprise Architect (and a plethora of other “architects”) all serve to drive delivery costs much higher.  Not only are the costs of this labour increasing but the labour is now institutionalised, i.e. its place and value is not questioned – despite the data showing there seems to be limited economic value added through these services (i.e. no great improvement in industry delivery costs).

3.  Project Costs.  Projects are never delivered according to plan.  Requirements are interpreted differently, the cohesion of the stakeholder team can adversely impact the management of the project, even the sheer size and complexity of the project can baffle and bewilder the most competent of teams.  Supply chain visibility, complicated security implementations and difficult management structures all add to project friction and management drag.  There are many more factors which may have an adverse or favourable effect on the cost of performing projects. 

IT Transition Cost Graph

In the Defence community, Ph.D student Ricardo Valerdi created a cost model – COSYSMO – which isolated 14 separate factors peculiar to systems engineering projects  and gave these factors cost coefficients in a cost model.  Ultimately, each factor may be scored and the scoring then determines the effort multiplier, usually a number between approximately 0.6 and 1.8.  Naturally, when all factors are taken into account the overall effect on the contract price is significant. 

More importantly, for IT implementations, the “project” is not short.  IT outsourcing projects are generally split into 2 phases:  Transition and Transformation.  Transition involves what outsourcers call “shift-and-lift” or the removal of the data centres from the customer site and rear-basing or disposal of the hardware which allows the company to realise significant cost savings on office space. 

During the second phase – Transformation – the business seeks to realise the financial benefits of outsourcing.  Here, a myriad of small projects are set about in order to change the way a business operates and thereby realise the cost benefits of computer-based work, i.e. faster processes from a reduced headcount and better processes which are performed by workers on a lower pay-band. 

IT outsourcing  is not just about the boxes and wires.  It involves all the systems, hard and soft, the people, processes and data which enable the business to derive value from its information.  Just finding all of these moving parts is a difficult task let alone throwing the whole bag of machinery over the fence to an outsourcing provider.   To continue the metaphor, if the linkages between the Purchasor and the Vendor are not maintained then the business will not work.  More importantly, certain elements will need to be rebuilt on the Purchasor’s side of this metaphorical fence, thus only serving to increase costs overall.  The financial modelling which takes into account all of these people, processes and systems must, therefore, be exceptional if an outsourcing deal is to survive.

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.

Cloud research exposes gaps between CIOs and the business. . .again Reply

In a recent article for Beyond IT Failure Michael Krigsman highlights the colossal disconnect between IT and the business.  Looking at the graph below has IT really spun off at a tangent?  Is IT just pursuing its pet projects again?

IT is not wrong.  IT is best placed to understand compliance requirements.  IT should understand which applications delivery value for money and IT should be able to choose which apps support competitive advantage.  Cloud is, by and large, a non-functional requirement as so does not need to be in the functional user spec.

“Business is not a toy shop and the argument “but I’ve got it on my phone” does not wash in a secure, structured enterprise environment.”

So why the disparity between what what the business thinks it needs and what IT choses?

  1. IT is a cost centre.   IT is responsible for delivering functionality in the most cost effective way.  Business is not a toy shop and the argument “but I’ve got it on my phone” does not wash in a secure, enterprise environment.
  2. Business Requirements.  I have never met a business vertical which understood its requirements.  Requirements engineering for the systematic design of accurate software is an entire segment of the tech industry.  It is complex and (mostly) poorly done.  Invest in getting it right if you want to deliver better systems.
  3. Engagement.  There is no two ways about it – IT is appalling at business engagement and business are shockingly bad at letting IT in and then articulating their needs (in order to begin the requirements process.
  4. Productivity.  Improved productivity is more of a human problem than a technological one.  New software will not make people smarter.  Unless the processes and collaboration structures already exist then new binary systems will only serve to compound the problem.  In such cases, software procurement becomes a very, very expensive process of sandboxing and prototyping to elicit accurate business requirements.

In order to achieve better ROI on tech investments whilst still delivering great software which improves productivity, businesses need to (a) understand where tech enables business capability in their value chains, (b) understand the development of their business’ capabilities, and (c)  create a ‘value ladder’ which supports the parallel propositions of architectural development and business productivity.

2013: Not The Year Of The CIO – Yet Reply

It is highly unlikely that this will be the year of the CIO.  Tom Curran is entirely correct that CIOs need to get closer to business units to prove their value.  After years of uncontrolled IT budgets and then recent vicious cost reduction programs CIOs need to prove that they are more than email, storage and security.  CIOs need to be proactive in supporting the cost of businesses and that means developing capability.

Firstly, there are 3 types of business tech: (i) embedded systems such as robotics, (ii) operational systems such as customer ordering systems, and (iii) management information systems  such as email, ERPs, ERMs, collaboration tools etc.  The first two are largely accounted for in the cost-of-goods-sold but the latter is usually accounted for as overhead in SG&A.  Although their worth is unquestionable (could a large company really do without email these days?), it is these MIS systems which are notoriously hard to prove the value of.

There is still little evidence that MIS directly increase profitability.  Corporate IT spending largely increases in accordance with SG&A costs which tells us 2 things: (a) that as companies grow and increase their revenue they increase their management commensurately, and (b) IT is bought to connect this management.  There is not some inflection point where systems are bought, magic happens and companies become organised.  Organisation is the job of the business but enabling that by bringing distributed human communities together through electronic communications is the primary purpose of MIS.


In order to become the critical enabler that it has always wanted to be IT needs to focus on capability and not just costs.  Although Tom suggests that this will be achieved through in-house architects I would suggest that in-house capability is too hard and costly to maintain at the requisite level to actually analyse and build business capability.  The only function that should be retained and honed, in-house, is information mangement.  Businesses need to be absolutely certain about exactly what information (at an atomic level) actually makes them money  – and how.  Outsiders without the context, peripheral information, subtext and political insight cannot adequately contribute to this role.  Only once the business understands its financial the anatomy of its fianancial dependencies can it adequately source architectural support in order to build business capability.  The business which misses the point and only develops architecture is just gilding the lily and will just be rewarded with a higher overhead burden which they need to chargeback to disgruntled internal customers.

Is this achievable in 2013?  The likelihood of this belies my underlying assumption that CIOs do not belong in the C-Suite.  As critical as technology and information is to business it is only a critical enabler and not a separate function in itself.  Due to the radically different skills which the technical community possess I do not believe that they will ever be able to set the agenda in non-digital industries.  Putting CIOs in the C-Suite merely overemphasises the importance of technology as an end and not merely the means.  It is here I think that standard operations should stop abdicating its responsibility and start setting the technical agenda and this will certainly not happen in 2013.

The Failure of Risk: lessons from the GFC Reply

risk management. hop scotchWe live in uncertain times. The failures in risk management which lead to the global financial crisis have created an unprecedented set of circumstances. Not only are regulators imposing heavier compliance burdens but shareholders and investors are demanding greater reporting and higher levels of information transparency. On top of all this operational costs are too tight to carry the overhead of separate risk and assurance functions.

When the analysis is done there are 6 key lessons to learn from the global financial crisis:

  1. Integrate G, R & C.  In medium and large corporations isolated risk management practices actively work against the business.  Technical and operational experts will identify risk from experience and create risk slush-funds to mitigate them.  These increase the cost of business and in many cases price the company out of the market.  In an integrated GRC system the firm is able to manage risks across business units so that the risk funds are held centrally and do not add a premium to initial project costs.  Risk identification and analysis percolates from the bottom up but governance is driven from the top down.  In an integrated system they both to work within the business lifecycle to add the right mix of checks and balances so that no additional drag is added to investment/project approvals.
  2. Make Passive GRC Active.  Systems need to be active.  They need to hunt out risk, define it, quantify it and measure the dependencies of the risk.  Then, those same systems need to bring it to the attention of the executives so that they may make informed investment decisions.  In the end, humans follow the law of least effort:  employees will follow the path of least resistance in designing and gaining approval for their projects.   GRC must not follow a system of honour & audit but rather one of  active assurance.  When GRC systems are passive the business lifecycle becomes clogged with nugatory and useless program reviews that turn into technical sales pitches by design teams.  Such events and practices only serve to affirm the belief that GRC is a legal burden and one which only serves to satisfy the needs of regulatory compliance.  Raytheon, for instance, have an excellent system of governance-by-exception.   Their Integrated Product Design System (IPDS) has active governance measures and allows Raytheon to manage a pipeline of thousands of critical projects dynamically and by exception.GRC
  3. Get Granular.  When projects fail it is not usually because the risks have not been adequately managed.  The primary problems in risk practices are the failures of risk identification and analysis.  Managers are simply unable to deal with risks at a granular level and then weigh them up on a per project basis.   This is largely because the technical skills needed to do so are not within the standard sets of most executives (but they are within the more mathematical ones of the FS&I industry).   Where this disparity exists then businesses need to develop separate Red Teams or Assurance Teams, either from the existing PMO of from hand picked executives.
  4. Bottom Up & Top Down.  Risk management is bottom-up but governance is top-down.  The technical skills and software reliance involved in effective risk management mean that the entire practice usually percolates from the bottom of a business, upwards.  Consequently, unless it fits within a comprehensive governance framework it will be open to being gamed by senior executives.  This is why major projects which are seen as must-win are often approved with little or no governance or assurance.
  5. Risk Ownership.  Risks need to be owned at the lowest responsible level.  This is to say that when things go wrong the person at the lowest level who has the greatest amount of operational responsibility must be able to take charge to mitigate all aspects of the risk.  It is vital that the person owning the risk be able to recognise the variables which may see the risk realised.  It is also critical that the risk owner understand the corporate decision points, i.e. the points at which the contingency plans should be triggered.
  6. Invest in the Right Type of Risk Culture.  Risk should not be a dirty word.  Risks are inherent in every project and balancing them quantitatively and qualitatively is an essential skill for all senior executives.  Risk should be as much about seizing opportunity as it is about guarding profitability.  Businesses need to invest in top talent in order to drive good risk practices from the top.  Effective, Active-GRC involves a complex array of tools, practices, structures and processes which need an experienced senior executive to drive them constantly and consistently in the business.  The softer side of risk management cannot be neglected.  The nature of risk forces people onto the defensive as they attempt to justify all aspects of their project designs.  CROs need to help executives understand that all projects must balance risk if they are to attempt to push profitability.  Otherwise, risk cultures will mire companies in conservative, risk averse cultures which only act to add friction and reduce profitability.

Risk practices need to work together inside a single, comprehensive risk framework that goes beyond simple probabilistic modelling and disjointed regulatory compliance.   Businesses need to implement processes which not only integrate the business lifecycle but actively increase both liquidity and opportunity for risk to be seen to add real value to the company.   Only once this is achieved can risk management cease to be an operational drag for the business and become a value-adding proposition which works actively to increase the profit and performance of a company.


Top 5 Benefits of Effective Risk Management 1


After the failure of risk management during the recent (and ongoing) financial crisis one could be forgiven for thinking that risk management – as we know it – is dead.  However, effective risk management is the only means which businesses have to:  (i) assess and compare investment decisions, (ii) seize subtle opportunities, and (iii) ensure regulatory compliance.  Risk management has greater utility beyond these obvious benefits.  Listed below are 5 of the top financial benefits of effective risk management:


When managers cannot identify or mitigate complex risks they create risk contingency slush funds and pad their accounts with excessive risk premiums. This is not an efficient allocation of capital and it can even price a business out of the market. Precise identification of risk premiums removes these slush funds and creates greater firm liquidity and the ability to allocate capital where it is needed.


The best methods for risk identification and analysis of risk in projects are through the quantitative analysis of cost models and project schedules. However, these methods are only useful where such models are in enough detail. Good risk management leads to greater collaboration by cross-functional teams to optimise cost and schedule performance.


With greater liquidity comes the ability to seize emerging opportunities. Not only can the company use this capital across portfolios to manage risks but it can also seize opportunities for M&A, talent acquisition, share buybacks, increased dividends, employee bonuses or increased project funding/investment.


As managers work across the business to calibrate cost models with the project schedules; the contract and commercials with the technical architecture, the business is forced to adopt a more consensual, multi-disciplinary approach. Where GRC is implemented as part of a high-performance business initiative the culture is more likely to stick rather than one imposed from the top-down.


An active GRC process which is fully integrated with the business relies on the quantitative analysis of core artifacts (cost models, project schedules and technical architectures and contracts). A quantitative culture coupled with regular, detailed analytical outputs also greatly improves the standard of financial and operational reporting and therefore the possibility for improved investment decision making.

Measuring Risk in Logical Processes Reply

logical-architecture.-wire-diagram.pngLogical architecture is valuable in the design of large systems for 2 key reasons:  (i)  it helps developers instantiate the softer concepts and  more social aspects of large systems, and (ii) it provides another review-gate to iron out design flaws before proceeding to the physical system.  Military systems provide good examples of the value of logical architecture.  Many Defence systems are so complex that they are never developed at all.  If they are at all then they are often broken down into such small components that the integration can become unmanageable.  Joint Effects Targeting, counter-IED exploitation, systems to fuse operational and intelligence and the nuclear firing chain are all areas which have enormous social input so that the development of a logical architecture is paramount.

Unless a person has a pedigree in military systems logical architecture is, usually, the least understood/used part of the design process.  Certainly in Agile environments or any area requiring rapid applications development where the application is fixed (portals, billing systems, SAP etc) then logical architecture design is nugatory.

In this blog we look at logical process design but the method is equally applicable to the entire logical design phase.


When designing processes, however, logical architecture is an invaluable tool in measuring, assessing and comparing risk before moving to the more expensive technical design & implementation phases.  Because logical designs can be created, compared and assessed, quickly,  they become an excellent technical/commercial appraisal tool.   Cross-functional teams of executives and architects can collaborate on logical designs before a GO/NO-GO investment decision and thereby create 3 major benefits:

  • Reduce the time of the physical design cycle.
  • Increase executive involvement and the effect of executive steering on designs.
  • Significantly reduce the risk in physical designs.


The Value of a Process

There is a way of viewing, and thereby measuring risk in logical processes.  Ultimately, the value of a process is its cost divided by its risk.  So, a process which has a total cost of $100,000 and a 60% chance of success has a nominal value (not “worth” or “price”) of $60,000.  Which is to say that on average the business will realise only 60% of its value.  This is roughly the same as saying that, on average, for each $100k in earnings, the firm will spend $40k on faults.  Whether the value indicator is dollars or white elephants does not matter, so long as it is applied consistently over the choices.  This simple measuring mechanism allows senior executives to engage in the design process and forces architects to help assign costs to difficult design components.


The difficulty is in ascribing costs to concepts.  In order to do this the team must first instantiate the concepts win some form of logical structure, such as a software system or a management committee/team.  The team then ascribes an industry benchmark cost to this structure, accounting for uncertainty.  Uncertainty is important because the benchmark cost will not represent the actual cost exactly (in fact the benchmark cost should represent the 50% CI cost).  So, when it comes to determining the probability it is vital to use the experts to come up with what the construct could cost (as little as and as much as).


The difficulty with measuring logical architectures is in measuring concepts.  Concepts usually have no value and no standard means of comparing them.  In short, (i) assemble a small, cross-functional team of experts, (ii) ascribe costs (with uncertainty) to the concepts, apply a risk equation, and then (iii) simulate.  One possible equation is:

Logical Risk Equation - An equation for measuring process risk in logical architectures.


  • R is the overall risk.
  • P is the probability of an adverse event occurring in the process.
  • Ct is the criticality of the location of the event, in the process.
  • is the likely time it will take to notice the manifestation of the risk (i.e. feedback mechanisms).
  • Cy is the availability of a contingency plan which is both close and effective to the point of the problem, in the process, and
  • Sl is the likelihood of success that the process will be fixed and achieve an acceptable outcome.
  • 100 simply makes it easier for the team to see differences between scores.

In this equation, we determine the overall risk of the process.  It does not have to be perfect but rather it just needs to be applied consistently and account for the major variables.  If applied rigorously and evenly, measuring risk in logical architectures has the ability to reduce the design cycle, increase the certainty of the choice, build better stakeholder buy-in and significantly reduce the risk in the physical solution.

Building a Risk Culture is a Waste of Time 3

The focus of a good risk management practice is the building of a high-performance operational culture which is baked-in to the business.  Efforts to develop risk cultures cultures only serve to increase risk aversion in senior executives and calcify adversarial governance measures which decrease overall profitability.  The right approach to risk management is a comprehensive, holistic risk management framework which integrates tightly with the business.

risk management. waste of timeThe financial crisis is largely due to the the failure of risk management and over-exposure in leading risk-based institutions.  More specifically, the failure of risk management is linked to:

  • The failure to link link risk to investment/project approval decision making.  The aim of risk management is not to create really big risk registers.  Although, in many organisations one could be forgiven for thinking that this is the goal.  The aim of identifying risks is to calibrate them with the financial models and program plans of the projects so that risks can be comprehensively assessed within the value of the investment.  Once their financial value is quantified and their inputs and dependencies are mapped – and only then – can realistic and practical contingency planning be implemented for accurate risk management.
  • The failure to identify risks accurately and comprehensively.  Most risk toolsets and risk registers reveal a higgledy-piggledy mess of risks mixed up in a range from the strategic down to the technical.  Risks are identified differently at each level (strategic, financial, operational, technical).  Technical and Operational risks are best identified by overlapping processes of technical experts and parametric systems/discrete event simulation.  Financial risks are best identified by sensitivity analysis and stochastic simulation but strategic risks will largely focus on brand and competitor risks.  Risk identification is the most critical but most overlooked aspect of risk management.
  • The failure to use current risk toolsets in a meaningful way.  The software market is flooded with excellent risk modelling and management tools.  Risk management programs, however, are usually implemented by vendors with a “build it and they will come” mentality.  Risk management benefits investment appraisal at Board and C-Suite level and it cannot be expected to percolate from the bottom up.


All this does not mean that risk management is a waste of time but rather it is counter-intuitive to the business.  It is almost impossible to ask most executives to push profits to the limit if their focus is on conservatism.  Building a culture of risk management is fraught with danger.  The result is usually a culture of risk aversion, conservatism and a heavy and burdensome governance framework that only adds friction to the business lifecycle and investment/project approval process.  Executives, unable to navigate the labyrinthine technicalities of such a systems achieve approvals for their pet programs by political means.  More so, projects that are obviously important to the business actually receive less risk attention than small projects.  Employees learn to  dismiss risk management and lose trust in senior management.

If risk management is to be an effective and value-adding component it must be a baked into the business as part of the project/investment design phase.  If not, then risk management processes  just build another silo within the business.  The key is to forget about “Risk” as the aim.  The goal must be a performance culture with an active and dynamic governance system which acts as a failsafe.  The threat of censure is the best risk incentive.

risk management. immature disciplineAWARENESS IS NOT MANAGEMENT

risk management. immature disciplineManagement has long been aware of risk but this does not always translate into true understanding of the risk implications of business decisions.  Risk policies and practices are often viewed as being parallel to business and not complimentary to it.

Why is it that most businesses rate themselves high on risk management behaviours?  This is largely because businesses do not correlate the failure of projects with the failure of risk and assurance processes. 

In a 2009 McKinsey & Co survey (published in June 2012 “Driving Value from Post-Crisis Operational Risk Management”) it was clear that risk management was seen as adding little value to the business.  Responses were collected from the financial services industry – an industry seen as the high-water mark for quantitative risk management. 


Risk management needs to become a collaborative process which is tightly integrated with the business.  The key is to incentivise operational managers to make calculated risks.  As a rule of thumb there are 4 key measures to integrate risk management into the business:

  1. Red Teams.  Despite writing about collaboration the unique specialities of risk management often requires senior executives to polarise the business.  It is often easier to incentivise operational managers to maximise risks and check them by using Red Teams to minimise risks.  Where Red Teams are not cost effective then a dynamic assurance team (potentially coming from the PMO) will suffice.  Effective risk management requires different skills and backgrounds.  Using quantitative and qualitative risk management practices together requires a multi-disciplinary team of experts to suck out all the risks and calibrate them within the financial models and program schedules in order that investment committees can make sensible appraisals. 
  2. Contingency Planning.  Operational risk management should usually just boil down to good contingency planning.  Due to the unique skill sets in risk management, operational teams should largely focus on contingency planning and leave the financial calibration up to the assurance/Red teams to sweep up.
  3. Build Transparency through Common Artefacts.  The most fundamental element of a comprehensive  risk process is a lingua franca of risk  – and that language is finance.  All risk management tools need to percolate up into a financial model of a project.  This is so that the decision making process is based on a comprehensive assessment and when it comes to optimise the program the various risky components can be traced and unpicked.
  4. Deeper Assurance by the PMO.  The PMO needs to get involved in the ongoing identification of risk.  Executives try and game the governance system and the assurance team simply does not have the capacity for 100% audit and assurance.  The PMO is by far the best structure to assist in quantitative and qualitative risk identification because it already has oversight of 100% of projects and their financial controls.

Traditional risk management practices only provide broad oversight. With the added cost pressures that businesses now feel it is impossible to create large risk teams funded by a fat overhead. The future of risk management is not for companies to waste money by investing in costly and ineffective risk-culture programs.  Good risk management can only be developed by tightly integrating it with a GRC framework that actively and dynamically supports better operational performance.