Business Analysis For Dummies
Book image
Explore Book Buy On Amazon

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

About This Article

This article is from the book:

About the book authors:

Paul Mulvey, CBAP, Director, Client Solutions, B2T Training, has been involved in business analysis since 1995. Kate McGoey, Director, Client Solutions, B2T Training, has more than 20 years' experience in application development and life cycle processes business. Kupe Kupersmith, CBAP, President of B2T Training, possesses more than 14 years of experience in software systems development. He serves as a mentor for business analysis professionals.

This article can be found in the category: