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

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

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

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

There are many reasons why projects fail.

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

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 ? ? ? ?

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.

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

The volume and complexity of stakeholders

Stakeholder expectations & involvement

Who is managing the requirements - skills of the requirements team

Process

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

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

The IIBA and BABOK

Certification

Melbourne events

BABOK Chapter overview

break

WHAT DOES A BA DO? Requirements Management Business Processes People Change Management Project Portfolio Planning

Requirements Management

Business Processes

People Change Management

Project Portfolio Planning

Requirements Management

MATURITY LEVELS (SEI/IEEE) Chaos Written requirements Organized Structured Integrated

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?

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

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

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 Verification Validation Plan Do Check Act

Requirements Management

Planning

Elicitation

Communication

Verification

Validation

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

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

Basic Skills Requirements Management Planning Elicitation Communication Verification Validation

Requirements Management

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

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

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

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)

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.

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

RTM

UAT

Ready for Service

Change Mgt Plan

Comms Plan

Training

Business Processes

3 Things Use cases Swim lanes Context diagrams

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

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

Aware

Desire

Knowledge

Ability

Reinforce

Project Portfolio Planning

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

Enterprise Analysis

Defining the opportunity

Solution Strategies

Business Cases

Benefits management

Enterprise Architecture

Information Management

Application Planning

Business Process

break

workshop Break into groups Review examples Present feedback

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

What makes good requirements?

Quality of documentation

Completeness

Accuracy

Clarity

The difference between requirements and design

Management through the process

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

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

Articles

Forums

Templates

Other resources

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

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

Software development

Requirements management

Product management

See

Structured analysis and Use Cases

Scott Sehlhorst, Austin Texas