For Business Analysts

Craig Brown
www.betterprojects.net

Business Analyst Training

My agenda
1.
2.
3.
4.

5.

To explain the role of the

business analyst,
To discuss the methodology
described in the BABOK
To discuss practical tips and
techniques for doing the job well
To review sample requirements
specifications to get an
appreciation of what goes into
them
To provide a list of further
resources analysts can call upon
for help

Your agenda

The Business Analyst

Context > Role > Skills
Context

What BAs do

Practical skills

Projects and SDLC

Why projects go
wrong
Project team roles

8.15-9.45

break

Requirements
Management
Business Processes
Human change
management
Project Portfolio
Planning

10.00-11.00

break

Technical skills
Analysis exercise
Questions and
discussion

11.15-12.15

Projects and the SDLC

Product Scope
Initiate

Requirements

Plan

Design
Monitor &
Control

Implement

Test
Close

PMI Project
Management Process

Build

Release

Waterfall Development

Projects and the SDLC

Product Scope
Initiate

Requirements

Plan

Design
Monitor &
Control

Implement

Test
Close

PMI Project
Management Process

Build

Release

Waterfall Development

Projects and the SDLC

Product Scope
Initiate

Agile

SCRUM
Plan

Requirements

PRINCE2
Monitor &

Design

RAD

Control
Build
Implement
SIX Sigma

Etc.
PMI Project
Management Process

Rational
Close

Test

Release

Etc.

Waterfall Development

Projects and the SDLC

Product Scope
Initiate

Agile

SCRUM

Requirements
Plan

Design
RAD

PRINCE2
Monitor &

Control
Build
SIX SigmaImplement

Etc.

PMI Project
Management Process

Rational

Close

Test
Release
Etc.

Waterfall Development

Projects and the SDLC

Product Scope
Initiate

Agile

SCRUM

Requirements
Plan

Plan

Design
RAD

PRINCE2
Monitor &

Control

Do

SIX SigmaImplement

Etc.

PMI Project
Management Process

Check
Rational

Close

Act

Build
Test

Release
Etc.

Waterfall Development

Initiate

Business AnalysisProduct Scope

SCRUMand the BABOK Agile
Requirements
Plan

Plan

Design
RAD

PRINCE2
Monitor &

Control

Do

SIX SigmaImplement

Etc.

PMI Project
Management Process

Check
Rational

Close

Act

Build
Test

Release
Etc.

Waterfall Development

Projects and the SDLC

Product Scope
Initiate

SCRUM

Plan

Plan

Agile

Do

Check

Act

Requirements
Design
RAD

PRINCE2
Monitor &

Control
Build
SIX SigmaImplement

Etc.

PMI Project
Management Process

Rational

Close

Test
Release
Etc.

Waterfall Development

Project Failures
There are many reasons why projects fail.
Lack of sponsor
involvement

Poorly defined
objectives/scope

Lack of handover

Poor strategic
alignment

(people change management)

Poor or wrong
requirements

Team skills
(esp. interpersonal skills)

Poor risk
management

Poor
planning
Ineffective
communication

Long time to
delivery

Lack of formal
pm processes

Poor requirements management is consistently

in the top 3 reasons, regardless of the source

The cost of bad requirements

The following are a few key findings and data from the study:
1. Companies with poor business analysis capability will have three
times as many project failures as successes.
2. 68% of companies are more likely to have a marginal project or outright
failure than a success due to the way they approach business
analysis. In fact, 50% of this groups projects were runaways which had
any 2 of:
Taking over 180% of target time to deliver.
Consuming in excess of 160% of estimated budget.
Delivering under 70% of the target required functionality.
3. Companies pay a premium of as much as 60% on time and budget when
they use poor requirements practices on their projects.
4. Over 41% of the IT development budget for software, staff and external
professional services will be consumed by poor requirements at the
average company using average analysts versus the optimal organization.
5. The vast majority of projects surveyed did not utilize sufficient
business analysis skill to consistently bring projects in on time and
budget. The level of competency required is higher than that employed
within projects for 70% of the companies surveyed.

The cost of bad requirements

The following are a few key findings and data from the study:
1. Companies with poor business analysis capability will have three
times as many project failures as successes.
2. 68% of companies are more likely to have a marginal project or outright
failure than a success due to the way they approach business
analysis. In fact, 50% of this groups projects were runaways which had
any 2 of:
Taking over 180% of target time to deliver.
Consuming in excess of 160% of estimated budget.
Delivering under 70% of the target required functionality.
3. Companies pay a premium of as much as 60% on time and budget when
they use poor requirements practices on their projects.
4. Over 41% of the IT development budget for software, staff and external
professional services will be consumed by poor requirements at the
average company using average analysts versus the optimal organization.
5. The vast majority of projects surveyed did not utilize sufficient
business analysis skill to consistently bring projects in on time and
budget. The level of competency required is higher than that employed
within projects for 70% of the companies surveyed.

The cost of bad requirements

The following are a few key findings and data from the study:
1. Companies with poor business analysis capability will have three
times as many project failures as successes.
2. 68% of companies are more likely to have a marginal project or outright
failure than a success due to the way they approach business
analysis. In fact, 50% of this groups projects were runaways which had
any 2 of:
Taking over 180% of target time to deliver.
Consuming in excess of 160% of estimated budget.
Delivering under 70% of the target required functionality.
3. Companies pay a premium of as much as 60% on time and budget when
they use poor requirements practices on their projects.
4. Over 41% of the IT development budget for software, staff and external
professional services will be consumed by poor requirements at the
average company using average analysts versus the optimal organization.
5. The vast majority
of projects surveyed did not utilize sufficient
Requirements
? on time and
business analysis
skill to consistently?bring projects in
Professionals
budget. The level of competency required is higher than that employed
within projects for 70% of the companies surveyed.

Project Failures

IAG report can be accesse at iag.biz

Requirements Failures
The volume and complexity of
stakeholders

Process

Stakeholder expectations &

involvement
Who is managing the
requirements - skills of the
requirements team

Not
deliverable
s

Requirements Failures
Avoid requirements failure by doing these
things;

1. Feedback
Have developers feed back their interpretation
of requirements to the stakeholders and
clients. Do it early and often. Use workshops,
wireframes, prototypes, or documents, but do
it.
2. Bring people together
Bring the subject matter experts and
requirements owners into the same room as
the developers. Get them talking to each other.
If you can't be in the same room, arrange
regular meetings. Don't rely on written
communication.
3. The right Requirements team
Make sure your BAs are trained and highly
skilled at requirements management (ie not
just elicitation, but the whole shebang.)

Practical
tips

Project Team Roles

Project Team Roles

Sponsor

Project
Manager
Business
Analyst
Process
Analysts
Systems
Analysts

Change
Manager
Trainers
Technical
Writers

Quality

Testers

Users

Solutions
Team
Solutions
Architects
Designers

Liaison
Roles
SMEs

Developers

Solutions
Architects

Project
Manager

Sponsor

Liaison
Roles

Users

Designers

Business
Analyst

Developers

SMEs
Change
Manager

Testers

Technical
Writers

Quality
Trainers

Systems
Analysts

Process
Analysts

 The IIBA and BABOK

link

Certification

link

Melbourne events
BABOK Chapter overview

Link 1 Link 2
link

break

WHAT DOES A BA DO?

Requirements Management
Business Processes
People Change Management
Project Portfolio Planning

Requirements
Management

MATURITY LEVELS (SEI/IEEE)

1.
2.
3.
4.
5.

Chaos
Written requirements
Organized
Structured
Integrated

BABOK Knowledge areas

Defining the role, resources etc

BA BOK and contents

Planning
Elicitation
Modelling and Analysis
Communication
Validation
Verification

Enterprise analysis
Level
Strategy and Structure
Business Process Analysis
Financial analysis and business
cases
Consulting skills
Project Management

3?

BABOK Knowledge areas

Defining the role, resources etc

BA BOK and contents

Planning
Elicitation
Modelling and Analysis
Communication
Validation
Verification

Enterprise analysis
Strategy and structure
Business process analysis
Financial analysis and business
cases
Consulting skills
Project management

Basic Skills
Requirements Management
Planning
Elicitation
Communication
Plan
Do
Verification
Validation

Check

Act

Requirements integrity

Level 4?

Guy Beauchamp
Modern Analyst

Requirements integrity

Guy Beauchamp
Modern Analyst

Beautiful Requirements
??
?? ? ?
?
?
? ? ?? ??? ?? ?? ????? ??? ? ??? ? ???
? ??? ? ??? ?? ? ? ? ? ???? ?? ?
??
?
?
?? ?
?
?
?
?
?
??
?
?
?
?
?
?
?
? ?? ??? ? ? ? ? ?? ? ? ? ?
?
?
?
?
? ? ??? ????? ? ? ??? ?? ??? ?? ?
? ?? ? ? ? ?
???? ???
???? ????? Level 5?? ?
?? ??
????
?
?? ? ?? ? ??? ?
?? ? ? ?
? ? ??? ?
? ? ? ? ???? ? ?? ?? ??? ? ? ? ?
?
? ? ? ? ? ? ? ? ? ? ?? ? ? ?
?
?
?? ? ?
? ?

should

WHAT DOES A BA DO?

1. Understand the stakeholders
2. Break work down to activity level
Who does what, when and why?

3. Get lots of feedback (validation)

4. Manage expectations throughout the
process

Requirements management

Basic Skills
Requirements Management
1. Planning
2. Elicitation
3. Communication
4. Verification
5. Validation

Requirements Planning
Plan before you act
Lack of Completeness is
the greatest source of
requirements problems
Incorrect Requirements is
also an issue

Know the stakeholders,

know their business
Break your work down to
detailed tasks

Plans
change

Requirements Elicitation
Desk research
Interviews
Workshops
Models

Flow charts (Swim Lanes)

Use Cases (with stories)
Context Diagrams
State Transition

Remember

Activity Level
Method H

Requirements Communication
Know who needs to
know
Have enough time to
communicate
effectively
Communicate through
the whole lifecycle
No surprises, Bad
news early

Plan your
communication

Requirements Verification

Document Reviews
3 day review cycles dont
always work well
Tell people in advance

Reviews and Inspections are

one of the most effective
methods of Requirements QA

Walkthrough workshops have

strengths and weaknesses
S: Group Synergies
W: Time and effort

Peer Review,
Manager Review,
Tester Review
Look for
completeness and accuracy
(in that order)

Requirements Validation
Testing
V-Model and Agile both highlight test
driven development, beginning with
requirements. Waterfall also relies
heavily on testing (% of time/effort)

UAT
BA role in planning, participating,
assessing impact of bugs,
troubleshooting, workarounds,
stakeholders expectations

Business Acceptance
Contract perspective, Responsibilities
of both project and business,
Overlapping period

Validation is
done by people.
Take them on
the journey.

BA activities

Scope/ High
level
requirements

Workshops
and
Interviews

Approve
Business
Requirements

Document
Business
Requirements

Identify
Stakeholders

Identify
Constraints

PM

Business
person

Business
Analyst

Bus BA

Systems
Analyst

Revise
Scope/Bus
Case

Designer/
Program
mer

IT BA

Stakeholders

Stakeholders

Business Managers
and SMEs

IT managers,
Infrastructure and
network SMEs

Solution
Design

Assess
Design

Requirements
Management

Change
Management

RTM
UAT
Ready for
Service

Change Mgt
Plan
Comms Plan
Training

Business
Processes

3 Things
Use cases
Swim lanes
Context diagrams

Use Cases

Case

user

Tyner Blain: Use Cases

Verb/noun

Actor 3
Actor 4

Begin and end

in same lane
Binary
decisions

Actor 2

Actor 1

Swim lanes

Activity level
participants

Boundaries

Hand-over

Context diagrams
Internal

External
Drilling
down
Information
flow
Context
Boundary

and UML

Diagram from Wikipedia

and UML

UML is for
solution design

Diagram from Wikipedia

People
Change
Management

Changing people
Lewin:
Unfreeze > Freeze
Maister:
The Fat Smoker
Prosci:
ADKAR

Aware
Desire
Knowledge
Ability
Reinforce

Changing people

Stakeholder 1

K Aware
A

Stakeholder 2

K Desire
A

Stakeholder 3

Stakeholder 4

Stakeholder 5

Knowledge
K
A
R
Ability
K
A
R
Reinforce
K

Project
Portfolio
Planning

Project Portfolio Management

Enterprise Analysis

Enterprise Architecture

Defining the opportunity

Solution Strategies
Business Cases
Benefits management

Information Management
Application Planning
Business Process

break

workshop
Break into groups
Review examples
Present feedback

workshop
What makes
good
requirements?

1.

Quality of documentation

2.

Completeness
Accuracy
Clarity
The difference between
requirements and design

Management through the

process

Reviewing Requirements

Resources
IIBA
New, but growing in
influence.

BOKS
BA BOK
PM BOK
Others

Modern Analyst
Articles, Forums, etc

Ed Yourdon
JESA

TynerBlain
Structured analysis
BetterProjects

Modern Analyst

Articles
Forums
Templates
Other resources

Ed Yourdon
Website
Blog
Structured Analysis Wi
ki
Free download of his
JESA ` book
And much more

Tyner Blain
Software development
Requirements
management
Product management
See
Structured analysis and
Use Cases

Scott Sehlhorst, Austin

Texas