Introduction to Business Analysis

Course Introduction
Hello and welcome. I'm Casey Ayers and this is Introduction to Business Analysis and Needs
Assessment. In this course we're going to seek to answer some of the key questions you might
have around business analysis and needs assessment, and help to get you on track with
understanding some of the core principles behind this emerging field, which is increasingly
important, especially in larger enterprise environments, and in project management sort of
capacities where you might be working on things like developing new software applications or
discovering what the needs of your business or client might be in regards to a new project that
should take place. Some of the key questions that we're going to seek to answer include what is
business analysis? What is it that we seek to accomplish through these sort of tasks? Furthermore,
who is it that conducts business analysis? What type of titles might be associated or other formal
capacities might be aligned with some of the roles and responsibilities of a business analyst. What
skills do you need to have in order to succeed as a business analyst or in conducting business
analysis sort of tasks? Also, how does business analysis relate to projects? How can it help us to be
more successful in the way that we plan our projects and address needs, either within our own
company for something we're trying to develop or for a client if we are working alongside a partner
of some sort. Throughout the course we're going to first introduce business analysis at a high level,
and seek to define it for you, and give you the answers to some of those questions. After that we'll
look at identifying problems and opportunities from the business analysts perspective. Then, we'll
look at how to compare capabilities that your organization or your team might already have to the
requirements that you've helped to figure out from the work that we've done in identifying those
problems and opportunities. After that we'll seek to recommend action. How can we move forward
based on those problems or opportunities we identified, based on our new understanding of what it
is that we can accomplish, and what we need in order to meet those problems or opportunities with
a solution, and what's our best path forward to get there? This is the first in a five course series
helping you learn more about business analysis. In this course we'll introduce some of these key
topics. In course two we'll go onto Planning Business Analysis and show you the formal way that
you can bring more stakeholders into the fold, get the information that you need when we move onto
course three, which is Discovering Information Through Elicitation. This is the process of working
with stakeholders and subject matter experts to better understand what the problem or opportunity
might be, and how it can be best addressed. In course four we'll look at Conducting Business
Analysis and Developing Requirements, diving deeper than we will in this course when it comes to
these sort of topics. Finally, in course five we'll look at Monitoring Requirements and Evaluating
Business Analysis Solutions. Here we want to make sure that everything that we've done so far,
when it moves into a project environment or some other sort of initiative that results in action, that
that action aligns with the requirements that we've laid out, and that those requirements remain
aligned with our business goals and objectives. Furthermore, we'll seek to evaluate that solution
once it's been completed to make sure that we've in fact solved the problem or addressed the
opportunity that we set out to address in the first place. All of these courses will be helpful for those
who are considering business analyst certifications, such as the CBAP or the PMI-PBA, among
others. Furthermore, for those seeking continuous education credits for other certifications like the
PMP, these courses can be part of your extended learning path, helping you to reach those
recertification requirements that you have to meet every three years, so without further ado let's
jump right into the subject matter. In this module we're going to look at defining business analysis,
help to answer some of those questions that we mentioned right at the top. Then we're going to look
at the Business Analyst's Toolkit, some of the different traits, and attributes, and skillsets that you
need to have in order to succeed as a business analyst. Then we'll look at the business Lifecycle.
The responsibilities of a business analyst change over time, and we'll look at how that shifts
throughout the course of developing a proposal, and identifying what the businesses strengths might
be, and so forth. Finally, we'll look at defining requirements, how we'll seek to attack either that
problem or leverage that opportunity in a formal method that includes a set of steps of things that we
seek to accomplish. Let's get started.
Defining Business Analysis
Let's begin taking a closer look at business analysis and what it is that we seek to accomplish, what
process we follow, and so on. First, as a business analyst we begin by determining a problem and
identifying a business need. Often times this may already be done in some capacity for us. Perhaps
we have noticed that there's a problem or it's been brought to our attention by someone who might
eventually become a project sponsor or someone who is simply an upper level executive within an
organization. They've noted that there's an issue, there's been a call for action to take place, but
before we can begin we need a better idea of what precisely is going wrong or, in a more positive
sense, what opportunity might be available for us to leverage. In this case, we're going to compare
our business goals and objectives to the current situation that we see. In doing so we can help to
identify where a gap might exist between what we want to accomplish and what we are
accomplishing. Then we can dive deeper into that problem using tools like root cause analysis to try
and get past the symptoms that we might see on the surface to better understand the underlying
issue, so that we don't just patch it, but instead we fix the issue for good. From there we want to
identify and recommend viable solutions that can meet these needs that we've identified. During this
process we're going to seek to speak with different stakeholders and subject matter experts, those
who have a good idea of what it is that needs to be accomplished, and how it might be able to be
accomplished in order to solve this problem or meet this opportunity. In the next stage we're going to
elicit, document, and manage these stakeholder requirements in order to meet our business and
project objectives, so first we were able to come up with some of the potential viable solutions, and
now we incorporate even more of that feedback into the mix to make sure that the solution that we
recommend and move forward with meets the requirements of all of those people involved. This can
include people who have to work directly with whatever the problem might be or those who might be
impacted by its solution, either while it's being implemented or by its end result. Once we've come to
a consensus, and we've been able to create a business case that proves that we should move
forward with the solution, we can recommend this solution, and then help to facilitate implementation
of this product service or end result of whatever the program or project is that might be deployed as
a result of the business analysis that we've done. After all, at the end of business analysis we
haven't actually solved the problem, but rather we've set the stage. We built a foundation on which a
new initiative can begin to take place. A project can be chartered based on information first surfaced
during business analysis. That project can then move forward to fix the underlying problem, and to
help address those underlying needs that were developed and identified during business analysis
processes. Now business analysis isn't necessarily only conducted by someone as a business
analyst. Of course, this can be the case, and there are full time business analysists, especially in
many larger organizations today. These full time business analysts are exclusively focused on areas
like discovery and analysis of information. Investigating stakeholder needs, interviewing others, and
seeking their feedback, gaining an understanding of how the organization as a whole functions, and
how different processes might interrelate and impact one another. Also, determining underlying
issues and identifying opportunities. In many cases business analysts might be the first ones to
identify a problem or opportunity in the first place. It might not come from a potential project sponsor
or some sort of upper level executive or someone on the front lines who's noticed that an issue
might be impacting their work. Instead, the business analyst might be the first one to discover that
this potential opportunity or area to address an underlying problem might exist. However, there are
also a multitude of different part time business analysts. Often times these sort of roles are
conducted in addition to other responsibilities. In these cases the business analyst might not be
called a business analyst. They might be called a business architect, a business systems analyst,
an enterprise analyst, systems analyst, process analyst, product manager, project manager or
requirements engineer, among other titles. In each of these cases we're seeking to perhaps build
processes or have a better understanding of how the business works or could work better. In the
case of a product or project manager they're directly responsible for making sure that certain
objectives are completed, and certain end results come about because of that work. In these cases
they might also be able to identify these needs and incorporate it into the product or the project that
they're helping to manage, so that those needs can be addressed. In any case, the business analyst
job is actually quite simple, and it gives us some understanding of the many different types of people
that can conduct these sort of tasks. What a Business Analyst seeks to do at a fundamental level, is
to first understand what the present state is of either the organization as a whole or a certain subset
that might be impacted by this problem or opportunity. They also need to be able to define the
desired future state, not only where are we, but where do we want to go, and why do we want to go
there? Third, we then have to determine how technique get there. Tying these two together, having
and understanding of what capabilities exist now, what capabilities need to exist in the future in
order for us to get to that desired future state, and provide recommendations on the roadmap that
we can follow in order to get from here to there.

The Business Analyst's Toolkit: Analytical Skills

What tools and traits are most valuable when it comes to the work of business analysis? There are
three main categories that we should look at, analytical, technical, and interpersonal. First, let's take
a closer look at analytical traits and how the apply to understanding the present state, the first step
in our role as a business analyst. The first query we need to consider is what information is valuable
to gather and analyze. Here we need to know how to separate the wheat from the chaff. In the data
that we collect, in the conversations that we have with stakeholders, in the different documents that
we might analyze and read over in order to understand the present state of an issue. What
information here helps us to get to the root cause of the issue that we're trying to identify or address,
and what information is kind of extraneous and not very helpful. It just gets in the way or distracts us
from that root heart of the matter that we're trying to get to. How do we analyze the information that
we've gathered in order to gain the most valuable understanding from this information? What kind of
analysis would be considered most effective and helpful for us to undertake, and how to do we then
further contextualize that information once it's been analyzed? How are we able to make sure that
we truly understand the results of the analysis that we accomplish in comparison to other data
points that might also be important. For example, we might see that a certain process is running
270% behind schedule and we might think, well there's the problem, we've identified the root cause.
Of course, if it turns out that this is only a 10 second process within a larger framework that might
take several hours of work to accomplish, then maybe that's not actually the bottleneck we're
looking for, so we have to be able to put that analysis in the context along with all of the information
that we gather and deem valuable toward our fundamental understanding. When it comes to
defining the desired future state we have to think about what the optimal outcome might be given
the project or business objectives that we face. Now we may not be directly responsible for setting
many of these objectives, rather, our job is to help define how to get to those objectives, how to
complete them successfully. In other cases it may fall to us to help to define what these objectives
might be based on overriding business goals or overriding strategic philosophies that apply to the
entire company or to our product line or our portion of the overall enterprise. What evidence do we
have that this is indeed the optimal outcome based on those business objectives? Whether we've
set those objectives or not, we certainly want to make sure that whatever we recommend gets us
closer to those objectives, and that those objectives are in line with the overall strategic philosophy
of the enterprise. How can we ensure the proposed solution leads to the most optimal outcome?
Now only do we need to be certain that that is in fact where we want to go, but that the solution we
recommend can get us there. Further, how can we verify the solution remains aligned with business
objectives as it's developed and deployed. After all, things can change over time, and so we need
some fail safes in place or some different safeguards that can help us to understand along the way
and to verify that what we are developing remains in line with what we were seeking to accomplish
in the first place. Analytical skills can also be important in determining how we get from the present
to that desired future state. In this area we need to look at some key information, such as the
organization's current competencies. What are we good at right now? What do we have the
resources to accomplish? Furthermore, what competencies will be required to move us to that
desired future state? What do we need to get good at or what type of talent do we need to acquire?
What sort of resources do we need to have in place in order to meet that future state objective that
we're helping to set? Further, we also have to question whether the expected benefit of that future
state will exceed the expected cost given where we are right now, and where we need to get to.
After all, if we could simply snap our fingers and have a magical solution to a problem, then that
would be great. No one would stand in opposition of that, however, if we're going to get bogged
down from a strategic standpoint or if we're going to have to spend more money than we can
eventually save, if the return on the investment is not sound, then we may make a recommendation
that no action actually take place, and so we have to verify that that expected benefit will in fact
exceed the expected cost that we project. Key tools and skills within the analytical area include, as
you might expect, analytical skills such as the ability to think creatively, and to think critically, to be
objective, and to look at things from multiple viewpoints, to get the best understanding of where we
are, where we want to go, and how we can get there. We need to have a knowledge of our business
and our industry because these tasks will change so much in their particulars from project to project,
from topic to topic, and industry to industry. We need to have organizational skills, so that we can
compile and understand and harness all of this information that we bring into the fold here. If we
don't have some sort of way of keeping track of this information it will be very difficult for us to
analyze it and to leverage it in a way that can give us a better understanding. Finally, we also can
benefit from project management methodologies. Having an understanding of the project
management lifecycle, and different ways that projects can be accomplished, cannot only help us
with our miniature project of business analysis, but also in understanding how to put that analysis in
the context that a project manager will need in order to succeed in bringing that solution to life.

The Business Analyst's Toolkit: Technical Skills

Next, let's take a look at some of the technical skills that are required for effective business analysis.
When trying to understand the present state we have to question what the organizations current
technical capabilities might be. After all, we might have a strategic idea from our analytical research
of what it is we seek to accomplish what exact capabilities will we need in order to go from here to
there? To begin with, we have to understand what we can do right now because that'll give us a
better idea of what might be possible, what we'll need to change in order to get to that desired state,
and what that desired state might be. We need to think about what technical factors might be
responsible in whole or in part for the challenge or opportunity that we're facing. Is our problem one
of people in process or policy or is it one that's more directly related to the tools that our front line
workers use in order to accomplish whatever process might be in question. In that case, it may be
as simple as identifying a new technical solution, rather than as complicated or abstract as trying to
change something at an organizational or philosophical level. Third, what technical prowess do we
need to have in order to fully grasp the situation? As a business analyst we aren't expected to have
the same level of expertise as many of the subject matter experts and key stakeholders that we
might need to be able to speak with intelligently, however, we do need to have at least a baseline
understanding of our area in order to appreciate what these underlying technical challenges might
be. For example, if you're working within a software development area you want to at least have
some understanding of what might be a hard or easy problem to solve from a technical perspective.
Rather than simply waving your hands and saying, well you're smart, you can figure it out, we need
to have an appreciation for what they need to go through in order to bring that solution to life. Doing
so will help us ensure that our end solution is effective and efficient in meeting whatever problem or
opportunity is that we might be investigating. When it comes to defining the desired future state,
what changes and how technical capabilities are expected following completion of work, we need to
be able to speak about this at some level of detail, so that we have objectives that are clear and
measurable. We can't just say that we want our systems to be faster. We need to be able to say that
we expect to deploy this type of solution, using this sort of architecture, resulting in x percent
improvement, based on these sort of facts or evidence that lead us to believe that that will be
possible. Without that level of detail, even at this relatively early part of what might turn into an
extended project, we're simply not offering much value. We also need to think about what new
technical skills will or must be acquired by stakeholders along the way. It may turn out that while
attacking this problem or opportunity on its own might not be terribly cost effective, we're in fact
learning so many new things, both in terms of what our key stakeholders and other resources might
learn, that it's worth undertaking simply for that educational process. Think, for example, about how
much was learned by the aerospace community during the Apollo project sending men to the moon.
There were so many different challenges that had to be met, and so many things were learned that
didn't just apply directly to the space program, but also to a wide variety of industries that touched it
in some capacity during that initiative. These technical skills cascaded through a wide variety of
different areas, providing untold benefits into the future. Perhaps your project or the type of analysis
that you're looking at right now might lead to the same sort of cascading effect at a smaller flow, of
course, of new skills that can be valuable throughout the organization. If so, that can create some
additional inherent value that should be cataloged. When it comes to the determine how to get there
portion, bringing that past or that present into the future, we have to look at what capabilities need to
be developed in order to reach that future state. Now we did this when it came to the future state,
but now we need to put steps together that can get us from here to there. We need to think about
the skills that have to be developed in order to reach that desired state, and who needs to develop
those skills in order for that future state to be accomplished. Finally, as always, we need to also
question once again, whether the expected benefit exceeds the expected cost. If not it's entirely
possible we should not take any action at all. If so, then we need to continue pursuing this. The key
tools and skills from a technical perspective will vary widely based on the type of work that you are
undertaking. You're in a software development environment versus a building construction
environment versus an aerospace engineering environment. It might be very different in terms of the
tools and skills that you need to bring to the table or the type of underlying technical concepts that
you need to have an understanding of. However, having technical awareness and systems thinking
abilities will be useful in all endeavors, so always seek to understand the type of work that you're
analyzing. If nothing else, it'll provide you with the value context you need to do your job effectively.

The Business Analyst's Toolkit: Interpersonal Skills

Finally, in addition to the analytical and technical skills that we need to bring to the table,
interpersonal skills are absolutely vital to the business analyst's work. When it comes to
understanding the present state we need to think about how stakeholders view this issue. Is it
important to them? Is it a contentious topic, something in which there is vested interest on many
sides? If so, we could potentially be stepping into a minefield here of different ideas and different
agendas, and we need to keep that in mind, so that we can extract information from our sources as
objectively as possible, and try and create a solution around which consensus can be built, so that a
solution can eventually be implemented. If, after all, we propose something that might make sense
technically, but has no support from the organization, then our job will have effectively been
worthless. Instead, we need to consider all of these different interpersonal topics and stakeholder
views as well. To do so we have to first understand what stakeholders might be impacted by this
issue, and to what degree they are impacted. Furthermore, is this a positive or a negative impact?
Are they positively or negatively impacted by the present state, will they be by the future state or
might they be impacted by the work that needs to be accomplished to get us from here to there? All
of these different categories must be understood. We also need to think about how much support
exists for progress to be made in any capacity whatsoever. It could be that this is a relatively low
level priority for most people within the organization. If we think it should be of a higher priority, than
the onus will be on us to lobby, to some extent, to influence and to build support for a solution to
take place. To do so we'll need to be able to provide convincing evidence that can help to rally
others to our cause. We have to think about what cultural factors might relate to this issue as well.
Based on your organizations norms there may be certain different ways of doing things in place that
might be very difficult to impact or influence, even if they are one of the underlying causes of the
issue or preventing us from taking advantage of an opportunity. More positively, there might be
certain traits of the organization or personalities within it that can allow us to very aggressively tackle
this problem or to go after that opportunity in a big way. Understanding these cultural factors give us
an idea of what's possible and practical given the other people that we have to work with. Finally,
think again about that impact of the political climate within the organization. This needs to be kept in
mind when understanding the present state and what might shift or change what the responses
might be as we move from here to some future state. In that future we need to think about what will
be different, better or worse, and what skills and knowledge will have been created within the
organization? Here we can help to develop the skills of some of these stakeholders, perhaps make
their workplace a more fun or desirable place to be in, which can lead to better talent in the future.
We might make people more satisfied with their jobs, helping us to retain them in the long term or
we can help to reduce frustrations that lead to higher levels of productivity. All of these can be
positive outcomes for the organization and relate directly to the personal context of the problems or
opportunities we might be analyzing. In determining how to get there there are a number of
questions we should ask. First, what communication methods are most effective and efficient when
dealing with different stakeholders? How can we help to convey our message and extract
information from them that can be valuable? What cultural factors might require attention in the way
that we go about speaking with others and hopefully eliciting valuable information from them to help
us understand underlying root causes and propose business cases for solutions? How will issues be
managed and conflicts resolved as they emerge? Often times focus groups or different moderated
sessions might be used in order to gather more information about the needs of the organization. In
these cases there may be arguments, disagreements about what is wrong or what the best path
forward might be. How do we defuse these and help to ensure that the focus remains on finding a
solution that's best for everyone? What kind of influence must be used, can be used, and by whom,
and on whom? Do we have the authority from a formal sense to require stakeholders to speak with
us or provide us with information? In many cases we might not, which means we need to be
persuasive. We need to find ways to make them believe and understand and buy into the value of
what it is we're seeking to accomplish. After all, everyone perceives their own time as very valuable,
and if you need some of someone else's the onus is on you to convince them that it's worth their
time to give you some of theirs. Finally, what kind of team environments must be managed within
business analysis? This is true both during the analysis process when multiple individuals might
work together, and when it comes to the sort of solutions that we might propose. We need to
understand the project environments that might be practical, possible, and likely to succeed within
our organization, so that our recommendations can be effective. Key tools and skills that are
extremely useful in this regard include a wide variety of communication skills, such as conflict
resolution, an awareness of cultural differences, decision making skills, allowing us to move forward
in certain areas, chase leads or determine what factors might represent root causes, elicitation,
where we're able to get information for others and help them to share that information in an objective
and useful fashion, facilitation, where we help to facilitate discussions between others from which we
can cultivate and harvest much of this valuable information we need, leadership, as well as
negotiating skills, political awareness of the landscape around us and the type of responses we
might expect from different stakeholders and why, and presentation skills that can allow us to share
this information that we've been able to gather, the business case that we recommend in an
effective way that's viable to lead to action to the benefit of the organization as a whole.

The Business Analysis Lifecycle

By this point, hopefully you have a better understanding of what business analysis is, who conducts
business analysis, and the type of tools and traits that could be useful in being effective in
conducting business analysis. Now let's take a closer look at the formal business analysis life cycle,
the sequence of steps that you might be expected to take as a business analyst. First, we're going
to look at assessing needs, then we're going to plan business analysis. After that we'll seek to elicit
information, then development requirements. Followed by that, we'll want to monitor and control our
requirements, and then evaluate our solutions to see how successful they've been. When it comes
to assessing needs, which will be the focus of the rest of this course, we want to assess the current
environment and capabilities as it exists today. Then we want to define our desired environment and
capabilities. This gets back to our idea of understanding the present and defining of the future. Then,
we need to focus on how to get there, in other words, identifying the differences or gaps between
our current and desired states. Finally, we have to be able to develop a business case for action to
take place. Some sort of proposal that can help us get from here to there, and why that's worthwhile
of the business to do. In the Plan Business Analysis phase we're going analyze our stakeholders at
a deeper level, have a better understanding of how this problem or opportunity might impact them
presently, might in the future or might if we take action, and whether that impact could be positive or
negative in nature. We need to assess the environmental factors in which our work takes place right
now, and might if we take any action toward change in the future. What are our competitors doing,
what is the regulatory environment like, what are the geospatial or time factors that might be an
influence here as well? Is it possible for us to address the problem or opportunity in time, and at the
right location for an impact to be made or not? We have to develop a plan for our business analysis
work to take place with the philosophy of measure twice and cut once. We want to make sure that
all the work we do moving forward is effective, and by thinking things through now and better
scoping out what it is we seek to accomplish and the techniques we'll use, we can help ensure
success. Finally, we also will seek to define various work processes, how we'll go about the work of
business analysis moving forward. The next step in this is eliciting information from stakeholders.
We want to first identify our objectives, what information we seek to learn and gather from the
different stakeholders we'll speak with, and who should participate in these discussions. Then we
should determine what elicitation techniques we're going to use. Are moderated focus groups the
best method, one on one interviews, simply a phone call or some emails, reading through reports of
information that's already been documented from stakeholders in the past? The correct answers will
vary widely not only based on the type of analysis we're doing, but also depending on the type of
stakeholder and the type of information we'll seeking to obtain. Finally, we should develop our
questions and choose the formats we're going to use to ask them in order to maximize the amount
of useful information we're able to gather. From this point we'll use that information we've gathered,
the needs assessment we've done, and the planning work that we've already done at this point in
order to develop our formal requirements. Here we first analyze the results of our elicitation, all of
that information that we gathered from speaking with others. We want to compare these findings to
the needs that we assessed earlier on. Do these in fact match up and align with one another? We
thought this was the issue or we thought this was the opportunity, is that verified by the
conversations that we've had with others or do we need to go back and modify those assessed
needs to take into account this additional information? We should use models here to enhance our
requirement details when possible. These might be computer simulations in some cases, but in
many others it can be as simple as developing process flows and other visualizations that can give
us a better idea of how the businesses work is accomplished. We'll look at those in more detail later
in this course, then we need to specify and prioritize our requirements, providing any technical
details that might be necessary in order to measure whether those requirements have been met,
and then place them into a final order that can be useful when it comes to the project or initiative that
might follow this work. Then, we need to ensure that our requirements align with our needs. This is
important for us to circle back to time and again, but especially as we finish finalizing our
requirements we want to take a moment to go back and make sure that these requirements that
we've created are in fact in line with the strategic and philosophical needs of the business. When it
comes to monitoring and controlling our requirements this might actually be accomplished after
project work has already begun to take place, so we see some intersection here between the
planning and the analysis that might be accomplished by a business analyst early on, and the active
work to address a need that could take place later on down the road. Here we want to use
requirement traceability methods to make certain that we have accountable stakeholders for each of
the different requirements that need to be fulfilled. We should try to measure our requirements
performance here as well to make sure that we are in fact addressing the need we sought out to
address. We should continue to verify that our requirements match needs, and that the environment
around us hasn't changed or that we haven't learned something new from the work we've done so
far. That changes our perspective on the cost benefit of the work that we're doing or on whether, in
fact, our end result will meet these needs. We should also manage any changes to requirements
that need to be made based on these sort of findings that can really only be discovered after work is
underway. Finally, we need to evaluate our solutions once project work has been completed and
new initiatives begin to be rolled out to address needs or opportunities. Here we develop and select
key performance indicators that we can look to as measurements to define whether or not we're
being successful, and addressing those underlying needs. We should ensure that he solutions that
we come up with match those requirements, so any ways that we can measure that our end result
matches up and fulfills those requirements can be valuable here. We need to also verify that that
solution again, meets those underlying strategic needs that led to business analysis being
conducted in the first place. We need to ensure that the solution meets the acceptance criteria that's
been generated by different key stakeholders. Who needs to sign off, and how can we ensure that
the projects result will meet what their requirements and acceptance criteria might be? Then we
need to officially obtain signoff or release for work completed. Now often times all of these steps,
when it comes to monitoring, and controlling, and evaluating solutions, we'll intersect substantially
with the work of the project manager. If you happen to be both the business analyst on a part time
basis and the project basis on a more full time basis, then this is simply a confluence of similar
tasks. In other cases, if there is an independent project manager aside from you as a business
analyst, you'll need to collaborate with them in order to make sure that these steps are fulfilled to the
greater benefit of the whole while not treading too much into their territory as well, so this becomes
another area where those interpersonal skills become very important.

Developing Requirements
We've mentioned requirements several times so far because they are at the heart of the business
analysts' work. However, it's worth taking a moment to more formally define what we mean by
requirements, and to look at the type of requirements that might come into play when conducting
business analysis. When speaking about requirements we have to actually first start with needs.
Needs motivate stakeholders to take action. These are also referred to as business needs often
because they come from some sort of strategic viewpoint. They are something that is critical to the
heart of the companies objectives, something that's either impeding us from doing our work
effectively or represents an opportunity for the business to expand and be more successful in what
it's doing. Requirements are refined from these needs and outline what should be done about them,
so we may see that we need to be faster in the way that we fulfill shipments to customers, but that
doesn't actually give us any usable, actionable information. That's what requirements are for.
Solutions are particular methods for meeting these requirements and satisfying those underlying
needs behind requirements, and value is either the tangible or intangible worth that's created when
requirements are met using these solutions. With this in mind there's actually a hierarchy or
requirements that we can look at as well. At the top are business requirements, followed by
stakeholder requirements, and then underneath those, solution requirements. Business
requirements are strategic and broad in nature. They represent why action is being taken in the first
place. These are the underlying needs of the organization specified in some fashion that's
measurable. They may apply to either the enterprise as a whole, to a certain department within a
company or to a particular initiative that's taking place. Examples of business requirements would be
to increase top-line revenue by 10% next year, reduce customer hold times by an average of 3
minutes per call or introduce a new product in order to effectively compete with new competition
that's come into our market. Below business requirements are stakeholder requirements. These
requirements are expectations regarding the work that needs to be done, how this work will be
done, when this work will be done, the level of communication that will be provided, both in terms of
format and the detail regarding the work that's progressing, as well as the level of contribution that is
required or expected from each of the different stakeholders who might be involved. Examples of
stakeholder requirements tend to be a little bit more abstract than business requirements, but these
are the sort of things that we'll hear from stakeholders that we work with along the way. For
example, these features are most important to me, so focus on those. We need this completed
within a month. We need a solution that includes this supplier due to a contract or because we
simply prefer to work with them. Minimize the number of focus groups used, someone might say if
they want to make sure that time isn't spent in group settings, and that instead we can focus more
on getting information one on one, so as not to require entire teams to have down time for elicitation
purposes or I don't have much time to contribute, says the stakeholder who might not want to get
terribly involved, and probably isn't too invested in the overall outcome, perhaps even resistant to
any action taking place. These sort of requirements have to be worked through and understood.
Whatever the fundamental reason is behind each of these is important for us to analyze and
understand as analysts, so that we can meet these as best as we can while not undermining the
overall business requirements that we're seeking to achieve. Solution requirements are found one
more level down below stakeholder requirements. These are details regarding the solutions to
business requirements that we develop or propose. These indicate how solutions should be
developed and deployed. Within this area we find two different types of requirements, the first being
functional requirements. These describe the capabilities that are designed in order to meet both
stakeholder and business requirements, so here this is what our solution should do. On the other
hand, we also have non-functional requirements, which describe the situations and environments in
which the solution should be able to fulfill its job. Not only should our solution be able to accomplish
certain tasks, but it must be able to do so for a certain amount of time with a certain amount of
consistency or accuracy, with any certain geographic environment, within a certain climate or
without exceeding certain limits, whether they be technical, financial or otherwise. Examples of
functional requirements include systems needing to be able to accurately route 15, 000 packages
per hour, so think about us as a shipping fulfillment system. Perhaps this is one of the things that we
are seeking to deploy in order to meet a business need. This would be a firm example of a
requirement. Perhaps instead we're working on developing a new price generation software tool.
Here the solution needs to be able to generate price quotes within 10 seconds of a request being
placed. This will be another functional requirement. Ideas of nonfunctional requirements would
include the uptime for a solution needing to be at least 99. 999% following its deployment because
it's critical to a variety of different business applications. Another type of requirement might be the
ability for the system to operate in temperatures ranging from -20 to 110 degrees Fahrenheit. This
could be important depending on if perhaps a scientific tool or something that needs to be hardened
for outdoor use in a wide variety of different environments. Finally, there's also another type of
requirement aside from business, stakeholder, and solution. These are transition requirements,
which are those that apply while moving from the present to the future state. These are temporary in
nature, unlike the other requirement types, which are permanent to either the business as a whole,
the stakeholders who might be involved or the type of solution we're seeking to deploy because they
only apply while we are building out that solution. Examples might include the old and new ticketing
platforms operating in tandem until a trial period has ended successfully. In other words, we need to
have a smooth handoff from our old way of doing things to our new way of doing things to ensure no
disruption to our customers. Provisional results from newly automated systems might also need to
be verified by staff until enough data is collected to prove that it's working correctly.

Module Review
We've covered a lot of material in this module, so let's take a few moments to review. The heart of
business analysis is about identifying capabilities and needs. Once we've identified problems or
opportunities that we want to either address or leverage, we then seek to elicit input from
stakeholders to better understand and to benefit from their sort of subject matter expertise that might
play into the situation. Solutions might then be recommended and developed based on this input.
It's important though, to make sure that this work consistently aligns with our needs, so at every step
of the process we want to ask, do our requirements that we've developed line up with these needs?
Is the work that we're suggesting doing aligned with these needs? Is the work that we are doing
aligned with these needs, and so on. The work of business analysis may either be conducted on a
full or on a part time basis and by a variety of individuals with different titles. There aren't just
business analysts, there are also system analysts, business architecture analysts, engineering or
requirements analysts, product managers, project managers, and a wide variety of others who might
undertake business analysis as part of a broader role. The skills required to be effective in business
analysis fall into three key categories. The first, analytical skills, include creative thinking, critical
thinking, and organizational skills, the ability to think through problems and to understand at a logical
level how the business works, how we want it to work, and what needs to happen to get us from
here to there. Technical capabilities include skills that are directly related to the type of work or issue
that might be at hand. It's not enough for a business analysis to just have analytical skills or the
ability to work effectively with others. They also need to have some context on what it is that they're
trying to solve, what the need might be, what type of capabilities might exist within the organization,
what type of capabilities need to exist for certain solutions to be deployed, and what the work is
that's required to get from one place to the other. This requires a technical understanding of what's
easy, what's hard, what might take a short amount of time or long amount of time. These skills will
vary based on the industry and company and even division or problem that you're seeking to solve.
However, while you don't need to same level of understanding as a subject matter expert from
whom you might elicit information that's helpful in creating a solution, you do need to have enough
technical capability and acumen to be able to converse with those sort of subject matter experts
effectively. Interpersonal skills are also key here given how often business analysts are speaking
with others, be it key stakeholders, subject matter experts or even other business analysts who
might be working together with you on creating a solution and identifying needs. These skills include
communication skills, the ability to manage conflicts and different agendas and objectives that might
arise between stakeholders, how to navigate cultural factors that might be important, how to
facilitate conversations with others, either individually or as part of the group, leadership and
negotiating skills, which can be important in building consensus toward a solution, as well as political
awareness for understanding what's feasible not just from a technical level, but also from an
organizational and political level. Finally, we took a look at the hierarchy or requirements beginning
with business requirements, which are high-level goals and objectives for either the enterprise, a
subset of the organization or a certain initiative, project, functional area, division or so on. Here
we've refined needs into something measurable, something actionable. That's what a business
requirement is. Stakeholder requirements determine the context of the work based on power,
responsibility, and the interest of different parties that might be involved here. In order to meet those
business requirements, what context is required from our various key stakeholders, how do we do
the work, when, where, with what resources, and with what level of input? What do we need to
communicate, how often, and in what format? These are all examples of stakeholder requirements.
Finally, solution requirements detail how stakeholder and business requirements might be met. A
fourth, hidden, type of requirement are transition requirements, which are temporary in nature,
unlike these other ones, and are requirements that have to do with the work that will get us from the
present to the desired future state. In the next module we're going to look at identifying problems
and opportunities. We'll take a closer look at assessing business needs, as well as the role of
stakeholders and needs analysis. Then, we'll look at identifying and developing goals and
objectives, and how to rank these objectives, so that we'll have something concrete to work with
when we begin identifying our current capabilities, and those capabilities we'll need in order to meet
requirements. I'll look forward to seeing you then.

Identifying Problems & Opportunities

Module Introduction
Welcome back. In this module we're going to start by discussing how we assess business needs,
and what we need to keep in mind when we're doing so. Then we'll take a closer look at
stakeholders and their role within needs analysis. Who are some of the key stakeholders that should
be involved in almost any type of business analysis, and what type of information should we seek to
get from them, and how should we interact with them in order to be effective in our role? Then we'll
look at goals and objectives, and how these differ from the needs and requirements we spoke about
earlier, what the formal definitions of these might be, and how we can set effective objectives as part
of our work in business analysis in creating a proposal for action to be taken. Then, we'll look at
ranking objectives, how we can determine which ones are most important, and where we should
place our focus once work does begin on implementing a solution. Let's get started.

Assessing Business Needs

In the last module we summed up the work of business analysis using this visualization. Beginning
with understanding the present state and wanting to move forward to defining the desired future
state, part of what the business analyst also must do is determine how to get from that present state
to that future state. A big part of doing so is by conducting effective needs analysis. That's what
we're going to focus on here. As we also discussed, business needs are often problems or
opportunities that should be addressed, and from which we can spawn requirements that give us a
more specific idea of what it is we should seek to accomplish. However, these needs are very rarely
fully known at the outset. Even if you have a suspicion as a business analyst that there might be a
problem or an opportunity, and you begin to investigate this yourself or you're handed down an
order or a request from someone higher up or elsewhere within the organization asking you to look
more into what might be a problem or opportunity, when you receive this request or when you begin
an investigation on your own you'll almost certainly not know everything there is to know about the
root nature of this business need. You might see some of the symptoms, but you're unlikely to see
all of the root causes, unlikely to see the sort of cascading side effects that the problem or
opportunity could or does cause right now within the organization, and so on. It's up to the business
analysts to gather facts and conduct analysis in order to discover and further add detail to the
understanding of these needs. Furthermore, this assessment may be revisited as external factors
change, so this isn't a one and done process where we conclude that we now know everything there
is to know about this need, and then move forward focusing solely on what we're going to do about
it. Rather, much like we need to when it comes to a solution, we have to constantly check to make
sure that our understanding of these underlying factors doesn't need the change, as external factors
might influence it and cause it to actually move. Just like with solutions, it's important for us to
continually return to our assessment of what these business needs might be, and to make sure that
we still have a proper effective definition in place, even as factors might change, both within and
outside of the organization. Another way of looking at this visualization would be to say that we have
to conduct gap analysis here. When we speak about needs what we really means is that we have to
figure out where we are, where we want to go, and what it's going to take to get there. Gap analysis
is a popular term used to describe this understanding of where our present capabilities are versus
where they need to be in the future, and what we need to do in order to reconcile those too. By
conducting sufficient analysis, we yield a better understanding of what our business needs truly are
at a root level, and not just at that surface level. Our early focus should be on understanding the
situation fully rather than on trying to find a solution from the outset, so try to avoid the temptation
when you begin to assess needs of jumping to conclusions, and thinking that an easy solution is
possible. After all, it may be readily obvious to you at first that there's a particular solution that could
solve this problem, but wait, as we dive further down into the problem, as we learn more about it,
and about the type of effects it has elsewhere on the organization, we learn that it's actually much
more complex in nature than what we had originally anticipated, and as such, requires a more
comprehensive solution than what our quick fix would have been had we just moved ahead with it
right away. Moving forward with quick fixes have cost businesses time and money countless times
in the past, and so by taking the time to instead fully understand the issue before making a decision
on how to move forward, we end up in a better position long term. Insufficient analysis or focusing
on developing a solution too early will either result in a poor solution, one that doesn't cover all of the
ground it needs to or, in other cases, could result in overkill where we have spent more resources,
more time, more money, more of our focus as an organization toward addressing this problem than
would have been necessary. Sometimes a quick fix might not be good enough, but in other cases if
we had just spent a little longer we could have found that a smaller, more elegant solution could
have taken the place of a vast change that we might have implemented without a full understanding
of how precise the issue truly is. When we're conducting assessment we should also be certain to
include stakeholders in this process. This isn't something that a business analyst should do in a
vacuum. After all, we don't have all of the information we need to make intelligent recommendations
at the outset. Rather, we have to go to the sources, in this case, the people who would know best,
those who will be impacted by, those who might work around the issues related to or those with
subject matter expertise in the problem or opportunity that we're seeking to address.

Stakeholders & Needs Analysis

Because of the valuable role that they play with the needs analysis and business analysis at large,
it's worth taking a moment to define exactly who we're talking about when we say the word
stakeholders. Stakeholders can be represented by either individuals, groups or organizations. In
each case one thing definitely ties stakeholders to the analysis that we're conducting, there's a
project of some sort or a proposal that might be the result of our business analysis, if we indicate
that getting to that future state will require some work. When that's the case, if these stakeholders
either are affected by the project, can have an effect on the project or, perhaps most importantly,
perceive that they may be affected by the project, then they can be considered a stakeholder. Now
the perceived affect is very important here because in some cases stakeholders might not be
directly affected or might just barely be affected by the project itself. However, if they hold any
power, and if they're able to make their opinions known, they can have an impact on the way that
we conduct our business analysis, and on how any project would move forward. As such, we have
to treat them with the same respect and communicate with them at the same level as we would
others who would directly be affected by or would potentially have a direct impact on the project.
While all stakeholders are important, certain key stakeholders require additional attention. These
serve as primary sources of information during the needs assessment phase. Often times they're in
positions to know things that other stakeholders simply aren't, and that information can be essential
as we begin to construct our goals and determine how valid our objectives are as we try to specify
exactly what needs need to be filled. These key stakeholders are critical to the formation, approval
or execution of any work that will help to meet these objectives, so even if they don't have a direct
role to play in your business case that you're building a proposal for a project, they absolutely will
when it comes to the project itself, and we have to prepare accordingly. Some of the roles that key
stakeholders might play include sponsor, both of the business analysis that you might be
accomplishing now, and of the project that might be it result. These sponsors are responsible for the
overall project or action, as well as its initiation. The business analyst, if it's you, you would be
considered a key stakeholder as well. If there are other analysts who are involved here, then they
could also be considered key stakeholders due to the type of research and analysis that you and
other analysts are doing. Project managers would also be considered key stakeholders. After all,
they are going to be the ones responsible for planning and executing project work, potentially based
on the recommendations that business analysis yields. Benefactors could be considered those who
provide funding and support for the project. These could be upper level executives within the
organization that buy into the concept behind your proposal, but don't necessarily take a day to day
role in helping it come to fruition. Instead, they are the gatekeepers who provide the funding and the
resources needed for you to move forward alongside your project sponsor, and others who can
provide similar support. Beneficiaries are those who might stand to gain from the project or the
action, whereas the impacted are those who may be influenced in either neutral or negative ways by
either the outcome of our research, the ongoing work of a project or of the projects result. Users are
another key group of stakeholders. Who's going to use the solution or the result that we end up
proposing at the end of our business analysis? Regulators are also important, as they may require
work or our works result to fit within certain constraints. These regulators can be found internally for
those who are in charge of corporate policy, as well as externally in areas like government agencies,
which may require that work be done in certain fashions. Implementers can be considered those
who conduct project work directly in order to bring about our desired result. These would be the
frontline workers responsible for helping to fill that gap in our capabilities in order to reach that
desired future state. Finally, maintainers are those who would be responsible for supporting a
solution following its development. After all, most of the time business analysis results in a project,
but projects by their very nature are temporary. Once they've created their unique result the project
team is often wound down or moved on to another project, leaving behind those who will be
responsible for the day to day operations of its results. That's where these stakeholders come in,
and due to their long-term exposure and ownership over the solution, are particularly critical to
speak with early on in understanding needs. When grouping stakeholders it's often helpful to think
about them using what's known as a RACI chart. This stands for Responsible, Accountable,
Consult, and Inform. Those who are responsible are in charge of performing needs assessment
directly. Those who are accountable approve needs assessment activities taking place. Those who
consult will be asked for input due to insight regarding the issue at hand. They may be subject
matter experts, for example, even if they don't have any direct executive authority over the results of
our assessment, and those who need to be informed will receive the results of the needs
assessment, and perhaps have an opportunity to provide feedback on it in a later stage. This same
RACI chart can be applied to other areas of business analysis and project management as well, and
the exact roles of stakeholders may change over time. Let's look at an example. Here we see a
chart that includes our different responsibilities here. For the project sponsor they might be
accountable for identifying the problem or opportunity, and for assessing the current state of the
organization. However, they're not directly responsible for these activities, they just are the ones
who need to ensure that they are completed successfully. When it comes to recommending action
and preparing the business case they simply need to be informed of these steps. For a product
manager they may need to be consulted when it comes to identifying a problem or opportunity, but
they're not going to be held directly responsible for its outcome. They need to be informed about the
current state of the organization as we assess that, but they will be held accountable for
recommending actions in preparing the business case. This makes sense, as they'll be the ones
that we turn some of this work over to at a later stage after the business analysts complete their
work. Here we see that the business analyst is responsible across the board for all of these areas,
so even if they're not directly in charge of every facet of each of these steps, they are the ones who
have the ultimate responsibility for ensuring each of these steps are completed properly. In this
example the product development team should be consulted in each stage due to the obviously
close relationship they have to any necessary development. The mobile technical team here would
need to be consulted on all except the business case. Here they just need to be informed. They're
not going to be responsible for building it out directly, but they will be expected to help maintain the
solution after it's been completed, that's why they'll be consulted with on all of these earlier stages.
Finally, the project manager only needs to be consulted when it comes to recommending action,
and they only need to be informed of the business case, because it then becomes their
responsibility to take that business case, turn it into a project charter, along with the assistance of
the sponsor, and perhaps the business analyst, and then begin the plans for bringing that business
case's requirements and objectives to life.

Goals & Objectives

When we speak about goals and objectives what we are referring to are either positive traits that we
wish to maintain or other traits that we either wish to improve or change or traits that don't yet exist
that we'd like to develop. Some of the goals we should keep in mind when conducting needs
assessment may already be specified in organizational strategy documents. Chief among them
would be the organization's mission and vision statements, which are goals written large, a long
term look at how the entire organization is supposed to conduct itself, and what its reason for being
might be. These goals can vary based on internal factors, industry trends, and the market
environment. Sometimes our goals might be to simply get better from an internal standpoint. In other
cases it may be to combat a threat that another industry competitor poses to us or to address
market demand in an effective way. These goals can have varying levels of importance to the
organization at large. Some maybe very important, while others may be mostly important to certain
divisions or lines of business while not being critical to the organization's overall reason for being.
Furthermore, goals may have varying levels of support. While in theory all of these goals might be
important, and formerly endorsed by the organization, the reality is we tend to put our focus in
certain areas, and so understanding where key stakeholders have that focus can give us a better
idea of what needs might be perceived as most critical for us to address. Examples of potential
goals that could be found within a company would include improving uptime or service availability for
customers. Creating new features and capabilities within our products, addressing competitive
action effectively, launching a new product meant to compete in the market, for example. Improving
customer satisfaction or improving employee satisfaction if we're focused more internally. Growing
revenue and reducing costs is also one of the goals that we most often see within companies of any
type of work or industry. However, it's important to also understand the difference between goals
and objectives when we speak about the two. Goals are long term and ongoing in nature.
Objectives on the other had are short term, and have a defined time horizon. Goals are qualitative in
nature, whereas objectives should be measurable, quantitative in nature, something that we can
know if we have achieved or not. Goals are meant to be aspirational. We should always be trying to
database the very best for our customers. On the other hand, objectives are verifiable. When we say
we want to do the best for our customers what does that mean? How could we measure it, what
precisely do we expect of ourselves in order to hold that end of our ideal up properly? Goals may be
decomposed into objectives, and this can be very helpful because we can take these overriding,
lofty concepts and bring them down to earth, make them something more actionable for us. When it
comes to our requirements those are kind of like the rules we need to follow, but objectives, those
are the targets that we're trying to hit. Objectives may help to justify the business case for
undertaking new work because if that work helps us to fulfil some of these overall organizational
objects that might be in place, based on the goals that the organization has set, then that adds
value, and helps to strengthen the case for action. When we define objectives we should ensure that
they are in line with the principles and desires that we see in our goals. Further, they should be
rooted in our needs assessments, and in feedback obtained from stakeholders. We can look at
these objectives and make sure that they are in line with what we actually see on the ground,
especially when it comes to our unique problem or opportunity we're seeking to learn more about
and address. These objectives should be tested against the five-component check in order to gauge
their quality and usefulness. This test is known as SMART. To have a SMART objective we have
one that's in line with the principles and desires seen in our goals, but also goes a number of steps
further. First of all, it's Specific. It's clear, and leads to an observable outcome that we can verify. It's
Measurable. That means that we can test to make sure that we have indeed met that objective. It's
Achievable. That means that it's realistic in nature, especially within the context of the resources
expected to be available. This is where understanding the priority or different goals within the
organization can be important. We can't expect to be able to apply the full weight of our organization
towards solving this individual problem. That's why we need to understand how important it is, and
therefore, how likely it is to be given a top priority within the company, and what resources might be
made available accordingly, therefore, we'll have a better idea of whether or not it's an achievable
objective. The objectives should also be Relevant. In other words, it should align with the company's
vision, mission, and goals. If we come up with an objective that we can't directly tie back to a goal,
then it's not actually a very good objective at all. Finally, it should be Time-Bound in nature. In other
words, we expect it to be complete within a specific time frame that aligns with our business's
needs. Whereas goals are ongoing, objectives should have some sort of time period placed on them
in order for us to be able to best measure that progress. After all, if we say that we expect to reduce
costs by 10%, but we don't say when we expect to do that by, then that's not very helpful is it? Just
the same, if we say that we're going to launch a new product to combat the competition, well if we
don't say when, then by the time we eventually launch that product the rest of the market may have
passed us by, and therefore, the objective would no longer align with the businesses true and
ongoing needs. Let's take a look at a couple SMART objective examples. Here's the first one. We
want to improve our software's efficiency in order to reduce processing time by 10%. This will help
us to improve customer satisfaction over the next six months. Now this is a smart objective because
it fulfills all five of these requirements. In orange we see that it's specific. We want to improve
software efficiency in order to reduce processing time. It's measurable. We want to reduce that
processing time by 10% in order to improve the software's efficiency. We can also argue that this is
an achievable goal. We are not trying to reduce the processing time by 99%, in fact, 10% sounds
like it's probably a reasonable goal, and that's something that we could verify by speaking with key
stakeholders, and understanding the realities of our technical platform. It's relevant in nature
because doing this, reducing our processing time, will help us to improve customer satisfaction,
which here, we can assume is one of the organizations overall goals. Finally, it's also time-bound.
We have a deadline here. This needs to be accomplished within the next six months. Let's look at
another example. Here we want to reduce departmental materials waste by 5% per quarter for the
next year as part of the company's company-wide environmental initiative. Here again, we see that
it's specific in nature. We want to reduce departmental materials waste by a measurable amount of
5% per quarter, we consider this to be achievable based on the conversations we've had with key
stakeholders, and we see that this is relevant because it's part of the company's overall
environmental initiative, which indicates that it's one of the companies goals. Furthermore, it's also
time-bound in nature. We want to accomplish this at a rate of 5% per quarter for the next year, so
this is a specific amount of time in which this is meant to take place. Creating objectives that are
specific, measurable, achievable, relevant, and time-bound allows us to not only gain consensus
from stakeholders, but make a firmer, clearer, business case for why actions should be taken, and
leave us in a better position for success if we do begin to undertake action because now we'll know
what it means when we've succeeded.

Ranking Objectives
Just as different goals can have different priorities to the organization as a whole, different objectives
might be more or less important than others. When we look at these objectives there are four key
categories that we can use to help rank them. First among these are organizational and
environmental factors. Second are constraints on our available solutions. Third would be technology
and infrastructure, followed by the potential value that that objective can create. Let's look at each of
these a little more closely beginning with organizational and environmental factors. We have to
ask ourselves a number of questions, beginning with how well the objective aligns with
organizational goals. It's possible that we have an objective that somewhat serves an organizational
goal, whereas we have another that's directly in line with what the organization's goals are. In that
case, well the one that fits the goal better would be the objective worthy of higher priority. However,
it's more complicated than that. We also need to consider what stakeholders may support the
completion of the objective, and which may resist its completion. In certain cases an objective might
be, in our opinion, directly in line with the organization's goals. However, we may know that it simply
doesn't have the political support necessary within the organization to move forward. In that case,
the pragmatic solution is to put a little less emphasis on that one, and a little more on the one that's
more likely to find success. After all, even if it's a great objective, if we had no chance of successfully
completing it due to resistance from within, then it's not actually going to have any benefit for us at
all. Further, we should also consider what market conditions may either help or hinder meeting this
objective. What are our competitors doing? What's the regulatory environment like? What about our
customers, and how are their preferences shifting over time? All of these factors should be
considered. Next are constraints on our available solutions. First, we should look a little more
closely at those legal and regulatory hurdles in particular, and we should look at how objectives can
be impacted by organizational policies and procedures. If they're not impacted directly by some sort
of external force, such as regulatory restrictions, perhaps our own organization has policies and
procedures in place that would either help or hinder our ability to complete this objective
successfully. Third, which objectives are the most practical for us to complete given the
organizational resources, talent, and focus that's liable to be granted to the eventual project team
responsible for taking this objective and completing it. This goes back to a lot of those cultural
questions regarding where support and resistance might come from within the organization. We
have to be smart about how we move forward, being certain to build consensus in the way that we
accomplish these objectives, so that we can have the most positive impact on the organization as a
whole. When it comes to technology and infrastructure what IT infrastructure or other types of
infrastructure are going to be required in order to complete the objectives? Further, how much of this
is already in place? This is another area where we look at where we currently are and where we
need to be, and can complete some gap analysis accordingly. We should also consider how difficult,
costly, and time consuming it'll be in order to develop any of that necessary infrastructure not
already in place. It could be that we have the ability to complete an object if we completely overhaul
our internal infrastructure, but the support to do so is simply not there. The amount of time it will take
to complete that overhaul means that we'll likely miss the opportunity that we're trying to chase, and
the amount of value that we create would be less than the cost that it would take in order to
complete all of this new overhaul of our infrastructure, and as such, perhaps it's not a very good
objective after all. On the other hand, even if an objective has a relatively small benefit, if it has
genuine support within the organization, and can be accomplished within the existing confines of the
company's infrastructure and technological environment, then perhaps it is worth pursuing
because the cost to us to do so is so little. This all leads inevitably to Potential Value. What's the
net benefit that can be expected from completing the objecting, not just the amount of benefit that
we expect, but the amount of benefit less the cost and labor and expense when it comes not only to
money, but also focus and strategic resources that were required in order to complete the objective.
How long will it take us to earn back out investment? Even if the payoff could be huge, if it's going to
take too long it might not be in the best interest of the company. On the other hand, even if the
payoff's relatively small, if it's an easy win for us, then it might be worth accomplishing because the
amount of resources required would be very small compared to that value. Does this objective offer
a greater return on investment than other options? It could be that there are alternatives to the
objective that we are looking at an analyzing, and by pursuing those objectives instead we can
lineup with the organizations goals just as well while unlocking additional value that wouldn't be
possible through the first objectives. Finally, does the alignment of the objective with the
organizations goals somehow result in a higher value than the objective in a vacuum might
otherwise indicate? This goes back to the example we used earlier when speaking about the Apollo
program and NASA and all of the external benefit and cascading positive elements that came out of
the research and development done as part of that program. Here we can see the same sort of
thing where the objective itself might only directly result in a certain amount of value, but the amount
of value created by aligning perfectly with the organizations goals might be much higher. For
example, if we look at a new recycling initiative for the company it might actually be a loss leader for
us. Might be an area where we don't make nearly as much money on our material collections as we
spend making sure that recycling is taking place accordingly. However, if an organizational goal for
us is to be environmentally friendly, then it could well be worth the cost because it's something that
we believe in, and it's an expense that goes directly toward one of our organizations strategic goals.
When looking at these four areas and others to consider when ranking objectives, we can turn to a
useful tool known as SWOT Analysis. Our organizational goals and objectives are not always clearly
defined, especially at the outset, and SWOT analysis can not only help us in forming these goals
and objectives, but also in collecting insight from stakeholders that can help us to better gauge
which objectives might be those most worth pursuing. If you don't know already, SWOT and TOWS
refers to strengths, weaknesses, opportunities, and threats, and it often is filled out using a
visualized square pattern as you see on the left side of the screen. Beginning with strengths, which,
of course, are ways the organization is well positioned to solve problems or leverage opportunities,
examples might be a high level of customer loyalty already in place, favorable component cost
contracts, and a talented and committed staff. On the other hand, weaknesses are ways in which
the organization is not well positioned to solve problems or take advantage of opportunities. Often
time we may develop objectives that are directly targeted at either improving or eliminating entirely
these areas of weakness. Examples of potential weaknesses include low levels of customer
satisfaction, long lead-times on new development projects or lack of internal expertise within areas
identified as important by the organization. Opportunities are externally-focused in nature, and can
also include not only leveraging opportunities for positive benefits, but mitigating any problems and
helping to eliminate any issues and negative factors that might arise. Examples of potential
opportunities include new market areas that might be seen as ripe for development, seeing that
upgraded technology and processes could result in increased productivity and reduced costs, and
discovering that unserved customer needs exist that the organization could help tackle, and
potentially benefit from. Threats are also externally focused in nature, but are any factors that may
stymie our success or completion of objectives. Examples of this include competitors introducing
new product lines, new laws that require changes to our current business practices, or any
shortages in supplies for necessary components. Generally speaking, our objectives are created
based on opportunities and threats because objectives tend to be more externally focused in nature.
We're responding to something that we see outside in the market. In a way of thinking, this is even
true when it comes to internal objectives that we might have because we're seeking other areas
within our company where improvement can be made. These objectives are created based on those
opportunities of threats, but they're designed specifically and ranked based on the strengths and
weaknesses that are exhibited within the organization. In some cases, we may seek to capitalize on
objectives where our strengths are high. In others, it may be a high objective precisely because it's
an area of weakness for us, and one that we can no longer tolerate. SWOT analysis helps to
provide greater context to our needs analysis process, and it can also be helpful in identifying root
causes, which will be one of the key topics in our next module.

Module Review
Let's take a brief moment to review. Business needs may spawn from perceived problems or
opportunities, however, it's very rare for them to be fully understood when first identified. Rather,
helping to gather more information on these needs in order to refine them into objectives or
actionable pieces of information is one of the early and most important parts of business analysis.
These objectives can later be very useful in forming project charters and other foundational
documents that can lead to action taking place. Objectives spawn directly out of goals, which are
long term and qualitative in nature. These can be things like the mission or vision statements of a
company. They're some of the overriding principles and philosophies that guide us, but they're not
very specific, and they're not time-bound either. Objectives, on the other hand, are short-term and
measurable in nature. These have an end, whereas goals can often go on for a very long time.
Smart objectives are the type that we should try to create during our work and needs assessment.
SMART means specific, measurable, achievable, relevant, and time-bound. Objectives that are able
to properly fill all five of these traits are the ones the most likely align best with our goals and
organizational needs. In forming our goals and objectives and in understanding our business needs
we're going to have to engage stakeholders. Stakeholders can be any person, group or organization
that impacts or may be impacted by our assessment of needs or by any related project or projects
that might take place. They can also be any people who perceive themselves as being impacted by
either the assessment of needs or any projects that might follow. Even if they aren't directly affected,
the fact that they'll be able to provide feedback, have some input, and potential influence over this
process means that we should take their insight and their feedback into account as well. Some of
the key stakeholders whose insight and opinions can be most important include any sponsors,
project managers, benefactors, those who are providing resources to either our needs assessment
or any sort of project that might follow, as well as users who might benefit from an objective being
completed on a daily basis, implementers or those who are expected to complete objectives, as well
as others. These are all critical sources of input, and gathering information, and forming our
requirements and objectives in a way that aligns best with business needs and goals. Of course, not
all objectives are going to be created equal, which is why it's important that we take the time to rank
them. Some may demand more attention or make more sense to undertake than others for a variety
of reasons. Factors can include organizational and environmental factors, as well as constraints on
what solutions are available to us. Our existing technology and infrastructure and the necessary
technology and infrastructure to successfully complete an objective can play a big part as well, as
does, of course, the potential value that completing that objective can create when compared to the
cost and amount of time and resources necessary to complete it. Completing a SWOT analysis, with
SWOT standing for strengths, weaknesses, opportunities, and threats can provide useful
perspective in forming and ranking these objectives. In the next module we'll go a step further
comparing our existing organizational capabilities to those capabilities that will be necessary in order
to meet requirements and achieve objectives. I'll look forward to seeing you then.

Comparing Organizational Capabilities & Requirements

Module Introduction
Welcome back. In this module we're going to focus on comparing organizational capabilities to the
requirements that we have outlined in order to reach our objectives. To do so we're going to look at
a number of different concepts beginning with the business architecture, before moving onto
understanding the state of the organization how it exists today. Then, we'll look at organizational
assessment techniques that can be used in order to better understand what our capabilities are, and
what will be required to get them to that desired future state necessary to complete objectives. After
that we'll look at determining required capabilities, so that we can add some specificity to what that
future state will require, and then how to compare those existing and required capabilities using gap
analysis and other techniques in order to determine what we have to do to go from here to there.
Let's get started.

Business Architecture
Now it's time to discuss business architecture and how it comes into play. As we've discussed in the
previous couple modules, ranking objectives is very important to creating a business case for action.
We need to be able to evaluate how these objectives rank based on factors like organizational and
environmental attributes, any constraints that we might face in terms of the type of solutions we are
allowed to undertake based on corporate policies or the regulatory environment, as well as our
existing technical infrastructure, what might be required from our technology in order to complete
objectives, and the potential value that we can seek to unlock, as well as how quickly, and with what
level of effect we can expect to unlock that value, as opposed to other alternatives we might turn to.
However, this is all well and good, but you may have noticed that we have a glaring omission so far
in our discussion. We've said that there are many questions that should be answered, but we
haven't really talked about how to answer those questions effectively. That's because answering
these questions can be pretty difficult, especially for a business analyst in a complex enterprise
trying to understand how all of it works together. This is where business architecture can be so
valuable. Business architecture provides a framework to better understand the business as a whole,
to project the impact of changes across the entire business, so that we can understand what our
proposals or potential courses of action might mean, as well as to develop any proposed changes
and plans using a common model and set of assumptions rather than building things from scratch
every time we go about the thought process of considering a potential course of action or change
that we might want to make. Basically, a business architecture is a simulation or a model that we
can follow that gives us an idea of how the business overall works in a more manageable, tangible
form. A business architecture is comprised of a group of documents, models, and diagrams that can
help us to see not only all of the policies that a business might have, but also how it's processes
work, why we do things the way we do things within the enterprise, what the business value of them
and the philosophy behind them might be, and more. Some of the assets that we'd hope to see
inside of a business architecture that will make it more valuable for us to work with as analysts
would include information on a company's vision, as well as its mission statement, any strategic
documents or overriding strategic goals and philosophies that help to guide the organization,
information about the organizations functions, how we complete the businesses that we're in, how
we do the work that we're supposed to be doing, rules and policies that guide our work and require
things to be done in certain ways, whether these be internal or external in nature, the structure of the
business, things like our organizational structure, but also the technical structure of the way that
different portions of our resources and tools might function, the processes that we use in order
technique complete our work, as well as information on the locations where this work currently takes
place or could take place based on the type of technical and human resources required to complete
those sort of tasks. Oftentimes we'll actually build two different types of business architectures, one
that will serve as our foundation, will show us how the business works currently, and provide us with
a simulated model that we can turn to to answer questions about where we are in our present state.
The other is based on this, but modified, so that it can take into account proposed changes, so that
we can see how future iterations might be different from the present as we deploy different solutions
or alternatives. This now versus later comparison allows not only business analysts, but also
stakeholders to learn more about the impact of proposed changes, and to be able to imagine them
and visualize them in a more tangible fashion than would be possible without being able to tie it
directly back to the business in a form that can be understood widely by many individuals. The focus
when developing a business architecture should be purely on developing a viable model of the
business. We should be trying to represent it as objectively, as fairly, and as honestly and truthfully
as possible, so that it can be most useful to us. We don't want to try to solve problems prematurely
at this stage, but rather focus on understanding the business as it is, and once we have begun to
come up with potential solutions, create other architectures with those solutions in mind, so that we
can make comparisons accordingly. Business architectures allows us to align the strategic and
operational viewpoints that might differ within the business otherwise by modeling the process level
impact of changes, so we can understand not only what what goals might be out there from a
strategic point, but how this will affect the day to day frontline operations of our business. It shows
the projected impact of changes across many different functional lines, both across the organization
as a whole and how we might need to change the way that we do our work or the way that our
organization is structured, as well as any functional changes that might come into place regarding
the type of work we do or how we do it. Procedural changes, in terms of the process we follow could
also be shown here, as can any changes from a technical perspective. Finally, any geographic
changes can be modeled here as well. If we're going to need to make a physical move to a new
location as part of whatever our solution might be, then we can represent that in its potential impacts
here as well. The level of detail found in a business architecture will vary depending on the size of
the organization and the resources available to the business analyst. In a small organization simply
following the businesses overall business plan, as well as the organizational charts, policies, and
rules that the business analyst might be able to obtain can be enough to give us a good idea of how
the business operates. In larger organizations all of the above are very important, but we may also
have access to sophisticated modeling tools that would show simulated results on how things might
change in a very complex factory, for example, if we were to make changes to our processes. We
might include proprietary simulations and datasets here as well, in addition to other analytical tools
that can allow us to be more technical and more fine-grained in the type of modeling that we do.
Whatever the case is, we want to make sure to include enough detail, so that the architecture can
be useful, and serve as a true and valuable model for us to work with, but we don't want to have so
many variables that it becomes unwieldy or difficult to work with given the tools that the analyst has
available. After all, it's up to the analyst to be able to digest this information using the business
architecture as a tool, so that they can then repackage it and use the architecture and other assets
to present their case to stakeholders. If it's too complicated that might not be possible to first
analyze, and certainly might introduce some difficulties when it comes to presenting the findings as
well. Developing a business architecture, simply following the process of creating one, could be very
helpful in assisting business analysts looking to learn about different information related to the
business. Being able to put together a model in a baseline simulation, even if it's a static one that
you only find on paper, can give the business analyst a much better idea of how processes flow
within the organization, how different departments might interlink and interrelate to one another,
where there might be duplications of functions, where there might be potential bottlenecks or areas
that could obviously use improvement. Looking into all of the different processes here can help the
business analyst to have a better idea of what they can do moving forward, and will better prepare
them to converse intelligently with stakeholders across the board, as they'll now have a better idea
of the type of work those stakeholders undertake, and the perspective that they face on a daily
basis.

Developing the Business Architecture

While having a business architecture in place can certainly be very useful in helping you to create
and understand requirements and objectives, we have once again, left an important omission out.
How do we create a business architecture in the first place? Well, if you're lucky, many your
company already has one or perhaps there's even a fulltime business architecture on staff that you
can interface with, and perhaps work with to build one that suites your needs. If not though, it's still
possible for the business analyst to create one using the raw materials and assets that we
discussed just a few moments ago. To do so you should ask yourself the following questions. First,
what approach should be used? This is most important if we're talking about a complex enterprise,
one where there are many moving pieces, perhaps some of which could be considered to be
definitively outside the scope of what's being investigated. Therefore, perhaps we can get away with
just modeling a single division or line of business or a certain product if we are a more productized
organization. In those cases, we can work around just that question as opposed to trying to build a
model of this conglomerate that has many different pieces that don't necessarily have anything to do
with each other based on the question we're looking to answer. How the architecture will be used is
the other portion of this question. If it's meant to look at the enterprise as a whole, then we need to
model it as such. If, on the other hand, we're very limited in the scope of the questions we're trying
to answer or the kind of issues we're trying to investigate, then a more limited architecture could be
just as useful. Third, will the architecture model the present or the desired future state of the
organization? It's entirely possible you may want to build both, in which case, starting with the
present version is normally easiest. However, if you're starting to create something wholly new, if
you're trying to revolutionize a portion of your business, then in that case you may want to start with
that future state, and then work backwards to better understand how the organization can adapt to
that new model moving forward. If the architecture will describe the entire enterprise or a business
line or a functional area is one of those questions that should be answered just as we spoke about,
and then we have to also consider what informational resources will be needed, and what
informational resources are available to us. We want to make sure that what we need in order to
build an effective model is something that we can obtain. Otherwise, we may need to make
assumptions or try to simulate certain factors of the business that could impair the overall value of
the model, so we should work to find what information we need, and how we can go about obtaining
as accurate and up to date information as possible in these areas. What tools and resources are
going to be needed in order to build the business architecture? If we're making them purely on
paper, if we're just using process flows and organizational charts, different types of visualizations
that aren't very dynamic in nature, then that's one thing. If, on the other hand, we're trying to
introduce very complex simulations and real time computer models into the equation, then we may
need an entirely different suite of tools in order to accomplish that. Can we get access to these? Is it
within the resource purview of the business, and within your authority as the business analyst to find
these or create them? Who will be involved in creating the architecture, and who will help to review
its quality, accuracy, and usability? Business analysts don't develop business architectures in a
vacuum. Rather, just like other portions of business analysis, this should be done in coordination
with other stakeholders who you may turn to for feedback, to work with directly on creating the
business architecture or at minimum, to run it by them to make sure that they can validate it, and
that what you see and what you've created lines up with their perspective of how the business truly
operates. At the end we have a series of desired results regardless of the complexity of the
business architecture we create. First, we want to compile all of the strategic plans and philosophies
that have to do with the issue or opportunity that we're investigating. We want to include all of the
organizational structure information that could be relevant and valuable here to understanding how
the business operates, and what might be impacted by any changes we can propose. We should
include our goals and objectives for business units that are directly tied or perhaps even indirectly
tied to the business, so long as they might be impacted. Function, service, process, role, and
product details for all relevant business units should be included as well. We should understand the
type of jobs that people do, how they do them, why they do them, what their role is within the overall
process, and so on. Finally, we should include the results of gap analysis as it takes place, although
this may not be readily available to us as we first develop the business architecture, rather, this is
something that we continue to add over time, as we use the architecture as a tool, and continue to
refine it over the course of our analysis. Often times when we want to validate whether or not our
business architecture will be a valuable and effective tool we can use use cases and different
business scenarios in order to learn and test this model, to learn more about the business, and to
test whether or not the architecture is functioning as we would desire it to. If we know, from past
data for example, how certain scenarios would work out, if we can't turn to our business architecture
and arrive at a very similar result, then perhaps we don't have a full understanding of the business
or perhaps key things have changed since that scenario originally took place. Having an appropriate
modeling philosophy will vary by the business and the needs, so it depends on what you're trying to
model here, and this is why bringing stakeholders in is so important. They'll have the best idea of
how things really work on the ground, and you can use that information to build models that
accurately represent reality. These models are often built around an organizational structure, but
they can also be built around a certain activity or a function, such as a product line, and how a
product is developed from beginning to end. Regardless, you want to build your model in a way
that'll be most useful to you when conducting your needs assessment and other business analysis
activities.

Organizational Assessment Techniques

By this point we've talked about goals, and objectives, and requirements, we've built a business
architecture, we have a better idea of how the business works, we've identified some of the key
stakeholders that we need to work with, and we've probably worked with them to some extent to
better understand and identify what the issue or opportunity might be, and as such, we have
probably, at this point, created at least provisional objectives, we have an idea of what it is we seek
to accomplish to get from here to where we'd like to go. Our business architecture provided us with
a greater understanding of what the current organization might look like, and how the changes or
solution we might want to implement could result in changes to that desired state of the organization
down the line. However, we have not yet necessarily analyzed the underlying causes of our
situations, so we know what we might want to fix, and we think we have an idea of how to do it, but
we don't know for certain if we're truly going to solve the problem or if we're simply going to be
treating symptoms. This is where root cause analysis comes into play. Here we can help to
understand what the underlying cause of the problem is that we're seeking to resolve. The flip side
of this would be opportunity analysis when we're looking to leverage on an opportunity rather than
combat a problem. What are the defining traits of an opportunity, and how viable are our prospects
of being able to take advantage of it? Will we be able to move quickly enough? If we do will our
solution be effective in helping us to leverage this opportunity? We have to answer these questions
and more. Both of these types of analysis benefit from similar tools and processes that can be used
in either case. This type of formal analysis prevents us from jumping to conclusions and choosing
either incorrect or overwrought solutions that "solve" far more than they actually need to to complete
the objectives, so now that we know what we want to do we need to understand exactly what the
problem might be, so that we can make sure to treat it effectively and complete those objectives in
the most efficient and effective manner. Here are some of the different techniques that can help in
this regard.

The Five Whys

Let's first take a look at one of the easiest and most effective techniques possible for organizational
assessment. It's known as The Five Whys method. See root causes rarely present themselves right
off the bat or are identified immediately. Instead, we may misidentify deeper symptoms as root
causes, but we still haven't gotten there, so we might think that the symptoms on the top, well that's
not the root cause, we need to look a step further down, and we do, and then we think, ahh, well
now we have solved it, we've found the root cause, let's build a solution to fix this, everything'll be
fine, just to discover later on that we haven't actually fixed the underlying issue, that these were just
additional symptoms. By asking why again, and again, a number of times we can dig deeper into a
situation, and have a better understanding of when we truly do hit that rock bottom stage of
understanding this is truly the root cause or at least the deepest cause that we can find for the
problem that we have identified. This is helpful in avoiding solutions that lack an understanding of
the actual problem, and might simply act as a Band-Aid or a patch in the short-term, but not help to
solve it in a long-term comprehensive manner. Let's look at an example of how this might work in
the real world. We have a text conversation here between a business analyst and a frontline
specialist within a fulfillment center for an online retailer. The frontline specialist begins the
conversation, I received a request to switch our fulfillment center to a new order management
platform. Well, the business analyst responds, okay, sounds like a major project. Can you tell me a
bit more about what's leading you to this request? Did you catch it? This was actually a way of us
asking why without ever saying the word why. If you think this might be a little bit like having a
conversation with a toddler it doesn't need to be. We can continue to ask why in intelligent manners
throughout the conversation, and hopefully you'll see that here. The frontline specialist responds,
well, about 20% of our orders received are shipping later than our target. They think the new
platform will help. Well, the business analyst replies, we definitely don't want so many orders to ship
late to customers. Do you have any perspective on where the bottlenecks exist currently? Here
we've asked why again, so at first we saw that there's been a request for a new fulfillment center, we
learned a little bit more about what the problem might be, and now we want to get to the heart of the
matter. Why is this problem occurring in the first place? Why are our orders shipping later than our
target date? The analyst replies, that's just it. We timed the pick 'n pack staff, and they're meeting
target, but they often have to wait for the order manifests to come from a line manager, and then
report back when the order is filled, so the supervisor can update the order with the shipping
information. Hmm, the business analyst replies. Why is the line manager handling the order
manifests and updating the orders manually. I can't imagine that's how are system was intended to
work. Here we've actually asked the question why for the first time, but this allows us to get another
layer deeper. Our orders are shipping behind schedule, we have determined that they are doing so
because there's this perceived bottleneck with our staff having to report back to managers for
additional information and approval, but we still don't know why that's happening, so at this point the
specialist is really out of answers. He says, you're right, something sounds off. Let me check it out. A
few hours later he replies back. I was able to speak with the line manager. He says it's a limitation of
the system, and there's nothing we can do about it. However, I checked out the system manual and
it looks like he's wrong. Pick 'n pack staff should be able to do all of this from their mobiles rather
than using paper copies printed by the line manager. The business analyst replies, so maybe we
don't need a new system after all. Is there any reason the line manager wouldn't be aware of this
feature? Here we've dug down yet again. See, at first we thought that we just needed a new system,
and then we knew that we needed a new system perhaps, based on the fact that our orders were
shipping late. Then, we learned that they're shipping late because there were actually bottlenecks in
speaking with managers, but now as we get farther down it seems like perhaps there's a
misunderstanding of the system that's at the heart of the issue here. The specialist replies, he did
recently transfer from another facility using an older system. Maybe that was true for the last
version, and no one's trained him on the newer version yet. The business analyst replies, is there
any reason he wouldn't have received that training when he transferred over? Here we've asked
why one more time. See, the real problem here isn't that our orders are behind or that there's a
bottleneck that requires the line manager to sign off, or even that the line manager had a
misunderstanding as to how the system functioned. The true issue here is that he never received
the proper training, which led to this cascade of additional issues up the line. The specialist replies,
we conduct training semi-annually. Checking over his records, it looks like he might have missed the
last training session by a couple weeks. There we go then, the business analyst replies. Let's make
sure to get him trained up, and let's put a plan in place to ensure any new transfers or additions
receive training during orientation rather than waiting for the next general training session. Sounds
good to me. I'll get right on it, replies the specialist. Here we went from needing an entire new
platform as the original proposal to simply needing some new training protocols put in place for
employees who are transferring over in between those semi-annual training sessions that we
already have on the books. We've come up with a solution that's far easier, far more elegant, and
certainly vastly more affordable than it would have been if we had just accepted the surface level
symptoms, deemed them to be a root cause, and moved on accordingly.

Fishbone Diagrams
Fishbone diagrams come next. Also known as Ishikawa diagrams after their original creator, these
are helpful cause-and-effect visualizations that are often used alongside the Five Whys method to
better understand all of the different potential issues that we see within a particular problem or if
we're investigating an opportunity. This problem or situation is placed at the head of the fish.
Potential causes and sub-causes follow on the bones giving it its fishbone-like shape. Let's look at
an example. Here we see at the head of the fish that we have a problem or a situation that we'd like
to look into. At the top of each of the different fish bones here we have different cause categories.
Within each of these we have a variety of different primary causes that can serve as offshoots. We
see these represented by the horizontal lines. On the more vertical, diagonal lines here we see a
variety of secondary causes that might also be possible to see within certain cause categories
underneath certain primary causes. There's no limit on the number of primary or secondary causes
possible, and you don't necessarily need to have secondary causes in each case. Sometimes the
primary cause might be enough. Let's apply this to a business example, saying that our problem is
that we're falling behind schedule within a manufacturing facility. Here we have six different
categories that we can look at. Perhaps the problem is with our equipment or with our processes.
Maybe it's a people problem. Maybe it has to do with how we're managing things. Perhaps the
external environment holds some blame or the materials that we're using. Here we can see a variety
of different primary causes as well. If it's people, perhaps it's improper training that's to blame. With
process perhaps inefficient workflows are the cause. Inferior equipment might be the problem or
improper materials. Client delays or delayed approvals by clients could also contribute from the
external environment standpoint, whereas delayed approvals from management, before we go
ahead and send them onto clients, could also be a potential problem. Here we also see several
secondary causes. If it's the inefficient workflow that's to blame, perhaps the steps that we follow
haven't been optimized properly or maybe we're doing some duplicative work and we could simplify
on the type of work that we're doing. If it has to do with materials is it that the quality is poor or
perhaps that we're using the wrong materials entirely. As we drill down further we can get a better
idea of what the underlying cause might be, and you can see how this visualization might tie nicely
to this sort of Five Whys conversation we had a few moments ago.

Interrelationship Diagrams
The next type of organizational assessment technique that might be helpful are interrelationship
diagrams. Interrelationship diagrams can be helpful in visualizing complex relationships between
many different variables, and when we don't follow a purely linear path from one element to another.
Causes could very well be the effects of other problems or vice versa, and understanding how this
complex relationship between different issues that we see can help us to have a better
understanding of the underlying problem, and to identify root causes. This focus on the individual
elements leads to a better understanding of the whole picture as well, and can be useful when trying
to communicate complicated issues to stakeholders. Let's look at an example. Here we start with
decreased sales revenue, believing that to be a serious problem that we face. Well decreased sales
revenue also leads to a loss of purchasing power. In addition to this, decreased sales revenue leads
to cuts in our quality assurance budget. We've seen both of these occur already. Let's go a little
farther. Due to our loss of purchasing power we have fewer procurement options that we can turn to,
and this leads to inferior production materials being purchased, because we no longer have access
to the top dollar, highest quality suppliers. Well, inferior production materials leads to decreased
customer satisfaction, and it also leads to an increased rate of product defects. What we see further
is that our quality assurance budget cuts also have led to an increase in our product defect rate,
creating a double sided problem here. Because of our increased rate of product defects we're
seeing a decreased rate of sales revenue due directly to the decreased amount of customer
satisfaction we see because, as you might expect, decreased customer satisfaction leads to lower
sales, which leads to lower sales revenue. Furthermore, decreased customer satisfaction leading to
lower sales revenue leads to a loss of purchasing power as well. You can see here how this actually
all makes sense, and isn't that difficult to understand now that we have this visualization in place
showing how valuable interrelationship diagrams can be in helping to show the cascading effects
and relationship between different elements that could cause a snowball of problems to occur.

Process Flows
One of the most complex, but valuable organizational assessment techniques is harnessing process
flows. Process flows visualize how a business process progresses through various systems or job
roles. In other words, it's how we conduct our business, how it moves from person to person, and
from system to system throughout the organization. Using process flows can help in identifying how
existing workflows may contribute to problems that we're analyzing or show us where potential
opportunity points might exist. Process flows should be analyzed on a step by step basis in order to
identify whether or not each step in that process could potentially be a cause or a contributing factor
in a problem or an opportunity that we're investing. Let's take a look at an example of a process flow
here for an insurance company. We have two different roles that this process is going to flow
through, a claim adjuster, and a telephone claim agent. First, we'll begin the process with the
telephone claim agent. They receive a call at this point. However, a number of things can go wrong
even this early of the process. We can have customers either have to wait for a long time or
potentially give up and try again later, we have a limited number of agents, which helps to lead to
this factor being the case, and the number of agents being limited is a direct result of previous
budget cuts, which have left us understaffed. Once we've received a call it's up to agents that are
able to answer calls to determine whether or not a claim is eligible to be filed. If so, they record an
accident details. Here we again, run into another potential problem. See the accident detail
recording system is an internal interface only open to other telephone claim agents and not directly
to claim adjusters. This is a potential area for improvement moving forward. At this point they would
go on to find open times for claim adjusters to be able to meet with customers. Here we want to find
a match for our customer schedule and for open time slots that claim adjusters have available. If
we're able to find a match, then we can go ahead and schedule an appointment for this exam to
take place, moving onto process A, which we'll get back to in just a few moments. If we're unable to
find a match, however, we have to determine whether or not to continue our search. Typically, we
may try to continue our search to find additional open times for claim adjusters, however, there's a
number of potential issues that could result here as well. We've heard from our claim adjusters that
it can be hard to find available times, and one of the reasons for this seems to be that there are
limited adjusters on staff. This also seems to be a direct result of a recent budget cut, which has left
us not only understaffed for our telephone claim agents, but also for our claim adjusters in the field.
For this reason, sometimes the search may not continue, which would allow us to simply save the
claim, and then perhaps have the customer call back at a later point in order to be able to schedule
a potential time. Here the process of our telephone claim agent would end. However, the process
isn't yet complete. If we were able to schedule an appointment for an examination properly, then we
go ahead and store this exam appointment, which is passed along to the claim adjuster. It's then up
to them to confirm this appointment, then to meet at the appointed time and place with the customer
to examine damages. Here there are a number of other potential issues that we have also identified.
It may be weeks after an accident has taken place before a claim adjuster is able to meet with a
customer. Will the damages still look the same? Could additional damage have been done between
the time of the accident and now that the customer might claim or that we might perceive as an
agent to have been caused by the accident, even though it was a separate event? This is true
because of a shortage of staff, as we mentioned above, and we don't have enough trained adjusters
either, so it's not just a number of bodies in the field, but also the number of adjusters who are truly
competent at their job. Once again, we see that this is a direct result, you guessed it, of our recent
budget cuts. Once we've examined the damages it's up to the claim adjuster to take photos of the
damages, and then to complete a claim report, however, we see some other areas for improvement
here. This report right now is filed on paper, and there's no mobile capability that could help the
claim adjuster to file this more expeditiously. As such, they then have to move on to file the claim
report, and these reports are often delayed by one to two days due to having to go from a paper to
digital format. Once again, we see that this an internal interface only that's only available to our
claim adjuster, and can't be accessed by our telephone claim agents should the customer call back
in for an update later on. This is another area we might seek to improve. At this point, our claim has
come to an end. Here we see that there are a number of different areas where we can certainly
apply resources in order to help fix our systems and improve them for the future, however, we are
also able to see one of the root causes that's behind several different issues we see, and that's
some of the budget cuts we've made. We need to go back and reevaluate whether the perceived
cost savings that might have led to these budget cuts in the first place were actually worth it given
the amount of over-utilization we see now with our staff, and the potential for customer
dissatisfaction that can arise from not having enough trained and competent agents on hand in
order to help them in a time of need.

Determining Required Capabilities

By working with stakeholders and using the organizational assessment techniques we've covered,
at this point, hopefully we've done a good job of identifying the root causes behind the issue or
opportunity that we're looking to address. As such, our attention now turns to resolving these issues
or leveraging these opportunities, and to do so we have to first determine what the necessary
capabilities will be in order to take action. In other words, what do we need to be able to do in order
to accomplish whatever solution is that we might be considering for this issue or opportunity. In the
case of simple situations we may simply have simple recommendations. This goes back to our
earlier conversation during the Five Whys example. Here we really didn't need an active congress in
order to do anything, rather, at our fulfillment center we were able to change some of our training
protocols accordingly to make sure that everyone would be on the same page even if they transfer
in in between our normal training sessions. In other cases we may require a more complex solution
that's going to require an assessment of organizational capabilities at large. This can be true
especially if we're developing a new product line or trying to solve a very complicated issue that
involves many different portions of the business. As such, we can use tools like a capability table in
order to help. These are useful in tying problems to root causes and suggesting capabilities that
might be useful for dealing with them. Here as headers we have problem or current limitation, along
with root cause or causes, and new capability or feature that we might be proposing. The problem in
this case is that our fulfillment times are below target. The root cause here might be that there's
inadequate training, and any new capability or feature that could be helpful would be enhancing our
training, and having special training for new recruits or transfers into the organization. However,
there are some other causes that we saw identified during our discussion earlier. The system
version does have discrepancies between facilities, and this indicates that there might be a larger
problem within the organization, and that this isn't something that is unique purely to our fulfillment
center. In this case, unifying the platform versions across all organizational facilities could go a long
way toward ensuring that everyone's on the same page, and that new recruits and transfers are able
to conduct themselves immediately upon entering that facility the same as they would any other.
Third, there might also be a lack of valuable features in the current platform. While the line manager
in our example happened to be incorrect about whether or not the current generation version of the
software that we're using is going to have the feature he was looking for or not, that doesn't mean
that he was entirely wrong or that we shouldn't investigate this further. Perhaps there are other
features that we could put into place that would allow us to continue improving our systems, and the
way that we fulfill orders. A next generation platform with the desired feature set could help to
handle this, and so perhaps we should investigate what sort of features could be most useful, and
do some work on identifying a next generation platform that could be used across all facilities,
especially if we're going to go to the trouble of unifying them all onto one platform anyway. Let's say
that another current problem or limitation is that our customer satisfaction is below target levels. This
could be due to the increase defect rate that we saw in the interrelationship diagram example. The
addition of new quality assurance procedures may be helpful in this regard. However, if inferior
materials quality is also leading to customer satisfaction being lower than we'd like, then we may
want to look at having higher budgetary flexibility, so that we can contract with higher quality
sources. It could be that we need to cut into our margins a bit in order to ensure that we can make
the highest quality product possible. In this case, we'd be relying on the fact that our reputation
being improved and customer satisfaction being higher will lead the better sales, and in the long
term, help to benefit the company more than any small cuts might in the meantime. Another tool that
can be useful in helping us to determine our required capabilities are affinity diagrams. Affinity
diagrams help to surface common themes across issues, and can be helpful in determining what
capabilities may contribute to solutions to one or more of these issues at the same time. After all,
any time that we can take care of several problems with the same solution that would be particularly
effective, and a good choice. So, we might categorize all of our HR issues together, for example,
and we might see that a potential solution is that we can implement new training protocols. This
would help to solve a number of different issues, including infrequent training, gaps in training for
new transfers, versus those who are already on the ground and working, as well as some issues
that we're seeing with below target performance. We may also decide that we want to use new
quarterly evaluations to also help to address this below target performance. After all, if we're
providing additional training, and we feel like everything is up to snuff in that regard, but we're still
not getting the performance we're looking for, perhaps we need to look at the individuals a little more
closely, and how we can make sure that we have the right people on the job. Different technical
issues might arise as well. Here we see just one type of solution that's being employed, which is the
deployment of a new system potentially. This could help to fill the technical gaps between facilities,
as well as the need for new features, and so it might make more sense than simply unifying around
the most current version of the software. Management issues would fall under a different category in
here. We see that we might want to retool our analytics reporting. The problems that we're having in
our fulfillment center went on unnoticed and unreported for too long, and so that indicates that we
might need to do something in order to help keep this from happening again, in the future. By
making sure that we're getting the right analytics, we can help to nip the next problem in the bud
rather than allowing it to cascade in a manner that would cause problems. Another way we can help
to identify what required capabilities might be is by conduction competitive analysis. Have others
solved similar issues or leveraged similar opportunities in the market place, either within our own
company or elsewhere? How have they done so? What best practices can be followed based on
examples that we see either inside of our own organization, elsewhere in the industry or even by a
direct competitor? There are a number of different ways that we can conduct this competitive
analysis. The first is to simply review analytics, and this is particularly important if we're looking to
internal guideposts as a marker. Here we may be able to get data from other divisions or product
lines, and learn from what they've done so far. This isn't so much competitive analysis as it is
collaborative analysis, since we'd be building on the work of our peers. When it comes to direct
competitors perhaps we can do some research, looking at their website or other publicly available
assets that they might publish that can give us an idea as to how they've gone about solving these
issues in the past. Perhaps we can interview people directly. Key stakeholders, subject matter
experts, even those from outside the company, industry sources, external consultants, and more
who can help us to better understand how others have dealt with similar issues in the past. In the
case of certain environments we might even be able to secret shop them. In other words, go directly
into the organization or competitor and see how they're doing things first hand. This is particularly
the case in retail environments where we can go in and pose as a potential customer, and learn
more about how that business is able to conduct itself when it comes to challenges that we may be
investigating.

Comparing Existing & Required Capabilities

At this point, we've conducted root cause analysis, we have an idea of what's going on, we've set
some objectives for what we'd like to do about it, and we've looked into what we'll need in order to
do something about it by examining what the required capabilities might be. Now our focus turns to
gap analysis. This is the process of checking what our current capabilities are against what we need
to be able to do in order to complete those objectives. It may be possible to resolve problems or to
leverage opportunities using only existing capabilities. In other words, there may be no gaps
between what we'd like to do, and what we can do right now. However, in most cases new
capabilities or assets of some sort will need to be developed in order to create or achieve that
solution. A full review of the existing capabilities can help to prevent a "reinvent the wheel" scenario
though, allowing us to better determine what we can do now, what might be able to be modified in
order to fit a need, and where we might need to develop new talents or assets entirely. First, we can
turn, once again, to process flows. What existing processes can help address the issue as they exist
today right now. In addition, how can existing processes be retooled in order to help address an
issue? It could be that we're doing things pretty much the right way, but there's just a small tweak
that we could make that could allow us to complete an objective successfully. The training protocols
for our fulfillment center are a perfect example of this. There's nothing wrong with the training,
except not everyone is receiving it at the right time, so simply working on our scheduling and our
rules for who undergoes training and when would allow us to fix this issue using existing resources.
Third, how can existing processes either grow or be refined in order to address the issue? Perhaps
we don't need to retool them or change them, so much as just build them out even further. Maybe
once we've begun to roll out that new training we notice that our trainer is now severely overworked,
and that the reason we had that training scheduled only semi-annually is because they have to
travel to many different fulfillment centers. In that case, the answer might be bringing additional
trainers onboard, growing the process, so that it can better address the overall company's needs.
Process flows can also help us to answer what resources can be reallocated in order to help
address an issue. We may see that there's duplicative work, and also a need for additional talent in
the same area. In that case, we could simply re-task some of those individuals away from the
duplicative work, and toward what we need them to do in order to achieve objectives. What
resources are necessary in order to address the issue, and which ones are missing entirely? We
can see this, to some extent, on the process flow because if we don't see anyone responsible for
certain tasks or anything similar to tasks that we know we need to accomplish in order to meet our
objectives, then these are areas where we have a capability gap that will need to be filled with
wholly new work. The business architecture can also be very valuable to revisit here. Present
models need to accurately reflect existing resources, processes, and capabilities in order to be
effective. While future-focused models should address the resources, processes, and capabilities
deemed necessary to meet our objectives. By comparing the two we can get a clear indication of
where the gaps might lie, and what work will be necessary moving forward. At this point, we can
revisit the capability tables we began to build when first discussing what our required capabilities
might be. Here we can now expand it in order to include specific deliverables that will help us to fill
gaps in our current capabilities. This can also help lead to the development of recommended
actions, which lets us move forward in creating a business case, which can then lead to a project to
achieve these objectives. Here we again see our first three columns joined by a new one titled,
Deliverables to Fill Gaps. When addressing fulfillment times that are below target, and the root
cause of inadequate training, we see that advanced training might be needed, and that special
training for new recruits or transfers might be useful. The deliverables we might use to fill these gaps
include a new training curriculum, as well as upgraded or expanded on-boarding processes and
training. When it comes to a lack of valuable features in our current platform, and our desire to
deploy a next-gen platform with additional features, we can fill this gap with the development,
selection or deployment of a next-gen platform of some sort once we've investigated this fully. When
it comes to our customer satisfaction being below target levels, and the increased defect rate we
think might help be behind that, we see that an addition of new quality assurance procedures is one
new capability we could suggest. To fill that gap we should develop, evaluate, test, and deploy new
quality assurance methods, as well as to design new QA training to make sure that our quality
assurance staff are aware of the best practices to keep the defect rate low. When it comes to our
inferior materials quality, and our suggestion that budgetary flexibility to contract with higher quality
sources might be a feature that could help solve that cause, we can help fill this gap with new
guidelines that allow greater financial latitude for our procurement staff while making sure that our
business interests are protected, and we don't so adversely affect margins that we create problems
for other portions of the company.

Module Review
We've covered a lot of material in this module, so let's take a moment to review. We first spoke
about the business architecture, which provides a framework to better understand the business and
the impacts of projects that are under consideration. Business architecture is comprised of
documents, models, and diagrams describing the function of either the entire workplace, the whole
line of the business, or a whole functional division. It needs to be large enough to encapsulate
everything that might be related to or indirectly affected by the issue or opportunity that we're
investigating, otherwise, we've left the apps in our understanding of the big picture that could cause
us to not be able to come up with objectives that fully encapsulate the solution we'd like to use or
fully address the problem or opportunity. This business architecture should include information on
the businesses vision, mission, strategy, functions, rules and policies, structures, processes, and
any geographic location information that might come into play as well. When developing the
business architecture we should consider how it's going to be used, and who it's going to be used
by. What the scope of the business architecture should be will depend largely on not only what
resources are available to us, but also on what problem we're trying to solve. If we're trying to solve
something that involves the entire business, then simply creating a business architecture
representing one line of the business won't be enough, whereas if we're trying to solve a problem
directly and exclusively related to one product line we can probably just create an architecture for
that and be okay. The business architecture should include a compilation of strategic plans and
philosophies, as well as information on the organizational structure, business unit goals and
objectives that are relevant, as well as details on functions, services, processes, roles, and products
that are directly in and directly related to the problem or opportunity we're investigating. In addition,
we'll want to add our gap analysis results over time, although those may not be immediately
available when we first begin developing the business architecture. Different organizational
assessment techniques can help us to have an understanding of the root causes behind our issues,
especially within the context of the business architecture, given that it gives us a better
understanding of the business at large. The first of these assessment techniques that we can use is
known as the Five Whys. Here we continue to ask why, in an intelligent manner, in order to deeply
investigate an issue, and discover what its root cause might be. we're able to strip past layers of
potential symptoms in order to determine where the true problem lies, so that the solution we create
is as perfectly tailored to solving all facets of the problem as possible as permanently as we can.
Fishbone diagrams are cause and effect visualizations that are effectively used in conjunction with
the Five Whys. They're known as fishbone diagrams because they begin with a problem, and then
branch out to primary and secondary causes from there. Interrelationship diagrams can help us to
visualize the complex relationships between various causes and effects, given how things can
interrelate, and how causes of some issues might be effects of others, and vice versa. Process
flows help us to visualize how business processes progress through different systems and job roles.
In other words, they're a visualization of how our work gets done, and who might be affected by or
affect that work along the way. These are useful in identifying issues and gaps in our capabilities,
which comes in handy when we begin to determine what our required capabilities to meet objectives
might be. Here we can use capability tables, which list problems, along with identified root causes,
and propose new functions that would help to solve these problems or leverage these opportunities.
Affinity diagrams can be useful here too, tying multiple issues, symptoms, causes or themes
together in meaningful ways. These can help to tie problems directly to solutions, and can help us
see where a certain solution might solve several problems at once. Competitive analysis can also
help us to determine our required capabilities. It provides insight into how similar issues were solved
in the past. This also affords the opportunity for us to benefit from best practices that others have
already developed, so that we don't have to reinvent the wheel along the way. Finally, we need to
compare our existing capabilities to what capabilities will be required in order to complete our
objectives. This is known as gap analysis. Process flows and business architecture are both helpful
in gap analysis, and the development of potential solutions, which leads us directly to our next
module, which will be focused on recommending action. Here we're going to take all that we've done
so far, all of this research and needs assessment, and we're going to turn it into several different
proposals, and then select which one we'll recommend to other key stakeholders in order for a
solution to be put in place. I look forward to seeing you then.

Recommending Action

Module Introduction
Welcome back. In this module we're going to look at Recommending Action. Now that we've defined
where we currently are, where we'd like to be, and laid out some objectives it's time to make some
decisions and recommendations that we can pass along to potential project sponsors, so that action
can begin to take place. First, We'll look at some of what goes into Recommending Action, and then
we'll look at gauging option feasibility. Here we're going to determine which of the several different
methods that could get us to that future state we desire might be best. Then we'll look at how to rank
and weight them based on the information we're able to find during that feasibility analysis. After that
we'll look at value projection methods that can give us an idea of the cost benefit for each different
alternative we're thinking about proposing. Then we'll look at creating a business case around the
alternative or option that we think is best for the business and the organization moving forward. Let's
get started.

Recommending Action
Thus far in our tour of business analysis, and more specifically needs assessment, we've done a lot
of work. First, we've helped to establish our goals or at least learned about what they are from
research that we've done, interviews that we've conducted with different members within our
organization. We've learned more about the strategic philosophy behind our business, and the types
of problems or opportunities that we should be focused on accordingly. Following that we went on to
identify those problems and opportunities, and figured out which one we wanted to investigate at
this time. From there we were able to develop some objectives as to how we can help to either
combat that problem or leverage the opportunity in question. From there we went on to catalog our
current capabilities and have an understanding of what we are able to do right now as an
organization. Then we outline what the desired capabilities must be in order to complete those
objectives and either solve that problem or take advantage of that opportunity. At this point we have
a few more steps left in our business analysis life cycle. We need to develop recommendations for
the gaps that we've identified in our current capabilities versus what we need to be capable of in the
future. We need to describe a specific approach to how we are going to fill these gaps, and we
should try to share several different alternatives that are worth other key stakeholders considering.
Oftentimes there's not just one way to solve a problem. There may be more or less complex or
costly solutions that are more or less comprehensive in nature. They may only temporarily solve a
problem or leverage and opportunity or they might set us up for long-term success. The cost benefit
of these isn't always necessarily up to just us to determine. In fact, most of the time we are simply
gathering the information and providing analysis, so that either others can make decisions or we can
work alongside others to build consensus toward an alternative worth choosing. From here we need
to analyze the feasibility of each approach, so that the stakeholders we share these alternatives with
have some perspective, and an objective viewpoint to work with when considering each alternative.
Then we should rank these approaches based on an objective set of merits to further help our
stakeholders in their decision making process. To do so we also have to create high-level overviews
for each of the different alternatives that we might have in mind. These help to describe how
capability gaps can be filled, but it lacks the detail of a formal project plan. Here we just want to give
the general roadmap for how each alternative would work. It's not up to us or appropriate at the
moment to go ahead and provide all of the details that we would need to complete these alternative
methods. Instead, we simply want to provide an idea of what might be entailed, what the cost might
be, and some objective estimates as to the timeline. Oftentimes these high level overviews can help
serve as the foundation for project charters that are later created, so that action can begin to take
place. The business analyst should coordinate with technical experts as necessary in order to
provide adequate and accurate details here. Sometimes we don't need all of the details up front, but
there certainly could be certain key details that we very much do need to consider, even at this early
point, in order to make a fair decision about which alternative, if any, to go with. When describing
these alternatives we do need to remember that more than one path is almost always possible, and
that while the best option may seem obvious to you, it may be much less obvious to others. After all,
they may be coming from different viewpoints, and certainly are working with different information
than you are. As a business analyst you have been able to obtain information from a wide swath of
sources throughout the organization, and you may have a better idea of how things actually work on
the ground throughout every portion of the process that's involved than most other stakeholders do,
given that their expertise is in whatever portion they're most directly responsible for. As such, the
analysts may typically make recommendations, but not final decisions, and so we need to provide
these alternatives, even if we don't necessarily think that all of them are equally strong, because if
nothing else they can help to lend valuable context to our recommendations, and allow these
decision makers to understand where we're coming from, and to make the best choice possible.

Gauging Option Feasibility

Oftentimes there are many possible solutions to a problem or many possible ways that we could
leverage an opportunity. However, that doesn't mean that they are all practical. Here let's say that
we have a wide variety of solutions, 10 in total that we can choose from. However, once we begin to
scrutinize these a little more closely we see that some options fall by the wayside pretty quickly. For
example, B, H, and D in this example would not be considered operationally feasible because we
just don't know how to implement them, even if it would be possible theoretically. In addition, G and
J would not be considered technically feasible given the equipment we currently have or could
reasonably get access to. Just the same, we would need to knock off several more when it comes to
cost effectiveness. While these could potentially solve the problem, the cost would be greater than
the benefit, and therefore, not worth pursuing. If we worry about which ones are timely it would allow
us to solve an issue very quickly, and then we see that we're actually only left with one solution in
this case, so while there were 10 that might have been possible, only one passed all of the tests that
we had in terms of gauging their feasibility. When trying to determine what alternatives might best fit
our needs we need to consider a number of questions. First, looking at operational feasibility, we
should consider how well the business need is met by the solution. If we have a potential solution,
but it doesn't really address the underlying root cause as well as other ones, then that's
comparatively weak, and that should be taken into consideration. Will stakeholders embrace the
solution on a permanent basis? This speaks to some of the organizational and cultural norms within
the organization, but also potentially to the type of talents, philosophy, resources, and experience
that these stakeholders have as well. If you're asking them to learn entirely new systems, different
from what employees might have spent decades doing in the past, then you can be certain that
you'll find some resistance here. That doesn't mean it's necessarily not worth pursuing, but it is
certainly a cost of that alternative that must be taken into consideration. Further, what impact does
the solution have on the organizational environment as a whole? If our solution is going to require a
serious restructuring of the entire organization, then that can cause serious upheaval. Maybe we'll
even lose some employees in the mix because they get tired of the changes or scared about job
security, and therefore leave to go elsewhere. In that case, we could leave ourselves depleted of
some of our most valuable resources, and unable to actually achieve the solution as we originally
saw fit. How reliable, supportable, and sustainable will the solution be over the long term? Is it a
patch? Is it something that's relatively cheap to implement now, but might not continue to work later
or is it a system that will be very difficult to maintain over a long period of time? We have to consider
the total cost versus the total benefit over the long-term, and not just look at what the short-term
benefit or cost might be. When it comes to technical feasibility, first, does the organization already
have the technical capability to develop the solution in house? If so, that's a tremendous positive in
favor of that particular alternative. Can the needed technology be developed or procured, and how
practically? Sometimes it might be as simple as buying a bit of new equipment that would be
relatively affordable compared to the problem it would solve. In other cases we might need to invent
entire new processes and technologies, and this could be much more costly and difficult for us to
undertake. Does the organization have or can it obtain the technical expertise necessary? This is an
organizational question as much as a technical one. We need to understand the capabilities and
talents of our own people, where their focuses and expertise might lie, where our strengths and
weaknesses as an organization are, and so on. To what extent is the solution compatible or
incompatible with existing technology? An alternative that might work very well in a vacuum, but
could cause serious difficulty when we try to integrate it with other platforms is not a very good
solution at all. When it comes to cost-effectiveness, at a high level, what are the initial and ongoing
expenses that might be expected, and compared to the expected benefits, is the solution projected
to be cost-effective? We need to look at this in several different perspectives, not only for the
percentage gain that might exist here or what we might expect from an absolute dollar standpoint,
but rather a mix of both, understanding the practicalities of the capital that our business might have
access to, but also want to keep in mind what that long-term benefit might be if a large investment
might make sense. This leads to the third question, which is whether necessary funding can be
acquired in order to implement the solution. Even if it makes a lot of sense to do, if we simply can't
afford it or don't have access to it, then that alternative is effectively sealed off to us. These different
questions should not be asked in a vacuum, nor should the assessment of each alternative take
place independently. Instead, we should consider these options as compared to the current
situation. What would the expected future be if no action is taken, and what would it mean if we went
with one of the other options that we're looking at instead of this one? We should work with
stakeholders in order to benefit from their insight in judging the true benefits and drawbacks of each
approach. After all, typically those who are expected to use or interact with a solution on a daily
basis will have a better perspective on what the daily challenges or benefits of each different
solution might be, and by speaking to upper level executives, and those with a more strategic
mindset, we can get a better grasp on how well the solution matches up with the company's long-
term goals.

Weighing Options for Action

Let's take another look at those 10 potential alternatives, and see what would happen if things went
a different way. First of all, let's say that after looking at all of our options we've actually eliminated all
10. No options were considered feasible. In this case we may want to first go back and see if we
missed any potential alternatives, but if not, if we've exhausted all of our research we may end up
recommending not taking any action. We may indicate that the problem is either too small or not
important enough to solve or that there's simply nothing that we are able to do about it right now that
makes sense as an organization or we could see that an opportunity is simply too small or
insignificant to take advantage of or that it's too fleeting from a time sense, and that by the time we
do anything it'll simply be too late. If there's just one option we need to recommend that one most
likely, but we'll need to include some of the others that were closest to being feasible in order to
provide some perspective. It's never appropriate to recommend only one course of action without
providing a look at some of the other alternatives. However, we could find that after we've weighed
all of our options there are several that remain feasible. In that case, maybe we're not sure which
one to recommend. Here one method that we can use is to conduct a weighted ranking. A weighted
ranking assigns a percentage weighting to each of several different factors that we can decide upon
ahead of time. Criteria and weightings will differ based on the situation and on your organization's
priorities. For example, in some cases it might be most important that the solution be cost effective.
In others it might be most important that it's completed as soon as possible. With that in mind,
different criteria and different weightings might apply. These criteria and weightings should be in line
with our relevant goals and objectives, and the ratings themselves should be objective in nature. We
shouldn't try to rig these rankings in favor of any one solution, but rather setup guidelines that best
indicate what would address our need, as opposed to what would best fit the alternatives we have
available to us. One method of weighted ranking is known as pair-matching. This allows each option
to be compared individually to each other option, and can give us an idea as to what the overall
ranking of all of these different options should be. Analysts may make choices or choices can be left
to a vote of key stakeholders who are brought in and asked to help in this ranking process. Whether
they're involved in voting or not, consensus of key stakeholders should be built around the weighting
and ranking processes, so that everyone agrees on what the criteria should be, what's there, and
what's in the best interest of the business. Let's look at an example of pair-matching here using our
five different potential solutions. First, we're going to compare A and D with each other to see which
one we think is stronger. Here we've determined that D is actually superior to A based on the cost-
effectiveness factor. As such, we'll go ahead and give D a vote. Next, we'll compare A and F. Here
we see that A is actually superior to F, so it earns a vote. Next, we'll compare A and G, seeing
again, that A is superior, earning another vote. After that we'll compare A and J. J is actually
superior to A, earning J a vote in this case. Next, we'll go onto D as compared to F. Here we see
that D is superior to F, earning it another vote. Next, we'll compare D and G. We see that G is
actually superior to D, so we'll give G a vote within our rankings. This process continues next
comparing D and J. D is actually superior to J, so we'll go ahead and give it another vote
accordingly. Next, we'll look at F versus G. Here G is superior to F, earning G another vote. Then
we'll compare F and Jabber, noting that J is also superior to F, earning J another vote. Finally, we'll
compare G and J. Here we see that J is actually superior to G, which will result in another vote being
granted to J. As you see here, J and D actually have an equal number of votes, so what would be
most appropriate is to compare their direct pair-matching to see which one we considered to be the
better solution. If you recall, we actually slotted D in front of J during their head to head comparison.
As such, we would give D the tiebreaker, and say that it was actually the most cost-effective solution
out of those that we evaluated. Here we would rank all of these based on the votes that they
received, and noting where they fell in orders and tie breakers we would see that D is number one,
followed by J at two, A at three, G at four, and F at five. Then we would assign a score to each of
these. This scoring system can change based on the rules that you've setup, but in this case we'll
have a top score of five, and a minimum score of one. As such, our scores are the exact inverse of
the rankings. Next, we'll look at how this would look within a weighted-ranking matrix. Here we
would have a variety of different factors with different weightings. You can see that D has our full five
points here, while F earned just one point, as the weakest, least cost-effective solution. Next, we
multiplied these by the weight of 35%. Let's say that we went through this same process, even
though it's a bit arduous for our other factors as well. For technical feasibility, which we applied a
40% weight to, for operational feasibility with a 25% weight, arriving at total scores, where we added
together the weighted scores from each of these three factors. This allows us to get to a final
ranking. Note that solution A was actually the one that we considered to be most appropriate here
based on its high score with technical feasibility and acceptable scores for cost effectiveness and
operational feasibility. Even though D was the most cost-effective, it only came in second place
because it wasn't very technically feasible for us to implement. F didn't do very well as a whole,
while G and J might both prove serviceable if we are unable to build consensus around A or D for
some reason. However, with this rated ranking in mind we created a more objective platform, which
this recommendation can be based, and through which we can present each of these different
solutions with their strengths and weaknesses.

Payback Period & Return on Investment

When evaluating and weighing the different alternatives open to us one of the key things we have to
keep in mind is the business value that we're able to create with each solution. There are multiple
different methods we can use to help get a look at what this business value might be. Two of these
are the payback period and return on investment. The payback period is the amount of time until a
project's investment has reached the breakeven point. This can be important for organizations
where resources might be constrained or really for any organization that needs to know not only
what the total benefit might be, but how quickly they might be able to achieve it. Longer payback
periods also indicate greater risk because there's more things that could go wrong or more
conditions that could change while that payback is still occurring. Let's look at two different options
here. Solution A is a $3 million project that results in $400, 000 of savings per year, according to our
estimates. Here we would see that there's a $3 million investment, and divide it by 400, 000. That
would allow us to reach a figure of 7. 5, indicating a payback period of 7. 5 years. Solution B, on the
other hand, is a $2 million project resulting in savings of $160, 000 per year. Hmm. This project
costs less, but the savings per year aren't nearly as great. The payback period on this one would be
$2 million divided by 160, 000, equal to 12. 5. That means 12. 5 years, indicating that solution A is
the one with the better payback period, even though it does cost us more up front. Return on
investment is our estimated net benefit divided by the total investment that's going to be required,
however, we don't typically take ongoing costs into account when calculating our ROI. Instead, we're
looking purely at those upfront costs, and the return that we can expect on the backend. That means
that ROI is more or less effective depending on what you would expect your ongoing cost to be, and
how substantial that is relative to the project at large. Let's look at an example of ROI being
calculated. Solution A involves costs of $500, 000, but we expect total benefit of $595, 000 over
time. If we take $595, 000 and subtract 500, 000 from it, and then we divide that remainder by 500,
000, we would get a ROI of 19%, indicating a return on our money of 19%. Solution B would involve
$750, 000 in cost, but $935, 000 worth of expected benefit. Hmm, we're spending more here, but
we're also receiving more benefit. However, is the ROI higher? Well when we subtract $750, 000
from 935, giving us our expected benefit, and then we divide it by our initial investment of 750, 000
we arrive at a number of roughly 24. 67% indicating that solution B results in the higher return.

Internal Rate of Return

The next financial tool we might use for assessment is internal rate of return. Internal rate of return
helps to estimate the annual yield of a project investment. What makes IRR very useful is that it
includes both initial and ongoing costs of the project, unlike a simple ROI. However, the calculation
is much more difficult. The formula we have to follow is net present value equals the summation of
our period cash flow, divided by 1+R to the power of T, all of that less the initial investment. Now
here R equals the interest rate, while T equals the number of time periods. NPV is the net present
value of the project. When calculating IRR we assume that we are aware of the net present value of
the project, however, we're trying to determine what that interest rate could be because this
represents our internal rate of return. Financial calculators and Excel are both very helpful in
calculating IRR, but let's take a look at an example of how it works just at a high level. When looking
at two different solutions, beginning with solution A we see initial costs of $300, 000 and benefit of
$150, 000 per hear for 3 years. At the end of the project we'll be able to sell whatever the solution is
that we created for an estimated scrap value of $10, 000. In total, we would expect an IRR of around
24. 31% for this project. Pretty good. Solution B, on the other hand, indicates $100, 000 worth of
initial costs. The benefit changes yearly, $20, 000 in year 1, $30, 000 in year 2, $40, 000 in year 3,
and $40, 000 in year 4. However, there's no scrap value in this case, so the resource is considered
exhausted after the four year time span. The IRR of this project is expected to be around 10%, so
even though we see an extended length of benefits, and a lower cost up front, the total benefit, as
we would look at it today given its net present value, would be considered lower.

Net Present Value

On the other side of internal rate of return is the net present value. This is the current value of all
expected future benefits. This accounts for all ongoing benefits, as well as any costs that might be
incurred with the time value of money also being taken into account. Just because we're going to
make $50, 000 a year over the next 5 years on a project, for example, doesn't really mean we're
going to make $250, 000 because you have to take into account the time value of that money.
Inflation gets in the way, the fact that we can't invest the money we will make in year four until we
get to year four, and so on, all mean that there needs to be a discounted rate applied to those future
earnings, so that we can better understand what that's worth to us today. So long as the net present
value is greater than 0 it's considered beneficial, however, we might have a higher hurdle than that
that must be cleared based on organizational policies or on the comparisons we do with other
alternatives when considering NPV. NPV is calculated using the same formula as IRR with the
summation of the net period cash flow divided by 1+R to the power of T, all of that less the initial
investment. R here is the interest rate, while T is the number of time periods, and in this case we
have the other information to plug in, such as the cash flows and the interest rate, but we don't yet
know what the net present value of all of these different factors is. Financial calculators and Excel
are both also helpful in calculating NPV due to the complications of its formula, and the types of
cash flows that can vary from year to year. Let's look at a couple different examples. In solution A
we have a $50, 000 investment that takes place that offers a $25, 000 benefit per year for 3 years
with an ending value of $0. Let's say that we're in a 5% interest rate environment because that's the
rate at which we can borrow money in order to fund this investment. Here we would expect a net
present value of $68, 081 with $0. 20. That's based on the $25, 000 per year in cash flows, $75, 000
in total, but we're applying that 5% interest rate to the money that we're not going to see until the
ends of years 1, 2, and 3 based on an investment that we make today. Solution B indicates a $75,
000 investment that has a $20, 000 benefit per year for a 5 year time span. Again, we have a $0
ending value, but our interest rate is a bit higher because the investment is larger and we'd have to
borrow more money. Even so, we see that the net present value of this investment is higher, at
more than $84, 000, due to the greater payback period over the span of 5 years instead of 3. As
such, so long as we can afford it, we should probably move ahead with solution B, even though it
means borrowing more money.

The Business Case

At last, we've evaluated our different alternatives, and we are ready to build a business case around
the one we'd like to recommend. In some cases, projects might be expedited directly to the
chartering process after we've analyzed these options, however, developing business cases can
allow for all of these disparate proposals and alternatives to be evaluated on a more even basis, so
that we can make certain that we have consensus around the solution we'd like to move forward
with. This results in better decision making, and less resources wasted during the chartering
process where we might work on project charters that could result in rejections later on because
stakeholders determine, once they see the additional details, that they really don't like that
alternative, and they'd like to consider something else, so a business case gives us an opportunity
to create a more initial document, something a little more provisional in nature before going into the
trouble that goes into making a fully-fledged project charter. The details that are included in a
business case will vary by the situation and the organization, and can be more or less
comprehensive in nature, especially on topics that are considered a priority or not a priority by your
organization. In some cases, we might want to have a lot of information about projected costs and
benefits right up front, whereas in other organizations maybe the focus is more on what the
qualitative benefits to the organization will be, and how it will help some of the functional problems
that we see in our day to day operations as opposed to what the exact cost or dollar benefit might
be. Whatever the scenario might be, creating a business case is a useful thought process, even for
organizations that have less rigid structures in place, and don't require as much information.
Typically we'll have an idea of what sort of details are expected of us because business cases are
templated in order for them to be easily compared with other cases. Even if you are exhausting all of
the different alternatives that relate to your specific problem, it's unlikely that yours is the only
problem being investigated within the company, especially if you work in a larger organization. As
such, sometimes decisions have to be made between several different problems or opportunities of
which one to pursue based on the business cases created for each. As such, following a similar
format allows upper level executives and other key stakeholders to more easily compare them, to
decide where they'd like to place the organizations focus first. The business case compiles the
results of all of the work that we've completed up until this point, which includes information, first and
foremost, on the problem or the opportunity. Why are we suggesting action be taken in the first
place? We should have a formal statement of the situation and how it relates to the strategic and
business goals of our division, our functional area or the enterprise at large. It should indicate who is
likely to be impacted by either inaction, action or action being taken along the way. This also serves
as a list of potential stakeholders for a project. It's appropriate to include any relevant data here as
well that can help to backup that a problem really is a problem or that an opportunity really is an
opportunity we should consider exploring. How do organizational goals and objectives relate to the
situation, and to what extent do they do so? It could be that our problem is relatively periphery to the
central philosophies and guiding principles of the company or it could be right there in the headlights
of what our major objectives and goals are as a company. The results of root cause analysis should
be included, along with any useful data and visualizations that can show that we've thought about
what the true problem is, and how to create a comprehensive, long-lasting solution to it, and not
simply treat the symptoms. We should also include a description of our current capabilities relating
to this issue, as well as what the desired or needed capabilities might be. Any information on gaps
and capabilities, and how we could potentially fill them, should be included here as well. That leads
directly to recommending action. What options are open for action, and what action will we
recommend taking? We should include the feasibility analysis results for all of the options we end up
presenting. Sure, some that we considered early on might not make the cut, but as we said earlier,
it's important to include several different options, even if you think one is certainly the strongest, so
that you can provide proper perspective to the stakeholders who can benefit from the business
case. You should present a ranked order of these presented options, and give substantial context
for the recommended action. How did you rank them, and how did you arrive at the particular
ranking that you have in place? What went into creating the weighted ranking system, for example,
and how are votes cast when comparing different options against each other? We should also
include high-level information on our suggested implementation strategy for the recommended
action. It's not up to us to create a full project plan, but we should at least give that roadmap of how
we foresee that strategy being implemented, given that it's the one that we're suggesting. Finally, we
should also include some information on how to conduct evaluations, even at this early point. We
need to know how the benefits can be measured, and how we can check to make sure that they're
in line with our expectations. By laying out guidelines in this regard early on we can help to shape
the project charter and project plans to ensure a strong monitoring and controlling process. Metrics
to ensure the successful completion of the objectives should be included at this point or at least
provisional ones that we can use until the project team can create ones that even better fit the final
solution. The business case overall and evaluation criteria serve as important foundational elements
for the project charter, and so including this evaluation criteria early on, along with a roadmap of how
we think actions should take place moving forward, can be very informative as the chartering
process begins.

Module Review
Let's take a moment to review. When recommending action what we're really doing is
recommending what capability gaps should be filled, and how we should go about filling them in
order to get to that desired future state that we've identified. We should analyze, assess, and rank
the different courses of action that might be possible, taking these different alternatives and figuring
out which one best fits our objectives and our business's philosophies and needs. We should also
develop high-level objectives and a roadmap for progress, so that we know the general path that
should be followed, and can help the project chartering process be more successful if key
stakeholders choose to take action based on our recommendations. When weighing the feasibility of
different options we can often benefit from comparing these options on a one-on-one basis. This can
be helpful in ranking possibilities because it allows us to look at each one in a vacuum compared to
each other potential option, and then rank them in a more objective fashion than might be possible if
we're looking at five or six alternatives all at the same time. Weight-ranking can then often be used
to prioritize attributes that are being compared, so we can have a system in place for weighing
metrics, such as technical feasibility, and cost effectiveness, and timeliness, and that we can rank
these by comparing options one on one, and then applying scores to each one. By doing so we can
then determine an objective ranking for each of our different alternatives based on a sound process.
Operational feasibility, technical feasibility, and cost-effectiveness are among the areas that can be
considered in this analysis, but the exact weight or focus that they're given, and any additional
factors that you might add in, can vary based on the type of project or organization we're talking
about. There are different ways to project value of the project in particular, which is important in
making the business case. A payback period is the amount of time until a project investment is
payed back in whole from the benefit of the action we'd seek to take. Longer payback periods
indicate higher risk, so those with lower ones are typically desired. Return on investment is the
projected net benefit from our initial investment, typically expressed in a percentage format,
however, ROI does not include any ongoing costs that we might see related to the project, and
therefore, doesn't always provide a clear measure in more complex cases. Internal rate of return can
be helpful here because it's an estimated annual yield of the projects investment, including both
upfront and those ongoing costs. Net present value can estimate the current value of an investment,
given all of its expected future benefits and costs, as well as when we would see those based on an
interest rate set perhaps by the amount we're borrowing or the amount of money we could make if
we applied our resources to a different project entirely. When creating a business case we should
seek to include a variety of elements, even though the details might change a bit depending on the
situation, and your organizations expectations. We should definitely include information on the
underlying problem or opportunity that we're seeking to address, as well as an analysis of the
situation as it exists today. We should include a list of possible actions that we could take, along with
our recommendation out of that list of actions, and why we're recommending it. We should include a
high level roadmap for action, how we would foresee a project taking place that could help to
address this problem or opportunity based on the alternative we've recommended, and we should
include criteria that will help us to know as that project work begins and progresses, whether or not
we are actually on the pathway to solving the problem or leveraging the opportunity we are seeking
to address. With that, we've reached the end of this introduction to business analysis and needs
assessment. Congratulations. I hope you feel a little more informed now about what it is business
analysts do, how they go about their work, and how it might apply to different types of environments.
In the next course we're going to look more deeply at how we plan business analysis, how we set up
the formal structures necessary to gather all of the information from stakeholders that we can then
use to develop these sort of requirements, and later, recommendations, allowing us to build that full,
strong business case, and then move forward toward taking action. I'll look forward to seeing you
then, but once again, congratulations!