IBM Innovate Conference: Transforming the Role of the Business Analyst

Transforming the Role of the Business Analyst Kurt Bittner CTO-Americas, Ivar Jacobson International kbittner@IvarJacobson.com RDM-2166A The premiere software and product delivery event. June 6–10 Orlando, Florida

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

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 85% gaps 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 67% mark Models are not consistent with written requirements 59% Requirements are contradictory or conflicting 52% Source: Dr. Dobb’s Requirements Development Journal, 2006

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

What’s Needed? A Shift in Perspective: From To  Gathering requirements  Discovering Needs  Championing the Right Solution  Delivering what the Business wants  Delivering what the Business needs  Creating documents  Facilitating communication and ensuring a common understanding  Getting “sign-off”  Forging consensus 5

Work in the Inception Phase Explore Possible Solutions Understand Needs Evaluate Confirm Proposed Business Solutions Viability of Selected Scope & Plan Solution Scope & Iteration Plan Phase 6

Work in the Inception Phase Explore Possible Solutions Understand Needs Evaluate Confirm Proposed Business Solutions Viability of Selected Scope & Plan Solution Scope & Iteration Plan Phase 7

Understanding Needs  Knowledge and Changes in your Way of Techniques to Master Working First-hand knowledge of the First-hand observation of Business business processes and Facilitation skills to uncover problems needs and desired outcomes Probing into root causes; not  Investigative skills being satisfied with identification  Interviewing skills of wants  Elicitation skills Pushing past “requirements” and solution statements The ability to understand and find root causes for business Focusing on desired outcomes, problems not features  Including gathering data to Active listening and active support costs & benefits questioning 8

Explore Possible Solutions  Knowledge and Changes in your Way of Techniques to Master Working The ability to synthesize and Working with an extended cross- generalize needs to better functional team to explore possible understand how they can be alternatives met Working with the team to create The ability to identify creative demonstrations of solution solutions to problems alternatives The ability to communicate Consider more than one alternative solutions and tie to benefits Be creative! Have fun! The ability to show how the solution will meet needs and produce desire outcomes 9

Evaluate Possible Solutions Knowledge and Changes in your Way of Working Techniques to Master Planning, organizing and leading Being able to “sell” Stakeholders interactive solution review sessions on the proposed solution(s) Don’t circulate documents, e-mails or Show them how the solution presentations meets their needs Make the sessions interactive … even if it is not what they Decrease or eliminate reliance on “sign- originally asked for off” Soliciting and accepting feedback … but document agreements and Guiding discussions confirm understandings in writing Handling objections When a solution is accepted, make sure that everyone knows that: Managing and directing expectations Lots of details need to be ironed out, but… Real money is being spent going forward 10

Work in the Elaboration & Construction Phases Develop Increment Refine Solution Specification Evaluate Confirm Results Technical Viability of Solution Scope & Plan Scope & Iteration Plan Phase 11

Work in the Elaboration & Construction Phases Develop Increment Refine Solution Specification Evaluate Confirm Results Technical Viability of Solution Scope & Plan Scope & Iteration Plan Phase 12

Refine Solution Specification Knowledge and Techniques Changes in your Way of to Master Working Knowledge of a variety of different Working iteratively requirements techniques Being able to refine specifications An understanding of the level of without getting lost in detail detail appropriate for the situation Being able to decide how much detail The ability to work interactively with is needed business representatives to probe Understanding when and how to into specific requirements apply various requirements … without getting lost in techniques unnecessary detail … without resorting to “feature creep” 13

Requirements Approaches to Master 14

Evaluate Results Knowledge and Techniques Changes in your Way of to Master Working Being able to “sell” Stakeholders on Planning, organizing and leading the proposed solution(s) interactive solution review sessions Show them how the solution Don’t circulate documents, e-mails meets their needs or presentations … even if it is not what they Make the sessions interactive originally asked for Decrease or eliminate reliance on Soliciting and accepting feedback “sign-off” Guiding discussions … but document agreements and Handling objections confirm understandings in writing Managing and directing expectations 15

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

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

www.ibm.com/software/rational © 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. 19

IBM Innovate Conference: Transforming the Role of the Business Analyst

by Ivar Jacobson International on Aug 09, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

IBM Innovate Conference: Transforming the Role of the Business Analyst — Presentation Transcript