Is an operational risk considered a project risk?

Question

Assuming there is an IT operational risk such as the lack of backups during a delivery of a solution would it be considered a project risk and if so how would you classify the risks?

Answer 1

Does this have the ability to affect the successful completion of your project? if so, it is a risk. I'm not sure that dividing risks into "operational" and "project" helps me to close the project successfully. A risk is any unknown that could affect the schedule, cost, quality, or scope of my project. The lack of backups isn't a risk per se. Absence of backups means that:

• Given that there are no backups IF an event occurs that degrades or destroys any of my data, THEN I could lose a predictable amount of time/effort/resources remediating the outage. In some cases this could result in the complete failure of my project. The probability of an outage is easily quantified, the amount of time spent in remediation is relatively easy to predict. The cost of doing backups is predictable and relatively small. Therefore, my mitigation plan is to impose backups.

• Given that my IT staff is ignoring simple best practices in backup, IF they are ignoring other best practices THEN my ability to exert control of my project is significantly diminished. Mitigation plans should include analysis of why the IT staff is ignoring backups and what other procedures are flawed, and what impact this might have. This is an example of a risk where risk analysis significantly reduces the risk.

I've never been a fan of classifying risks. Risk management isn't a goal, it is a tool to help close the project successfully. Strip out anything that doesn't help to close the project.

Answer 2

In my view the way to think about this is that the risks on the Project's Risk Log pertain to risk to the goals of the project. In other words, things that could happen that prevent you from delivering the project on time, cost and quality and particularly against the acceptance criteria.

So in your case (depending on what your project actually is!) a lack of operational backups would not be a project risk. Actually "lack of backups" is not a risk at all, it is a description of a situation and should be phrased "Because of the lack of operational backups there is a risk that [some effect or consequence]".

Having said all of that, part of a software delivery project is usually to assure post-live support and operational handover. If the lack of operational backups could compromise that side of the delivery then it could be a project risk...

Answer 3

Both Marv and Mark have great answers to this, but I want to add something on the classification of risks. I agree with Mark that risk management is not the end but the means to an end and keeping it simple and straight forward are two great rules; however, classification of risks, and other more formal risk documentation rules, may not help your current project but are great inputs into FUTURE projects and lessons learned and maybe even become projects themselves. So depending on the size and complexity of your current project and plans for future projects, creating more formal risk management policies, which is a cost, may serve the organization well in the long run.

I would classify this risk maybe as "operational", "process", or "policy".