Session 5.
Enterprise AnalysisRAM N SANGWAN
WWW.RNSANGWAN.COM
YOUTUBE CHANNEL : HTTP://YOUTUBE.COM/USER/THESKILLPEDIA
TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM
Agenda
• Enterprise analysis
• SWOT Analysis
• Feasibility Study & Analysis
• Problem Statement & Goal Statement
• Business Case
• Project Scope Statement & Vision Document
• AS IS (current state) and TO BE (future state)
• Root Cause Analysis – Fish Bone Diagram
2
Enterprise analysis
Define business need
Assess capability
gaps
Determine solution
approach
Define solution scope
Define business
case
3
Tools for enterprise analysis
1. SWOT analysis
2. Benchmarking
3. Brainstorming
4. Business rules analysis
5. Functional decomposition
6. Root cause analysis (RCA)
7. Document analysis
8. Decision analysis
4
9. Estimation
10. Interface analysis
11.Focus groups
12.Scope models
13.User stories
14.Risk analysis
SWOT Analysis
• SWOT analysis looks at your strengths and weaknesses, and the
opportunities and threats your business faces.
• The SWOT Analysis framework is a very important and useful tool to
use in marketing Management and other business applications
• As a basic tool its mastery is a fundamental requirement for the
marketer, entrepreneur or business person.
• A clear understanding of SWOT is required for business majors.
5
Strengths
• Characteristics of the business or a team that give it an advantage
over others in the industry.
• Positive tangible and intangible attributes, internal to an organization.
• Beneficial aspects of the organization or the capabilities of an
organization, e.g. financial resources, customer goodwill and brand
loyalty.
Examples –Abundant financial resources, Well-known brand name, Economies of scale,
Lower costs, Superior management talent, Better marketing skills, Good
distribution skills, Committed employees.
7
Weaknesses
• Characteristics that place the firm at a disadvantage relative to
others.
• Detract the organization from its ability to attain the core goal and
influence its growth.
• Weaknesses are the factors which do not meet the standards we
feel they should meet.
Examples –
Limited financial resources, Weak spending on R & D, Very narrow product line,
Limited distribution, Higher costs, Out-of-date products / technology, Weak
market image, Poor marketing skills, Limited management skills, Under-trainedemployees.
8
Opportunities
• Chances to make greater profits in the environment - External
attractive factors that represent the reason for an organization to
exist & develop.
• Arise when an organization can take benefit of conditions in its
environment to plan and execute strategies that enable it to
become more profitable.
Examples –
Rapid market growth, Rival firms are complacent, Changing customer
needs/tastes, New uses for product discovered, Economic boom, Government
deregulation, Sales decline for a substitute product .
9
!
Threats
• External elements in the environment that could cause trouble for the
business - External factors, beyond an organization’s control.
• Arise when conditions in external environment jeopardize the reliability
and profitability of the organization’s business.
• Compound the vulnerability when they relate to the weaknesses.
Threats are uncontrollable. When a threat comes, the stability and
survival can be at stake.
Examples –
Entry of foreign competitors, Introduction of new substitute products,
Product life cycle in decline, Changing customer needs/tastes, Rival
firms adopt new strategies, Increased government regulation etc.
10
Feasibility Study and Analysis
Feasibility Study
• It is an evaluation and analysis of the potential of the proposed
project which is based on extensive investigation and research
to give full comfort to the decisions makers.
Feasibility Analysis
• It is a process by which feasibility is measured.
11
Conducting A Feasibility Study
• Too often, we launch new ideas without thinking through what our
market is.
• Preparing a feasibility study will help you determine if there is
sufficient demand for the product or service AND can the product
or service be provided on a profitable OR sustainable basis?
12
Questions Before you begin.
• What defined market am I trying to reach?
• What specific companies/organizations are servicing this market?
• Are they successful?
• Something similar?
• What is their market share?
• Is the market saturated or wide open?
• What is the size of the market?
• Is it growing?
• Is it stable, volatile, trendy?
• How can you reach this market?
• How are competitors currently reaching the market?
• What do customers expect from this type of product or service?
And so on..
13
Why Do A Feasibility Study ?
• Gives focus to the project
• Narrows alternatives
• Surfaces new opportunities
• Enhances the probability of success by addressing factors early
that could affect the project
• Provides quality information for decision making
• Helps in securing funding
• Helps to increase investment in idea
14
Tests For Feasibility
• Operational feasibility
• Technical feasibility
• Schedule feasibility
• Economic feasibility
• Social feasibility
15
Problem Statement
When pursuing a development project it is always done to solve a
problem.
• But what problem?
• A good problem statement should answer these questions:
• What is the problem? This should explain why the team is needed.
• Who has the problem or who is the client/customer? This should explain who
needs the solution and who will decide the problem has been solved.
• What form can the resolution be? What is the scope and limitations (in time,
money, resources, technologies) that can be used to solve the problem?
Does the client want a white paper? A web-tool? A new feature for aproduct?
16
What to put in a problem statement
• A concise wording of the problem to be tackled.
• Who is/are the customer(s), what is the clients need?
• What are the assumptions being made?
• What are the limitations?
• What are the engineering standards that impact the project?
17
Bounded Rationality
• Conceptualized by Herbert Simon in early 1960’s
“People try to behave rationally within the limits of their information
processing capabilities and within the context of their attitudes and
emotions”
• People engage in restricted searches for information;
• have limited information processing capabilities
• rely on familiar sources of information
• biases and heuristics
• construct simplified models of reality;
...and then they make decisions using those models!
18
Bounded Rationality
• So how do we deal with it?
Business cases are one of structured problem solving methods to
help us minimize or overcome the effects of bounded rationality.
20
Business Case Examples
• Consumer Products International
• Strengths?
• Concerns?
• Should this business case be funded?
21
Why Write Business Cases?
• Disciplined Exercise
• Make tacit assumptions explicit
• Provides basis for allocating capital
• Communication Tool
• Essential investment in building the relationship asset
• Defines what the project is (and is not)
22
Project Completion...Delivery
Phase...Execution Phase...Approval Phase...
Project
Close
BUSINESS
CASE
Post -
Impl’n
Review
POST IMP
REVIEW
DELIVERY
PLAN
Project
Delivery
SUPPORT
PLAN
COMM’N
PLAN
Project
Execution
PROJECTINITIATION
DOC.
PROJECT
PLAN
QUALITY
PLAN
STATEMENT
SUPPORT
REQUIRE’S
Project
Initiation
Project
Approval
BUSINESS
CASE
Project
Set-Up
PROJECT
OUTLINE
Project
Definition
Project Lifecycle and Business Case 23
Business Cases
• Are essential part of project selecting & scoping
• Require making assumptions explicit
• Use arguments of Facts, Faith, & Fear
• Set the direction & support for projects
• Establish business ownership
• Set boundaries
• Strongly influence the Relationship Asset
24
Vision and Scope Document
A typical vision and scope document follows an outline like this one:
1. Problem Statement
a) Project background
b) Stakeholders
c) Users
d) Risks
e) Assumptions
2. Vision of the Solution
a) Vision statement
b) List of features
c) Scope of phased release (optional)
d) Features that will not be developed
25
Vision and Scope Document Contd..
Project background -a summary of the problem that the project will
solve.
• It should provide a brief history of the problem and an explanation of
how the organization justified the decision to build software to
address it.
• cover the reasons why the problem exists, the organization's history
with this problem, any previous projects that were undertaken to try
to address it, and the way that the decision to begin this project was
reached.
26
Vision and Scope Document Contd..
Stakeholders
• This is a bulleted list of the stakeholders.
• Each stakeholder may be referred to by name, title, or role ("support
group manager," "CTO," "senior manager").
• The needs of each stakeholder are described in a few sentences.
Users
• This is a bulleted list of the users. As with the stakeholders, each
user can either be referred to by name or role.
• However, if there are many users, it is usually inefficient to try to
name each one. The needs of each user are described.
27
Vision and Scope Document Contd..
Risks
• lists any potential risks to the project.
• It should be generated by a project team's brainstorming
session.
• It could include external factors that may impact the project, or
issues or problems that could potentially cause project delays
or raise issues.
Assumptions
• The list of assumptions that the stakeholders, users, or project
team have made.
28
Vision statement
• The goal of the vision statement is to describe what the project is
expected to accomplish. It should explain what the purpose of the
project is.
• This should be a compelling reason, a solid justification for
spending time, money, and resources on the project.
• The best time to write the vision statement is after talking to the
stakeholders and users and writing down their needs; by this time,
a concrete understanding of the project should be starting to jell.
29
List of features• A feature is as a cohesive area of the software that fulfills a specific need
by providing a set of services or capabilities.
• Any software package in fact, any engineered product can be broken
down into features.
• The project manager can choose the number of features in the vision and
scope document by changing the level of detail or granularity of each
feature.
• It is useful to describe a product in about 10 features in the vision and scope
document , because this usually yields a level of complexity that most
people reading it are comfortable with.
• Each feature should be listed in a separate paragraph or bullet point. It
should be given a name, followed by a description of the functionality that
it provides.
30
Review the vision and scope document
Once the vision and scope document has been written, it should be
reviewed by every stakeholder.
Performing this review
◦ can be as simple as emailing the document around and asking for comments.
◦ The document can also be inspected.
◦ it is important that the project manager follow up with each individual person
and work to understand any issues that the reviewer brings up.
◦ The project manager should make sure that everyone agrees that the final
document really reflects the needs of the stakeholders and the users.
• Once the document has been reviewed and everyone agrees that it is
complete, the team is unified toward a single goal and the project can be
planned.
31
AS IS (current state) and TO BE (future state) 32
AS IS
TO BE
Current capabilities
Desired capabilities
Assess capability gaps
• Analyze current capabilities.
• Assess new capability requirements.
• Document assumptions.
33
Capabilities
• Capability is demonstrated ability to perform.
• Sample capabilities are
• Business processes.
• Features of a software application.
• Tasks that an end user may perform.
• Events that a solution must be able to respond to.
• Products that an organization creates.
• Services that an organization delivers.
• Goals that a solution will allow stakeholders to accomplish.
34
Root Cause Analysis
• Root Cause Analysis is an in-depth process or technique for
identifying the most basic factor(s) underlying a variation in
performance (problem).
• Focus is on systems and processes
• Focus is not on individuals
35
Why Determine Root Cause?
• Prevent problems from recurring
• Reduce possible injury to personnel
• Reduce rework and scrap
• Increase competitiveness
• Promote happy customers and stockholders
• Ultimately, reduce cost and save money
36
Look Beyond the Obvious
• Invariably, the root cause of a problem is not the initial
reaction or response.
• It is not just restating the Finding
37
Most Times Root Cause is Much More
Such as:
• Process or program failure
• System or organization failure
• Poorly written work instructions
• Lack of training
38
When Should Root Cause Analysis be Performed?
• Significant or consequential events
• Repetitive human errors are occurring during a specific process
• Repetitive equipment failures associated with a specificprocess
• Performance is generally below desired standard
39
How to Determine the Real Root Cause?
• Assign the task to a person (team if necessary) knowledgeableof the systems and processes involved
• Define the problem
• Collect and analyze facts and data
• Develop theories and possible causes - there may be multiplecauses that are interrelated
• Systematically reduce the possible theories and possible causesusing the facts
40
How to Determine the Real Root Cause? (continued)
• Develop possible solutions
• Define and implement an action plan (e.g., improvecommunication, revise processes or procedures or workinstructions, perform additional training, etc.)
• Monitor and assess results of the action plan forappropriateness and effectiveness
• Repeat analysis if problem persists- if it persists, did we get tothe root cause?
41
Useful Tools For Determining Root Cause
• Cause and Effect Diagram
• The “5 Whys”
• Brainstorming
• Flow Charts / Process Mapping
42
Concept of fish bone/ Ishikawa diagram
• Fish bone or Ishikawa diagram is one of the important concept
which can help you list down your root cause of the problem.
• Fish bone was conceptualized by Ishikawa, so in the honor of its
inventor this concept was named as Ishikawa diagram.
• Inputs to conduct a fish bone diagram comes from a discussion
and brain storming with people who were involved in the
project.
43
Cause and Effect Diagram (Fishbone/Ishikawa Diagrams)
EFFECT
CAUSES (METHODS) EFFECT (RESULTS)
MAN/WOMAN METHODS
MATERIALS MACHINERY
OTHER
44
MAN/WOMAN METHODS
MATERIALS MACHINERY
OTHERCannot
Load
Softwar
e on PC
Inserted CD Wrong
Instructions are Wrong
Not Enough
Free Memory
Inadequate System
Graphics Card Incompatible
Hard Disk Crashed
Not Following
Instructions
Cannot Answer Prompt
Question
Brain Fade
CD Missing
Wrong Type CDBad CD
Power Interruption
Cause and Effect Diagram: Loading My Computer 45