Conducting a business impact analysis (BIA) for project risk management had never really occurred to me in a serious way. That is until I read BIA for Projects in the current edition of Disaster Recovery Journal by John Glenn. I have come to realize that a lot of things can go wrong in business and you need to be prepared for risks. For example, having a supplier risk mitigation solution is essential to ensure that your business is not dragged under by the fault of a supplier.
Project Risk Management
My impression of what Glenn was trying to convey in his article was what I would more often equate to sound project risk management practices found in organizations with even modest enterprise risk management (ERM) programs and project portfolio management systems in place. Most of Glenn’s examples are about project specific threats and risks not the resulting business impacts of a project failure.
Under the umbrella of project risk management, project threats and project risk is assessed and summarized qualitatively or quantitatively to produce an overall project risk rating. Then, according to that project risk rating a risk mitigation plan is developed if the project is approved.
In my experience, the project risk assessment process is done formally at least twice. Once in support of the project submission so it can be used as one of the project selection criteria and again during the project initiation phase before the final WBS is completed.
Having worked as a service provider for many years I am also familiar with the vendor side of project risk management which is sometime called engagement risk management. Still it is handled within the vendor’s enterprise risk management program and works the same as their customers’ project risk management just with a slightly different view of the same project.
Business Impact Analysis
I am also accustomed to conducting a business impact analysis as part of the standard project management process to satisfy enterprise risk management requirements. But in this case the business impact analysis is aimed at creating or updating the business impact analysis to account for the project’s change on the business.
Ordinarily that is done with a traditional BIA Questionnaire administered by IT or published using SharePoint or similar platform for self service and regular automated update reminders. You can download a free BIA questionnaire here for subscribers which you can edit to fit your own needs.
So the business impact analysis would be conducted or updated for a new application or a major software upgrade. The relocation of a data center or migration of systems to the cloud would require an updated business impact analysis be done.
But I have never given a serious effort to having a functional area or the entire organization perform a specific business impact analysis just for a project and I am not sure I have ever come across an enterprise risk management program that required it. That doesn’t mean I haven’t tried. Most efforts result in the functional managers just working the BIA intent into the project risk management plan or into the change management plan for go live.
Glenn has convinced me I should probably try harder to get a business impact analysis done for projects and amending enterprise risk management to require it. But I am still not clear on criteria for when a BIA is warranted. Here is what I concluded:
- If the project risk rating is above some threshold the affected business units and functions must amend their existing business impact analysis or create a supplemental BIA to account for the project.
- If the project has limited or no tolerance for delays without significant impacts to the business a business impact analysis should be done
A great example for this idea is an earlier post on VDI and Business Continuity which is worth a read.