When we board an aircraft, we acknowledge there is risk. While nobody wants to dwell on this, we understand that the flight may suffer a catastrophic incident. If a passenger embarking a flight was asked what the risks are, a typical reply might be, “That the plane will crash.” In the same way, if stakeholders in a software implementation project, such as Business Central, were asked what the risks were, they may reply, “The project will run over schedule.” Or, “The project will go over budget.” Stating a risk in this broad manner is not helpful in managing it.
How should we define risks?
A risk is broken into several components, how these components are articulated is critical to how that risk is viewed, understood and managed. From the previous post in this series the first step in risk management is risk identification. Once a risk has been identified, it must be defined in a Risk Statement for those who will decide how to control it. This Risk Statement is a critical part of Risk Management.
The first step in risk management is risk identification. Once a risk has been identified, it must be defined in a Risk Statement for those who will decide how to control it. This Risk Statement is a critical part of Risk Management.
Creating risk statements
There are a great number of people who contribute to an aircraft getting passengers from point A to point B. There is the manufacturer of the aircraft, the maintenance engineers, the pilots, and the management team & executives of the airline. Risk statements across the various teams have different audiences, but they should all follow the same structure with the following elements:
Risk Cause – This is why something could go wrong. It is here that we consider what needs to be done to prevent it.
Risk Event – This is what could go wrong. This is where the uncertainty lies—the existence of the cause does not mean the event will happen. But if it does, there will most likely be an impact.
Consequence – This is the potential outcome of the event. It is the impact on the Critical Success Factors and highlights why we must pay attention to the risk. If the consequence can be quantified in real terms, i.e. a fine of $200,000, the Risk Statement should then be expressed as:
“Because of [risk cause], [risk event] may occur, which would lead to [consequence].”
What defines success, and how can we manage risks?
Every project and team will have a different view of success. Success for a pilot is getting to the destination safely and on time. Success for an airline is being profitable. Success for a company implementing a new ERP system may be to have the system live by a certain date to prevent incurring a license cost for their existing system. Success for a user within a company implementing an ERP system may be to increase the number of quotes they can enter each day.
Defining success will be discussed in detail in future posts, but it is important to understand that you need to know what success looks like before commencing a project and attacking the risks.
What could be risks that prevent success in the above instances?
- Because of inclement weather, an alternative flight path may be necessary, which would lead to a later than scheduled arrival.
- Because of an air crash, NQR Airlines may receive significant bad press and a decline in passenger numbers, which would lead to a decrease in revenue.
- Because of the unavailability of key staff during the analysis phase, critical system requirements may not be known until acceptance testing, which would lead to cutover being delayed.
- Because of a limited budget, competing functional requirements may take priority over enhancing the quoting process, which would lead to no performance improvements in raising quotes.
Events can lead to new causes, and consequences can lead to new events. As is the case in many aviation disasters, it is often a chain reaction or several events aligning that results in the unforeseeable. As such, having risks stated in manageable units is vital.
