Business Analyst

Overview:

So, how do we actually do business analysis? This section will help you understand the most common, industrial-strength business analysis tasks and processes. Each tab includes a discussion of methods, tools, and strategies you can use to gather, evaluate, and communicate the needs and requirements of the business.

Because business analysis doesn't exactly follow the typical project lifecycle, we've organized this section according to the major activities you will be engaged in. Your first task will be to gain a clear understanding of the business needs, as a foundation for developing a plan to extract and manage the project requirements. Later, as the solution is conceived and continuing throughout its development, you'll analyze options and alternatives for helping the project team deliver the solution in the best way to meet the requirements. Finally, deep into the project, your role will shift to supporting the transfer of the solution to the stakeholder community.

Activity:

Understand the Need
The more energy and effort a business analyst spends on understanding the business need, the more successful the project—and ultimately the business analyst—will be. The business need ultimately determines what the project is trying to accomplish. Some of the strategies and tools that can help you identify the business need are: looking at the goals of the organization or business unit; calling out any pain points or gaps in the current business processes; identifying the root cause of any problems the business is currently facing; and analyzing the costs and benefits of the current solution, compared with the alternatives.

At times, the business need may be clear at the start—for example, it may be clearly stated in a list of business goals or a clear problem statement. But at other times, you may need to work to uncover them. In most cases, you'll have to help the business understand what it actually needs. Tools such as root cause analysis, gaps analysis, and cost-benefit analysis can help you identify and document the business need in a way that your stakeholders will understand clearly.

Activity:

Create the Plan
People often assume that business analysts simply have a natural talent for managing requirements. They often overlook the many hours of hard work that a seasoned analyst will devote to preparing to address the detailed requirements of a project in a requirements management plan.

Good business analysts begin every project by planning their approach—the first step generally being to identify and get to know the stakeholders. Only then will they begin to draw up an actual plan for managing the requirements. The successful analyst also allots time for planning how they will measure the requirements, how they'll communicate with stakeholders, and how they'll measure the benefits of the solution.

For every project, large or small, managing the requirements requires that the business analyst complete a handful of core tasks within the requirements process. Experienced business analysts are so familiar with these important steps that they can easily recite them off the top of their heads and develop an estimate of the effort. They've thoroughly polished their skills in planning the optimal approach to fulfill all kinds of requirements processes at hand. The business analyst conducts a stakeholder analysis to promote effective communication—both major and minor. And they plan for requirements measurement and benefits realization before the work begins. Together, these efforts help them create a plan to effectively manage the business analysis activities and deliverables.

Activity:

Elicit the Details
There's a common misconception that project requirements are "gathered"—as if the requirements are waiting, like amber waves of grain, for the business analyst to come along and harvest them. The reality, of course, is different—requirements must almost always be elicited. That is, it's your job as business analyst to discover, draw-out, detail, review, and document any and all requirements, and review them again and carefully manage them as increasing numbers of requirements are uncovered.

Some of the techniques that experienced business analysts use to gather elicit the requirements are interviews, workshops, and reviewing all available documentation to understand the requirements challenges. Instead of simply asking the business stakeholders what they want, it's better to probe proactively for answers. Ask questions aimed at uncovering what the business actually needs now and will need in future, how the stakeholders perceive the current state, etc. Over the years, business analysts learn to reference the trends and needs that occur most often in projects, as a basis for understanding the present requirements.

Managing requirements is a large part of a business analyst's job, and it's one that needs constant attention. An organized, detailed approach will save you oodles of trouble and wasted time down the line. That's why it's a good idea to categorize the requirements, as far as possible, and seek consensus about how to prioritize them. Defining a formal process for reviewing the requirements will help you present the requirements to the right stakeholders, at the right time.

Will you be prepared when the requirements change—as they surely will? Once again, advance planning will help greatly. The changes will go more smoothly if there's a clear process in place for verifying that the changes continue to address the business need.

Activity:

Analyze the Solutions
Successful project management is, to a large extent, a matter of keeping your bearings. Without a map and compass (or GPS), it's all too easy to get disoriented. At various points in any project, an experienced business analyst will pause to check how well the solution is meeting the business needs. Is it still on track, or has have the efforts of the various teams started to drift from the business purpose? Doing frequent status checks, and communicating your findings to the business partners and project team, will help you—and the project—take the shortest route to successful completion.

Early in the project, establishing clear acceptance criteria will help you track compliance with the business goals as the project moves along. It's important to analyze the solution at key checkpoints in the project lifecycle. You'll be expected to play a role in choosing a vendor, analyzing decisions, reviewing the impacts of any changes, and participating in the testing process before final implementation. Any of these activities, and others throughout the project, will almost certainly challenge you to re-analyze the solution. For instance, what if you discover that none of the vendors who respond to an Request For Proposal (RFP) meet more than a small percentage of the requirements? Maybe it's time for the project team to change course and choose new vendors, or consider building solutions in-house instead of purchasing them.

At each checkpoint, as you re-analyze the solution to verify that it still meets the business needs, be aware that the solution itself isn't the only thing to consider. The success of any project is also tied to how completely the organization embraces the solution. A terrific solution will only be partially successful if all the stakeholders don't buy in. Thus, you may need to apply some organizational readiness analysis and change/transition management to find out how completely the organization will accept the solution. The next step will be to help the staff become comfortable with the solution.

Consider: What if a solution meets the technical requirements well, but requires some team members to do their jobs differently? And what if those people are unwilling or unable to change? As the business analyst, you can help create training and other transition activities to help the team understand the value of the solution and how to work with it.

Activity:

Transfer Knowledge
As a business analyst (or a team member filling that role), you're accountable to understand the requirements. But it's also your role to ensure that everyone else understands them, too——at least well enough to build, test, implement, and start using the solution. And the most important tool in your efforts to educate those around you is the requirements documents, because they put the requirements before the users, stakeholders, and solution developers in a tangible form.

Not all requirements documents have the same "look and feel"—some are more visual, others are more textual, some are tabular. Clearly communicating the requirements begins with choosing the right format for the information you're communicating. If you're communicating processes, process models are an excellent way to go. If you're trying to show how various systems interact with each other, or with various business entities, context diagrams can give a clear, visual image of the linkages. If you need to tell the story of how users interact with the system, Use Cases and User Stories will probably be your best choice. Finally, if you need to organize large volumes of detail about the requirements in a consistent way that makes it easy for readers to digest the information, consider building a repository for the data or business rules (e.g., a data dictionary).You will probably end up using a mix of formats in your final requirements documentation, in order to present each data type effectively and ensure users can understand them easily.