Course details

 1h 25m
 Beginner
 Released: 5/29/2019
(3,231)
One of the main reasons given for unsuccessful project results is the lack of clear
understanding of stakeholder requirements. Business analysis helps to prevent
project failure by identifying and validating those requirements early on. Of course,
business analysis doesn’t stop with requirements; business analysts also recommend
solutions and facilitate their execution. This course provides an introduction to the
foundations of business analysis. It helps demystify the role of the business analyst
(BA), and outlines the knowledge and skills required to build a successful BA career.
Instructor Greta Blash also provides an in-depth review of the business analysis
process, from conducting a needs assessment and identifying stakeholders to
testing, validation, and release. Each lesson demonstrates why business analysis
works—and how you can use it to improve your organization.

Learning objectives
 Identify the role and skills of a business analyst.
 Determine the four steps of a needs assessment.
 Distinguish the type of stakeholder needed for a specific activity.
 Explain the role of the business analyst in the project planning stage.
 Differentiate between the three points of view for breaking down
requirements.
 Identify the factors for requirements in the release planning phase.

Prevent project failure with business analysis

Selecting transcript lines in this section will navigate to timestamp in
the video
- Currently, there aren't a whole lot of jobs requesting a business
analyst. And that's mostly because people don't understand what
business analysis or BA is. But business analysis is key to business
success. Many people do it, or benefit from it, without even
knowing what it is. So what exactly is business analysis or BA? BA is
understanding the business needs. It's using a specific set of tools
and techniques to uncover and analyze the needs or potential
opportunities of stakeholders or customers. It also can help
determine the details behind a user story, or those requirements
that were collected as part of the scope of a project. But it's so
much more than just collecting. It includes elicitation or drawing out
additional meaning. It also helps with the verification of those
requirements. This helps ensure they're properly understood, and
then they can be prioritized. So if you're a project manager, this
course will help you better determine the scope of your
projects. For many others, this course demystifies the role of the
business analyst. We'll go through techniques and tools of the
BA. But mostly, we'll show you why BA works and how you can use
it to improve your organization.
What is business analysis (BA)?
Selecting transcript lines in this section will navigate to timestamp in
the video
- More than likely, you've encountered business analysis or even
benefited from it. You just didn't know what it was called. Business
analysis or BA, is the process by which we identify business
needs, recommend relevant solutions, and understand
requirements. Now, this is very general and it might not be that
clear, but maybe looking at how a business analyst thinks will
help. Very simply, business analysts are well, amazing. Obviously,
I'm not biased. We are constantly observing and
questioning. People who end up in this position, have a naturally
inquisitive and detail oriented mind, and are always analyzing
everything. Their minds are constantly running through
questions about activities they observe. What's being done and
why? Is there a better way to do it? Are rules being followed? Or are
exceptions being made? Should these rules even exist or should
they be adapted to the current situation? Are we being as efficient
as possible? These questions and more are just a natural part of the
way a business analyst's mind works. The thing that's interesting
is that we tend learn what the rules are, and it drives us crazy when
the rules aren't being followed. But that frustration is where we
discover both problems and opportunities. Like, if you're on an
airplane and see that people aren't boarding in their proper
boarding groups. Well, you might ask, why are there boarding
groups in the first place? Why are the gate agents letting people
from group seven go in with group two? Or, what relationship do
the group numbers have with the assigned seats and why? We
could go on and on, but you see the point. Business analysis is all
about seeing those problems, restructuring them as
opportunities, and finding solutions.
BA industry definitions
Selecting transcript lines in this section will navigate to timestamp in
the video
- Analysis of business needs have been around for over three
decades. It's just been known by different names and done a little
differently by different individuals. Recently, we've seen standards
developed to support these activities. These activities are referred to
as business analysis. But depending on which standards you're
using, business analysis might look slightly different. Let's look at
some definitions from the two major groups that are setting these
current standards. You'll see that these groups have slightly
different definitions that highlight different emphasis of business
analysis. First, we look at the International Institute of Business
Analysis, otherwise known as IIBA. They 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 and 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 program or project. So, notice some key phrases
here. "Stakeholder requirements," and, "Facilitate the successful
implementation." 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. When you do business
analysis, we also say you're delivering a solution. So, what do we do
with all this information? Well, the takeaway is that business
analysis is defined in different ways, depending on the point of view
of the definer. But here's a stable definition that should work across
all contexts. Business analysis seeks to identify and understand
business needs and provide solutions to enable change.
What is the role of a business analyst?
Selecting transcript lines in this section will navigate to timestamp in
the video
- Let's look beyond the definitions to the individuals who perform
these activities, the business analyst. Both IIBA and PMI defined the
business analyst as any person who performs business analysis, no
matter what their job title or organizational role. This role also
varies based on a couple of different factors, the type of industry,
size of the organization, maturity of the organization in terms of
both project management and business analysis practices, as well as
the project life cycle approach and methodology. More important
than the role or position are the actual activities that they
perform. So regardless of an individual's position or role in the
organization, business analysts are focused on understanding the
current needs in relation to the overall strategic objectives and
goals of the organization, and then helping achieve these goals. A
lot of what they do comes down to helping with change. The role is
often different depending on the situation. The BA may be involved
when a new product is created or a current product is
enhanced. They can help solve a problem by understanding the
situation and helping propose a solution. Often their skills are used
to help project team members better understand the needs of the
customer. There are two organizations where you might find a
business analyst. First, in a business organization, or secondly, as a
key member of a project team. As part of the business
organization, the BA plays a role in helping craft strategic
objectives, setting the future direction of the organization. This
knowledge and understanding is then transferred to others who will
support these objectives through projects or programs. In other
organizations, the business analyst is on a project team. Their role is
to provide understanding of the solutions for the identified
problems or opportunities. Basically, the BA is the person that has
to explain the solution. They explain why and what actually is
involved. There's a number of ways these solutions can be
provided, changes to ongoing operations may be required, or a
continuous improvement initiative may need to be supported by a
project or a program. The role provided by a business analyst
continues to evolve. And that's really because they're so
valuable across so many different situations. The analytical skills of
the business analyst helps with several things. They're able to
understand and define problems or opportunities more
specifically. They see how these fit into the overall strategy of the
organization. They understand and explain the reasons why projects
were selected. An increasingly important role of the business
analyst is that of a change agent. Change is inevitable, but it's
hard. It's change from the current state to a desired future state. As
Mark Twain once said, "I'm in favor of progress, it's change I don't
like." By working closely with individuals at all levels within an
organization, the business analyst is able to understand how any
change may impact them, and therefore, they're more likely to
embrace it.
Business analyst skillset
Selecting transcript lines in this section will navigate to timestamp in
the video
`- So, what are the skill sets of a business analyst? What does it
really take to do this job? Are these skills different depending
on the role or position in the organization? Actually, there's a few
common skills that are needed regardless of the situation. First is
expert judgment. Because a business analyst is more
knowledgeable about the organization, industry or application
area, they can help identify and analyze alternative solutions for a
problem. This is often referred to as business acumen. This includes
the ability to provide previous knowledge, as well as understanding
the organization's culture and political environment. Another set of
key skills are referred to as analytical skills. These help when you're
reviewing various types of information. You're breaking it down into
smaller parts, which can be individually assessed. It also allows you
to look at information from different points of view. You can extract
the relevant from the trivial, draw possible conclusions and help
formulate decisions and solutions, or just help solve
problems. These skills include creative and critical thinking, system
thinking, learning skills and problem solving. A third critical skill
includes the ability to communicate in multiple ways, and to
multiple individuals. Communication may consume 80% or more of
a business analyst's time. As a business analyst, you have to
collaborate and work closely with lots of different individuals, so
you need communication skills such as facilitation, visual and
presentation skills, active listening, awareness of your nonverbal
behavior, writing skills. and though it might sound simple, you need
to be able to have a meaningful conversation with a person. Finally,
a business analyst must have the ability to work with others in a
leadership role. As an agent of change, it'll often fall to the business
analyst to communicate problems, solutions, and the rationale for
both to organizational leaders. While it might seem intimidating,
remember that the business analysts have the data on their
side, they've already assessed the situation and recommended a
solution. They can and should communicate confidently with
leaders at all levels. The skills required of a BA might seem like a tall
order, but really they all naturally fit together. The role of the
business analyst requires that you can operate between and within
departments. You have to be able to turn problems over and
over until you find the right approach. A keen investigative eye and
attention to detail drives the BA, and it's this natural
inquisitiveness that leads to solid analysis and appropriate solutions.
Needs assessment basics
Selecting transcript lines in this section will navigate to timestamp in
the video
- Have you ever thought about things you might like to do? Maybe
you couldn't easily find something in the garage, or a closet and
thought, maybe I should reorganize that area. Maybe you thought
about selling some of those items you found in the garage to
generate a little more income. Or maybe you see an upcoming date
to get your taxes done, or your driver's license renewed. These are
all possible needs that you mentally assess as part of your personal
life. Now, if we move these into situations within the
organization, we often discover that needs fall into one of three
categories, problems or possible improvements, opportunities or
new endeavors, or compliance requirements. Business analysis
includes the assessment of these three different types of business
needs. For those problems or improvement needs, it's important to
understand what the problem is, the impact that it has on the
organization, any potential solution to resolve the situation. New
opportunities allow an organization to grow and expand. Business
analysis helps with focusing those opportunities and providing the
content to support decisions in these areas. Obviously, every
organization and every individual have compliance requirements of
one type or another, that must be addressed. It's important, but you
need to know what's required, and especially what happens if those
requirements aren't met. Regardless of whether we're solving a
problem or supporting a potential opportunity, we need to go
through a few steps. First, we need to identify what is the actual
problem that needs to be solved, or the improvement that should
be made. In the case of an opportunity, what exactly are we trying
to pursue? We then need to do an assessment of the current
state. This helps us understand any factors that are causing the
problem. Now, we have to be careful though not to fall into a state
of analysis paralysis. That's when you keep analyzing and
analyzing without stopping to generate a recommendation. It's so
tempting to try and study the current situation, down to the nth
degree. But this can turn into a journey down a rabbit hole and lose
touch with the original purpose of the analysis. To stay on track, we
need to work with the business area or customer, to understand the
vision they have of that future state. We then determine what gaps
if any, exists between the current state and the future state. If these
gaps are fairly large and can't be made in a single step, we may
need to consider an incremental approach to arrive at that future
state. This way, we can provide interim solutions as the change is
able to be absorbed by the organization. Through this assessment,
we will clearly define the situation and the current impact, and then
begin to craft a solution.
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 Why's. 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 define 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 costs 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.
Classifying your stakeholders
Selecting transcript lines in this section will navigate to timestamp in
the video
- Not all stakeholders are created equal. Some have a vision and
some are deep down in the weeds. The first thing you need to ask
yourself is this. Who've I been given and who do I really need? Do
you have someone who knows the situation? But can they make
decisions? Or do you just have a warm body? We say this all the
time because too often we get whomever is available. No matter
how much you like your lineup of stakeholders, you've got to do a
proper assessment of who they are and how they're involved. One
of the most common ways to do this is to use the power interest
grid. Now this grid allows us to evaluate a stakeholder based on
their power or ability to affect the project and then their
interest, which we could say it's their perception of how the project
will affect them. Your low power, high interest people are the ones
that are working with the problem area. They're affected but don't
typically have the ability to make meaningful changes. Now your
high power people are the executives and upper management. They
usually are lower in interest and just want to know the bottom
line or final recommendations. But you'll need to continue to
double check. For example, I had an executive one time who gave
us his request at the beginning of the analysis. When we presented
him with the final recommendations, he was disappointed we hadn't
fulfilled all these other requests he had thought about in the
interim. Now he didn't tell us any of this. So how would we
know? But then again, we could've asked him more explicitly and
made the request period more clearly defined. Your low power, low
interest people are more often than not what you've got. These are
what we call the warm bodies. Unfortunately, they usually get
assigned because they don't have much else going on or
management just doesn't know what else to do with them. The
people in the high power and high interest grid are obviously going
to need a lot of attention. They can suggest changes as they
perceive the change that will affect them. We'll go over the nuances
of engagement with stakeholders in another video. At the end of
your assessment, you'll want to be able to identify if you have
stakeholders that give you what you need. Do they provide access
to resources? Do they have the decision making power? Can they
provide the data you need for analysis? Can they provide the
perspective and insight on the activities that are being
assessed? Can they help with the completion of the analysis and
required documentation? Understanding your stakeholders help
you identify where you might need to spend more time or
resources. It also helps you figure out how to engage with them. All
of this is part of an early but important step in determining your
business analysis activities that are required for success.
Engaging stakeholders
Selecting transcript lines in this section will navigate to timestamp in
the video
- The more involvement that stakeholders have with the work to
deliver the outcome, the better chance we have that they'll be
supportive of the result. I can't stress this enough. And I know that it
can be tiring. After all, managing stakeholders can be an entire job
in itself. It might even seem like you don't have much time for
business analysis with all the needs of your different
stakeholders. But you have to know that your work will go to
waste, if you don't have the support of the stakeholder. By
engaging them in the development of the solution, they often have
a better understanding of the why, this change is necessary. And
can help with the transition to the future state. If they do not
understand the necessity for the change, they may be more apt to
resist the final result. So, how do we engage with
stakeholders? Especially if we have so many, well, first, working with
stakeholders is referred to as engagement. We need to figure out
and constantly monitor, the most effective way to engage with all of
them. And each stakeholder or each group of stakeholders, will
require a customized engagement plan. It doesn't have to be
complicated, but it does have to be thoughtful. We're not the only
person who has to collaborate and communicate with these
individuals and groups. Project managers, as well as solution team
members also need to engage and collaborate. So what exactly do
we talk to stakeholders about? Some of the key engagements
involve the setting of goals, objectives, and scope boundaries. Later
in a project, stakeholders are involved in testing activities and
reviews. Let's talk about determining the most effective way to
communicate with stakeholders. This includes the format, content
and timing. Each stakeholder or group of stakeholders will have
specific needs and preferences. Format can be email, meetings,
phone calls. It refers to the medium used to send the message. The
content is another variable to consider. What type of information
will be shared? How much detail? Which details? Have a
conversation with your stakeholders to make sure you're on the
same page with their expectations. You'll also want to determine
the timeframe and frequency of communication. But this doesn't
mean that the stakeholder can order information from you like a
menu. We have to understand the reason that specific
information is required at that time, and what the expected result or
impact will be upon receipt. As the project progresses, we need to
continue monitoring, how we will keep the stakeholders
engaged. We'll always have new stakeholders joining the
project, while other stakeholders remove themselves. Continual
monitoring of the involvement of stakeholders is important. This
allows us to determine why involvement may have changed and
whether additional engagements are needed. Here's a final tip
that's always helped me. Figure out how much time you need for
individual stakeholders. Especially those that are executives. Then
pre-schedule them, for the times when you need them. Reserve
dates and times for meetings with the stakeholders. They're going
to be surprised by how much of their time you really need. You
need to continually remind them though, of their importance to the
result of the project. By the end of the project, you want to make
sure they feel their engagement was well worth the time spent.

Purpose of a business case

Selecting transcript lines in this section will navigate to timestamp in
the video
- So 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 a 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 value input to the initiative 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 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 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 business case
Selecting transcript lines in this section will navigate to timestamp in
the video
- 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 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.
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
can 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 take 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 had 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 kanban 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. 
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 take 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 had 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 kanban 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. 
Requirement types
Selecting transcript lines in this section will navigate to timestamp in
the video
- 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 wishlist 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 sub categories, 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 to
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
finalized your requirements and scope boundaries, stick to
them. Requirements start out as an unprioritized 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.
Requirements elicitation techniques
Selecting transcript lines in this section will navigate to timestamp in
the video
- There are lots of ways to do elicitation, and you'll want to
customize your strategy to each situation. Different
stakeholders mean different elicitation techniques. One common
technique uses structured or facilitated sessions. You have a
facilitator that guides the conversation of the participants, prompts
brainstorming, and makes sure that the session fulfills its
goal. Facilitated workshops are great for a couple of reasons. One,
they can be used throughout the project. It allows us to make the
elicitation process truly iterative. Two, you can bring cross-
functional participants together. Having diverse participants
naturally uncovers gaps, redundancies, needs and other important
information. Finally, having a facilitator means someone is there to
help with communication between stakeholders, leading to better
relationships and consensus. Interviews have been used for
years. There are basically three loose categories of interview
styles. Highly structured with predefined questions. Semi-structured
with some prepared questions, and follow-up on answers. Or
unstructured interviews where you allow the conversation to
develop naturally. These are most appropriate when confidential or
sensitive information is needed, or the information is needed from
high-level managers. You can do these face to face, over the
phone, video conferences, through email, or even have the person
record the responses into an audio file. In addition, we collect and
analyze existing documentation. A major focus of our analysis is to
ask why certain information is even there. The answer, because it's
always been done that way, is not a valid response. What I've often
done is have the stakeholders take the documentation of a
process, and literally circle what they use or don't. It can be a really
revealing process for them. And it's a quick way for me to get to the
heart of what matters and what doesn't. You could also try
shadowing people in their environment while performing their
duties. If you have a large number of stakeholders, use
questionnaires and surveys. Remember though that open-ended
questions obtain more detailed responses, but will require
additional time to consolidate. One word of caution here, the
process can get very lengthy. You want to be thorough, but don't
fall into analysis paralysis. Constrain yourself to two phases. One
initial elicitation during the needs-assessment activities. A second
discovery is done after the project has been initiated. It's an iterative
process. Okay, you have to choose your elicitation techniques. This
is what you should consider. The type of project and approach
used. Time and budget constraints. Number and location of
stakeholders. And requirement documentation type and detail
required. So, regardless of the technique you choose, elicitation
activities take up project resources. So, choose wisely so your time
spent appropriately defines the product's solution.
Requirements elicitation techniques
Selecting transcript lines in this section will navigate to timestamp in
the video
- There are lots of ways to do elicitation, and you'll want to
customize your strategy to each situation. Different
stakeholders mean different elicitation techniques. One common
technique uses structured or facilitated sessions. You have a
facilitator that guides the conversation of the participants, prompts
brainstorming, and makes sure that the session fulfills its
goal. Facilitated workshops are great for a couple of reasons. One,
they can be used throughout the project. It allows us to make the
elicitation process truly iterative. Two, you can bring cross-
functional participants together. Having diverse participants
naturally uncovers gaps, redundancies, needs and other important
information. Finally, having a facilitator means someone is there to
help with communication between stakeholders, leading to better
relationships and consensus. Interviews have been used for
years. There are basically three loose categories of interview
styles. Highly structured with predefined questions. Semi-structured
with some prepared questions, and follow-up on answers. Or
unstructured interviews where you allow the conversation to
develop naturally. These are most appropriate when confidential or
sensitive information is needed, or the information is needed from
high-level managers. You can do these face to face, over the
phone, video conferences, through email, or even have the person
record the responses into an audio file. In addition, we collect and
analyze existing documentation. A major focus of our analysis is to
ask why certain information is even there. The answer, because it's
always been done that way, is not a valid response. What I've often
done is have the stakeholders take the documentation of a
process, and literally circle what they use or don't. It can be a really
revealing process for them. And it's a quick way for me to get to the
heart of what matters and what doesn't. You could also try
shadowing people in their environment while performing their
duties. If you have a large number of stakeholders, use
questionnaires and surveys. Remember though that open-ended
questions obtain more detailed responses, but will require
additional time to consolidate. One word of caution here, the
process can get very lengthy. You want to be thorough, but don't
fall into analysis paralysis. Constrain yourself to two phases. One
initial elicitation during the needs-assessment activities. A second
discovery is done after the project has been initiated. It's an iterative
process. Okay, you have to choose your elicitation techniques. This
is what you should consider. The type of project and approach
used. Time and budget constraints. Number and location of
stakeholders. And requirement documentation type and detail
required. So, regardless of the technique you choose, elicitation
activities take up project resources. So, choose wisely so your time
spent appropriately defines the product's solution.
Requirements elicitation techniques
Selecting transcript lines in this section will navigate to timestamp in
the video
- There are lots of ways to do elicitation, and you'll want to
customize your strategy to each situation. Different
stakeholders mean different elicitation techniques. One common
technique uses structured or facilitated sessions. You have a
facilitator that guides the conversation of the participants, prompts
brainstorming, and makes sure that the session fulfills its
goal. Facilitated workshops are great for a couple of reasons. One,
they can be used throughout the project. It allows us to make the
elicitation process truly iterative. Two, you can bring cross-
functional participants together. Having diverse participants
naturally uncovers gaps, redundancies, needs and other important
information. Finally, having a facilitator means someone is there to
help with communication between stakeholders, leading to better
relationships and consensus. Interviews have been used for
years. There are basically three loose categories of interview
styles. Highly structured with predefined questions. Semi-structured
with some prepared questions, and follow-up on answers. Or
unstructured interviews where you allow the conversation to
develop naturally. These are most appropriate when confidential or
sensitive information is needed, or the information is needed from
high-level managers. You can do these face to face, over the
phone, video conferences, through email, or even have the person
record the responses into an audio file. In addition, we collect and
analyze existing documentation. A major focus of our analysis is to
ask why certain information is even there. The answer, because it's
always been done that way, is not a valid response. What I've often
done is have the stakeholders take the documentation of a
process, and literally circle what they use or don't. It can be a really
revealing process for them. And it's a quick way for me to get to the
heart of what matters and what doesn't. You could also try
shadowing people in their environment while performing their
duties. If you have a large number of stakeholders, use
questionnaires and surveys. Remember though that open-ended
questions obtain more detailed responses, but will require
additional time to consolidate. One word of caution here, the
process can get very lengthy. You want to be thorough, but don't
fall into analysis paralysis. Constrain yourself to two phases. One
initial elicitation during the needs-assessment activities. A second
discovery is done after the project has been initiated. It's an iterative
process. Okay, you have to choose your elicitation techniques. This
is what you should consider. The type of project and approach
used. Time and budget constraints. Number and location of
stakeholders. And requirement documentation type and detail
required. So, regardless of the technique you choose, elicitation
activities take up project resources. So, choose wisely so your time
spent appropriately defines the product's solution.
Traceability matrix and task board
Selecting transcript lines in this section will navigate to timestamp in
the video
- When I buy something online, I really liked that I can track the
package from its original warehouse, all the way to my
door. Similarly, I can follow my Uber or Lyft driver as they make
their way to my location. The reason this is so satisfying is that I can
predict when the value will be delivered, and I can also tell when the
planned arrival is disrupted. We track our packages, our rides, and
even our friends, wouldn't it make sense to do something similar for
expensive work projects? In developing your business analysis
plan, you have to decide how requirements will be traced to ensure
they're all delivered and approved. You'll do this by determining a
Traceability Approach and using a Traceability Matrix. The
Traceability Approach is a way of thinking about how requirements
are related and tracking them. The project team should be able to
trace a single requirement to its supporting objectives and other
related requirements. The Traceability Approach also allows for the
visibility of progress on individual requirements. It clearly exposes
obstacles that are preventing requirements from
progressing. Appropriate actions can then be taken to remove
those obstacles. The Traceability Matrix is how you use the
Traceability Approach to track your project. It's a tool you actually
use. You might have seen this before in the form of a task board, in
Scrum, or Kanban board. What you do is arrange a few
columns with titles that represent the status of the
requirements. Typically the columns are labeled, To do, In progress
and Done. Now, the In progress column could be further
subdivided to show phases of the organization's
methodology, including maybe analysis, design, development, tests,
etc. On these physical boards, the connections between
requirements and objectives are visualized by sticky notes and
move between defined columns. These are extraordinarily
helpful, but a Traceability Matrix is a digital document used to not
just visualize the progress, but to consolidate all of your
documentation in one place. You can understand the current
status of individual requirements and link to other important
documents. These may include use cases, analysis models, design
documents, test plans, cases and results, acceptance sign offs are
also often included. The more detailed Traceability Matrix often has
a space dedicated to linking high level requirements, also referred
to as features or epics, to smaller user stories. They can also connect
each requirement to the corresponding business and project
objectives. The Traceability Matrix should act as a single source to
connect all project requirement documentation. You can use the
matrix to assess the impact of changes to requirements and the
overall project scope. This assessment allows changes to be
addressed and quantified from a risk, cost or time perspective. As
new requirements are approved, they're added to the Traceability
Matrix. You trace them as they are implemented. Now, the amount
of detail you include is dependent on the size, complexity and
importance of the project. Also note that you can certainly have a
task board as well, but the Traceability Matrix acts as the central hub
for information. Use the Traceability Matrix as your primary tool for
tracking your efforts, improving communication and clarifying your
progress.
Change control
Selecting transcript lines in this section will navigate to timestamp in
the video
- Change happens all the time. It's always been this way, so don't
think that were stable good old times, but change today is
happening faster and more often. As the business analyst, it's your
job to be a gatekeeper of sorts. Rather than trying to stop
change, we need to embrace it. But that doesn't mean that we just
react to every request for change, but rather we need to have a
way to analyze the request and the possible impact. Then we can
make a decision to modify our current work or continue as
planned, deferring the change until a later time. Most organizations
have a process in place to handle changes. This includes a way to
receive and log all requests, regardless of the type or source of the
request. Those requests are then analyzed and the importance and
impact to the work in progress helps determine what the next steps
will be. This process is often documented in the requirements
management plan. For changes that have a major impact on the
work, the approval may need to be made by a group that is charged
with this responsibility. This group is often referred to as a change
control board, or CCB, or a steering committee. Now, not every
request should be reviewed by this group. You need to have an
understanding of which types of changes and impact levels can be
approved by business analysts, project managers or
sponsor. Another way that we can support this changing
environment is to shorten the work timeframe. Rather than trying to
decide everything for a large effort, we break the work into smaller
portions. It's easier to plan what to do for that small portion, and
then incorporate any needed changes into the next portion. Part of
the overall area of change also includes a plan for configuration
control. This pertains to the tracking of changes to documents or
processes via version control. It's important to make sure that when
changes are made, everyone is made aware of the change and that
the most recent version is being used. The business analyst has their
hands in a lot of different areas. They have the perspective to ask
the questions needed to assess the change. So don't take this task
lightly. You can have a big impact just by tracking changes.
Testing and verification
Selecting transcript lines in this section will navigate to timestamp in
the video
- There's a number of times when requirements must be
verified. We do this to make sure that we have a clear and complete
understanding. The initial verification of the requirements is
done through the continued collaboration with stakeholders. This
may be part of the initial needs assessment or the review of the
situation and solution statements. All of this is done to make
sure that the requirements properly represent the needs of the
stakeholders, and we're constantly verifying that we have it
right. We also need to make sure that we're able to provide the
needed detail for those individuals who are going to develop the
solutions. This includes making sure that the appropriate detail and
acceptance criteria has been gathered for each requirement. When
using a predictive approach, this verification is often performed as
part of a formal review of a requirement specification
document. For adaptive approaches, this verification is most often
done through collaborative conversations and possible modeling
activities between the stakeholder, the business analyst, and the
implementation team member. Once each requirement's been
developed, the result needs to be verified to ensure that it meets
the specifications provided. Various levels of testing are usually
performed to provide this verification. These procedures and tests
are often defined as part of the development methodology of the
organization or the project's quality management plan. It's often the
role of the business analyst to help plan those testing
activities, including identifying test scripts and test data. As the tests
are conducted, the traceability matrix is often used to record the
results of the testing activities as well as often linking the
documentation for the test script and data to each
requirement. Everybody agrees the testing is important, but it's
important to understand how much testing is required. This is often
addressed as part of the analysis of what is referred to as the cost of
quality. That process reviews the appropriate activities needed to
prevent or appraise conformance or non-conformance or
failure. We need to remember that the law of diminishing
return applies to testing activities. At some point, enough is
enough.
Validation
Selecting transcript lines in this section will navigate to timestamp in
the video
- The final step that each and every requirement must go through is
the actual validation or acceptance of the result. Now, verification is
when we check conformance to the specifications that were
provided. Validation on the other hand is the process where we
confirm that the result meets two things. One, the acceptance
criteria and two, the needs of the stakeholder. Creating acceptance
criteria at the appropriate level of detail is not easy for either the
business analyst or the stakeholder. Most methods encourage the
identification of the acceptance criteria as the requirement or user
story is being initially written. A more effective method of
understanding the criteria to be used for acceptance is through
continuous discussion and review between the business analyst, the
developer and the stakeholder as the result is being developed. A
tool often used to help this process is a responsibility matrix often
in a RACI format where the approving stakeholder can be
identified for each requirement. It's also useful to see if other
stakeholders should be included or consulted in the validation
process as well as those who need to be informed of the status of
the approval process. Too often when we get to this final approval
step, we realize that either the acceptance criteria was not sufficient
and well understood or in some cases actually missing. The
traceability matrix becomes a key tool to help ensure that all
requirements are completed and accepted. This is a really good
time to be picky. You want to make sure your requirements are in
good order. That way your efforts are more likely to find success.
Release planning
Selecting transcript lines in this section will navigate to timestamp in
the video
- All the hard work on the project culminates in the release. Now,
when I say release, I mean the product, service, result, or
solution you're delivering to the client. The release is the what and
the when, what you're delivering and when it is to be delivered. It's
the end of the development work, the piece of work that has been
accepted. Since this is such an important moment, it makes sense
that we take time to plan for it. Release planning begins long before
you're about ready to deliver the result. In fact, you could say that it
starts with the design of the roadmap. When you lay out your
roadmap, you're deciding on a very high level what will be delivered
when. You take these milestones to form a rough draft of the order
of your releases. The schedule and choice of releases will determine
how the achievement of those releases are accomplished. It affects
the selection of user stories, and the more detailed planning of
sprints. So it's important to understand the vision of the final
product. Ask yourself, can the result be delivered in stages? If so,
which stages can be delivered first? Also, you'll want to consider
your receiver. You could have a group that just asked for a
change, maybe accounts payable wants to do it in a new way, or
maybe it's an organizational strategy, such as moving things to the
cloud. The nature of the audience will affect how we release
things. For example, say you want to start selling your products to
people in France by the first of next year. Then, your release
planning would have to prioritize which changes come first and
which are the most important. So you have to ask, what does selling
in France look like? Is it all online? Do we have to have an office
there? Do we have a completely new branding and a new
site? What about GDPR, do we comply? You can't release everything
at once. We have to create a hierarchy of requirements that are
prioritized according to feasibility and value. The requirements get
chunked into releases. The items in the planned release are then
prioritized by the stakeholder and the team. This is where sprint
planning starts. If release planning sounds like high level sprint
planning, you'd be right, it's very similar. Sprint planning is more
concrete at a lower level and time boxed. Regardless of whether
you're doing a release or a sprint, prioritization is the most
important part of the process. I'll leave you with a common analogy
about priorities. You have a jar and some rocks, you need to fill the
jar. You have big rocks, small rocks, and sand. If you put the sand in
first, and then the small rocks, you probably won't have room for
the big rocks. But if you put the big rocks in first, then the small
rocks and then the sand, it's more than likely that you'll have room
for everything. That's what we want to do with our planning. We
want to make sure the big rocks get in the jar first. The big rocks are
those high priority requirements. The small rocks and sand, lower
priority. So bottom line, put the big rocks in first.
Transition planning
Selecting transcript lines in this section will navigate to timestamp in
the video
- Regardless of the final recipient, there's a number of decisions that
need to be made about what's going to be released. The transition
is where you, the stakeholder, and the team are handing the result
to the client. The transition plan is how we're actually going to put
this out. The release plan is the what, this is the how. How are we
going to place this within the organization? There might be training
involved, there might be data conversion, there might be a lot of
things. Some of your transition requirements might actually be built
into the release plan itself, like translating English quick start guides
to French. But you need a transition plan. Otherwise, you put
together a product and just throw it over the fence and say, "Good
luck". A transition plan helps ensure the success of your
product. Pilot programming could be built into your plan. This
enables the discovery of adjustments that may need to be done
before full deployment. This is very common for new
products. They're often introduced in a test market to gauge
responses and acceptance. Now you might have a software
application that replaces an existing one. You might need to have
both the old and the new running parallel for a period of time to
ensure that the results are correct. This is especially important in the
financial areas where full testing is not always possible. This
approach though requires additional effort to prepare the data for
both versions, as well as checking the results for
consistency. Another approach is risky but often the only one
possible, it's referred to as the big bang. This is where the old
method or result is totally replaced by the new. This requires
extensive planning and testing to make sure that everything
performs as planned. Usually in this case, there's no going
back. Regardless of the approach, you need to provide new or
updated training and documentation for the receiving
organization. Usually we train prior to finishing the project and then
we go away. The problem is if somebody gets hired a week
later, there's no training for them. So part of what we have to look
at is not just training as part of the transition, but also to provide for
training later. You might have to run train the trainer sessions to
make sure there are plenty of options for onboarding new
employees after you've left. When you think transition planning,
think change. For you, this is the end of a road of living with this
solution. It's not new to you anymore, so you might not be
sensitive as to how disruptive it's going to be for the recipients. So
try to put yourself in their shoes, anticipate the pain points and the
resistance. Transition planning can help you ease a lot of
frustration and set your solution up for success.
Implementation planning
Selecting transcript lines in this section will navigate to timestamp in
the video
- The project manager and the team are gone. They've moved on to
bigger and better things, leaving you behind to make sure that what
you did is actually going to be used. It falls upon the business
analyst to work directly with the receiving organization to make
sure the solution is used and meets the original
expectations. Especially when there's a substantial change to the
way they've been doing things before, it's going to be hard. All of
our work was meant to move the organization from a current state
to a desired future state. But even when that future state was
desired, planned, tested, and approved, it can still meet with
resistance. The acceptance of the change needs to be continually
evaluated. At this point as a business analyst, I'm probably going to
do more shadowing. This is so I can see if and how the result is
being implemented. I'm identifying things that need to be fixed and
possible future requirements. The solution we put in may have been
good, but often it only fixes a portion of the problem. It's the job of
the business analyst to identify that need and propose it for future
enhancement. The support for the actual implementation of the
result often includes additional funds and resources. Sometimes
you've got to have a support team. For example, if you put in a new
piece of software, you'll need a help desk or similar resources to
support it. This could be either internal to the organization or done
by an external group. This is a typical situation for software
applications. This support group may not only require
additional and ongoing funding, but often require specific
documentation and training. The business analyst sets up the
support team and provides them with information about the
solution. Just like you supplied the development team with
information, now you're working with the support team. The change
might also require individual coaching and support by either key
business people or the business analyst. Regardless how the
ongoing support is delivered, there's always a need to track the
result of the changes made to help determine if the expected
results are being delivered. The process of tracking and
reporting should've been included in any transition and
implementation planning effort. We always need to remember that
after resources have been consumed to deliver the new result or
solution, we can't go from the as is or current state to the to be or
future state, only to return to the as was.
Next steps
Selecting transcript lines in this section will navigate to timestamp in
the video
- Learning to dive deeper into the details behind requests is an
important skill for any worker. Having learned the foundations of
business analysis, I hope you want to explore further. Part of doing
business analysis means constantly learning and analyzing, but your
work doesn't stop at the responsibilities of your role. You should
always make it a habit of always looking for ways to hone your
skills. There are two main groups that support business analysis with
standards, documents, and user groups. These are the International
Institute for Business Analysis, or IIBA, or the Project Management
Institute, or PMI. There are also many articles and blogs
written about the various areas which are part of business analysis. I
hope you check out some of mine, which I post frequently on
LinkedIn. And while you're on LinkedIn, connect with me. Thank you
for watching this course. I know business analysis isn't the easiest
topic. I also know not all organizations appreciate the hard work
that goes into being a BA. But trust in the process, and know that
your diligence will produce a successful result.