The Business Analysis Process: 8 Steps to Being an Effective

Business Analyst
In: BA Roles and Responsibilities, Plan Your Business Analysis Approach By: Laura Brandenburg

Being assigned to a new project is an exciting time as a business analyst, but it can also be nerve-
wracking. You might be wondering what exactly is expected of you, what deliverables you should be
creating, and how to guarantee success on your project.

In this article, you’ll learn about the 8-step business analysis process that you can apply whether
you are in an agile environment or a traditional one, whether you are purchasing off-the-shelf
software or building custom code, whether you are responsible for a multi-million dollar project or a
one-week project.

Depending on the size and complexity of your project, you can go through these steps quickly or
slowly, but to get to a successful outcome you must go through them.

(We cover each of the 8 steps in even more detail in our BA Essentials Master Class – in fact, each
step gets an entire lesson in this virtual, self-study course.)

First, take a look at this process flow below which shows how the 8 steps fit together and how you
might iterate through them on a typical business analyst project.

Now let’s look at each of the 8 steps in more detail.

Step 1 – Get Oriented

Often as business analysts we are expected to dive in to a project and start contributing as quickly as
possible to make a positive impact. Sometimes the project is already underway. Other times there are
vague notions about what the project is or why it exists. We face a lot of ambiguity as business
 analysts and it’s our job to clarify the scope, requirements, and business objectives as quickly as
possible.

But that doesn’t mean that it makes sense to get ourselves knee-deep into the detailed requirements
right away. Doing so very likely means a quick start in the wrong direction.

Taking some time, whether that’s a few hours, few days, or at the very most a few weeks, to get
oriented will ensure you are not only moving quickly, but also able to be an effective and
confident contributor on the project.

Your key responsibilities in this step include:

 Clarifying your role as the business analyst so that you are sure to create deliverables that
meet stakeholder needs.
 Determining the primary stakeholders to engage in defining the project’s business objectives
and scope, as well as any subject matter experts to be consulted early in the project.
 Understanding the project history so that you don’t inadvertently repeat work that’s already
been done or rehash previously made decisions.
 Understanding the existing systems and business processes so you have a reasonably clear
picture of the current state that needs to change.
This is where you learn how to learn what you don’t know you don’t know, so to speak. This step gets
you the information you need to be successful and effective in the context of this particular project.

Step 2 – Discover the Primary Business Objectives

It’s very common for business analysts and project managers to jump right in to defining the scope of
the project. However, this can lead to unnecessary headaches. Uncovering and getting agreement
on the business needs early in a project and before scope is defined is the quickest path
forward to a successful project.

Your key responsibilities in this step include:

 Discovering expectations from your primary stakeholders – essentially discovering the “why”
behind the project. (Our BA Essentials Master Class covers 7 different business analysis techniques
that can be used as part of this discovery.)
 Reconciling conflicting expectations so that the business community begins the project with a
shared understanding of the business objectives and are not unique to one person’s perspective.
 Ensuring the business objectives are clear and actionable to provide the project team with
momentum and context while defining scope and, later on, the detailed requirements.
Discovering the primary business objectives sets the stage for defining scope, ensuring that you don’t
end up with a solution that solves the wrong problem or, even worse, with a solution that no one can
even determine is successful or not.

Step 3 – Define Scope

A clear and complete statement of scope provides your project team the go-forward concept to realize
the business needs. Scope makes the business needs tangible in such a way that multiple
project team participants can envision their contribution to the project and the implementation. 

Your key responsibilities in this step include:

 Defining a solution approach to determine the nature and extent of technology and business
process changes to be made as part of implementing the solution to the primary business objectives.
 Drafting a scope statement and reviewing it with your key business and technology
stakeholders until they are prepared to sign-off or buy-in to the document.
 Confirming the business case to ensure that it still makes sense for your organization to
invest in the project.
Scope is not an implementation plan, but it is a touchstone guiding all of the subsequent steps of the
business analysis process and tasks by other project participants.

Step 4 – Formulate Your Business Analysis Plan

Your business analysis plan will bring clarity to the business analysis process that will be used to
successfully define the detailed requirements for this project. Your business analysis plan is going to
answer many questions for you and your project team.

Your key responsibilities in this step include:

 Choosing the most appropriate types of business analysis deliverables, given the project
scope, project methodology, and other key aspects of the project context.
 Defining the specific list of business analysis deliverables that will completely cover the scope
of the project and identifying the stakeholders who will be part of the creation and validation of each
deliverable.
 Identifying the timelines for completing the business analysis deliverables.
In the absence of defining a credible and realistic plan, a set of expectations may be defined
for you, and often those expectations are unrealistic as they do not fully appreciate everything that
goes into defining detailed requirements.

Step 5 – Define the Detailed Requirements

Detailed requirements provide your implementation team with the information they need to implement
the solution. They make scope implementable.

Without clear, concise, and actionable detailed requirements, implementation teams often
flounder and fail to connect the dots in such a way that delivers on the original business case for the
project.  

Your key responsibilities in this step include:

 Eliciting the information necessary to understand what the business community wants from a
specific feature or process change.
 Analyzing the information you’ve discovered and using it to create a first draft of one or more
business analysis deliverables containing the detailed requirements for the project.
 Reviewing and validating each deliverable with appropriate business and technology
stakeholders and asking questions to fill in any gaps.
Effective business analysts consciously sequence your deliverables to be as effective as possible in
driving the momentum of the project forward. Paying attention to the project’s critical path, reducing
ambiguity and complexity, and generating quick wins are all factors to consider when sequencing your
deliverables.

Step 6 – Support the Technical Implementation

 On a typical project employing a business analyst, a significant part of the solution involves a
technical implementation team building, customizing, and/or deploying software. During the technical
implementation, there are many worthwhile support tasks for you to engage in that will help drive the
success of the project and ensure the business objectives are met.

Your key responsibilities in this step include:

 Reviewing the solution design to ensure it fulfills all of the requirements and looking for
opportunities to meet additional business needs without increasing the technical scope of the project.
 Updating and/or repackaging requirements documentation to make it useful for the
technology design and implementation process.
 Engaging with quality assurance professionals to ensure they understand the business
context for the technical requirements. This responsibility may include reviewing test plans and/or test
cases to ensure they represent a clear understanding of the functional requirements.
 Making yourself available to answer questions and help resolve any issues that surface
during the technical design, technical implementation, or testing phases of the project.
 Managing requirements changes to ensure that everyone is working from up-to-date
documentation and that appropriate stakeholders are involved in all decisions about change.
 When appropriate, leading user acceptance testing efforts completed by the business
community to ensure that the software implementation meets the needs of business end users.
All of these efforts help the implementation team fulfill the intended benefits of the project and
ensure the investment made realizes a positive return.

Step 7 – Help the Business Implement the Solution

Your technology team can deliver a beautiful shiny new solution that theoretically meets the business
objectives, but if your business users don’t use it as intended and go back to business-as-
usual, your project won’t have delivered on the original objectives. Business analysts are
increasingly getting involved in this final phase of the project to support the business.

Your key responsibilities in this step may include:

 Analyzing and developing interim and future state business process documentation that

articulates exactly what changes need to be made to the business process.
 Training end users to ensure they understand all process and procedural changes or
collaborating with training staff so they can create appropriate training materials and deliver the
training.
 Collaborating with business users to update other organizational assets impacted by the
business process and technology changes.
This step is all about ensuring all members of the business community are prepared to embrace the
changes that have been specified as part of the project.

Step 8 – Assess Value Created by the Solution

A lot happens throughout the course of a project. Business outcomes are discussed. Details are
worked through. Problems, big and small, are solved. Relationships are built. Change is managed.
Technology is implemented. Business users are trained to change the way they work.

In this flurry of activity and a focus on delivery, it’s easy to lose track of the big picture. Why are we
making all these changes and what value do they deliver for the organization? And even more
 importantly, are we still on track? Meaning, is the solution we’re delivering actually delivering the value
we originally anticipated?

Nothing creates more positive momentum within an organization than a track record of
successful projects. But if we don’t stop and assess the value created by the solution, how do we
know if we are actually operating from a track record of success?

Your key responsibilities in this step may include:

 Evaluating the actual progress made against the business objectives for the project to show
the extent to which the original objectives have been fulfilled.
 Communicating the results to the project sponsor, and if appropriate, to the project team and
all members of the organization.
 Suggesting follow-up projects and initiatives to fully realize the intended business objectives
of the project or to solve new problems that are discovered while evaluating the impact of this project.
After completing this step, it’s likely you’ll uncover more opportunities to improve the business which
will lead you to additional projects. And so the cycle begins again!

>>Learn More About the 8 Steps to Being an Effective

Business Analyst
We’ll discuss all 8 steps in a lot more detail as part of our BA Essentials Master Class.

Your investment includes 8 lessons in PDF and audio mp3 formats covering each of the 8 steps of the
business analysis process, weekly guidepost emails to help you stay focused and motivated, and a
planning template covering all of the key activities that you can use to create a business analysis plan.

There’s even a self-study option for earning 8 PDs/CDUs.

Business Analysis Process Flow

by Thejasree Prakash, Project Manager
June 19, 2015

Before a project commences, it is important to begin with the business analysis phase. The
process is generally divided into multiple steps with each step involving specific tasks to
perform, principles to follow, and documents to produce. While these steps and principles are
agnostic to the SDLC cycle, the frequency of occurrence or the order may tend to change.
Each step within the business analysis phase may be longer or shorter depending on the type
of project.

This diagram depicts the business analysis process flow.

Business Analysis Process Flow Diagram

Step 1: Gather Background Info

This first step is where much of the ground work for a project is covered. Whether a project is
brand new or existing, it’s crucial for the business analyst to gather a significant amount of
background information on the project. These are the conditions of the project that need to be
determined at this stage:

 What domain is the project under? Financial, health, energy, hosting, etc. Is there
enough information corresponding to the domain? If the answer is no, a business analyst
would perform additional research about the project by spending time understanding the
do’s and don’ts and terminologies of the corresponding domain.
 Determine the various circumstances that could potentially affect the business strategy
for the project. This can be accomplished by using a PESTLE Analysis or Porter’s Five
Forces framework.
  PESTLE Analysis – this technique of analysis examines the impact of external
forces such as Political, Economic, Socio-cultural, Technological, Legal, and
Ethical and the implications on an organization that have the potential to impact the
project and strategy.
 Porter’s Five Forces framework – based on the idea that an organization
operates in this technique, this determines the pressures on an organization that may
impact the project. Industry competitors, new entrants, substitutes, buyers, and
suppliers are examined to determine what, if any, external pressures exist.
 Thoroughly understanding the history of a project and documenting it allows the
requirement gathering process to flow well.
 If there are any existing systems that need to interact with business processes or be
accounted for, they need to be understood and documented during this stage of the project.

Optional documents that are beneficial at this step are:

 Glossary of Terms
 System and Process Records
Step 2: Identify Stakeholders

The stakeholders on a project are the ones that give sign off on requirements, priorities, and
make decisions. Therefore, identifying all of the stakeholders early on is important. A
stakeholder wheel technique can be used which contains each stakeholder that impacts the
project.

 Owners – shareholders, trustees or anyone who is sponsoring the project.

 Managers – senior or middle managers responsible for communication and
monitoring the progress.
 Employees – developers, analysts, or testers responsible for delivering the project.
 Regulators – any regulators involved that monitor adherence to rules. For example, a
regulator that monitors HIPAA compliance.
 Suppliers – any API provider or other supplier service needed that the project might
interact with.
 Partners – individuals responsible for working alongside the project that provide
complementary or supplementary products or services.
 Customers – the end users of the product.
 Competitors – a potential section of users of competitive products or inputs from the
competitors themselves.
The document at this stage is the:

 Stakeholder Matrix – a list of groups and stakeholders for each classification

Step 3: Discover Business Objectives

Establishing the business strategy and objectives and putting them on paper will help the
business analyst and project managers stay focused on the vision and make course corrections
along the way. It will also help during scope definition.

 Before getting too deep into the project, asking why the project is needed helps
narrow down the business objectives.

A few techniques to assist in establishing business objectives for a project are:

 Benchmarking – understanding competitors and peers who work on the same level.
Ansoff’s matrix can be used for this.
 SWOT Analysis – determine the strengths and weakness.
 Focus groups and brain storming.
 Documenting and conveying the business objectives to all of the stakeholders ensures
a single vision.
 A business objective needs to be “SMART”.
 Specific –describes an outcome that is visible.
 Measurable – outcome should be measurable.
 Achievable – objective needs to be feasible to achieve.
 Relevant – needs to be in alignment with the company’s vision statement.
 Time-bound – can be within a defined time frame.

The document at this stage is the:

 Business Objectives List

Step 4: Evaluate Options

To achieve the objective, it is important to determine the critical path among the various
options available. Here are the steps involved in determining the best path:

 Identify options – brainstorming and focus group meetings help determine various
options.

Possible options can be:

 Customize/enhance an existing solution to achieve the business objective

  Purchase an existing service/system
 Build a product from scratch
 Integrate to other systems to achieve quick to market times.
 Shortlist options – narrowing down options from the big list to a short list of viable
options.

A few factors to consider while narrowing this down are:

 Feasibility
 Budget/funds available
 Acceptable return on investment
 Prepare a business case – based on the narrowed down options, a business analyst
might need to prepare a business case using:
 Cost-benefit analysis – this looks at cost of pursuing an action and the benefits
of that action.
 Impact analysis – identifying and presenting actions that affect the project or
company that would have be factored into pursuing an action.
 Risk analysis – various risks that can be involved in pursuing an action
 Presentation of business case – based on the analysis of various options, the business
analyst will present the options to the stakeholders to make a decision.

The document produced during this stage is a:

 Business Case Document

Step 5: Scope Definition

Based on the objective of the project and a team discussion, this step is when the scope is
defined. A list of project development goals is detailed, along with a list of items that are not
included in the project. The scope definition document can include:

 Development modules in scope

 Development items out of scope
 Integrations in scope
 Integrations out of scope

The document produced in this stage is a:

 Scope Definition Document

Step 6: Business Analyst Delivery Plan
The business analyst and project owner will provide a detailed timeline for delivering the
requirements to the development team.

 A timeline for the requirements will be provided based on factors such as:
 Stakeholders and their availability
 Project scope
 Project methodology
 By dividing the requirements into deliverables and providing realistic dates for each
of them, this will help plan resources and project timelines accordingly.

The document produced here is the:

 Business Analyst Delivery Plan

Step 7: Define Project Requirements

This step requires the business analyst to clarify the requirements to the business owner and
get the ok to deliver them to the development team.

Requirements can be divided into functional and non-function. Non-functional requirements

can be documented in a business requirement document which includes performance,
scalability, and security. Functional requirements are provided in terms of use cases, story
boards, prototypes, and wireframes. A few techniques that help the requirement gathering
phase are:

 Interviewing the stakeholders – asking when, how, where, and what is supposed to be
achieved by the user helps arrive at requirements.
 Requirements defining techniques – use case templates, story boards, prototypes, or
wireframes.

Based on the development method, requirements can be all delivered upfront e.g., the
Waterfall technique. Most development companies shy away from Waterfall because it’s
difficult to accommodate changes along the way. For Agile projects, requirements can be
delivered per sprint cycle. A business analyst will sequence deliverables to facilitate
development plans.

Documents required in this stage are:

 Non-functional Requirements – business requirement document

 Functional Requirements – use cases
Step 8: Support Implementation Through SDLC
A business analyst is involved through the technical implementation of requirements to
ensure that everything aligns.

These are a few steps during this phase:

 Reviewing the technical deliverables to align with requirements.

 Based on feedback from the development team, update or repackage requirements to
facilitate implementation.
 Engage with quality analysts to ensure requirements are tested and requirements are
understood.
 Manage changes from the business owner that are requested once the initial
requirements are delivered and implemented.
 Facilitate user acceptance once the requirement implementation is done.
Step 9: Evaluate Value Added By Project

To maintain the business objective through the implementation, a constant evaluation on

business outcomes needs to be maintained. Questions to ask can be – Are we on track? Is the
solution delivering the value initially anticipated? A few key points are to:

 Evaluate the actual progress across the timeline and business objectives and provide
stakeholders updates and answer questions.
 Based on the progress and feedback, suggest any modifications or initiatives required
to realign the implementation phase with business objectives.

If you see an opportunity for more changes or enhancements or new projects, communicate
the idea to the stakeholders by performing research.

The importance of the business analysis phase cannot be overstressed. This phase sets the
tone for the entire development project so it is crucial to flush it out as much as possible. The
more time and energy dedicated towards perfecting this phase, the smoother the overall
development will proceed. This guide provides a general overview for Business Analysis
Process Flow, but each company should modify it to make the process fit their company the
best.

Sources:

 http://www.slideshare.net/pvanabbema/enterprise-analysis
 http://www.bridging-the-gap.com/business-analysis-process/
 Business Analysis Techniques: 72 Essential Tools for Success by James Cadle, Debra
Paul, and Paul Turner
 GET YOUR REQUIREMENTS OFF TO THE RIGHT START WITH
THESE 5 STEPS!
Written by  Angela Wick

t’s project kick-off time! February, more than any other month, tends to be the time when organizations transition
from planning to action. New initiatives have been prioritized, dollars have been allocated and teams are being
formed—everyone is ready to get to work.

BAs being assigned to these projects often working with new PMs or new leaders and sometimes leaders expect
BAs to jump in and start detailed requirements, like NOW! BAs are often asked to begin gathering requirements
before solution scope and context are defined. The project scope might be defined, but that does not mean the
solution scope is defined.

Most leaders I talk to would say they expect that BA start with scope and context activities and some planning,
yet BAs don’t feel that is what leaders are asking of them. BAs feel they are expected to jump into specification
level of detail based on expectations from leaders and business stakeholders, coupled with unrealistic deadlines.

BAs might be tempted to go with the flow and jump right into detailed requirements. Instead, we need to rock the
boat a bit, think strategically, and advocate for the time needed to properly get requirements right and avoid the
rework. After all no matter if we are working on agile or traditional projects, rewriting and reworking requirements
because we jump to writing details vs. aligning on the big picture spells waste and disaster. Our leaders DO want
context and the big picture defined, even if they seem focused on details and deadlines. Here are 5 things BAs
should do to build a solid foundation for their requirements:

1. Create a Scope/Context Diagram: A high-level scope/context diagram helps the project team
understand the boundaries of the solution. Agile and traditional teams benefit from this critical visual of the
solution. It helps the team identify stakeholders, processes, products and systems that will be affected by the
solution. The diagram offers a great starting point for dialogue when BAs begin their work. Even when assigned
to a project late in the game, I start with this as a critical tool to build credibility with the team that I understand the
scope of the solution, its impact. Stakeholders and I have alignment to where the details fit into the bigger picture,
and this makes planning easier. I find leaders LOVE these diagrams and teams can rally around all the details
once everyone has the same big picture visual to understand where the various details fit in.

2. Document The As-Is and the To-Be: The as-is and to-be models, often presented in the form of a
diagram rather than text, are a valuable tool for defining gaps between the current state and the future state.
These models can model the process (current and new), the product (current and new) or the system (current
and new). They are really great at showing the changes that will be taking place and that we are eliciting
requirements for. These don’t need to be at a detailed level, they should be high level to start, adding detail if
needed. Agile and traditional teams will rally around full understanding of what details impact what parts of the
bigger process with the proposed changes.

Most BAs see the value in this information, but they get caught up in details. We need to put our reading glasses
and microscopes away and look at the big things. Outline the major differences between the current state and
future state before beginning with the details.

3. Identify Stakeholders: Who are your primary stakeholders and how will the solution impact their team,
processes, and/or systems? This step seems so obvious. We know our stakeholders, right? We always have a
list of key leaders and SMEs before a project begins. Have we taken it to the level of what user roles are
impacted and how? And communicated/reviewed this with all project stakeholders.
 A key analysis at the beginning is to identify all user roles impacted by the solution and how they are impacted.
This gets elaborated as we discover more, and a high level to start can really help the team move forward with
very positive results.

In truth, projects rarely start with exactly the right stakeholders. They either start with an unnecessarily large
group (everyone), that we help refine and manage based on impact, or with small group that expands with the
scope.

When we leap into requirement details too quickly without solution scope, context, as-is and to-be, we miss
stakeholders, which means we miss requirements. We use extra time to get these stakeholders up to speed on
the project and they often miss the very important collaborative processes in the initial phases of elicitation.

4. Outline Acceptance Criteria: Similar to the future state, acceptance criteria outlines the minimum
criteria that will make the solution a success, and gives BAs and stakeholders a glimpse of the future. BAs begin
to understand what success looks like and this picture keeps us focused on value. The strategic focus on value
helps us make good choices along the way. On agile teams acceptance criteria is often paired with User Stories;
here I am discussing the entire solution, so a comparable term in agile is MVP (minimum viable product) and its
criteria.

5. Tailor the BA Approach: For every new project BAs should consider what is new or different about the
project. Which techniques will work best in the project environment to best define the solution? Is there more or
less risk? In what areas? How can we use techniques to mitigate them? Custom development projects have a
very different approach then package software, and process improvement projects are different as well. The
same approach, techniques, and templates will not work, we need to tailor the approach for the unique project
and solution characteristics.

Even if the deliverable list remains the same for every project from a governance perspective, we always have
flexibility in how we elicit the information and how to use the templates. For example, a package software project
might require us to dig into and understand the vendor capabilities and functions and do a gap analysis, then
user demos and prototyping with the vendor package. Whereas a project to build a new in-house system, with
team members scattered across the world might require a series of virtual requirement workshops focused on the
users, what they need, and why. Prepare for these differences and prepare the team for them.

When we consider these activities carefully, we quickly realize they are interdependent. BAs need to work
through them iteratively, circling back through each task multiple times as the project evolves. For example, we
can’t really develop a high-level scope diagram without the help of some stakeholders, and we can’t identify all
stakeholders before you define the scope.

Because of this spiral effect, BAs need to be very aware of “good enough.” We need to be efficient in order to be
effective. Don’t worry about perfect or complete. Focus on the main components and the quality of dialog,
engagement, and relationship building with your stakeholders. We need to focus on what we need to generate
and maintain your focus on value throughout the project.

Don't forget to leave your comments below.