Overview
When I started to write this article, I looked at a number of various definitions of Capacity, Appetite and Tolerance used in Risk. There are quite a number of different definitions.
The ones I will use for this article, and also been using for number of years when instructing on Risk mainly related to Project Risk, are those below, as defined by the ISO 31000 and the Guide 73.
The official ISO:31000 definition of Capacity is:
Risk capacity: the amount and type of risk an organisation is able to support in pursuit of its business objectives.
The official ISO:31000 definition of Appetite is:
Risk appetite: the amount and type of risk an organisation is willing to accept in pursuit of its business objectives.
The Official ISO:Guide 73:2009 definition of Tolerance is:
Risk tolerance: organization's or stakeholders’ readiness to bear the risk after risk “treatment” in order to achieve its objectives
Note 1 to entry: Risk tolerance can be influenced by legal or regulatory requirements (added to the definition in the Guide)
A “legal” definition of Capacity is:
A firm’s ability to identify their financial resources, expertise, and operating mandate to determine how much risk they are able to take. In other words, as with Insurance companies for example, the amount the organization is able to withstand.
It is vital that when one is looking at definitions to agree which are the most appropriate for the organization, but this does NOT mean picking and choosing to make life easy. It means understanding the business of the organization and the type of change initiatives that are employed and ensuring that way the organization members use them are the same. However, I would recommend using the “official” ones which will avoid confusion and arguments.
The Detail
Let us have a look at these definitions in more detail as it will then be easier to understand the relationship between.
Capacity
The official ISO:31000 definition of Capacity is
Risk capacity: the amount and type of risk an organisation is able to support in pursuit of its business objectives.
The key words here are – “able to support” and “pursuit of its business objectives”. Every organization has its business objectives. These are measurable targets it sets itself to achieve its mission in life. “What is the organization here for”? How much is the organization able to absorb, take on board as a whole.
Understanding the amount of risk capacity an organization has is very much related to its Mission and hence the objectives it needs to achieve because these are linked to the investment the organization makes overall based on those objectives and risks involved around them. These risks are areas such as competition, which Porter’s Five forces relate to and help understand the competitive forces at play. An area that should/could/ and would normally be within the role description and abilities of a Business Analyst. External risks should also be identified by external forces such as defined by PESTLE. Point being that whatever the undertaking of an organization for the business it is in there will be certain criteria that shape the risks it could face and therefore the overall capacity (financial and resource investment for example) that would be supported.
For example an Insurance company would have a different “capacity” to that of a supermarket chain to that of a car manufacturer. Therefore, when it comes to initiating change and funding those changes and understanding the risk of not just delivering the change but the risk of the change on the organization, the broader impact on the organization as a whole, and its ability to keep viable, sustainable”, is vital.
Appetite
The official ISO:31000 definition of Appetite is
Risk appetite: the amount and type of risk an organisation is willing to accept in pursuit of its business objectives.
The risk “appetite” key words are “willing to accept”, the stress being on the “willing”. As I will note later, “Tolerance” is initially linked to this word. However, it will have a reference to “support”.
Capacity is defined at strategy level and remains unchanged in the main, unless there is a change at strategy level. However, this is not the same for Appetite and here lies the first key difference.
Appetite is about how much the organization is willing/prepared/ready to absorb – for any particular change initiative. It will vary as each initiative is different. One of the characteristics of a change initiative is that each is unique and so will have its own risks associated with it. Yes, there will also often be risks that are more common place, the same of other initiatives. Resources (people, systems, finances, accommodation etc.) can often be a source of risk across and number of initiatives, for example. However, it is important to remember that when assessing risks at the outset, that means outset of the initiative and outset of each session related to identifying risks, the first consideration is that of the “context” of the initiative that provides an understanding of the sort of risks that this particular change could attract or be subject to.
At strategic level, when considering the change at Portfolio level, the business would be doing this to understand the major risks that could be associated with the specific change, as the business would need to assess and decide if any would be “show-stoppers” at the outset, or, materialize during the change. These would be considered and documented in the Business Case. These risks would then come under the next topic of this article – Tolerance. That would be one area of Tolerance. Other risks could also catagorized under Tolerance and that is what I am going to look at next.
Tolerance
The Official ISO:Guide 73:2009 definition of Tolerance
Risk tolerance: organization's or stakeholders’ readiness to bear the risk after risk “treatment” in order to achieve its objectives
What this refers to is that the Tolerance in this case is an organization’s willing to bear the risk after any “response” has been put in place. Which is not the same as “Appetite” which generally refers to the overall risk, (collection of all risks), associated with a specific initiative. So the tolerance here is risk by risk related. This is a sensible way to assess and to estimate the impact/probability/proximity of each risk, decide on a response and then reassess it and decide if it is still “acceptable”! Now this can be taken one step further.
In PRINCE2® the application of “Tolerance” takes this one step further.
Why and how you might ask (I hope you do anyway as I am getting there to answer them both)?
One of the key elements of PRINCE2® is that of Governance, (and indeed AgilePM®, though this methodology does not go into Tolerance in so many words on Risk, but certainly does on Governance). The point of Governance in any project is for the business is to decide whether or not they want to keep investing in the initiative. Three words here
Desirable - Achievable – Viable
And in each, or any combination, of these points part that decision will be around any risks that have been identified and subsequently assessed with respect to their possible impact on the initiative – Threat or Opportunity! So any risks that are “out of tolerance”, beyond the “appetite” boundary, as defined by the organization/business, will be focused on to see if the proposed “response” will reduce the risk to an acceptable level, below this “tolerance” boundary. In other words no longer be considered as a “major risk” (show-stopper).
Is the initiative still ”desirable”, and/or “achievable” and/or “viable” because of such a risk? This is the use of Tolerance with respect to risk and its relation with appetite.
The other application of “Tolerance” in a project applying the methodology PRINCE2®, relates again to Governance, however, this time in a broader way. Tolerance is used here to set boundaries of empowerment. What is meant by this is that the business will empower the Project Manager with authority to deal with variations in a given timeframe of a project, within boundaries before the Project Manager needs to escalate for direction and then often decision by the Project Board (more likely the Project Executive). Risk is one of those areas of variation. (Just to add here the other five are: Time, Cost, Scope, Quality and Benefit). Each of these will also have a tolerance set for the same reason/purpose.
This diagram depicts the boundaries of tolerance on Time and Cost as an example, where the Project Manager can track these two parameters against the desired and real tracking of the project and the projected direction of either or both in order to ascertain a need for escalation or not.
The “Forecasting Here” is the trigger as the projected path of that forecast could take the project past the Time tolerance and so needs to get direction from the next level of Governance, the Board. The diagram would work for Risk as well. Here it is to explain the other defined use “Tolerance”.
It might be interesting to note here that under the AgilePM® methodology two of these “parameters” do have a tolerance set on them, but it is ZERO. Time and Cost. Arguably there are three, the third being Quality. Where Time and Cost do not vary (should not – another discussion!), Quality, by using MoSCoW, has a minimum limit, Must Have, so could be argued can vary! The REAL “variable” in this approach is Scope.
Closing Note
Risk is always a variable and should always have tolerance set on each individual risk, for the reasons mentioned above, which, as noted also, is related to the Appetite of the organization/business for the overall risk associated with the change initiative and then applied to each individual risk (as per the Guide 73 definition). I believe that taking this one step further, as PRINCE2® does, adds better control and ultimately, good Governance, for any initiative.
So it is imperative that the Capacity of the organization is defined at strategic level and filtered down through the Portfolio, (could even be through Portfolio Support/Management Office), to the change initiatives themselves (and, once again, through the Programme/Project Support/Management Offices), so that this level is understood first. Only then can a realistic understanding of the appetite for each initiative be defined by the relevant governing business, and then finally the tolerance for each Risk.
PRINCE2® - is a registered trade mark of AXELOS Ltd
AgilePM® - is a registered trade mark of Dynamic Systems Development Methods Ltd.
Author Bio
Antony della Porta has experience of over 30 years in the project management profession. He is an established professional in the delivery of strategic business change and an advisor for programme and project recovery with critical systems thinking approach. He has been an Executive Advisor and Director at GPM Global and founded “The Sustainable PM” initiative, which is a platform that is set to help PMs become "sustainable”. He is also an accredited instructor and practitioner for a number of courses in the fields of management and project management.