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?

3 Answers 3


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.

  • For the purposes of multiple projects, the operational team is ignoring/overlooking standard practices such as backup. If the project is delivering into an environment that lacks these practices, would it be considered a project risk?
    – Motivated
    Commented Aug 15, 2015 at 2:06

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...

  • The OP wrote, "during delivery...." That would suggest it could impact delivery. Commented Aug 14, 2015 at 11:15
  • That would be one reading of it, I interpreted it as happening at the same time as delivery [delivery meaning "the duration of the project"]. It is not clear. If, for example, the OP meant that during "deployment" there were no backups then there is a clear risk that in the event of failure no rollback is possible and I would certainly grant that as a project risk as it impacts a project goal. My overall point is that a risk is a Project risk if it impacts on Project goals
    – Marv Mills
    Commented Aug 14, 2015 at 11:18
  • @Marv Mills - When you say the goals of the project, what are examples?
    – Motivated
    Commented Aug 14, 2015 at 20:48
  • @Motivated the goals of the project... what the project is delivering. Only you know the goals of your project, I cannot tell you what they are.
    – Marv Mills
    Commented Aug 16, 2015 at 11:01

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".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.