Getting started when your company doesn't perform strategy analysis

Selecting transcript lines in this section will navigate to timestamp in the video
- When you're tasked with moving a project forward, I understand you're not always
in a position to change your organization's practices to incorporate strategy
analysis. But this doesn't mean your team needs to remain in the dark about why
their project is important, or what the intended purpose is for the solution they're
building. Whether your organization is failing to communicate the why or
sidestepping strategy analysis altogether, you can overcome these challenges in
small ways. A key practice to develop more successful solutions is to slow down
before beginning a project, and elicit information to gain necessary context. To do
this, set up time to talk to your business partners. Your objective is to obtain the
missing information that ties your development work to the organization's
strategy. Doing so provides you the why behind your work and helps you avoid
making assumptions. To accomplish this, come prepared to the conversation with a
good set of questions to help draw out the key pieces of information that will
provide missing context. Focus on obtaining information about the business
need. Ask what are the reasons for needing to address this business situation? Also,
ask what the intended business objectives are, and also, ask your business partners if
there are any options that will address the current situation. As you ask about these
topics, the people you speak with may have never thought of the business
situation to the degree you're thinking about it. They might have had a rough idea of
the problem but never looked into the real root cause of the situation, or they may
have loosely defined their objectives but overlooked identifying measurable
criteria to evaluate against. That's okay, the goal is to use this time to discover what's
missing. It's also possible your business partners didn't write a business case. They
may have been able to champion their idea, speaking to senior leaders using only
their domain knowledge and business acumen. In this case, their analysis was loosely
done. That's okay, the context you'll need resides in their minds, and while it might
take a couple of conversations, it shouldn't be too difficult to obtain. You may find
that someone already developed a business case but just overlooked sharing it. If
written well, the business case will contain a lot of the context you're needing. While
it might be disappointing that your organization hasn't incorporated strategy
analysis practices formally, or in the way you'll learn about in this course, you can still
use the best practices to tease out the details, gain context, and avoid making
assumptions. Doing this will move the solution development in the right
direction. And hey, if your organization is up for improvements formally
incorporating something new, then by all means, help them get started by folding in
the practices you'll learn about in this course.

Strategy analysis key concepts

Selecting transcript lines in this section will navigate to timestamp in the video
- As you get started with strategy analysis practices in your organization, let's
establish a common vocabulary to roll out the practices more seamlessly.  Your pre-
project work will be easier when everyone is using the same common language. Let's
start by taking a look at the most common terms used when discussing strategy
analysis. The first term is change initiative. An initiative is a specific project,
program, or action taken to solve some business problem or achieve some specific
change objective. This definition supports the idea that strategy analysis is performed
in areas of your business that goes beyond project-focused work. For example,
business changes can be rolled out as part of a program, or as the result of ongoing
process improvement and operational efforts. Does your company have a dedicated
staff who analyzes workflows or customer experiences? If so, they are doing this work
on an ongoing basis, looking for ways to improve processes and not supporting a
specific project. The term change initiative, therefore, reminds us that strategy
analysis work happens beyond the project space. The second term is business
need. The business need is a problem or opportunity of strategic or tactical
importance. Think about your last project. What problem or opportunity was your
business wrestling with? Lost revenue, cost increases, whatever the business was
looking to address, this was your business need. Business needs establish why the
change initiative is important. For example, a sponsor might identify the need to
address inefficiencies in processing customer orders, or a senior executive might
have a need to integrate the operations from a newly acquired business. Alongside
the business need, we can write business goals and objectives to explain what we
want to do to accomplish the business need. Goals are high level statements, while
objectives are more detailed and measurable. For example, a business goal might
be to address inefficiencies in processing customer orders, while the business
objective would be to improve processing time by 30%. Now, in order to define the
business needs, goals and objectives, you'll have to understand aspects of the
current environment. This is what we call the current state. It can be called the as-is
environment. But either way, it's the business environment today. It's made up of
existing capabilities, such as processes, products, services, people, IT systems, just to
name a few. Current state understanding is good, but we're making changes so we're
transforming the current state. We're going to the future. The future state, also
known as the to-be environment, is the desired business environment after the
proposed changes are made. For example, if we successfully implement a new
commercial off-the-shelf software package, the future state reflects what the
business environment looks like once the software package implements. Finally, the
last term, change strategy. A change strategy is a plan to move the current state to
the future state to achieve the desired business objectives. It's your explanation of
the major activities needing to take place to transition the business into its future
state. You might come up with a few change strategies, but there'll be a preferred
change strategy that is explained in detail so it's clear how the business
transformation will happen. Remember, establishing common terms with your
team will facilitate a much smoother adoption of the practices. As you start to
establish strategy analysis practices in your organization, bring along the key
terms and start using them as a team.

Analyze current state

Selecting transcript lines in this section will navigate to timestamp in the video
- Think about the last time you made a major purchase. Maybe it was a new car, a
house or a computer. What was the thought process you went through to decide
whether the purchase was needed? What did you consider in your analysis? For
example, take Bob's situation. Bob is looking to purchase new equipment for his
team. He's not sure if now is the right time to make this purchase. He thinks about
his current situation. His analysis includes the age of the current equipment, its value,
condition and so on. He first focuses on understanding the current state of his
existing situation so he can decide whether the condition of the existing equipment
warrants purchasing new equipment. In strategy analysis, the purpose of analyzing
the current state is to understand the business need and current business
environment before implementing changes into it. Here's another example. Paul is
director of a call center for a major financial institution. He's noticed that it's taking
longer to service customer calls, resulting in a huge drop in the customer satisfaction
scores. He wants to replace the call center software to address the customer service
issues and is asking senior leaders for $625,000 to do so. Just like Bob, Paul requires
some current state analysis to help support his decision making. When you analyze
the current state as part of strategy analysis, you want to seek information that will
help you gather enough context to understand the situation at hand. In Paul's case,
he needs to identify the real reason why calls are taking longer. Maybe it's the
software, but maybe it's a training issue with the agents. Maybe it's a business
change occurring somewhere else that's adding to the customer confusion. If he
spends the $625,000 on replacing the software and that wasn't the root cause of the
problem, he's pursued the wrong solution and wasted the company's
money. Analyzing the current state isn't hard. It just requires time to use
techniques, some of which I cover in this course, to analyze the business
environment where the problem or opportunity exists. Which aspects are analyzed in
your environment is dependent on the business need. In Paul's case, the analysis
might involve looking at call center processes, observing call center agents in
action, or talking to leaders who understand operational metrics. Whatever makes
sense to provide an understanding of the existing business environment is what
you'll be looking at. We have to know whether replacing the software is the right
solution and we can't know this unless we obtain insight into what the call center
environment is like today. If done correctly, analyzing the current state will result in a
shared understanding about aspects of the current state that are relevant to the
problem or opportunity you're analyzing. This might include a high level
description about the capabilities, resources or components of enterprise
architecture that would be important for everyone to understand due to some
relationship to the situation being analyzed. And a list of business
requirements, which could be represented as goals, objectives, and outcomes the
business is interested in achieving. Without this context, the business is just jumping
into conclusions and spending money without understanding the big picture. As you
begin establishing strategy analysis practices in your organization, make sure to
make analyzing the current state a goal in your process.

Technique: Determining root cause

Selecting transcript lines in this section will navigate to timestamp in the video
- Many times in business, bad decisions are the result of making incorrect
assumptions. It happens all the time, especially when identifying the root cause for a
business problem. But how do you improve your skills to accurately identify root
causes? There are actually a number of techniques you can use. Root cause analysis
is a problem-solving approach used to discover the underlying cause of why
problems exist in the first place. When we know the root cause of a problem, we can
propose the right solutions for addressing it. Otherwise, if you don't do this
work, you run the risk of proposing solutions based on assumptions and making the
wrong decisions. Let's look at some root cause analysis techniques. Any of these are
good options to use in a workshop or even when conducting interviews with
stakeholders. Five whys is a fun technique using a process of repetitively asking a
series of why questions to get to the root cause of the situation. You ask your
stakeholders to state the problem. They tell you that the amount of time it's taking to
fulfill customer orders has spiked. You ask, "Why is this happening?" They tell you
they don't have enough people. You capture their answers and ask a second why
question, probing for more details. You ask, "Why don't you have enough
people?" And you continue the process until you've drilled into the
situation. Typically, this means asking about five questions. Now, five isn't a hard or
fast rule, but it's the typical amount of questioning required to be able to identify the
underlying problem. To see a full five why conversation between a business leader
and business analyst, check out the document titled 5Whys in the Exercise
Files. Here's another technique to try, the fishbone diagram, also known as a cause-
and-effect diagram. It's a visual model for facilitating root cause discussions that look
like this. It can help you decompose causes and effects as you work through
understanding a root cause. Start by writing the business effect at the head of the
fish, and then you facilitate discussions to draw out underlying causes, which you'll
represent on the various fish bones. Using our first example, I'll write Fulfillment Time
Increasing. Then I'll facilitate discussions to draw out a list of potential causes, placing
each on the main bones of the fish. From the main bones, I'll place secondary
causes and tertiary causes if we need to. The information used to build out the fish is
taken from stakeholder discussions. You use the consecutive questioning of five
whys to fill in all the bones on the diagram. Now, there's also an interrelationship
diagram, another useful technique to analyze cause-and-effect relationships. Start
with a blank canvas. Place the main problem on the board to focus your
participants. Ask participants to brainstorm a list of causes for the problem. For each
cause, add an oval on the board and label it appropriately. Then focus your
participants on a single cause at a time, asking them to understand the effect each is
having on the business. Place each effect on the board, and establish a
relationship between each cause and its associated effects. Use an arrow to establish
these relationships, and have the arrowhead pointing to the effect. When participants
have exhausted providing causes and effects, count up the number of inputs and
outputs. Once completed, review the model together to pinpoint the primary causes
for the problem. The oval having the largest number of outbound arrows will be the
main cause of the problem under discussion. In our example, high shipping cost is
the main cause of the problem. If you find yourself solving business
problems without understanding what's causing the situation, don't assume. Try one
or more root cause techniques. Doing so will help you avoid making decisions off
assumptions and avoid costly mistakes.

Technique: Business model canvas

Selecting transcript lines in this section will navigate to timestamp in the video
- In business analysis, information is elicited through discussions with participants. As
you begin to analyze the current state of a business, you might consider using the
business model canvas. The business model canvas is a popular strategic analysis
technique used to explore how the business currently creates and delivers value for
its customers. Creating this canvas will help you gather the necessary information
more easily, because being able to see the work will support more collaboration from
your audience. The objective of the framework is to break down the business
model into nine core components. As information is provided, it's captured and
placed on the canvas. The canvas can look something like this. Let's review each
component that you will want to focus your elicitation on to understand your current
state business model. First, the key partnership section is where you'll list the
supporting organizations and businesses that help support your business model. An
example might be a vendor provided by an offshore development team. Second, the
key activities should show the major activities required to create, deliver and
maintain value as well is operationally support your business processes. This section
is often broken up by looking at work that adds value for customers, value add, work
performed that customers don't want, non-value add, and activities that must be
included, possibly because regulations require it but customers are not benefiting
from them, business, non-value add. Third, the key resources identifies any
physical, financial, intellectual or human assets required to support the business
model. An example of an intellectual asset would be a patent which physical resource
examples would be machinery and buildings. Fourth, the value proposition section is
where you'll capture the products and services produced or supported that deliver
value to your customers. Then you have the customer relationship section where
you'll list different ways your business creates and maintains relationships with its
customers. Here, you'll identify approaches used to establish and retain
customers. After the customer relationship section is the channel section. The
channels is where you'll identify the customer touch points. These are the ways your
business interacts with and delivers value to its customers. An example of a process
focused channel is a distribution channel. A communication channel would be a
marketing channel. The seventh section is customer segments. It's where you'll
collect who your business creates value for. This would be anybody who pays for
your products or services or uses what you build or produce. Next in the revenue
stream section, you'll identify the different ways your business makes money. Here,
you can list transactions that are considered one time for example, where a customer
pays for a product or reoccurring transactions like subscription and usage fees. And
finally, in the cost structure, you'll itemize the costs associated with the products and
services produced. Once you've filled out the canvas, the model represents your
current state business model. The team can use the results to look for key
areas where improvements might be focused such as where there are
elements consuming a large amount of time, people or money resources. But don't
forget to discuss areas that are strong and should remain as is.

echnique: SWOT analysis

Selecting transcript lines in this section will navigate to timestamp in the video
- The SWOT technique is a favorite in the strategic planning space. It's no wonder it
works well when performing strategy analysis too. The technique can be used to
analyze at any level, for example, for an enterprise, organization, business unit, or
department. And in strategy analysis, the technique can be used to draw out
information about the current state. Through the model, the facilitator draws out the
strengths, weaknesses, opportunities, and threats, or SWOT, impacting the
business. Once complete, the strengths and opportunities provide ideas the business
may wish to exploit the future state. The weaknesses and threats serve as reminders
of areas to mitigate. Let's take a look at how to perform the SWOT analysis so you
can immediately begin to use it in your strategy analysis activities. First, draw the
matrix for all participants and label it strengths, weaknesses, opportunities and
threats, as shown here. Flip charts and whiteboards work well when building the
model in a face to face setting. Then walk your audience through each section of the
grid, asking probing questions. For strengths, ask participants to share what business
the does well. Examples might be they hold specific patents or possess unique skills
among staff. For weaknesses, participants provide aspects of the business that are
poorly performing. One example could be a struggle to fulfill orders. Opportunities
represent external elements that have the potential to provide great value. An
example could be a new technology the company wants to leverage, such as
machine learning. And threats should be anything in the external environment that
has a direct negative impact on the business. You can think of burdensome
regulations or high barriers to enter markets as two examples. As you focus on each
quadrant on the grid, participants should begin to share input. Make sure to
condense their language so the content fits on the grid. Write just enough to get the
points across. Once the grid's filled out, facilitate more detailed discussion around
each entry. Analyze what has been added to the board. In your discussion, ask the
team to identify ways to apply strengths to take advantage of opportunities. For
example, your company might have developed a revolutionary system for internal
use, but then they decide to offer it externally, opening up a new revenue stream and
raising their brand awareness. Strengths can also be used to minimize threats. A
company competing with a large competitor, the threat, might level their strong
financial reserves, a strength, to acquire one or more smaller companies for the
purpose of taking a leading position in the marketplace. The end goal of this
technique is to identify ways to take advantage of opportunities and to minimize or
eliminate current threats. Everything learned becomes important in the context of
strategy analysis discussions. The results are usable as input when formulating ideas
for the future state and building out the change strategy, steps you'll take after
completing the current state analysis.

Technique: Process modeling

Selecting transcript lines in this section will navigate to timestamp in the video
- We've been using maps as a tool to help us get from point A to point B for
years, so it's no surprise that as humans we are very comfortable breaking down
sequential activities visually to show flow and sequence. This too is the concept
behind process modeling. A business process model describes the sequential flow of
work across the defined tasks and activities through an enterprise or part of an
enterprise. You can think of a process model as the visual language to show how
work gets done. What is modeled can be business-focused or IT-focused. Another
benefit of using process models is that they can be used to analyze processes at
different levels of the enterprise. You can begin discussing processes from a high
level, also referred to as the conceptual level, all the way down to the details, which
can show specific steps performed in each process.  This makes the model super
handy when discussing the current state and trying to educate everyone on the
team about how different functional groups perform their work. Process models can
also be constructed to depict the processes for different stakeholder groups. Hear
the examples show both the process for the customer and the deli clerk at a grocery
store. In strategy analysis we build process models to analyze both current and future
states. For example, a current state business process model can show the sequence
of work activities such as what happens first, second, third and beyond in the current
environment then a future state process model can show the desired flow after
proposed business changes occur. A comparison of the two can showcase desired
changes. While the models can tell us a lot it's very and to provide a textual
description for each process or the major processes so additional information can be
shared without having to put a lot of details on the model itself. Some common
information often noted are who performs or partakes in the process, the individual
steps performed within each process, triggers that can initiate the process, for
example, the completion of an activity or point in time on a schedule, and expected
outputs or results. Process modeling has been around for years, so there are several
types that exist, too, besides business process models. And process models are just
fun. Use them to explain the current and future state processes. You may find they
help maintain stakeholder engagement and participation because they are just so
well understood.

Ch 3

Define future state

Selecting transcript lines in this section will navigate to timestamp in the video
- Abraham Lincoln is famously quoted as saying, "The best way to predict the future
is to create it." And when it comes to defining the future state, that's pretty much
what you'll be helping your organization do. The purpose of defining the future
state is to help your business partners explain what they are looking to accomplish if
the change in a is pursued. To accomplish this task continue to use techniques to
perform research and lead discussions with business leaders. In your conversations,
aim to form a shared understanding of the goals and business objectives by sharing
information you're collecting with stakeholders and work with them to find what
success looks like for them in the future. Make sure to speak in terms of expected
outcomes and ensure what is stated is measurable. This will help you provide
clarity around what the business wants to achieve once the change initiative is
complete. Also don't forget to conduct a review of the enterprise architecture to help
with identifying any new, modified or eliminated architectural components the future
state might incorporate. Enterprise architecture is a description of the business
processes, information, technology, people, operations, information, and projects of
an enterprise and the relationships between them. There's a lot here to unpack, so
bring in different experts to share their knowledge about these aspects of the
business to formulate a future state that is feasible. Of course, any of the architecture
is changeable, but these conversations help draw out the size of changes required for
the future state the business is asking for. And of course the more changes
required, the more complexity is introduced, as well as the potential costs, which
brings me to the value discussion. Make sure to reach a shared understanding about
the potential value of the future state. You'll want to make sure conversations of the
expected benefits are grounded against the conversations about the expected
costs. Keep in mind that value equals benefits minus costs, and while the formula is
easy to remember it's often forgotten as leaders focus on the shiny list of
benefits. Your job is to understand the costs associated with the proposed
changes, so conversations about the future can be grounded in a value discussion. If
done correctly, defining the future state will result in the business objectives that the
business is looking to achieve. A future state description, which is a high level
explanation of the desired future state describing the overall future state
vision, including components of the enterprise proposed to be added or
modified. Changes might impact future capabilities, policies, resources,
dependencies, or infrastructure, just to name a few. And finally a shared
understanding of the potential value the change initiative will provide to ensure
expected benefits are grounded against costs. Defining the future state is a research
exercise and the information, while thorough does not have to be detailed. Estimates
will start off high and that's okay at this stage. You are establishing the context that
will eventually help you complete the fourth task when you create a change strategy.

Identifying solution options to analyze

Selecting transcript lines in this section will navigate to timestamp in the video
- We have all dealt with a situation that's difficult to figure out. Maybe we leaned on
a family member, a significant other, or a friend to come up with suggestions of how
to address a problem we were struggling with. Identifying solution options in
strategy analysis is very similar, in that you will be working with others to define your
options. Once you start taking the lead in analyzing the current environment where
the situation exists, you might have already begun to think about some broad
solution ideas for the situation you're beginning to grasp. And if so, that's a great
start. But here's the deal. While the goal is to identify potential solution options for
implementation after your current and future state analysis, you're never expected to
be the sole source for identifying solution options. It's just not practical. While you
will acquire a lot of knowledge over the course of time supporting the
business, you're never going to be the expert on everything business and
technical. There's a lot of domain knowledge and expertise that feeds into the
creation of good solution options. Many individuals contribute to generating this
list. Here are some of the sources where solution options might be identified. First,
vendors' input. Perhaps this is through the completion of requests for information,
RFI, requests for quote, RFQ, or requests for proposal, RFP, process. While each of
these are slightly different in scope and approach, the underlying purpose is
similar, where vendors are solicited to provide input on how their products and
services can address a specific business need. Second, subject matter experts. By
completing one or more brainstorming sessions with subject matter
experts representing either the business or IT, after sharing the business need,
participants can brainstorm as many possible solution options as possible for
addressing the situation. You could also conduct focus groups or to bring a group of
individuals together to solicit input on possible ways to meet the business
need. Third, competition. Through benchmarking and market analysis, you can
obtain ideas from the best in class companies, including competitors, to generate
new ideas to build from. You might be thinking, "What about the
customers?" Conducting meetings with customers, stakeholders, and delivery team
members often will help you deliver solution options too. Just be specific in focusing
your discussions on either the problem-solving or business customer
opportunities. There are many techniques to elicit information throughout strategy
analysis. I've shared a few to get you started in this course. As you build out your
strategy analysis practices, you'll want to apply these different techniques to help
your team identify the list of solution options. Through ongoing conversations, the
list will evolve and eventually turn into the set of options you can analyze, and then
narrow down to a list you can present to decision-makers. There are many times in
strategy analysis where you'll work independently, but identifying solution options is
definitely not one of those times. Take advantage of the expertise that resides across
the organization, and recognize that often the best solution ideas are the results of a
collaborative effort.

Technique: Elicitation

Selecting transcript lines in this section will navigate to timestamp in the video
- Elicitation is an important activity during strategy analysis, so you'll want to choose
a combination of elicitation techniques to obtain information that's important for
your analysis. Let's review six of my favorite to support your elicitation efforts during
strategy analysis. First, benchmarking. It's an elicitation technique that involves
comparing aspects of your environment against the best-in-class competitors or
industry best practices. The idea is to learn from others' success. Benchmarking is
very useful to generate an initial list of ideas when defining the future state and to
generate ideas to formulate potential chain strategies. Second, brainstorming. This
technique allows for the elicitation of a large number of ideas within a short window
of time. It's one of the more popular elicitation techniques in practice, as it's easy to
perform and well understood by most stakeholders. You could conduct a
brainstorming session to capture initial ideas for possible improvements, potential
conditions for a future state, and to help generate an initial list of risks for a risk
register. Third, document analysis. It's another easy technique to learn and apply
too. Elicitation is not limited to only obtaining information from people. You can
elicit a ton of valuable information to support analysis by reviewing existing
documentation. Document analysis is a superb technique for acquiring information
about the current state, since most of what your organization produces is in the form
of systems or technical documentation, standard operating procedures, work
instructions, et cetera. It's all written about the current environment. It's also helpful
to review documentation about the industry and competitive landscape you're
working in. Fourth, focus groups are powerful for obtaining insights from a select
group of participants, specifically to understand aspects of the current state or a
wishlist of wants for a future state. They are typically used by more experienced
analysts because it requires skills to choose the right participants and to formally run
the session. Fifth, interviews are one of the most heavily used elicitation
techniques. The idea is to elicit information from an individual one-on-one. Use them
to obtain information about aspects of the current state, desires for a future
state, and specifics about the business needs and the objectives. Almost any
information you're looking to obtain in strategy analysis can be obtained through an
interview. And finally, sixth, workshops. Provide set time and venue by which you
bring a group of stakeholders together to work on a topic of importance. These
require more experience, especially expertise in facilitation, but they're high
value. For strategy analysis, workshops are very useful to bring stakeholders
together to discuss aspects of the current state and the desires for the future
state. They're also helpful to combine with brainstorming. Doing so ensures the
information you're obtaining is drawn out in a variety of approaches, reducing the
risk that important information is overlooked.

Technique: Constraints, assumptions, risks, and dependencies

Selecting transcript lines in this section will navigate to timestamp in the video
- Once you've gone through the process of analyzing the current state and begun to
define the future state, you most likely will have more than one solution option. You
can now start to analyze them, but you need to analyze how solution A compares to
solution B and solution C, but what exactly are you looking to compare? How do you
begin these comparisons? If you and your team find it difficult to compare and
contrast the solution options up for consideration, you're not alone. It's a common
struggle, but doing so will help you evaluate how feasible each solution option
is, including things like cost, schedule, technical, and operational feasibility, all
important details that could persuade decision makers towards or away from a
specific option. What will help you elicit this information is determining the CARDs of
each solution option. CARD stands for constraints, assumptions, risks, and
dependencies. Constraints in business analysis are influencing factors that cannot be
changed, and they place a limit or restriction on an option. Some goals and
objectives may be too lofty for the budget, timeframe, and resources available. For
example, during analysis, you might discover an option is constrained by
policy, regulations, skillsets, or technology, making that option less valuable as
compared to other options. Constraints can also make an option riskier, such as
when the development work is constrained by a tight project schedule. The
constraint might impose pressures on the team to cut corners to meet the aggressive
timelines, resulting in the development of a lower-quality solution. Assumptions are
influencing factors that are believed to be true but haven't been confirmed to be
accurate or that could be true now but may not be true in the future. When a team
has to assume anything pertaining to a solution option, there's a degree of risk
introduced. Assumptions mean there is a chance that something assumed plays out
to not be true. The more assumptions surrounding a solution option, the riskier that
option is. A risk in business analysis is the effect of uncertainty on the value of a
change, a solution, or the enterprise. Business analysts identify risks that could
impact expected value, but the presence of risk alone is not conclusive to void a
solution option. Yes, it's true that some decision makers may be risk averse, turning
down risky options, but others may be risk seekers, desiring riskier options with the
hope of acquiring more return. For example, solution A exploits a new technology. If
it has a higher degree of risk, the team needs to have more time and money to figure
it out, but if all works out, the company may have built a solution that stands
apart from the competition, increasing market share and revenue, and lastly, a
dependency, it's a tie or a relationship between two things. A solution can be
dependent on a feature being delivered by another project team. The more
dependencies a solution has, the riskier the solution option is. Consider a solution
where the delivery team is dependent on a third party to complete a portion of the
development work. This dependency adds risk since the resources are external and
not under the full control of the contracting organization. As you compare and
contrast solution options, consider comparing based on the cards. While you don't
own the decision of which option is ultimately selected, you will have the
responsibility of putting forth great analysis. The details your business is seeking just
might be in the cards.

Technique: Gap analysis

Selecting transcript lines in this section will navigate to timestamp in the video
- We compare all the time. It's how we explain the differences between any two items
we're talking about. Something is faster, cheaper, better. Someone is taller, nicer,
funnier. In business analysis, performing comparisons is how we analyze. In another
technique where comparisons are important is during gap analysis when defining the
future state. A gap analysis is a comparison of the current state and the desired
future state of an enterprise in order to identify differences needing to be
addressed. This definition explains what we do in strategy analysis, but it doesn't tell
us how to do this. So let's take a look at some common comparisons business
analysts perform when performing gap analysis. First is the process gap
comparison. We build process models to represent the current state, build a second
set of process models for the future state, and then lead discussions to compare how
the current and the future state processes differ. The differences that exist between
the two sets of models identifies the gap. Knowing the gap is helpful to
emphasize what needs to change from a process perspective in order to achieve the
future state. A second way to analyze is performance gap comparisons. This is when
we build prototypes of different solutions. A prototype is a partial or simulated
approximation of the solution for the purpose of eliciting or validating requirements
with stakeholders. We can have prototypes built for two solution options and
demonstrate the prototypes in front of stakeholders so they can identify their likes
and dislikes for each option. This often is much better approach to lead solution
discussions because stakeholders can actually see the differences, what isn't covered
could change the solution option recommendation put forth during strategy
analysis. A third way is requirement gaps and these are identified through a
traceability matrix. A traceability matrix is a tool used to show the relationships
between business objectives, requirements of different levels, design solution
components, and test cases. In strategy analysis, the matrix can be used to identify
gaps where a business objective may not have supporting requirements yet
elicited or requirements have been elicited but those requirements can't be tied
back to a business objective. Where the first gap would signify where the elicitation
needs to occur, the latter situation would identify a problem where the business
analyst has worked outside the defined scope. And lastly, capability gaps. Capability
gaps pertain to differences between current and desired capabilities. A capability
consists of the set of activities the enterprise performs, the knowledge it has, the
products and services it provides, the functions it supports, and the methods it uses
to make decisions. In strategy analysis, analysts compare any one or more of these
items to help stakeholders identify a set of potential changes to move from the
current state to the future state. Consider presenting gaps you uncover textually and
visually to help your stakeholders identify and understand the gap areas. It's a great
way to help them focus on what's missing and what needs to be built or required to
achieve their desired future state.

Technique: Financial analysis of solution options

Selecting transcript lines in this section will navigate to timestamp in the video
- In strategy analysis, solution options are analyzed in many different ways, including
financially. Financial analysis provides decision makers guidance on whether a
solution is a good investment. Once solution options are identified, it's good practice
to analyze options to estimate the possible financial return of each. But analyzing
financially is one of the most feared ways to analyze because many business analysts
don't feel qualified or comfortable with their financial skills. But there's nothing to
fear because you're not expected to be an expert in finance. But you can and should
leverage those that are. Consider seeking out the assistance of a financial analyst or
similar role from your finance department who could perform the financial
calculations for the solution options listed in your business case. Your input is
analyzing the results of their work. You'll need someone who knows how senior
leaders make investment decisions and are familiar with the financial valuation
techniques most favored by your organization. Here are four commonly used
valuation techniques. The first is payback period. This is how long it takes for the
business to produce enough benefit from the solution to surpass the costs incurred
to build and deliver it. Because the payback period is a time period, it's represented
in months or years. The longer it will take the business to recover the original
investment, the higher the risk. For example, when comparing two options based on
the payback period, if the business covers this cost after year two with option A, but
it takes four years with option B, option B is riskier, hence option A is more
desirable. Then there's the return on investment or ROI. It's the amount of return
obtained for what was invested. It's calculated as a percentage by dividing the
average return or benefits by the projected cost to obtain them. It's not uncommon
for a business to establish a minimum ROI percentage in order to approve a business
case. As an example, if you're informed by finance that option A has an ROI of
30%, and option B has a return of 10%, option A is the better investment
financially. Now, have you heard about IRR? An internal rate of return or IRR is the
interest rate at which an investment breaks even. Another way to think of the IRR is
that it's used to calculate the amount of growth or return an investment is expected
to provide. Companies will establish a minimum IRR that investments must
surpass. These are referred to as hurdle rates. So if the hurdle rate is 10%, and if the
IRR for solution A is 12%, and it's 15% for solution B, both options are viable because
they surpass the hurdle rate. But solution B would be the preferred solution since its
financial return is more. And finally, the last valuation technique I'll leave you with is
net present value. This is used to calculate the difference between the present value
of both cash inflows and cash outflows over a specified time period. It takes into
consideration the time value of money, looking at the impacts of inflation and how
money can be invested and grow over the time period. You'll want to look for the
option with the highest NPV. I hope you won't shy away from including the financial
analysis in the future, now that you know it's perfectly acceptable to leverage the
financial experts in performing these calculations. Financial analysis is a tried and true
way many leaders make decisions about which solutions to invest in. So you won't
want to overlook including one or more of the valuation techniques, now that you
know your finance experts are there to help.

Ch4

Assess risks

Selecting transcript lines in this section will navigate to timestamp in the video
- So you've analyzed the current and future environments, and you've come up with
a list of possible solution options. You'll always want to analyze the solutions you're
considering fairly and you won't be able to do this without considering potential
risks. So now your third strategy analysis task is to assess risks of these solution
options. Remember, we're teaching these tasks sequentially to cover the process but
always keep in mind that all the business analysis tests, including strategy analysis
tests are performed iteratively. So it's expected that you could return to assess risks
again as new information surfaces or new situations arise that impact your prior
analysis results. Now, in business analysis, we define risk as the effect of
uncertainty on the value of a change, a solution or the enterprise. Notice, this
definition is directly tying risks to its effects on value. Therefore, assessing
risks involves identifying any uncertainties that could lead to your solution, providing
less value than what you're proposing to the decision makers it can provide. Your job
is to collaborate with your stakeholders to identify a list of risks, results of those risks
and the probability or how likely they are to happen. If they do happen, you'll want
to draw out information to assess the impacts and value. Here's the scenario. Say
your solution is projected to provide a cost savings of $500,000 a year by utilizing a
new technology to automate the intake of medical claims. But the team identifies
two risks. There's a risk in using the technology because they haven't implemented
anything like this before. There's also the potential for quality issues due to the
uncertainty over how well the automation works. You'll also want to draw out
information to assess the impacts on value. Continuing our discussion, we expected a
savings of $500,000 a year. Quality issues could lower the savings and the team feels
there's a high chance of this happening. If the technology doesn't work well, we may
achieve no savings at all. The team feels there's a medium chance of this
scenario. Every option under consideration can have some level of associated risk. As
a business analyst, you're not expected to create your list of risks on your own. Work
with your stakeholders and delivery team to determine risks they will have the
knowledge and experience that can help you draw this information out. Risks can be
uncovered by solution architects, product development teams, operational staff or by
reviewing lessons learned. Even the constraints and assumptions, and dependencies
identified during future state analysis are potential sources for identifying
risks. There're a variety of potential sources for identifying risks. Identify the risk first,
then work with the stakeholders to understand the probability of the risk
occurring and follow that up with an assessment of impact to value. You can even
consider applying techniques to help with this analysis, like the risk analysis
techniques discussed in this course.

Technique: Risk analysis and management

Selecting transcript lines in this section will navigate to timestamp in the video
- You know the panic that sets in when you're getting ready to implement a
solution, and all of a sudden a huge problem surfaces that's stopping the team from
delivering. The findings have to be reported, and management is not going to be
happy with the news. Team members are starting the blame game. It's
uncomfortable and stressful. You ask yourself, "How could the situation have been
avoided?" In strategy analysis, we minimize failures by using risk analysis in
management. The risk analysis technique directs the team to spend time early to
identify concerns or uncertainties that could negatively impact each solution. For
example, a risk area might be from the development and delivery of the
solution, such as the ability of the team to deliver on time, within budget, within
scope, as well as impede the expected value of the solution. As a result of analyzing
risks early, teams are better prepared with plans of action up front, which is much
better, much preferred than being hit with the unanticipated circumstances. Risk
analysis involves four steps. First, risk identification involves identifying a list of
potential risks that could impact the solution delivery, including anything that could
impede the expected value of the solution. Consider facilitating a brainstorming
session to generate a quick list of potential risks. Your key stakeholders may apply
lessons learned or expert judgment when helping create the list. This second step of
this technique is risk analysis, or analyzing each risk based on the impact and
probability. Impacts can be stated in terms of impact to value, cost, schedule or
quality. And probability can be stated as a percentage or by using an indicator such
as low, medium, high. For example, a tight labor market could result in poor service
to customers due to a high number of untrained workers. The business determines
the impact to quality is high and the probability of occurrence is also high, based on
conditions they are currently facing in the marketplace. Third, risk evaluation is
determining whether each risk is acceptable. Through discussions with key
stakeholders, here you'll draw out risk tolerance levels. For example, if risk averse, the
business is unwilling to accept a risk. If risk neutral, they will accept some
risk, depending on its consequences. And if risk seeking, they're willing to accept or
even seek out more risk in order to achieve more gain or value. Each risk should be
evaluated based on these or other tolerance levels you'll establish. In our prior
examples, the company prides itself on quality. Therefore, they evaluate the risk of
poor service and state they are unwilling to accept the risk of employing a high
number of untrained workers due to its impact on the customer experience. Finally,
fourth, risk treatment, this is establishing the course of action the business will take
should the risk occur. To arrive at this answer, you'll use the results of risk
analysis and risk evaluation. Using our prior example, because quality is a
cornerstone of how this business operates, the business chooses to avoid the risk
completely. So they plan to roll out an incentive program to ensure attrition rates
stay below 8%. They will also require all new hires complete two weeks of mandatory
training before starting their positions. Identifying and managing risks early and
often helps teams be better prepared when negative situations happen. Consider
using this technique to keep a pulse on any potential risk that can impact the
solution, and get your team prepared to know how to react should the risk occur.

Ch5

Define change strategy

Selecting transcript lines in this section will navigate to timestamp in the video
- It's so rewarding to finally get to the last chapter of a novel. You finally get to see
how the storyline ends. You'll have a similar feeling once you approach the fourth
strategy analysis, Task 2, Define Change Strategy. Here, you'll finally get to see how
all your prior analysis comes together to finish the story. The purpose of the change
strategy is to use the results of all your prior analysis to recommend the best
approach for achieving the business objectives. You can think of your change
strategy as a high level plan made up of a list of key activities required to achieve the
future state. You might suggest creating a program of work with many projects
underneath it, or delivering the changes incrementally over time. How the plan is
structured impacts the timing of when business value will be delivered. There isn't a
standard format for defining a change strategy. No matter the format you
choose, include key elements in the plan. Depending on the size and complexity of
the change initiative, the information you're assembling can be quite large. Some
organizations will require the information to be assembled in the form of a business
case. In other organizations, the format may be less formal. Here are key elements to
consider when developing your change strategy. First, summarize the list of the
desired changes. You've been touching upon this throughout the other tasks, but
task four is about pulling the information together into one consolidated
report. Second, identify the alternative approaches you're considering in your
research. Provide a high level summary of each approach, including the benefits and
costs. If the goal was to improve customer engagement, you might have had the idea
to end enhance the website, start over and rebuild a new website, or build a new
mobile app. You will have obtained this information in your prior analysis. Then put
forth your recommended approach. This is the pinnacle of your research, so state the
recommendation with conviction. Be sure to speak to why you reached your
conclusion. Include more details than you provide for the alternatives. For example,
dig into the required investments beyond the financial obligations. Answer what are
the required investments from a people and time perspective? Identify the impacted
stakeholders. These are the people or groups who will be positively or negatively
impacted by the changes being proposed. Clearly explain what is in scope and out of
scope. Scope can be discussed on various levels, including new or enhanced IT
systems, processes, capabilities or organizational structures to name a few. The
results of any completed gap analysis can assist in defining scope. Finally, provide
your risk analysis for the recommended approach. Risks are always a big concern for
leaders, so share the findings for the alternatives you're presenting. Regardless of the
format used to communicate the change strategy, this is your opportunity to pull
your strategy analysis results together and tell the story of the future. The results are
reviewed with the decision makers, who will either approve the change
strategy, decline to invest in the change, or request more information, at which point
you'll revisit prior strategy analysis to further gather the information they request.

Technique: Business cases

Selecting transcript lines in this section will navigate to timestamp in the video
- If you've been working in the project space for any length of time, chances are you
have worked with business cases. Maybe you've been asked to create one, or
possibly, you've been on the receiving end of one, using its contents to guide your
work. A business case captures the rationale for undertaking a change. That change
can be anything that requires time, money and or people resources, whether it's the
acquisition of new equipment, new software, even a new service the business wants
to provide its customers. The list of ideas that can be championed through a
business case are endless. Business cases are useful because they provide a
structured way to assemble the analysis results from the fourth strategy analysis
task, Define Change Strategy. They've been around for a long time, and many
organizations require them to approve funding for a change initiative. While some
organizations may require a formalized business case, one that follows a defined
template and consists of a lot of research results, other organizations may not
require a lot of formality at all. If you're not sure what to include, there are common
sections. I recommend starting with a description of the business need. This is one
paragraph, or two, that describes the business problem or opportunity the
organization wants to address and an explanation of why the change is
important. Then this section is often followed up with a list of business
objectives, quantifying the desired outcomes the business wants to achieve if they
pursue the change. You'll also want to list the different solution options being
considered to address the business need. Since the business case is relied upon to
guide business decision making, only include options that make sense for a business
decision maker to consider. You might be asking, "How do you know an option
makes sense?" We refer to this as feasibility, and there are four factors you want to
consider. First, financial feasibility. This refers to an options expected costs against
the potential benefits that option will provide. Financial feasibility can be
determined by using one or more financial analysis techniques we discuss in this
course. Second, operational feasibility. This is your consideration of whether the
organization has the ability to support the solution after it's built and
delivered. Operational subject matter experts are a great source to provide this
information using the elicitation techniques we covered in this course. Third,
schedule feasibility. This pertains to whether the solution option can be delivered
within the desired timeframe. You'll have pulled this information together when
discussing the change strategy. And finally, the fourth factor is technical
feasibility. Assess your organization's ability to deliver the solution option using
existing or acquired technologies and skills. Your technology experts and solution
architects will provide guidance here. Finally, while analyzing the choices based on
feasibility is crucial, you should also provide your analysis of their associated
constraints, assumptions, risks and dependencies, or CARDs, too. Remember, we
covered the CARDs technique in the section on defining the future state. Any of
these factors can help decision makers narrow down their solution choices. Building
a business case is not required, as long as the analysis happens when defining the
change strategy. But a business case is a great way to pull your research together in
a consistent format decision makers are often familiar with.

Supporting project initiation

Selecting transcript lines in this section will navigate to timestamp in the video
- You've been thorough in your analysis and created a change strategy. As a result,
you presented your findings. Decision makers have approved the project and the
recommended solution they want implemented. Nice work. So you might be asking,
what's next? When projects are approved, it triggers a phase called project
initiation. And it's at this time that a project manager is assigned. Strategy analysis
exists within a timeframe, what we refer to as pre-project. It's where your strategy
analysis activity started but they continue on once the project is initiated. We refer to
this transition from pre-project to project itself is moving from strategy, pre-project
to execution, the project. Since your responsibilities began much sooner than the
project managers, you won't simply pass on the baton to a project manager and
disappear. But often team are not clear about the role differences between project
managers and business analysts. So what are the responsibilities for the business
analysts to support project initiation? As a business analyst, you'll support project
management by sharing what you learned from the pre-project activities. Sharing
what you learned helps project management recognize that project initiation is
supported by strategy analysis outcomes. And this emphasizes the importance of
seeking out business analysis research and analysis before jumping directly into any
project. Let's look at the outputs created from strategy analysis and discuss how each
supports project initiation by providing context the development team needs to
begin their work. This is a long list, so I'll cover them quickly. The current state
description describes aspects of the existing environment the project team needs as
it's here where the resulting changes from the project will occur. Business objectives
give teams clarity on what they are working towards. Business requirement. These are
the starting point for the other categories of requirements elicited and
specified during the course of the project. Future state provides a vision for the
project team to understand what they're working to achieve. Potential value is
communicated to the team during project initiation. So the expected value of the
project is clear. Risk analysis results are highly valued because risks could stand in the
way of the team's ability to deliver. And don't forget to share the change
strategy. During project initiation, detailed plans don't exist yet but this information
provides initial insights for release, planning and delivery expectations. Lastly,
solution scope provides the context for the team during their early stages of the
project. Prior to project initiation, scope is described in terms of high level features,
processes, or capabilities. If your organization is waiting until project initiation to
engage business analysts, they're overlooking all this critical pre-project
analysis. Don't wait. Instead get your analysts supporting project initiation so the
solution team will hit the ground running with the information they need to be
successful.

Revisiting strategy analysis when changes arise

Selecting transcript lines in this section will navigate to timestamp in the video
- When we begin research and analysis on a business situation there are a lot of
unknowns. There isn't anything we can do about that. We work with what we
know. We make assumptions when a full set of information isn't available. As the
work progresses we obtain more details from the completed analysis. From talking
with stakeholders and from decisions made along the way. The change initiative
evolves and so does the business, the competitive environment, the industry, the
economy, and so on. We're working within a dynamic environment while learning
about the business situation. There will always be new information and
conditions put forth that should make us rethink our decisions and
direction, including the solution under development. Now this isn't saying we are
constantly starting over. Only that business analysis tasks are intended to be
repeated when needed. Let me give you an example. Danielle is a business analyst
for a local hospital. She's been asked to build a business case to help the patient
records department acquire a new document management system. The business
case was approved. The decision was made to build the software. A vendor has been
selected, and detailed requirements, discussions, are underway. Now unbeknownst to
this team, senior leaders have now been working to close a deal with another
hospital. And today, it's been announced. Danielle's company is being acquired by a
larger hospital. She knows nothing about the record's policies, practices, or systems
the new hospital has in place. Building a system that could go away after the
acquisition could waste resources. The team has different options now that they
didn't have earlier. Danielle should dust off the business case and revisit her earlier
analysis. Because now there's an option to use the acquiring company's document
management system, or bring the new company onto her solution. She needs to
pause and see how this new information might change the team's direction. In your
analysis, like Danielle, there will be times that you will need to pause and consider
new information. Some times there are small discoveries like a new stakeholder is
identified, a key resource on your project is pulled for a higher priority project, new
regulations are enacted, an assumption proves to be false, and so on. In Danielle's
example, there was rework, but that is not every case. Tasks might need to be
revisited. But again, revisiting does not always mean redone. When new information
is discovered revisit prior decisions to ensure they're still valid and valuable. If you
run analysis work in a sequential way, you'll miss the opportunity to fold in new
information and conditions. And this ultimately could lead your team to deliver a
solution that will not meet their needs simply because their needs or environment
has changed. Stay flexible and open to change.