Post on 07-Dec-2014
description
transcript
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