Understanding and analyzing the risks of a business analysis project is an important part of identifying and documenting the project scope. Risks can be project-related and/or business-related:
Project risks: Project risks are potential problems that may impede the completion of a project. They include situations like losing a key person prior to the completion of the project or having a team inexperienced with a commercial off-the-shelf tool (or COTS tool, a pre-packaged, one-size-fits-all solution that may or may not have the ability for customization). Project risks are managed by the project manager.
Business risks: Business risks are risks that may impact the mission of the business area. Examples include having the release of the product go so well that the company can’t keep up with orders. You as the business analyst manage the business risks.
Identifying possible risks and response plans ahead of time puts you in a better position to react to a changing project. If the project falls behind schedule, you can focus your time more effectively on the areas that are the neediest because you’ll have already anticipated them instead of being caught by surprise. In addition, you should already know which pieces of the project can be postponed without business failure.
Risk responses in business analysis
Knowing what the risks are is one thing; knowing what to do about them is another. When identifying risks, identify a response as well so you know how you’re going to act if and when a risk actually happens or so you can put controls and checks in place to prevent a risk from occurring in the first place.
According to the Project Management Institute’s A Guide to the Project Management Book Of Knowledge, 5th Edition (PMBOK 5), you can respond to a risk in four ways:
Avoid: In this response, you change the project to eliminate the threat. For example, say that you want to put in a new software solution that allows customers to purchase products online, but this is being developed in a software program that the development team is unfamiliar with.
To avoid that risk, the team can either change the software and develop within the expertise of the staff or utilize developers that are experienced with the desired software.
Transfer: Shift the risk to another party. Perhaps you transfer the risk of creating the online purchasing system to a consulting company. The consultants are contractually bound to create the system, not you. They accept the risk.
Mitigate: Reduce the probability or impact of the risk. You don’t have experience in coding web pages, so you send your development team to an intensive two-week training in website coding.
Accept: Choose to accept the risk and develop a contingency plan. You put the online purchasing program in place, and your contingency plan is to drive customer traffic by using social media to promote the new site.
By thinking ahead, you’re prepared with a clearly thought out response plan so you can react with level heads instead of responding to the risk in the heat of the moment and making an uninformed (and possibly emotional) decision.
Risk factors in a business analysis
The last items you want to document surrounding a risk are the risk factors. They include the risk’s probability (likelihood) and impact (effect on the project).
As the business analyst, you bring the project team together and, through conversation and educated guessing, get members to agree on the likelihood that the risk will happen as well as the impact to the project or organization if it does.
How to put all the risk information together for a business analysis
After you’ve documented the project and business risks, what value do they have? Well, with the probability and impacts documented, you can prioritize the risks and concentrate on those you feel will be most likely to have the highest impact. Consider the risks shown below. You have a list of the risks for the project, as well as how you plan to respond to them if they happen.
| ID | Risk | Response Type | Response | Probability | Impact |
|---|---|---|---|---|---|
| 1 | Key developer leaves before the project is complete. | Mitigate | Pair up developers and cross-train. | Medium | High |
| 2 | Unfamiliarity with the new application may delay project dates. | Transfer | Hire consulting company to implement software. | High | High |
