Risk Management – What can go wrong in projects? What can go right? Why do we need risk management and who is responsible for risk management?
One of the distinguishing factor between project work and business as usual (BAU) is the amount of uncertainties in projects.
As a result of uncertainties normally embedded in projects it is important that project risks are proactively identified and managed well to increase the success rate of delivering project objectives meeting stakeholder requirements. We will start our discussion by first defining what is meant by project risks? All projects have some degree of risk or uncertainties. This characteristic of projects underpins the requirement of risk management in project s. Project risks are eventualities which may or have a probability of happening and if they materialize they affect our project deliverables either positively or negatively.
When eventualities affect the project objectives positively we call this an opportunity whereas if the project is affected negatively this is deemed as a threat. Project opportunities and threats need to be managed proactively and effectively so as to increase project success rate and stakeholders satisfaction. The project manager is responsible for managing project risks (both opportunities and threats) on behalf of the project sponsor or steering committee. Project manager must also ensure that project risk management approach or strategy is in place so that a risk register is created and used to manage both opportunities and threats. These main activities must be done during project planning phase however risk management is ongoing throughout the project life.
Project management best practices based on PRINCE2 and PMI PMP both demand that all projects must have a risk management procedure and accompanied by a risk register. Risk management procedure will dictate how project risks are identified, assessed (qualitatively and quantitatively), development of mitigation plans and communicated to relevant stakeholders. Mitigation and response plans need to be clearly defined whether we are dealing with opportunities or threats.
Known responses to threats include avoidance of risk, transfer of risk, accepting the risk as part of risk appetite, or having a fall-back plan B in place. Responses to opportunities involve s making decisions whether to enhance an opportunity, rejection of an opportunity, exploiting the opportunity or even decide on having pain/gain situation meaning should there be a loss or gain all involved stakeholders take it. All captured risks must be populated in the risk register and their respective mitigation plans, Expected Monetary Value, proximity risk owners and risk actionee etc.
Aggregated risk value must be expressed in monetary value and provided for as either a risk budget or project contingency in the project budget. A project budget without providing for contingency is risky in itself because should identified risks materialize they will be need to respond with a mitigation plan often needing to be funded. All risks materialized during project life help create lessons for future work or projects.
This is one of the reasons identified risks are never deleted but rather closed whenever the project is closed. Is there a difference between a risk and an issue? Indeed there is a difference.
All risks are probabilities or uncertainties they may happen or not. When risk happens then only it becomes an issue and can be resolved through issue management. Our takeaway from this week’s discussion is that projects without risk management are likely to have uncontrollable reactionary responses to unforeseen events. These may result in projects not achieving their intended objectives. Best practices in project management require that all projects have a risk management approach or strategy specific to the project and a well spelled out risk management procedure. This must be accompanied by a risk register needed for proper risk management activities. The project manager must ensure that all the above mentioned documents are in place and that risk management activities are taking place and hence scheduled in the project schedule.
This article was written by Dr Laban Mwansa, MSP®, PMP®, PRINCE2® Practitioner, Agile®, Laban is a consultant and trainer in project management and specifically trainer/coach in PMP®, PRINCE2® Practitioner, and PRINCE2 Agile® in Zambia, South Africa and Europe for many years. He was in the executive committee of ICTAZ as technical chair. He is also the managing partner of Betaways Innovation Systems and can be reached at: Laban.Mwansa@betaways-innovations.com, +260975280392 or WhatsApp +27817029669.