business analysis and process improvement

Business Analysis and Process Improvement

© Lonsdale Systems 1

1


[email protected]

Presenter: Phil Robinsonwww.lonsdalesystems.com

[email protected]



2

Agenda

• Business analysis process model

• Process improvement

• Individuals and change

• Beyond business analysis



3

Business Analysis Process Model



4

International Institute of Business Analysis (IIBA)– 6 Knowledge Areas (not related to

project phases)– 34 Techniques

British Computer Society (BCS)– Business Analysis

Process Model– 72 Essential Tools for

Success

These frameworks are great for certifying the knowledge and skills of individuals but can they be applied to real projects with varying skill levels and tight deadlines?

Also they do not describe process improvement or the process of individual change.

Knowledge and skills are not sufficient to improve a process or change the behaviour of individuals.



5

Define Requirements

• Formal Requirements

• Usage Scenarios

• Data Dictionary

Analyse Needs

• Strategic Needs• Information Requirements

• Business Rules• Gap Analysis

Evaluate Options

• Solution Options

• Feasibility• Selected Solution

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



Consider Perspectives

• Stakeholders• Business Scope

• Application Scope

Investigate the Situation

• Initial Scope


• Workflows

Model Business Processes

• Components• Features

Model Software Applications

This is intended to be an “essential” process.

This means that removing anything from the model, except perhaps Process Modelling, will almost certainly cause problems and likely lead to failure.

The process consists of five stages and two techniques. Each of the stages and techniques have a number of deliverables. For example, the Define Requirements stage delivers Formal Requirements, Usage Scenarios and a Data Dictionary.

It is possible to establish a deliverable before the process stage it is delivered in. For example, it is possible to identify some key Business Rules during Investigate the Situation or establish a Data Dictionary during Analyse Needs.



6



Analyse Needs

Evaluate Options

Define Requirements

• Workflows






• Initial Scope • Stakeholders• Business Scope



• Usage Scenarios

• Data Dictionary



Business Analysis Roles

Business Analyst

Business Analyst Systems

Analyst

Business Analyst

Systems Analyst

Solution Architect

Separation of roles into Business Analyst, Systems Analyst and Solution Architect is more common in larger organisations.



7


Rich PicturesMind Maps

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows




Unstructured techniques work best during this stage. See http://www.slideshare.net/lonsdalesystems/visual-communication-28395424.

It can be useful to establish a glossary of terms here. See http://lonsdalesystems.blogspot.sg/2012/03/creating-glossary-of-terms.html.



8


Rich PicturesMind Maps

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows




Unstructured techniques work best during this stage. See http://www.slideshare.net/lonsdalesystems/visual-communication-28395424.

It can be useful to establish a glossary of terms here. See http://lonsdalesystems.blogspot.sg/2012/03/creating-glossary-of-terms.html.



9

CompetitorsSuppliers

None

EmployeesHotel owner

PartnersGuests

Duty manager

Some

Subject Matter Knowledge

Co

ntrol O

ver Sco

pe

So

me

High

HighNone

Back office clerkFront desk clerk

Call centreoperator

Functioncustomers

Coffee shopcustomers

Healthdepartment

Fire department


None


PartnersGuests

Duty manager

Some


Co

ntrol O

ver Sco

pe

So

me

High

HighNone


Call centreoperator

Functioncustomers


Healthdepartment

Fire department

Stakeholder Analysis


Functional Analysis

HotelManagement

System

Smart CardProgrammer

Duty ManagerBack Office Clerk

Front Desk Clerk

Call Centre Operator

Stay details

Accommodation Report

Bil l

Bil l ing Details

Check In Details

Check Out Details

Reservation

Context Diagram

HotelManagement

System

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows




It is essential to know who are the subject matter experts (SMEs) and who ultimately controls the scope.

Business scope is a consolidated view of the “work” of the stakeholders.

Application scope defines how the stakeholders will the application as a “tool” to support their work.

Functional Analysis and Context Diagrams are typical techniques used during this stage. However, actual techniques are not mandated here in contrast to the specific techniques described in Modelling Processes and Modelling Applications.



10


None


PartnersGuests

Duty manager

Some


Co

ntrol O

ver Sco

pe

So

me

High

HighNone


Call centreoperator

Functioncustomers


Healthdepartment

Fire department


None


PartnersGuests

Duty manager

Some


Co

ntrol O

ver Sco

pe

So

me

High

HighNone


Call centreoperator

Functioncustomers


Healthdepartment

Fire department



Functional Analysis

HotelManagement

System



Front Desk Clerk


Stay details


Bil l

Bil l ing Details

Check In Details

Check Out Details

Reservation

Context Diagram

HotelManagement

System

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows










11


None


PartnersGuests

Duty manager

Some


Co

ntrol O

ver Sco

pe

So

me

High

HighNone


Call centreoperator

Functioncustomers


Healthdepartment

Fire department


None


PartnersGuests

Duty manager

Some


Co

ntrol O

ver Sco

pe

So

me

High

HighNone


Call centreoperator

Functioncustomers


Healthdepartment

Fire department



Functional Analysis

HotelManagement

System



Front Desk Clerk


Stay details


Bil l

Bil l ing Details

Check In Details

Check Out Details

Reservation

Context Diagram

HotelManagement

System

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows










12


None


PartnersGuests

Duty manager

Some


Co

ntrol O

ver Sco

pe

So

me

High

HighNone


Call centreoperator

Functioncustomers


Healthdepartment

Fire department


None


PartnersGuests

Duty manager

Some


Co

ntrol O

ver Sco

pe

So

me

High

HighNone


Call centreoperator

Functioncustomers


Healthdepartment

Fire department



Functional Analysis

HotelManagement

System



Front Desk Clerk


Stay details


Bil l

Bil l ing Details

Check In Details

Check Out Details

Reservation

Context Diagram

HotelManagement

System

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows










13

Modelling Business Process and Software Applications

Physical

(How?)

Logical

(What?)

Future (“To-Be”)Current (“As-Is”)

Understanding

Needs

Solution

Concepts

Modelling current physical business processes are great for understanding but can often lead to a lot of wasted time. See http://lonsdalesystems.blogspot.sg/2012/03/business-analysis-and-process-modelling.html for a more detailed discussion of this slide.

The Functional Analysis performed during Consider Perspectives can often substitute for the current logical process model and bypass the current physical model.

Frequently BAs find that a current physical model of the application already exists. Current logical models are much less common but very important in understanding how the application is used as a “tool”.

The difference between the current and future logical models represent a needs “gap”.

More than one future physical process and application model may be created for different solution options.



14


Kio

skG

ues

tH

ote

l Ma

na

gem

ent S

ystem

Swipe creditcard

Read credit card

Retrieve guestreservation

Display guestdetails

Confirm guestdetails

Allocate room

Display roomallocation

Display availablerooms

Dispense keycard

Retrieveavailable rooms

Select room Remove keycard

[change room]

[accept allocated room]

Retrieve reservation

Allocate room

Record guest details

Check identity

document

Authorise credit card

Accept cash deposit

No acceptablemethod ofpayment

Record stay details

[walk in]

[acceptablecredit card]

Process Models

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows




Process models model the “work” performed by the stakeholders.

Activity diagrams are shown here but other notations such as BPMN or Achimate could be used.



15


Hotel Management System

Front Desk Back Office Housekeeping

Debtors Ledger General Ledger

Shift Management

Mobile App

Check out times

Minibar, Laundry

Staff details

Corporate sales

Corporate sales

Cash sales

Components

Mobile App

Enter Laundry Items

Record Laundry Return

Housekeeper

Record Minibar Usage

«actor,secondary»Hotel Management

SystemRecord Make Up

Room

«actor»Housekeeping

Features

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows




These model the “tool” that will support the stakeholder’s “work”.

Components are the physical view and features are the logical view of an application.



16

Analyse Needs

• Strategic– Improve a process to build on a strength or

exploit an opportunity– Mitigate a risk to preserve a strength or avoid a

threat– Remedy the underlying cause of a weakness

• Support business processes– Managing information– Enforcing business rules

• Identify “gaps”

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows




Strategic Needs are identified as part of a SWOT analysis.

Support for business processes represents the routine automation of “work”.

It is common for the Information Requirements to be defined in a Data Dictionary.



17

Evaluate Options

• Identify solution options

• Investigate feasibility– Technical

– Economic (business case)

– Schedule (estimate and plan)

– Compliance

– Operational

• Selected solution

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility







• Initial Scope

Define Requirements


• Usage Scenarios

• Data Dictionary

Evaluate Options



Analyse Needs



• Workflows




The “TESCO” mnemonic is a great way to remember the different types of feasibility.

Feasibility can sometimes become a “show-stopper”. For example it is often mandatory to comply with laws and regulations.

Schedule feasibility should be considered before economic feasibility as it identifies some of the costs associated with the application.

It is common to select a solution option based on its economic feasibility (cost-benefit).



18

Define Requirements

Application

Function Storage

Function

Quality attributeConstraint

Actor

Function

System

DeviceFunction

Formal Requirements

Use

r In

terf

ace

Usa

ge s

cena

rio

Inte

rfac

eS

erv

ice

Actor

System

Device

Application

Scenarios

Define Requirements

Analyse Needs


• Usage Scenarios

• Data Dictionary

Evaluate Options


• Feasibility

Analyse Needs







• Initial Scope


• Usage Scenarios

• Data Dictionary

Evaluate Options





• Workflows




• List of guests– Surname 30 alphabetic– First name 30 alphabetic– Address 3 x 40 alphanumeric

• List of reservations– Check in date DD/MM/YYYY– Check out date DD/MM/YYYY

• Reservation details– Room type [Standard|Deluxe|Suite]– Number of guests 1 numeric– Check in date DD/MM/YYYY– Arrival flight number 10 alphanemeric...

Data Dictionary

Formal requirements describe requirements from the perspective of the application.

They are most often described using mandatory statements such as “The application must…”.

Scenarios describe requirements from the perspective of the user of the application and applications that use its services.

They are most often described using structured scenarios that define how the user (or application) will interact with the application.

For example:

1. The user selects a transaction type

2. The application requests the transaction amount

3. …

Data dictionaries provide a structured way of defining interface and storage requirements.



19

AnalyseNeeds

InvestigateSituation

ConsiderPerspectives

EvaluateOptions

DefineRequirements

Backtracking and Iteration

In practice, business analysis does not proceed smoothly through the five stages of the process model.

Learning about a business area and the software applications that support it inevitably requires BAs to “backtrack” to previous stages of the process as they learn more.

For example, some previously unknown stakeholders may be discovered during Analyse Needs. This would require a BA to backtrack to the Consider Perspectives stage and revise the Stakeholder Analysis (and possibly the Business Scope) to include the new stakeholder.

While some degree of backtracking is inevitable, excessive backtracking can lead to inefficient repetition of work already performed (rework).

In situations where very little is known about the business area and its applications, a planned iterative approach can provide a better approach.



20

Process Improvement



21

• Identify potential improvements

• Identify performance measures

• Experiment with changes

• Collect performance data

• Evaluate experiments

• Review lessons learnt

• Institutionalise improvements…or

• Repeat cycle

PlanA

ct

Check

Do

PDCA Cycle

In essence, the PDCA cycle describes the experimental method used in science.



22

• Identify potential improvements

• Identify performance measures

• Experiment with changes

• Collect performance data

• Evaluate experiments

• Review lessons learnt

• Institutionalise improvements…or

• Repeat cycle

PlanA

ct

Check

Do

Software Projects• Ad-hoc processes• Lack of data

• Ad-hoc processes• Non-repetitive tasks• Difficult to

communicate planned experiments

• Variation in individual skills

• Data is accumulated slowly

• Difficult to compare data from different projects

• Slow feedback• Difficult to institutionalise

changes to ad-hoc process

• Difficult to communicate lessons learnt

PDCA is easy to apply to manufacturing processes because there are many repetitive tasks and sampling during manufacture quickly establishes many data points for measuring the performance of the process.

This is not true for software projects.



23

Process Capability

Ad-hoc

Managed

Defined

Measured

Improving

Plan

Act

Check

Do


Success through skill and “heroics”

• Projects• Quality• Change

Before PDCA can be applied to software projects, the process must be made more stable and predictable in a series of steps that build on each other.

It should always be remembered that the goal is that of continuous improvement NOT achieving the stable and predictable process. Stability and predictability are simply a means to an end!

The starting point is usually an ad-hoc process. Success is only achieved if staff have superior skills and make a “heroic” effort by working long hours.

The first step is to better mange the process by introducing the disciplines of project, quality and change management.

The next step is to institutionalise a defined process. “Institutionalise” means that everyone actually follows the process for all projects. There are no “special cases” and the process is not abandoned when faced with schedule slippage. The Business Analysis Process Model is a good example of a defined process.

Objective measurement is the key to applying PDCA and that is why it is the next and final step. Once it is possible to objectively measure the performance of a process, continuous improvement of the process becomes possible.

Some may recognise these steps as being very similar to the five capability levels described in the CMMI.



24

•Defined - framework for identifying problem areas and potential improvements•Measured - ability to assess severity of problems and identify performance measures for potential improvements

•Managed - facilitates controlled experimentation with potential improvements•Defined - framework for communicating planned experiments•Measured - defines what performance data to collect and how to collect it•Measured – supplies

the performance datato evaluate potential improvements

•Defined - framework for communicating lessons learnt and institutionalising improvements

PlanA

ct

Check

Do



25

Individuals and Change



26

Change Management Framework ADKAR

Reinforcement to sustain the changeR

Ability to implement the changeA

Knowledge of how to changeK

Desire to support the changeD

Awareness of the need for changeA

?

!

ADKAR describes individual change as a sequential process consisting of five steps.

A change can fail at any of the five stages. For example, if an individual is aware of the need for a change but does not have the desire to change, the change will not be successful even if the organisation goes through the “motions” of developing their knowledge and ability.

Training is often seen as providing a trigger for change. However, ADKAR predicts that the change will not be successful unless everyone is aware of the need to change and has the desireto change.

It is very common for changes to fail through a lack of reinforcement to sustain the change. Staff return from a training course only to be told that “this time is different” or the approach they learnt is “too academic”!



27

Beyond Business Analysis



28

Implement Product

Deploy Product



Analyse Needs

Evaluate Options

Define Requirements

• Workflows









• Usage Scenarios

• Data Dictionary



Manage Integration

Manage Change

• Validation• Verification• Defects

Manage Quality

• Acquisition Support

• Development Support

• Stakeholder Support

• Retirement Planning


The Business Analysis Process Model can be extended by adding stages for the Implementation and Deployment of the application.

The extended model also adds techniques for managing quality, integration and change.



29

Implement Product

Deploy Product



Analyse Needs

Evaluate Options

Define Requirements

• Workflows









• Usage Scenarios

• Data Dictionary



Manage Integration

Manage Change

• Validation• Verification• Defects

Manage Quality

• Acquisition Support

• Development Support

• Stakeholder Support

• Retirement Planning


Technology andOrganisation

Software Testing

Requirements Analysis Quality

Management

EnterpriseArchitecture

Managing change applies equally to:

•organisational changes described by ADKAR; and

•the version control of technology.

Managing integration (often called Enterprise Architecture) is about planning the integration of:

•the organisation’s “work”;

•the application “tools” that support the work; and

•the technical infrastructure on which the applications are deployed.

The goal of managing integration is to make it easy to respond to changing needs – especially changes to strategic needs.



30



Analyse Needs

Evaluate Options

Define

Requirements

Imp

lemen

t

Pro

du

ct

Deploy

Product

Op

erat

e P

rod

uct

Manage Integration

and Change

Iterative Life Cycle

Minor changes and

enhancements

New applications and major

enhancements

The stages of the extended model can be organised into an iterative version of the process.

Iterative processes are often better for the enhancement and support of an applications with long lifetimes.



31

Questions?

Presenter: Phil Robinsonwww.lonsdalesystems.com

[email protected]