For Business Analysts

Erlet Shaqe
www.erletshaqe.com
 Business Analyst Training
My agenda Your agenda
1. To explain the role of the
business analyst,
2. To discuss the methodology
described in the BABOK
3. To discuss practical tips and
techniques for doing the job well
4. To review sample requirements
specifications to get an
appreciation of what goes into
them
5. To provide a list of further
resources analysts can call upon
for help
 The Business Analyst
Context > Role > Skills
Context What BA’s do Practical skills
• Projects and SDLC • Requirements • Technical skills
• Why projects go Management • Analysis exercise
wrong • Business Processes • Questions and
• Project team roles • Human change discussion
management
• Project Portfolio
Planning

8.15-9.45 break 10.00-11.00 break 11.15-12.15

Projects and the SDLC Product Scope

Initiate Requirements

Design
Plan
Monitor &
Control Build

Implement
Test

Close
Release

PMI Project
Management Process Waterfall Development
 Projects and the SDLC
Product Scope
Product Scope

Initiate Requirements
Requirements

Design
Plan
Monitor &
Control Build
Build

Implement
Test
Test

Close Release
Release

PMI Project
Management Process Waterfall Development
 Projects and the SDLC
Product Scope
Initiate Agile
SCRUM
Requirements

Plan Design
PRINCE2
Monitor & RAD
Control
Build
Implement
SIX Sigma Rational
Test

Close
Etc. Release
Etc.

PMI Project
Management Process Waterfall Development
 Projects and the SDLC
Product Scope
Initiate Agile
SCRUM
Requirements

Plan Design
PRINCE2
Monitor & RAD
Control
Build
SIX SigmaImplement
Rational
Test

Close
Etc. Release
Etc.

PMI Project
Management Process Waterfall Development
 Projects and the SDLC
Product Scope
Initiate Agile
SCRUM
Requirements

Plan Design
PRINCE2
Monitor & RAD
Control
Plan Do Check Act
Build
SIX SigmaImplement
Rational
Test

Close
Etc. Release
Etc.

PMI Project
Management Process Waterfall Development
 Business AnalysisProduct Scope
SCRUMand the BABOK Agile
Initiate
Requirements

Plan Design
PRINCE2
Monitor & RAD
Control
Plan Do Check Act
Build
SIX SigmaImplement
Rational
Test

Close
Etc. Release
Etc.

PMI Project
Management Process Waterfall Development
 Projects and the SDLC
Product Scope
Initiate Agile
SCRUM
Plan Do Check Act
Requirements

Plan Design
PRINCE2
Monitor & RAD
Control
Build
SIX SigmaImplement
Rational
Test

Close
Etc. Release
Etc.

PMI Project
Management Process Waterfall Development
 Project Failures
There are many reasons why projects fail.
Poor strategic Lack of handover
Lack of sponsor alignment (people change management)

involvement
Poor
planning
Poor or wrong
Poorly defined Ineffective
objectives/scope requirements communication

Long time to
Team skills delivery Lack of formal
(esp. interpersonal skills) Poor risk
management 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 group’s 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.

1. Companies pay a premium of as much as 60% on time and budget when

they use poor requirements practices on their projects.

2. 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.

3. 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 group’s 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.

1. Companies pay a premium of as much as 60% on time and budget when

they use poor requirements practices on their projects.

2. 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.

3. 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 group’s 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.

1. Companies pay a premium of as much as 60% on time and budget when

they use poor requirements practices on their projects.

2. 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.

3. The vast majority of projects surveyed did not utilize sufficient

Requirements
business analysis skill to consistently?bring projects in ? on time and ? ?
Professionals
budget. The level of competency required is higher than that employed
within projects for 70% of the companies surveyed.
Project Failures
 Requirements Failures

The volume and complexity of

stakeholders Process
Stakeholder expectations &
involvement

Who is managing the Not

requirements - skills of the deliverable
requirements team
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
Practical
requirements owners into the same room as
the developers. Get them talking to each other.
tips
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.)
Project Team Roles
 Project Team Roles
Sponsor

Project
Manager

Business Change Solutions Liaison

Quality
Analyst Manager Team Roles

Process Solutions
Trainers Testers SMEs
Analysts Architects

Systems Technical
Users Designers Developers
Analysts Writers
 Project
Sponsor
Manager Liaison
Solutions
Architects Roles

Designers Users

Developers
Business SMEs
Analyst
Change
Testers
Manager

Technical
Quality
Writers

Process
Trainers Systems
Analysts
Analysts
• The IIBA and BABOK link

• Certification link

• Melbourne events Link 1 Link 2

• BABOK Chapter overview link

break
 WHAT DOES A BA DO?
• Requirements Management
• Business Processes
• People Change Management
• Project Portfolio Planning
Requirements
Management
MATURITY LEVELS (SEI/IEEE)
1. Chaos
2. Written requirements
3. Organized
4. Structured
5. Integrated
 BABOK Knowledge areas
• Defining the role, resources etc
• BA BOK and contents
– Planning
– Elicitation
– Modelling and Analysis
– Communication
– Validation
– Verification
• Enterprise analysis Level 3?
• Strategy and Structure
• Business Process Analysis
• Financial analysis and business
cases
• Consulting skills
• Project Management
 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
Plan
– CommunicationDo Check Act
– Verification
– Validation
Requirements integrity

Level 4?
Requirements integrity
 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?
1. Get lots of feedback (validation)
2. 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 Plans
• Know the stakeholders,
know their business
• Break your work down to
change
detailed tasks
 Requirements Elicitation
• Desk research
• Interviews
• Workshops Remember

• Models
– Flow charts (Swim Lanes) Activity Level
– Use Cases (with stories)
– Context Diagrams
– State Transition
Method H
 Requirements Communication
• Know who needs to
know
• Have enough time to
communicate
effectively Plan your
• Communicate through
the whole lifecycle
communication
• No surprises, Bad
news early
 Requirements Verification
• Document Reviews
– 3 day review cycles don’t
always work well
– Tell people in advance
Peer Review,
Manager Review,
• Reviews and Inspections are
one of the most effective
Tester Review
methods of Requirements QA

• Walkthrough workshops have

strengths and weaknesses Look for
– S: Group Synergies completeness and accuracy
– W: Time and effort (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)
Validation is
UAT done by people.
BA role in planning, participating,
assessing impact of bugs,
troubleshooting, workarounds,
stakeholders expectations Take them on
Business Acceptance the journey.
Contract perspective, Responsibilities
of both project and business,
Overlapping period
 Scope/ High Workshops Approve Revise
Solution
level and Business Scope/Bus
Design
BA activities

requirements Interviews Requirements Case

Document
Identify Identify Assess
Business
Stakeholders Constraints Design
Requirements

PM Requirements Change
Management Management

• RTM • Change Mgt

Designer/ • UAT Plan
Business Business Systems
Program • Comms Plan
person Analyst Analyst • Ready for
mer
Service • Training

Bus BA IT BA

Stakeholders Stakeholders

Business Managers IT managers,

and SMEs Infrastructure and
network SMEs
Business
Processes
 3 Things
• Use cases
• Swim lanes
• Context diagrams
 Use Cases

Case

Tyner Blain: Use Cases

user
 Swim lanes
Verb/noun
Actor 1

Begin and end

in same lane

Binary
Actor 2

decisions
Actor 3

Activity level

participants
Actor 4

Hand-over
Boundaries
 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
Aware
• Maister: Desire
The Fat Smoker Knowledge
Ability
• Prosci: Reinforce
ADKAR
 Changing people

Stakeholder 1 A D K Aware
A R

Stakeholder 2 A D K Desire
A R
Knowledge
Stakeholder 3 A D K A R
Ability
Stakeholder 4 A D K A R
Reinforce
Stakeholder 5 A D K A R
 Project
Portfolio
Planning
Project Portfolio Management

Enterprise Analysis Enterprise Architecture

Defining the opportunity Information Management

Solution Strategies Application Planning
Business Cases Business Process
Benefits management
break
 workshop
• Break into groups
• Review examples
• Present feedback
 workshop
1. Quality of documentation
• What makes – Completeness
– Accuracy
good – Clarity
– The difference between
requirements? requirements and design
2. Management through the
process

Reviewing Requirements
 Resources
• IIBA • Modern Analyst
– New, but growing in – Articles, Forums, etc
influence. • Ed Yourdon
• BOKS – JESA
– BA BOK • TynerBlain –
– PM BOK Structured analysis
– Others
• BetterProjects
 Modern Analyst
• Articles
• Forums
• Templates
• Other resources
 Ed Yourdon
• Website
• Blog
• Structured Analysis Wiki

• 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