Despite it being arguably the most effective Risk Management paradigm around today, most organisations are not aware of the beauty, power and persuasiveness of BowTie Risk Management methodology.
Those who are aware of it are either using it, or make up the vast remainder, who have heard good things about it, but don't really know what it is or where to start.
In this post i'll show you what BowTie Risk Management methodology is all about.
Calculating or quantifying risk, as opposed to qualifying risk, is essential if you want to accurately prioritise the risks your organisation faces, and ultimately control them down to acceptable or tolerable levels.
Calculating risk values or risk scores gives you an actual measure of risk instead of simply recognising a risk is present.
With two key numerical pieces of information; probability and impact, you can quantify any risk event (sometimes called top event).
This is fine if for example your company consists of a single or couple of departments, but what if, like many organisations, you have complex command structures, multiple departments, numerous domains and various locations? How do risks in one downstream department manifest in upstream departments?
This article attempts to show you how you can calculate risk in multi domain organisations which in turn will help you foster an all round more efficient enterprise risk management system.
In the UK, the Prime Minister David Cameron is expected to hold an EU Referendum by the end of 2017, with some, including David Lidington, the Europe minister, believing it could be as early May 2016 as UK-Brussels dialogue appears to be picking up pace.
Decided by millions of UK voters, the single question "Do you want the UK to be part of the European Union?" clearly has potential connotations for British businesses and overall trade relations with the continent, although to what degree, no one really knows just yet.
Indeed, even though we are at least 12 months away from the EU Referendum, and despite many believing that Britain will remain part of the EU after the referendum, several large companies have already began to look at the risk that Britain's departure from the EU could impart on their organisations. On the flip side, several business leaders have stated that Britain can "go it alone", and trade would not be affected.
Recent events at Thomas Cook has highlighted, in exceptional and tragic circumstances, where failures in Enterprise Risk Management (ERM) and especially Safety Management Systems (SMS) led to the very worst outcome in any risk management plan: serious injury and multiple fatalities.
As a direct result of oversights in effective risk management within their organisation, as well as an avoidable loss of life, Thomas Cook's reputation has taken a nose dive which was exacerbated by their ill-advised response to the incident. Indeed, Thomas Cook is now in a form of crisis management mode – trying to mitigate the effect of recent events on their reputation, post occurrence - all down to a single low probability, high impact event.
This article however, does not aim to critically analyse the loss of reputation in such circumstances, nor does it intend to criticise Thomas Cook; it instead endeavors to learn from maladaptive methods in large-scale management within enterprises, and tries to promote an all round increased focus on how reputation risk awareness, prior to an undesired event occurring, can lead to much better enterprise risk management, and hopefully reduce the prevalence of similar events erupting in the future.
In any complex engineering project, there is risk to project success and delivery at every stage from design, to development, to maintenance and beyond. Risk factors in systems increase with greater complexity and complexity itself is driven by the density and interaction of and between component parts whether that be when viewing the overall system, sub systems or sub sub systems etc.
Due to the fact that software architecture involves potentially hundreds of thousands, if not millions of lines of code, the risk factor is extremely high due to the shear number of component parts (individual lines of code) required to perform multitudes of required actions. In fact, in terms of risk calculation of project success, software engineering is amongst the highest risk engineering fields in the world; up there with nuclear engineering and aviation and especially if the software is for safety critical functionality. Risk in software development certainly cannot be taken lightly.
In the United States alone, SaaS (Software as a Service) sales are estimated to reach $21.3bn in 2015. This is up over 100% from 2010. Indeed, SaaS sales in 2010 were just shy of $10 billion and nearly $14 billion in 2011.
Not since the 2015 General Election in UK, when the polling companies realised the wrong way of gaining electoral insight was asking the same 15 men sat in the pub next door to their offices at 10am every morning for 6 weeks who are you going to vote for? has there been such an apparent dramatic change of thought.
So, what explains the upward trend in SaaS usage?
To many people, the term "Risk Management" is a bit daunting and instills in the mind images of high risk, life threatening dangerous health and safety scenarios at one extreme, and at the other is the picture of the stressed out stockbroker shouting over all his colleagues trying to make the killer sale at the exact profit-generating moment.