Chapter 1

Business Analysis in a Nutshell

IN THIS CHAPTER

Grasping what business analysis is and why it's valuable

Tracking a business analyst's role and skills

Staying nimble with an agile approach

Introducing industry guidelines and certification options

In today's competitive world, companies must always be at their best, maintain an edge, and capitalize on opportunities for growth. Business analysis is a deliberate attempt to review operations to ensure that business is moving along as well as it can and that the company is taking advantage of opportunities.

Basically, business analysis is a set of tasks and activities that help companies determine their objectives for meeting certain opportunities or addressing challenges and then help them define solutions to meet those objectives. Sometimes, companies hire outside, independent business analysts (BAs) to come in and perform the analysis. Other times, they may call upon employees to perform BA tasks internally regardless of whether they have a business analyst title. No matter which category you fit into, this book lays it all out for you.

This chapter gives you a very broad overview of what business analysis is, introduces you to the business analysis lifecycle, and explains what the job entails. This chapter also provides an overview of analysis in an agile environment and what the business analyst role might look like in that environment.

Defining Business Analysis

According to the Business Analysis Body of Knowledge (BABOK) version 3, business analysis is "The practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value."

Translation: Your goal as a BA is to understand how companies work and to enable companies to reach their potential by helping them articulate and meet goals, recognize and take advantage of opportunities, or identify and overcome challenges. All of which is a pretty tall order. But the task becomes more manageable - and understandable - if you think of it as having two distinct parts: the goal and the process.

• The goal: The goal addresses why you're doing the analysis in the first place - perhaps to improve a company's revenue and services or to reduce its costs. Think of the goal as the purpose of the project. In order to determine what the real goal is, you often have to employ the most frequently asked question in the world of business analysis: "Why?" Although we go into much deeper detail later in the book about discovering the goal of a project, the process really can be as simple as asking "why" until you've gotten to the root of the issue. (This fact is one reason we feel a four-year-old is the best business analysis professional around.)
• The process: The process involves understanding the how - that is, understanding what the solution needs to do, what it should look like, and the people or systems that interact with it. The process requires you to grasp where the company is today and where it needs to be in order to achieve the goal. During this part, you determine what the solution should look and feel like and how to make sure it's used after developed. To develop the process, you basically break the goal down into manageable pieces that you and the company can execute. Those manageable pieces make up the solution.

In business analysis, you do not actually perform the activities to build the solution, nor do you actually manage the process to build the solution or test the solution. Instead, you identify the activities that enable the company (with your expert help, of course) to define the business problem or opportunity, define what the solution looks like, and define how it should behave in the end. As the BA, you lay out the plans for the process ahead.

Knowing Your Role in the Basic Business Analysis Lifecycle

Business analysis work is done at many levels within a company. From the chief executive officer (CEO) and vice presidents to the line managers, individuals throughout the company use business analysis activities throughout their day.

Because folks at all levels view things in terms of a project (a set of steps to accomplish something), explaining business analysis activities as part of a project lifecycle (as shown in Figure 1-1) is easy. Although these tasks fall in a general order, they're somewhat fluid, as we discuss in later chapters. For now, get to know this cycle; it's at the crux of all things business analysis:

1. Plan the project.

   Planning includes creating a work plan or at least thinking through an approach for the analysis effort on a project, encompassing all the activities you do and the techniques you use. As the BA, your primary role during planning is determining the scope of the effort; if you're a more senior BA, you may be involved in project estimation and resource planning. These additional tasks are detailed in Chapter 11.

2. Scope the project.

   Defining and documenting the project scope requires you to understand why the project has been initiated (the project statement of purpose) and the goals of the project (the project objectives). As the BA, you hold folks to the project boundaries and analyze the business problem without jumping to a solution. This step includes clearly identifying the opportunity or problem the company needs to address. Chapter 9 includes information on how to develop a business case, which also discusses the problem definition. For more on scoping, flip to Chapter 10.

3. Elicit, analyze, and communicate the requirements.

   This step is the bulk of what business analysis professionals do at the project level. As the BA, you actively partake in understanding the real business needs and finding the root cause of business problems, as well as communicating requirements to the intended audience. This task involves categorizing the requirements and knowing how detailed they have to be to ensure your project is solving the right problem. We discuss requirements in Chapters 5 through 8.

4. Design a solution.

   BAs aren't typically responsible for this activity; rather, they collaborate with the solution team to develop a solution. Because solution design isn't a core business analysis activity, we don't cover it in this book. However, the fact that design doesn't fall to you doesn't mean you should walk away when the designing starts. Having the BAs available to support the design and development team is important.

5. Build or buy the solution.

   Based on the activities in Steps 1 through 4, the business and project team make a decision to build the solution internally, have a group outside the company build it, or buy a prepackaged solution. During this time, your role is to ensure the solution still meets the business need stated in the project objectives and the business requirements. In addition, you may also start writing test cases and test scenarios for the next (test) phase.

6. Test the solution.

   As the solution is being designed and built, you need to validate that the business needs elicited during the project are being met. You collaborate with the test team, either as an active tester or by working with the testing team to ensure the solution meets the stated requirements and other project documentation. You can find out more about how to test solutions in Chapter 14.

7. Implement the solution.

   After a solution is built, you need to help make sure the business uses the solution. You actively work with project stakeholders as the solution rolls out, perhaps as a change agent (advocating the need for change) and/or to train new users on the system. Part of the implementation may be eliciting metrics surrounding usability, noting how quickly they are adapting to the new system, and gauging customer satisfaction. We cover implementation in detail in Chapter 15.

8. Conduct a post-implementation review.

   After the solution has been implemented, you need to make sure the goals outlined in the project are being met. If they aren't, another project may be necessary to address the gap. We detail post-implementation review in Chapter 14.

   Don't confuse the post-implementation review with a "lessons learned" process. The latter generally discusses how you can do the project process better, not how well the solution works for the business.

© John Wiley & Sons

FIGURE 1-1: A generic project lifecycle.

Looking at the Value of Business Analysis

A popular perception of business analysis is that it makes businesses do business better. It's simple but true, and BAs are the people who function as the liaisons between the problems and solutions to make businesses everywhere do business better. Here are just a few of the ways that your performance as a BA can help an organization:

• Setting expectations: BAs help stakeholders define a solution for their problem. After a solution has...