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 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 the 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.
Illustration by Wiley, Composition Services Graphics
Figure 1-1: A generic project lifecycle.
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.
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 been defined — whether that solution is to
build a four-bedroom, wheelchair-accessible, three-car-garage house or to
improve a business process to reduce costs — expectations are set. The
stakeholders (the future homeowners, the business owner/executives, or
whoever) expect that whatever actions follow will result in the solution
that was identified.
Improving estimation: Most people don’t like surprises when it comes to
time and cost estimates. Performing business analysis helps define what
needs to be accomplished. Having this clearer picture lets organizations do
a better job of estimating what their solutions will cost and how long
they’ll take to implement.
Better aligning projects with goals/objectives: Because business
analysis professionals work on both the “why” and the “how” pieces, they
can see when a solution is no longer aligned with the goals and objectives.
Kupe was working on a project where the goal was to reduce
employee time on a specific process for a utility company and therefore
reduce salary costs associated with that process. He identified many parts
of the process that could be automated, thereby reducing employee hours
spent on the process. At one point, Kupe asked how many people
performed a particular part of the process and how often, only to find that
one person did it three times per year. Automating that part of the process
would cost $10,000 . . . and save approximately 30 minutes of work time
and $12 in salary cost per year. Automating this part of the process didn’t
align to the goal of reducing costs, so Kupe convinced everyone not to
automate.
If you discover that the project work is no longer adding value to
reaching the goals and objectives of the company, one of the best things
you as the BA can do is cancel the project.
Managing scope creep: Scope creep refers to the phenomenon of
bringing in new requirements after everyone agrees on what should be
included in a project. In companies where projects are going on all the
time, scope creep is going to happen. Gain buy-in on the project scope
from all impacted people as early as possible. Then, when scope creep
happens, you can show the impact the new requirements would have so
the business can make an informed decision.
For example, say you’re on a project where you’re solving a productivity
issue for one department of a company; halfway through, the company
wants to include another department. In this case, you have to review the
original scope with the company and outline how the added department
will change the project so the decision-makers can determine whether to
proceed with the change.
Reducing project defects: Business analysis activities detail the rules,
process, and user interactions of the solution. This level of detail helps
provide clear direction for the people developing the solution and those
testing the solution to help ensure that defects are reduced and caught
before the solution is implemented. In a solution that enables customers to
buy products from a website, for example, one of the required conditions
would be that the customer must enter a complete address; the BA would
then elicit requirements surrounding the expected experience from the
customer’s viewpoint: Does the company cancel the order? Do the
customers receive an error message? If so, what does the message say?
Smoothing the transition to production: Transition as it relates to
projects is all about moving from the development and test environment,
where you’re building the solution, to the production environment, where
the users are actually using the solution. Good business analysis includes
ensuring the solution will be used in production, which you do by getting
the organization ready for the change and developing a rollout strategy.
Reusing requirements and reducing duplicate solutions: For every
initiative, BAs should be careful not to duplicate requirements underway
in different areas of the company. Because you often develop many
solutions at the same time for the same goals and objectives, companies
may well be working on multiple projects trying to accomplish the same
thing.
Kupe was working at an energy company that was trying to
improve the operations of its four real estate divisions. Each division was
independently trying to address the same need: updating the real estate
database. By looking outside each individual group, Kupe and a team
suggested combining efforts that could save time and money by focusing
on one solution rather than four.
Improving communication within the team: Business analysis activities
boil down to communication. One of the BA’s main roles is to elicit and
communicate the true needs of the business so the right solution can be
delivered. Making sure everyone has a clear and consistent understanding
of what needs to be accomplished helps ensure all sides are working
together to accomplish the goal.
Increasing customer satisfaction: BAs help address the inevitable
changes a company goes through and can help mitigate any problems
customers may feel as a result of those changes. One of the biggest ways
you as a BA can help is by facilitating communication of the changes to
customers. For example, if the company wants to make a change to its
services or product, you can help it determine what the impact on the
customers will be and how to effectively communicate the upcoming
changes to those affected.