Business Analyst Training

For Business Analysts Craig Brown www.betterprojects.net

Business Analyst Training
My agenda
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
Projects and SDLC
Why projects go wrong
Project team roles
8.15-9.45
What BA’s do
Requirements Management
Business Processes
Human change management
Project Portfolio Planning
10.00-11.00
Practical skills
Technical skills
Analysis exercise
Questions and discussion
11.15-12.15
break break

Projects and the SDLC Release Test Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development Initiate Plan Monitor & Control Implement

Projects and the SDLC Product Scope Release Test Initiate Close Build Design Requirements PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Monitor & Control Implement

Projects and the SDLC Release Test Initiate Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Do Check Act Plan Monitor & Control Implement

Business Analysis and the BABOK Release Test Initiate Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Do Check Act Plan Monitor & Control Implement

Projects and the SDLC Release Test Initiate Close Build Design Requirements Product Scope PMI Project Management Process Waterfall Development SCRUM PRINCE2 SIX Sigma Agile RAD Rational Etc. Etc. Plan Do Check Act Plan Monitor & Control Implement

Project Failures
There are many reasons why projects fail.
Poor strategic alignment Long time to delivery Poor risk management Poor planning Lack of sponsor involvement Ineffective communication Lack of handover (people change management) Team skills (esp. interpersonal skills) Poor requirements management is consistently in the top 3 reasons, regardless of the source Lack of formal pm processes Poorly defined objectives/scope Poor or wrong requirements

The cost of bad requirements
The following are a few key findings and data from the study:
Companies with poor business analysis capability will have three times as many project failures as successes.
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.
Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
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.
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:
Companies with poor business analysis capability will have three times as many project failures as successes.
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.
Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
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.
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.
Requirements Professionals ? ? ? ?

Project Failures IAG report can be accesse at iag.biz

Requirements Failures
The volume and complexity of stakeholders
Stakeholder expectations & involvement
Who is managing the requirements - skills of the requirements team
Process
Not deliverables

Requirements Failures
Avoid requirements failure by doing these things;
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.
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.
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 Change Manager Quality Solutions Team Liaison Roles Process Analysts Trainers Testers Solutions Architects SMEs Systems Analysts Technical Writers Users Designers Developers

Sponsor Project Manager Change Manager Quality Liaison Roles Process Analysts Trainers Testers Solutions Architects SMEs Systems Analysts Technical Writers Users Designers Developers Business Analyst

The IIBA and BABOK
Certification
Melbourne events
BABOK Chapter overview
link link link Link 1 Link 2

WHAT DOES A BA DO?
Business Processes
People Change Management

MATURITY LEVELS (SEI/IEEE)
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
Strategy and Structure
Business Process Analysis
Financial analysis and business cases
Consulting skills
Project Management
Level 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
Planning
Elicitation
Communication
Verification
Validation
Plan Do Check Act

Requirements integrity Level 4? Guy Beauchamp Modern Analyst

Requirements integrity Guy Beauchamp Modern Analyst

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

WHAT DOES A BA DO?
Understand the stakeholders
Break work down to activity level
Who does what, when and why?
Get lots of feedback (validation)
Manage expectations throughout the process
should Requirements management

Basic Skills
Planning
Elicitation
Communication
Verification
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 don’t 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.

Designer/Programmer Scope/ High level requirements Workshops and Interviews Identify Constraints Revise Scope/Bus Case Identify Stakeholders Document Business Requirements Approve Business Requirements Solution Design Assess Design Requirements Management Change Management BA activities
RTM
UAT
Ready for Service
Change Mgt Plan
Comms Plan
Training
Business person IT BA Bus BA Systems Analyst Business Analyst Stakeholders IT managers, Infrastructure and network SMEs Stakeholders Business Managers and SMEs PM

Business Processes

3 Things
Use cases
Swim lanes
Context diagrams

Use Cases Case user Tyner Blain: Use Cases

Swim lanes Actor 1 Actor 2 Actor 3 Actor 4 Verb/noun Binary decisions Activity level participants Boundaries Hand-over Begin and end in same lane

Context diagrams Information flow External Internal Drilling down Context Boundary

… and UML Diagram from Wikipedia

… and UML Diagram from Wikipedia UML is for solution design

People Change Management

Changing people
Lewin:
Unfreeze > Freeze
Maister:
The Fat Smoker
Prosci:
ADKAR
Aware
Desire
Knowledge
Ability
Reinforce

Changing people
Aware
Desire
Knowledge
Ability
Reinforce
Stakeholder 1 A D K A R Stakeholder 2 A D K A R Stakeholder 3 A D K A R Stakeholder 4 A D K A R Stakeholder 5 A D K A R

Project Portfolio Management
Enterprise Analysis
Defining the opportunity
Solution Strategies
Business Cases
Benefits management
Enterprise Architecture
Information Management
Application Planning
Business Process

workshop
Break into groups
Review examples
Present feedback

workshop
What makes good requirements?
Quality of documentation
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 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

http://www.betterprojects.net	135
http://knoworacle.wordpress.com	127
http://www.slideshare.net	59
http://pyovevlibrary.blogspot.com	19
http://www.brijj.com	12
http://analizabusiness.com	3
http://www.globalprojectmanagement.org	2
http://www.techgig.com	2
http://static.slidesharecdn.com	1
http://www.nueronic.com	1
http://static.slideshare.net	1
http://www.lmodules.com	1
http://www.yatedo.com	1

Business Analyst Training

by Craig Brown on Mar 04, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

13 Embeds 364

Statistics

Business Analyst Training — Presentation Transcript