A business analyst identifies the needs and solutions for an organization to enable change.

This person
uses a specific set of tools and techniques to uncover and analyze the needs or potential opportunities
for end-users.

Business analysis, or BA, is the process by which we identify business needs, recommend relevant
solutions, and understand requirements.

the International Institute of Business Analysis, otherwise known as IIBA define business analysis as the
practice of enabling change in the context of an enterprise by defining needs and recommending
solutions that deliver value to stakeholders. So here you see, IIBA emphasizes the importance of BA
within the business to enable change. You're supporting the strategic direction of the organization by
enabling these changes.

Now, the Project Management Institute, or PMI, has a different flavor to their definition of BA. PMI
focuses mainly on project managers and their activities. So the way they approach BA is more about
supporting the project manager or the project effort. You see this in their definition of business analysis.
They define business analysis as the application of knowledge, skills, tools, and techniques to determine
problems and identify business needs, identify and recommend viable solutions for meeting those
needs, elicit, document and manage stakeholder requirements in order to meet business and project
objectives and facilitate the successful implementation of the product, service, or end result of the
programmer project.

PMI places a big emphasis on understanding of the requirements of all stakeholders. Also different from
the IIBA definition, we see PMI talks about implementation. They frame the BA role as being responsible
for the implementation of the result. When PMI defines a project, they define it as being able to deliver
a service, a product, or a result.

business analysis is defined in different ways depending on the point of view of the definer.

Business analysis seeks to identify and understand business needs and provide solutions to enable
change.

Business analysis identifies business needs--both problems and opportunities--by working with
stakeholders.

The IIBA sees business analysis as a process of supporting the strategic direction of an entire
organization, while the PMI's definition is more narrowly focused on projects and products.

Business analysis - and the responsibilities of business analysts - can be defined differently. The
important point is that analysts address the needs of a business and search for solutions.

Business analyst skill set:

 Expert judgement
 Analytical skills
 Communication
 Ability to work with leaders
Situation and solution statements
Selecting transcript lines in this section will navigate to timestamp in the video
- Since we don't have unlimited time and resources to address the various needs of the organization, we
need to document our findings in a manner that helps with the prioritization of work to be done. As we
do our needs assessment, we need to gather relevant data to make sure that we understand the
magnitude of the problem or opportunity. This helps us make sure that we properly size the solution.
Once we understand the need, with the supporting data, the business analyst drafts a situation
statement to provide not just what the situation was that we encountered, but also the impact on the
organization. The first part of a situation statement states the current problem to be solved or the
opportunity that needs to be explored in a structured manner. The second part then identifies the
impact of that situation on the organization. The format of this statement is: the problem or opportunity
has the effect of X on the organization with the resulting impact of Y. So here's an example. The existing
process for processing returns involves the need to submit paperwork duplicating the digital record. This
results in significant delays and extra labor costs. The impact is that additional staff is hired to meet
established quotas. It's critical to review this with the key stakeholders to make sure we've captured the
situation correctly, so that we can develop a proposed solution that addresses the real problem or
opportunity. One of the most commonly used tools to help correctly understand the situation is an
Ishikawa diagram for documenting a root cause analysis of the problem. Another tool which is used in
adaptive or agile projects is the five whys. We can also create models of the flow of processes to help
discover where problems might exist, and then recommend solutions. We might recommend a solution
by just making a modification to the current process without any additional resources needed. Once
we've defined the situation, it's time to move on to a potential solution. The solution is something that is
developed to deliver measurable business value. It could be a new product, components of a product, an
enhancement of an existing product, or just a fix. The solution statement recommends the most viable
option to meet the need. The solution statement or approach defines at a high level the areas to be
included or the initial scope and possible steps to move from the current situation or state to a future
state. If there are multiple options, weighted criteria may also be used to propose the best option that
will be further expanded upon in the business case. Before developing a final solution statement, we
may need to do a feasibility study to help gather more information. This may include reviewing
operational capability and the ability to either change or sustain the change. This may include whether
the solution is technically feasible, whether it might work in the current environment, as well as help
estimating potential cost or time requirements. We never want to provide only one solution. Instead, we
provide multiple options. This allows the stakeholders to choose the one they think has the best chance
of success.

Needs assessments are based on three categories of business needs. They are "Problem or Potential
Improvements", "Opportunities or New Endeavors", and "Compliance Requirements."

The definition of a stakeholder is "any individual, group, or organization that may be affected by, or
perceive itself to be affected by, or can impact a decision, activity, or outcome of a program or project."
Stakeholders can include several people: the group or individuals who initially propose the study, those
who will benefit from the solution, those who have special knowledge of the current situation, and those
that will use, support, or implement the result.
Purpose of a business case

how does an organization choose their projects? Are there any specific methods or documents that can
help justify the resources needed? The business case, developed by those requesting a solution, is
usually developed to help with the justification. This document is often a formal document. The time and
effort required to develop it, though, should be consistent with the size and importance of the solution
being justified. It will include the results of the needs assessment and findings previously discovered with
key stakeholders from the organizations impacted. It is a living document. It helps ensure that the project
remains aligned with the organizational objectives. This is especially important when organizational
objectives change. If a project or program is no longer in alignment with the current strategy, it runs the
chance of being canceled. Not all organizations create business cases or go through a formal process of
strategic planning to justify expenditures of organizational resources, both money and individuals, for
project efforts. Some organizations require the business case for capital expenditures or where time or
cost limits are met. Where a business case is not required or developed, executives may approve
projects based on compliance regulations, competitive pressure, or personal preferences, the last of
which is not a preferable method. When a business case is developed and reviewed as part of a portfolio
management process, it becomes a valuable input to the initiating of the project or initiative. It provides
valuable information of the business need and the proposed solution. If it's not created, the scope of the
project or initiative may creep beyond what was initially envisioned, resulting in cost overruns, delays,
and possible rework. The worst situation is that the result of the effort is never used because it didn't
meet the needs or expectations of the original requester. This documents the potential benefits and
justifies the resources needed. These resources may include people, supplies, and equipment, as well as
financing options. The benefits need to be weighed against the cost of the solution, but the cost is not
just for the development of the solution, but also for any ongoing support requirements. This analysis
reviews the findings from the needs assessment activities to the goals and strategic objectives of the
organization. It becomes one of the key inputs for project initiation, providing a concise and
comprehensive view of the business need and the proposed solution for that need.

Content of a business case

The Business Case is used to justify initiating a project as well as providing a summary of previous needs
assessment activities. Now, there are two major components of a Business Case the Business Needs and
the Previous Analysis of the Situation under consideration. The summary of the business needs includes
the identified needs of the situation statement, identification of stakeholders, and the initial scope of the
proposed project. The key stakeholders can include those involved in the needs assessment as well as
those individuals or groups of stakeholders, that will be impacted by the results of the project effort.
Previously obtained information that pertains to the result may include, the organizational strategies,
goals, and objectives, which will be supported by this effort, the analysis of the situation and root cause
of the problem, or supporting data for a new opportunity, critical success factors, which need to be met.
Analysis of the potential gaps between current capabilities and those required to support the future
state. High-level risk assessments, assumptions, constraints, and regulations, which will need to be
further validated as additional project work is done. Also, recommendations for alternative
implementation options and approaches. High-level milestones, dependencies, roles, responsibilities,
and risks. We have to justify the resources required for the project so we can use various benefit
measurement methods to help choose the project, providing the greatest benefits. Some of these
financial measurements include, payback period, net present value, internal rate of return, depreciation,
cost benefit analysis, as well as ROI. Even though much of the development of these methods are done
by those in the finance organization, the data used is provided by the business analyst through the
previous analysis that was performed. The business analyst then works with a sponsor or other key
stakeholders, for the proposed project to help understand the business need, feasibility, and potential
success factors.

The summary section includes the identified needs of the situation statement, identification of
stakeholders, and the initial scope of the proposed project.

Business section does not exist; however, business needs, costs, and various data are included in other
sections.

resources section would only include personnel needs for the project, and not the overall business
needs.

scope section would only include the project boundaries, and not the overall business needs.

Project planning: Vision

Selecting transcript lines in this section will navigate to timestamp in the video

- When we use the word vision, we might roll our eyes. Vision gets used in a lot of corporate trainings
and company culture messaging, but here in project planning, vision should be thought of as more of a
thesis statement or a goal. The project vision is an idealistic view of the desired outcome. It helps us stay
on task and remain oriented to the business value that's driving the project in the first place. Even with
all the detail that's included in the business case, it's important for the entire team to have a vision of
why the project is being done. This includes what the result will look like to those who benefit from the
result. Everyone, including the sponsor, project manager, business analyst, and key stakeholders need to
participate in building the consensus of that shared vision. The project charter, which formally initiates
the project, contains the project vision. The vision contains the why, what, who, when, where, and how
of the project. Let's start with the why. This is the vision, mission, and goals that are to be delivered by
the result. Then there's the what. Objectives identified in the business case, initial boundaries for scope,
and maybe what is not included. As far as the who goes, you identify the key stakeholders, both
internally and externally, who will play key roles in the project. The when is fairly simple. It's the
expected start and end dates. This is especially important when a final date is imposed or a time is of the
essence, or window of opportunity constraint exists. Then there's the where. The work or deployment
sites of the final solution. The how is the collection of various approaches, including predictive or
adaptive methods that are recommended. These will vary depending on the type of the project. Okay, so
now you have to put this together, but a great way to do this is to use the elevator pitch strategy. You
should be able to state your vision in one or two statements. It has to be short. You could actually think
of it as a tweet. The idea is to concisely explain what the project is and why, and this vision should be
aligned across the teams. Everyone should be able to quickly and easily explain why the project exists
and what it's going to do. It's critical that the vision be reviewed frequently to make sure that the shared
vision is still understood by all. The vision should be concise and easy to understand. It should help
inspire the team members to achieve the desired goal.

Project planning: Project roadmap

Selecting transcript lines in this section will navigate to timestamp in the video

- It's good practice to deliver value more frequently. You especially know this if you use the Agile way of
working. But whether it's Agile, Waterfall, or something else, it helps to communicate when various
components of the project will be completed. This is especially important in very large projects or
programs. It's also important when we need to adapt our results to the changing priorities of the
organization. The best tool for this is a project roadmap. The roadmap is a chronological representation
of not only the expected delivery of features and functions, but also the dependencies between major
milestones and resource requirements. The roadmap is pretty high level, but it provides transparency.
Everyone can look at it and know exactly where we are and what's coming up next. Here's a way to
visualize it, and you could even do this in your office if you like. Hang a string horizontally across a
whiteboard. Draw in your milestones along the way. Then cut a car out of paper and clip it to the string.
The car represents the team's state of progress, as you move the car to align with the appropriate
milestones. This is not just helpful for keeping everyone aligned. It can also be fun for the teams. And
you don't have to use the car metaphor. I've seen people use animals instead. Just pick something that
makes the roadmap clear and useful and fun for the team. A roadmap is very similar to a project
schedule, where timeframes for major activities are shown. The schedule though, is used to plan and
develop the more detailed activities. Now, don't be intimidated. The roadmap is merely a
communication tool to show the expected delivery timeframes for benefits and results. The roadmap
can be developed initially as part of the high level planning efforts. Details are then added later as the
start time nears. The roadmap is a key technique used for adaptive projects. It enables the project to
adapt to changing organizational objectives, since we often can't predict the future. As we get closer to
the start time, things are more certain. So the flexibility of the roadmap allows us to reflect that.
Determining the appropriate level of detail for various stakeholders is especially important. This can
include the interim results or benefits that are being delivered as the project is being conducted. The
specific communications and level of detail are identified on the communication management plan,
which is developed jointly by the BA and the project manager. It always helps to know where we are,
where we've been, and where we're planning to go. The roadmap enables us to make it all happen.

Project planning: Responsibilities

Selecting transcript lines in this section will navigate to timestamp in the video

- When we think of projects the primary role that comes to mind is the project manager but the business
analyst will also share a fair amount of the responsibilities especially when you haven't worked together
before. It's very helpful to lay out who's in charge of what. So there are two components or scopes for a
project, the project scope and the product scope. The project scope includes all the deliverables and
efforts required to complete the project. These are the responsibilities of the project manager. Now, the
product scope refers to the features and functions that the opportunity or problem will include. These
are the responsibility of the business analyst. Now, many of the project activities are jointly done by both
the PM and BA. These include the identification and analysis of different stakeholders and planning the
activities for the project manager, the business analyst, and other team members. Now it's the job of the
business analyst to provide the project manager with two things. First, a list of activities needed to elicit,
analyze and evaluate requirements. Also, the activities for tracing, verifying and validating those
requirements. The business analyst then takes these two components to develop the business analysis
plan, which is a fundamental part of the overall project management plan. So the business analyst makes
sure the business analysis plan contains a few things, the needed activities to be done on the project,
and the business analysis deliverables that might be required. Now, both the activities and deliverables
are highly dependent on the project approach being used. There'll be times when you use what we'd call
a more adaptive approach. In this case, the responsibilities of the business analyst are often fulfilled
before release or iteration planning. One of the biggest duties of the BA here is to get a clear
understanding of the requirements and the exceptions from the stakeholder or product owner. Formal
documentation here is minimal but pay close attention to this step. Only those requirements that have
been initially prioritized and analyzed are to be considered because we have to minimize the time spent
on areas that do not provide as much value to the organization. Once the requirements have been
identified, the BA fits them into the requirements baseline or release iteration backlog. It's at this point
that you start using the traceability matrix or equivalent adaptive tracking method like a con bond board
or task board. This will be the key tool used by the BA to ensure that all requirements are completed and
approved. So you can see there's a good amount of work on the part of the BA that goes into the
planning but it's all worth it. The role of the BA is to make sure that the project manager and the project
team are fully aware.

Requirement types

Requirements come in all shapes and forms, but don't let that confuse you. In a nutshell, requirements
are what we need to do, they're what we need to do to satisfy the customer. But what the customer puts
in their list of requirements isn't necessarily what we'll eventually do. It's a wish list that gives us a
direction, and depending on where you work, or who the client is, these requirements come to us in
different formats. It's our job to interpret that list, and then determine the most appropriate way to fulfill
the customer's needs. So let's review the different types of requirements. There are six major categories.
First, the business requirements. They represent the higher level needs of the organization. Usually
business requirements are identified through the needs assessment process, as either issues or
opportunities. They're the reason why the project was selected and justified in the first place. The
stakeholder requirements describe the needs of individual stakeholders, or groups of stakeholders.
These requirements could come from within the organization, internally, or from customers, suppliers,
partners, or other external organizations. Solution requirements describe the features, functions, and
characteristics of the result. By result, I mean this is what the customer wants at the end of our work.
Solution requirements have two subcategories, functional and nonfunctional requirements. Functional
requirements describe what the user will be able to do, or what they'll receive when we're done. So this
could be something like an online shopping site being able to process orders or returns. This type of
requirement is just a high level example of the features to be included. Nonfunctional requirements on
the other hand, describe environment, or quality of service conditions. These can also include
technology requirements. An example might be the security requirements for your online store's credit
card processing. Another category, transition requirements. These include the activities who help
transition from the current state to the desired future state. These include training, documentation, and
possibly conversion and implementation requirements. Now the next set of requirements are interesting
because these are the responsibilities of the project manager, not the business analyst, but we still need
to know them to have a full picture of the process. I'm talking about project requirements. They're often
specified by either agreements or internal procedures. They include processes and deliverables to
ensure that the project is completed on time. These may include management reviews, status updates,
and performance reports. The last set of requirements identify the quality levels required. They're the
responsibility of either a quality analyst or a group, like quality assurance. These include the conditions
or capability used to assess conformance to the requirements. Regardless of the type of requirement, it's
important to define how requirements will be managed and tracked. To do this, you use the
requirements management plan, and the traceability matrix, but don't worry about that, we'll address
those in another video. What's important is managing and understanding requirements, because this
helps you control the scope. Once you finalize your requirements and scope boundaries, stick to them.
Requirements start out as an unreprioritized wishlist, so it's important to be clear about exactly which
ones have been selected. That way you're more likely to provide the greatest value.