Kate McGoey

The details section of a business case provides all the supporting documentation and diagrams for the recommendation that results from your business analysis. You usually include only the details of the recommendation, but you may want to add details of some alternatives if they were close in comparison or the audience may be interested in seeing them.

Reverse engineering refers to looking at the solution to figure out how it works. Basically, you you’re your business analysis backward from the solution to understand the data, processes, and business rules. Reverse engineering is more common than you think. Have you ever looked into a Microsoft Excel formula to figure out where it’s coming up with the calculation?

“Why” is such a powerful question that it’s the basis for a root cause analysis technique called the 5 whys. The thought is that by the time you ask a stakeholder “Why?” 5 times, you generally have arrived at the root cause. Consider this example: Q: “Why did you submit a purchase requisition for $750?” A: “Because we need to purchase 150 staplers!

Aside from fulfilling a business analyst (BA) role at a company, you may have the opportunity apply your various business analysis skills to other roles. You can parse out individual business analysis skills to make yourself more marketable, take advantage of opportunities, and meet a company’s specific needs for growth and improvement.

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

When verifying and validating solutions, you perform a requirements review, a structured audit in which you give participants the opportunity to ask questions and make suggestions in order to improve the quality of the product being reviewed. Keeping the requirements review session moving forward is the facilitator’s job; because you may be wearing that hat during the meeting, here are some tips for conducting the requirements review session: Put on a thick skin when documents you authored are being reviewed.

On new development or mission-critical projects, several people may perform business analysis work. If so, business analysis planning may be divided among different business analysts. In these cases, the lead or senior BA should work with the sponsor, who has acquired funds to do the project and ensures project alignment with strategic goals.

Although many teams nowadays have one person function as both the project manager (PM) and business analyst (BA), a lot of teams still have different people performing those roles. One of the challenges on a project with a separate BA and PM is clarifying the responsibilities between the individuals. Because you and the PM interact with the same stakeholders, you both need to be very clear on what roles each of you’ll play during a project.

In business analysis projects, plans become outdated as soon as you start executing. As you discover new information about the people, project characteristics, and process, those changes impact your plan. Things may change from minute to minute, so your plan can only be as good as what you have now. Here are some tips to help you deal with the unforeseen: Tell your team right away about any changes you have to make.