Business analysis session 5 enterprise analysis

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

6

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

Problem Space

Simon refers to this as “satisficing”

19

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

ThankyouWWW.RNSANGWAN.COM