Paul Mulvey

Business analysis projects all follow the same basic life cycle. A project is a set of steps that accomplish something, so describing business analysis activities as part of a project life cycle makes sense. Although each project you undertake is different, and you must always remain fluid and flexible to some degree, business analysis tasks follow a general order: Plan the project.

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.

The genuine problem or opportunity that the business seeks to address in their analysis is the root cause problem, and it’s not always that easy to uncover. You typically have to ask a lot of questions to get down to that root cause because your stakeholders often report symptoms rather than the real cause. A business analyst’s best question is “why?

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.

“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!

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.

When you’re involved in process improvement projects as a business analyst, a key task is to take time to define the metrics you’ll use to measure success. The measures differ, depending on the industry and what you’re trying to improve, but the important thing is to make sure you have enough time to discover the baseline measurements and then calculate what the measure of success is.