The premiere software and product delivery event. June 6–10 Orlando, Florida

Transforming the Role of the Business Analyst

Kurt Bittner CTO-Americas, Ivar Jacobson International kbittner@IvarJacobson.com RDM-2166A

2

The Traditional Role of the Business Analyst

Interfacing between the Business and Developers, Testers

The Conduit for the Business’ wants and needs

Managing Requirements

Managing change and scope

2

User Acceptance Testing

Making sure the requirements were

implemented correctly

Subject Matter Expert - a Proxy for the

Business

Usually in the context of an existing system

Requirements Failures Survey Results

Users expect functionality they did not initially ask for 93%

Requirements are incomplete 89%

Requirements are unclear or ambiguous 85%

Developers make assumption when they encounter ambiguities or

gaps

85%

Users demand functionality that they never use 78%

Models are not consistently used or not used well 74%

The project’s vision and scope are not clearly defined 74%

Internal customers are unhappy due to project delays and missing the

mark

67%

Models are not consistent with written requirements 59%

Requirements are contradictory or conflicting 52%

Source: Dr. Dobb’s Requirements Development Journal, 2006

4

We Must Be Missing Something...

Many (most?) projects still fail

a prime cause of this is viewed to be

"requirements"

Clearly, the business doesn't really

know what it wants

so merely listening and recording is not

an effective strategy

In an “Agile” context, what is the role

of the Business Analyst?

A “Product Owner”? Does this simply

put a new name on the old role?

The Business Analyst needs to work

differently

and ultimately the role needs to change

4

5

What’s Needed?

A Shift in Perspective:

5

From

Gathering requirements

Delivering what the Business wants

Creating documents

Getting “sign-off”

To

Discovering Needs

Championing the Right Solution

Delivering what the Business needs

Facilitating communication and

ensuring a common understanding

Forging consensus

6

Work in the Inception Phase

Understand

Needs

Explore

Possible

Solutions

Evaluate

Proposed

Solutions

Confirm

Business

Viability

of Selected

Solution Scope & Plan

Iteration Scope &

Plan Phase

6

7

Work in the Inception Phase

Understand

Needs

Explore

Possible

Solutions

Evaluate

Proposed

Solutions

Confirm

Business

Viability

of Selected

Solution Scope & Plan

Iteration Scope &

Plan Phase

7

8

Changes in your Way of

Working First-hand observation of

business processes and

problems

Probing into root causes; not

being satisfied with identification

of wants

Pushing past “requirements” and

solution statements

Focusing on desired outcomes,

not features

Active listening and active

questioning

Understanding Needs

Knowledge and

Techniques to Master First-hand knowledge of the

Business

Facilitation skills to uncover

needs and desired outcomes

Investigative skills

Interviewing skills

Elicitation skills

The ability to understand and

find root causes for business

problems

Including gathering data to

support costs & benefits

8

9

Changes in your Way of

Working Working with an extended cross-

functional team to explore possible

alternatives

Working with the team to create

demonstrations of solution

alternatives

Consider more than one alternative

Be creative! Have fun!

Explore Possible Solutions

9

Knowledge and

Techniques to Master The ability to synthesize and

generalize needs to better

understand how they can be

met

The ability to identify creative

solutions to problems

The ability to communicate

solutions and tie to benefits

The ability to show how the

solution will meet needs and

produce desire outcomes

10

Evaluate Possible Solutions

10

Changes in your Way of Working Planning, organizing and leading

interactive solution review sessions

Don’t circulate documents, e-mails or

presentations

Make the sessions interactive

Decrease or eliminate reliance on “sign-

off”

… but document agreements and

confirm understandings in writing

When a solution is accepted, make sure

that everyone knows that:

Lots of details need to be ironed out,

but…

Real money is being spent going

forward

Knowledge and

Techniques to Master Being able to “sell” Stakeholders

on the proposed solution(s)

Show them how the solution

meets their needs

… even if it is not what they

originally asked for

Soliciting and accepting feedback

Guiding discussions

Handling objections

Managing and directing

expectations

11

Work in the Elaboration & Construction Phases

Refine

Solution

Specification

Develop

Increment

Evaluate

Results Confirm

Technical

Viability

of Solution Scope & Plan

Iteration Scope &

Plan Phase

11

12

Work in the Elaboration & Construction Phases

Refine

Solution

Specification

Develop

Increment

Evaluate

Results Confirm

Technical

Viability

of Solution Scope & Plan

Iteration Scope &

Plan Phase

12

13

Refine Solution Specification

13

Changes in your Way of

Working Working iteratively

Being able to refine specifications

without getting lost in detail

Being able to decide how much detail

is needed

Understanding when and how to

apply various requirements

techniques

Knowledge and Techniques

to Master Knowledge of a variety of different

requirements techniques

An understanding of the level of

detail appropriate for the situation

The ability to work interactively with

business representatives to probe

into specific requirements

… without getting lost in

unnecessary detail

… without resorting to “feature

creep”

14

Requirements Approaches to Master

14

15

Evaluate Results

15

Changes in your Way of

Working Planning, organizing and leading

interactive solution review sessions

Don’t circulate documents, e-mails

or presentations

Make the sessions interactive

Decrease or eliminate reliance on

“sign-off”

… but document agreements and

confirm understandings in writing

Knowledge and Techniques

to Master Being able to “sell” Stakeholders on

the proposed solution(s)

Show them how the solution

meets their needs

… even if it is not what they

originally asked for

Soliciting and accepting feedback

Guiding discussions

Handling objections

Managing and directing

expectations

16

Potential Barriers to Changes

Business Push-back

They may like dictating solutions. Even though the results usually fall short, they can

always blame IT

IT Push-back

Developers may like being able to blame someone else for bad requirements

IT staffers may not really want to work on a cross-functional team

Lack of Skilled Business Analysts

… or people who want to work in a new way. They may prefer to hide behind

requirements documents and formal sign-offs

Governance milestones that require the old way of working

Nothing kills innovation more than a bureaucracy that prohibits change

Lack of good Role Models and Coaches

The journey is hard enough without support and guidance

Lack of organizational support

Change takes time, and organizations often won’t take time to do it right, even though

continuing to work in the same way is not producing the desired results

16

17

How to Move Ahead

The first step is recognizing that you have a

problem

Doing the same thing and expecting different results is

a sign of insanity

Get agreement among all the stakeholders that there is

a problem, and a sense of urgency on solving it

Get commitment, if only for a pilot, to work in a new

way

Choose leaders, influencers as participants

Show an example of how a new way of working can

produce better results

Socialize success

Use road shows and internal web conferences to

spread the word about the new model

Attract the leaders, the rest will follow

Get people who are respected on board and working in

the new way

Coach and mentor to support the change

17

18 18

19 19

© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

www.ibm.com/software/rational