For project managers following PMI doctrine, project risk management is a core component of project control. Central to project risk management is its major process steps: Identification; Assessment; Control; and Monitoring. This cycle will kick off during initial project planning and periodically repeat periodically throughout the project. PMs engaged in risk management will be in a strong position relative to their peers who are not as they will develop a deeper understanding of their project and the landscape upon which it is executed. If you are interested in major initiatives that could have benefited from risk management, checkout this catalog of Information Technology Project Failures. If you’re interested in some major faux pas – try this.
A strong project risk management plan allows managers to look at the entirety of their project from numerous perspectives including: Resource; Technical; Cost, Schedule; Scope, Process/Procedure; Internal Threats; External Threats to name a few. Through a lens of what could go wrong, the project team will identify, assess, respond to, and assign personnel to monitor each risk worthy of continued observation. Individual risk responses will roll up into large scale project contingency plans. Here we will examine the benefits to establishing, maintaining and improving a project risk management plan and overall enterprise program.
Risk management makes it easier to identify troubled projects. As mentioned during the introduction, single risk events will be identified, assessed and responses planned. These events aggregate into an overall project risk score.
From initial planning, red flags will be raised by virtue of high probability/high impact risks events. Additionally, the trajectory of the project itself can be assessed by virtue of its risk trajectory. If project progression results in an accumulation of risk – it’s clear that this is a troubled effort and there won’t be any substitute for decisive action.
A robust risk effort simply reduces surprises. Of course, there will always be surprises that arise in spite of risk management – the so called unknown-unknowns. But there does not have to be as many and they don’t have to be as painful. Risk management forces the project team to be in touch with its event horizons – and prepared to deal with risk events as they occur.
In a nutshell, better quality data means that in order to perform project risk management properly, you’ll require data to analyze your situation. If you’re going to evaluate schedule risks, you have to have scheduling information. Hence, you need the capability in place that allows said evaluation. If you’re going to assess technology risks, you need to have technical information available.
Garbage in equals garbage out. There is an effort and a skill set required to reap the benefits of risk management. And as study after study has shown, risk management is something project teams are willing to blow off completely or just pay lip service to.
Not having information on hand to be able to assess risks is certainly a fact of life depending on where you are in the project life-cycle. But now you definitely know you don’t have it. You know what you need, and that lack of information is itself something needs addressed.
Higher quality data is identified as improved in Benefit #3. So, what do you do with that data? First, the team uses it for decision making. Second, and of interest to us here – communication of risk information will demand its own communication channel – a RIC process will provide coverage.
A properly implemented risk program will specify requirements for communicating risk information up and across the organization. This means that project sponsors and key stakeholders are on top of information as it unfolds – good or bad.
Better data quality is indeed a linchpin of several risk management benefits. Once risk information is available – it will have a positive impact on budget accuracy.
Further, it will allow a contingency budget to actually be calculated, or at least qualitatively arrived at, rather than simply assigning a standard contingency ‘fee.’
Everybody wants their technology project to succeed as envisioned. And everybody is pretty much always disappointed. If the stakeholders fully understand project risks, then activation of risk contingencies, however difficult, are at least seen as logical and planned if not pleasant .
The project planning process in general and the risk management process in particular will engage and focus team members outside of their respective specialties. I will say that based on my experience, nothing engages individual team members like being assigned ownership of a risk and responsibility for its monitoring.
Successful project management needs to manage uncertainty but also engage the known problems that emerge during project execution by a combined Risk-Issue-Change process. Read Change as Project Change Control – the formal process by which the approved project performance monitoring baseline schedules and plans are modified.
Project risks represent potential problems and project issues represent known problems. The short version of RIC is that risk management identifies the potential problems, if and when these become reality, they convert into issues. Issues are then managed, with possibility that their impact will require project changes.
If the project is meeting its obligations as envisioned in a risk management process of the type envisioned in Axelerate’s article entitled “Project Risk Management #1: Process Landscape,” that team will respond proactively to risk events as they occur. If the team has not met its risk management obligations, the team will be reactionary, acting in an ad hoc manner to events that have not been identified as risks and will not benefit from any predetermined corrective actions.
The accumulation of documented risk information can be used to generate a lessons learned and risk information support database – consisting of both procedural and risk management assist information. This would be used as a reference in future projects. Ideally, this will improve not only project level risk management, but project management across the organization.
Of course, all that glitters is not gold. Risk management programs have not necessarily become the panacea we might have hoped for. But why? If all of the aforementioned benefits are true, it would seem that ‘good’ risk management is what technology projects have been waiting for. It’s that word – good – that can be a bit fleeting. Garbage in equals garbage out. There is an effort and a skill set required to reap the benefits of risk management. And as study after study has shown, risk management is something project teams are willing to blow off completely or just pay lip service to.
Project risk management is not free. It creates a considerable overhead on the project (especially during project planning). Each organization must assess this trade-off for itself both at the project level and at the aggregate enterprise level. There is very little empirical benefit/cost data for this estimation – the fact being that project risk management is considered a somewhat fuzzy area of project management. The PMI conference paper “Risk Management Does (Not) Contribute to Project Success” provides excellent information in regards to risk management effectiveness.
In the final analysis, a well-constructed and well-intentioned risk program will reap the benefits detailed here. At a minimum, organizations with significant project expenditures should clearly define their procedures and expectations for risk management, communicate its importance, adequately train its personnel, and monitor high risk or major initiative projects for compliance with risk management procedures.