Business Analysis E-Book

Steven Blais

• Herausgeber: John Wiley & Sons
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 673

Veröffentlichungsjahr: 2011

Beschreibung

The definitive guide on the roles and responsibilities of the business analyst Business Analysis offers a complete description of the process of business analysis in solving business problems. Filled with tips, tricks, techniques, and guerilla tactics to help execute the process in the face of sometimes overwhelming political or social obstacles, this guide is also filled with real world stories from the author's more than thirty years of experience working as a business analyst. * Provides techniques and tips to execute the at-times tricky job of business analyst * Written by an industry expert with over thirty years of experience Straightforward and insightful, Business Analysis is a valuable contribution to your ability to be successful in this role in today's business environment.

Leseprobe

Contents

Cover

Title Page

Copyright

Dedication

Preface

How to Use This Book

Questions, Comments, and Complaints

Acknowledgments

International Institute for Learning, Inc. (IIL)

Part I: The Problem Solver

Chapter 1: What Is a Business Analyst?

The Business Analyst in Context

What Is It All About?

The Role of the Business Analyst

The Business Analyst in the Center

Business Analyst Focus

The Ideal Business Analyst

Last-Liners

Notes

Chapter 2: The Evolution of the Business Analyst

The Business Analyst Hall of Fame

Where It Began

Information Systems

The Rise of the Business Analyst

The Business Analyst Position

The Business Analyst Profession

The Question of Certification

The Challenge of Business Analyst Certification

The Value of Certification

Notes

Chapter 3: A Sense of Where You Are

Business Analysts Coming from IT

Business Analysts Coming from the Business Community

Living with the Business

The Lone Ranger

Working Both Sides of the Street

Central Business Analyst Organization

Chapter 4: What Makes a Good Business Analyst?

The Skillful Business Analyst

Is a Business Analyst Born or Made?

So What Does It Take to Be a Business Analyst?

Chapter 5: Roles of the Business Analyst

Intermediary

Filter

Mediator

Diplomat

Politician

Investigator

Analyst

Change Agent

Quality Control Specialist

Facilitator

Process Improver

Increase the Value of Organizational Business Processes

Build It and They Will Come

Reducing Complexity

Playing Multiple Roles

Notes

Part II: The Players

Chapter 6: The Business Analyst and the Solution Team

Business Analyst and Project Manager

Business Analyst and Systems Analyst

Trying to Do All Jobs

Business Analyst and the Rest of the Solution Team

Bottom Line

Notes

Chapter 7: The Business Analyst and the Business Community

Constituents and Constituencies

Business Analysts and Upper-Level Management

Product Stakeholders

Subject Matter Experts

Process Workers

Managing Expectations

Notes

Part III: The Problem

Chapter 8: Define the Problem

First Things First

Challenge 1: Finding the Problem

Challenge 2: The Unstated Problem

Challenge 3: The Misunderstood Problem

Define the Real Problem

The Problem Determination Game

Documenting the Problem

Product Vision

Define the Vision

Checkpoint Alpha

Focus on the Problem and Vision

Note

Chapter 9: Define the Product Scope

Project and Product Scopes

Product Scope

Product Scope Formula

Strategic Justification

Business and Product Constraints

Business and Product Risks

Functional Goals

Political Success Factors

Product Scope Formula

Measuring

Take the Technical Pulse

Applying the Product Scope

Notes

Chapter 10: Confirm Alignment and Financial Justification

The Business Case

The Value of IT

Considering Alignment

Organization Mission

Organization Goals

Organization Strategies

Department-Level Mission, Goals, and Strategies

At the Tactical Level

Determining the Value of the IT Project

Provide Financial Justification for Solving the Problem

Proof of Solution: Feasibility Study

The Metrics Game

In the End . . .

Notes

Part IV: The Process

Chapter 11: Gather the Information

Why We Cannot Define Good Requirements

Stop Gathering Requirements

Users Do Not Have Requirements

Gather Information, Not Requirements

Gathering the Information

Information-Gathering Plan

Information-Gathering Session

Solving Common Information-Gathering Issues

Iterative Information Gathering

Interviewing

Information-Gathering Meetings

Other Elicitation Methods

Are We Done Yet?

Notes

Chapter 12: Define the Problem Domain

Problem Domain Analysis

Defining the Domain

Changes in the Problem Domain

Neighboring Constituencies

Ancillary Benefits

Change in the Problem

The Essence

Note

Chapter 13: Determine the Solution

The Accordion Effect

Tools and Techniques

Determining the One Best Solution

Constraining the Solution

Stop Analyzing, Already

Confirmation

Checkpoint Beta

Notes

Chapter 14: Write the Solution Document

The Value of Documentation

The Anatomy of Requirements

Forms of Solution Documentation

Write the Right Thing

Write the Thing Right

Canned Brains

Requirements Ownership

Complete the Process

Note

Part V: Producing the Product

Chapter 15: Monitor the Product

Entering the Solution Domain

Development Processes

Implementing the Solution

Keep the Light on

Things Change

Checkpoint Charley

The Watchdog

The Essence

Notes

Chapter 16: Confirm the Business Problem Has Been Solved

Correct Behavior

Acceptable Level of Confidence

Circumstances of Interest

The Testing Game

User Acceptance Testing?

Handling Defects

Testing Does Not Stop at Delivery

Note

Chapter 17: Transition and Change Management

Steps to Ensure Successful Change in the Organization

Orchestrate the Transition

Facilitate the Transition

Timing the Change

Major and Minor Changes

Do Not Change a Thing

Wrapping Up

Notes

Postscript: Where to Go from Here

Future of Business Analysis

Why We Need Business Analysts

The True Value of the Business Analyst

Increasing the Value of the Organization

Power to the Business Analyst

Notes

Appendix A: Business Analyst Process

I. Define the Problem and Product Scope

II. Define the Solution

III. Keep Requirements Up-to-Date throughout Software Development

IV. Prepare Acceptance Tests Based on the Defined Acceptance Criteria That Will Prove to Business Analyst and Stakeholders That the Problem Is Solved

V. Enable the Transition of Solution into Production

VI. Start Over Again

Appendix B: The Principles

Principle 1: Focus on the Product

Principle 2: First Define the Problem and Then the Solution

Principle 3: Users Do Not Have Requirements

Principle 4: Focus on Information Not Individuals

Principle 5: Separate Elicitation from Analysis

Principle 6: Improve the Process First then Add Technology

Principle 7: Communicate, Cooperate, Collaborate

Principle 8: The Business Analyst Owns the Solution Requirements

Principle 9: Gain Acceptance as Well as Approval

Principle 10: Make the Business Community Ready for the Product

Principle 11: Measure Twice, Cut Once

Note

Appendix C: Why We Do Not Get Good Requirements

Appendix D: Comparison of the Roles of Business Analyst, Systems Analyst, and Project Manager

Appendix E: Context-Free Problem Definition Questions

Appendix F: List of Nonfunctional Requirements Categories

Bibliography

About the Author

Index

Copyright © by International Institute for Learning, Inc. (IIL). All rights reserved.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey.

Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone], or on the Web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging-in-Publication Data:

Blais, Steven.

Business analysis: best practices for success/Steven Blais.

p. cm.

Includes index.

ISBN 978-1-118-07600-2 (hardback); ISBN 978-1-1181-6155-5 (ebk); ISBN 978-1-1181-6157-9 (ebk); ISBN 978-1-1181-6160-9 (ebk)

1. Business analysts. 2. Business planning. 3. Organizational effectiveness. I. Title.

HD69.B87B56 2012

658.4′013—dc23

2011029140

10 9 8 7 6 5 4 3 2 1

To Sonia: You are on every page and in every word.

Preface

It is all about change.

There is a problem that needs to be solved. Sales needs support for the new marketing initiative. Human resources (HR) wants the employees to be able to manage their own United Way Fund and other charity deductions online. Marketing needs to change the mailing preferences to allow customers to opt-out of various publications in order to be in conformance with new regulations. The accounts payable system is old and slow and getting more inaccurate by the day. The organization wants these problems solved.

People running the business do not have the time to research, investigate, and determine the best way of solving the problems. Besides, today's solutions require automation, computers, software, and so forth and businesspeople do not do those things. They do not have the expertise. Businesspeople do not want code. They do not want systems. They do not want networks. What they want is a solution to their business problems.

The information technology (IT) department will make it happen. The technology professionals write the software, define and populate the databases, connect the networks, and install hardware. All they need to know is what the business wants done.

Yet, who is defining what will be done to solve the problem? Who defines the solution in such a way that the business can agree with the solution and the technologists can understand what needs to be done to implement the solution? And when the technology is ready for the business, who will make sure the change is made efficiently and the transition from the current to new process is smooth?

The answer to these questions is the business analyst.

Over the past 10 years or so the position of business analyst has found its way into the Human Resources job description catalog of many organizations. It has also earned its own trade group, the International Institute of Business Analysis (IIBA) and its own certification, the certified business analyst professional (CBAP), which is administered by the IIBA.

The role of the business analyst is to solve business problems. Specifying requirements is a critical function of the business analyst, but so are the many other responsibilities a business analyst can and should undertake all of which lead to the successful solution of a business problem.

Business analysis is all about change: changes in business processes, changes in the information technology systems supporting business processes; changes in the way the organization does business. Everything the business analyst does results in some kind of change to the organization. Most of what the business analyst does should be aimed at solving a business problem, and that requires changing the organization from the current situation in which the problem exists to a new process or operation in which the problem has been solved.

First and foremost, the business analyst is a problem solver. Kathleen Barrett, President of the International Institute of Business Analysis, calls the business analyst the ultimate problem solver. The business analyst becomes the go-to person in both the business and development communities when there is a problem. Any kind of problem: political, technical, business, misunderstandings, ambiguities, social, technological, philosophical. Big problems, small problems. Problems that require an IT intervention and those that can be fixed by rearranging the office furniture.

The business analyst accepts the job of proactively understanding what the business problem is and determining the consequences of not solving it and then defines a solution that will remove or ameliorate the problem. The business analyst does this before development starts and then ensures that the solution as built by IT, in fact, solves the problem and does so in such a way that those affected by the problem can use the solution.

By solving business problems, the business analyst is continually adding value to the organization. In fact, all the activities that a business analyst performs add value. The business analyst adds value by:

Acting as the organizational change agent to improve business processes (Chapter 5).

Investigating the real problem so that time and energy are not wasted solving the wrong problem (Chapters 8, 9, and 10).

Providing information to upper-level management so their decision- making can be faster and more effective (Chapters 5, 8, and 10).

Getting the business managers and process workers to talk directly to the technicians and technologists to reduce time and miscommunication (Chapters 5 and 15).

Creating an environment where there is an unfettered flow of information between business units and between business and IT that increases quality of overall operations in the organization (Chapters 5, 6, 7, 14, and 17).

Managing the organization's expectations of the solution so that the stakeholders realistically understand and accept the solution to their problem (Chapters 7, 9, 10, 16, and 17).

Applying analytical and creative thinking to ensure the organization is making the best decisions and acting on the best solutions to problems (Chapters 5, 8, 12, and 13).

Assuring the product developed by the solution team solves the intended problem (Chapters 15 and 16).

Orchestrating the transition from the current business operations to the changed operations so that the organization gains the benefits of the new process as quickly as possible (Chapter 17).

This is a daunting job, filled with challenges and obstacles, both technical and political. And it is also a job filled with satisfaction and personal reward. The business analyst sits in the center of it all, engaging technologists and businesspeople, mediating misunderstandings, defining functions and features, mollifying management, identifying impacts, creating constructive change, and solving business problems.

I have been performing the various roles and activities of the business analyst for 40 years now. I have worked with hundreds of business analysts and have heard their opinions, stories, frustrations, fears, concerns, and questions. This book is in response to them. Their questions, presented as actual quotes from business analysts, appear at the top of each section in which there is an answer. Hopefully, I answered your questions along the way.

My goal with this book is to demonstrate that the business analyst is more than a requirements recorder. The business analyst is a central cog in the successful organization's driving wheel.

The business analyst is the organizational change agent.

The business analyst is the organizational problem solver.

The business analyst is the repository of business process information.

In essence, here are the business analyst's marching orders:

There is a problem—define it.

There is a solution to that problem—describe it.

We need to change the organization to solve the problem—make it happen.

How to Use This Book

While one use of this book might be as a weapon to threaten recalcitrant users into submission, this book can also be used as a guidebook to the wild environs of business analysis. Reading it straight through, from cover to cover, or at least from page one until the end, you will get a fairly complete description of the overall business analyst's process for solving business problems. You can also use the book to bolster arguments for additional pay and benefits for business analysts or simply to provide supporting information in an effort to establish a centralized formal or informal business analyst group within your organization. However, if you need a quick answer to a question that has been bothering you, the book is also an F&IAQ (frequently and infrequently asked questions) as is described later.

While the main thrust of the book is a description of the business analyst's process for solving business problems, there are also a number of tips, tricks, techniques, and tactics to help to execute the process in the face of sometimes overwhelming political or social obstacles.

The typical business analyst has a finely honed associative memory. It is associative memory that allows the business analyst to relate potential solutions to the business problem and see emerging and existing patterns in the business processes. In deference to that associative memory, the book is littered with sidebars.

Some sidebars emphasize particular points or expand on them.

Example

Associative memory also allows us to recognize mistakes we have made in the past when we are making them again. This, according to F.P. Jones is the definition of experience.

Throughout the book I highlight tips, techniques, and guerrilla tactics that will serve you in good stead during your business analyst career. Many of the tips are humorous or tongue-in-cheek in nature.

Tip

When you end an information gathering meeting early announce the time you are ending to let people know you are ending early. This way you will be known as someone who ends a meeting on time. If you realize your meeting may be running late, make an announcement about five minutes before the scheduled end of the meeting that “It's about five minutes until the hour and we're about done here. Just a few more questions.” If you end ten minutes late most people will still remember the time you stated and have the impression your meeting got out on time.

The Just for Fun sidebars contain fanciful explanations of why things are as they are.

Just for Fun

Whenever we brought changes to the Vice President who was acting as the Change Control Board he would either approve the change or defer it to a later release. He asked what the last scheduled release we had, and schedule it for the next release after that, which at the time was Release 9. When, later on after the first releases of the system were delivered, we began to schedule more releases, he told us to move everything that was in Release 9 out to the next release after the last one scheduled, or Release 12. It was his way of not saying “no” to the business requests for changes to the system. Prior to becoming a Vice President of this telecommunications firm, he has spent years as a consultant in the Washington DC area where he learned how to say “no” without ever saying “no.”

Some of the sidebars contain some alternate ways for doing some of the activities you have been performing as a business analyst which might make your job just a little easier, or bring about better results.

May I Suggest?

Instead of thinking “users” and referring and documenting user activities, needs, wants, etc., think instead “process workers.” This enlarges the potential population of people who might be involved in the business process. Users are only involved with the computer and as long as we restrict our views to users we will not see improvements that can be made in processes, especially those improvements that turn process workers into users by automating a part or all of their process activities.

Some sidebars track a case study to show the real-life application of the principles and practices of the business analyst process.

Case Study

One of the case studies is an accounts payable system revision. It stars Charlie, the accounts payable voucher entry clerk whose primary goal is to get to Happy Hour on time.

Questions, Comments, and Complaints

Being a business analyst is a complicated job. It is a new profession in many organizations and that newness brings with it confusion, questions, concerns, and the inevitable complaints. Rather than try to guess what the questions are, I asked the business analysts themselves.

The following list represents an abbreviated collection of questions, concerns, and complaints that business analysts have voiced to me over the years. Many of these questions and concerns might have occurred to you as you go about your work as a business analyst. I index the questions to the chapter of this book where the question is answered. This provides a quick reference when the question comes up (again) in your day-to-day activities.

Questions, Comments, ComplaintsAnswers found inWhat is my relationship with the project manager?Chapter 6What are the roles and responsibilities of a business analyst?Chapter 5What is the connection between requirements and testing?Chapter 16How do I know what questions to ask the users?Chapter 11—The Information-Gathering SessionHow can I do it right the first time and avoid rework?Part Four: The ProcessHow can I write better requirements?Chapters 11, 13, and 14How do we get management and users to cooperate when they refuse to focus on requirements?Chapter 9Is it possible to create a common language for IT and business?Chapters 6 and 7Is there a methodology or process for business analysts?This whole bookHow can I improve the communication between stakeholders and business and developers?This whole bookSince I'm doing all three roles, what is the difference between the project manager, the systems analyst, and the business analyst?Chapter 6, Appendix BAre there any tools for business modeling, and if so which ones should business analysts use?Chapter 13How do I negotiate with the business to change their expectations? Or if you can't change them, how do you keep them in line with reality?Chapter 7Is there an efficient, effective way to define the requirements?Chapters 13 and 14I have to do everything from defining the requirements to coding and testing; how can I effectively be a one-man band?Chapter 6How can we make sure there are no surprises at the end when we are delivering the solution?Chapters 11, 15, and 17How do we deal with customers who give us the solution and not the problem?Chapter 11—Interview IssuesWhat is the best way to objectively define requirements after the boss has given us the solution? What do we do if the real solution isn't his?Chapter 11—Interview IssuesI deal with both internal and external teams, including offshore developers. How can I make sure all the communications are consistent and effective?Chapter 5 (Intermediary), 6 (Solution Team), and 15What's the best way to create the business case? Is it the job of a business analyst?Chapter 10Where does the business analyst fit into our software development life cycle?Chapter 15We're using agile development (Extreme Programming). What is my role as a business analyst in this situation?Chapter 15Is it necessary to provide cost justification, such as an ROI for projects, and if so, how do you do it?Chapter 10How do I separate the noise from the true requirements?Part Four: The ProcessHow can I get good requirements when management dictates schedules that don't allow enough time?Chapter 11What are some techniques that can be used to work with groups who won't cooperate?Chapters 7 and 12What do I do about new requirements that are defined after the project starts?Chapters 11 and 15How do I handle the project manager and project team?Chapter 6How do I negotiate with the business to change their expectations?Chapter 7How do we handle changes after getting sign-off on a hundred-page document?Chapter 15The business analysts are tasked with testing the results of the development efforts. We are not given much advance warning. Then when we use the requirements as a guideline to what we expect the system to do, it's all different. The technical team has made changes and we don't know what the system is supposed to do. How can we test it on behalf of the users if it isn't what the users asked for anymore?Chapters 15 and 16I have been a systems analyst for over five years; how do I transition to my new job as business analyst?Chapters 3 and 6Communication with the developers is not very satisfactory. They have no respect for what we do.Chapter 6Over-commitment—management is trying to do too many things without evaluation or prioritization.Chapter 7How do I explain to my kids what a business analyst does?Part One: The Problem SolverI transitioned from system analyst to business analyst. Will be technical background help me or hurt me?Chapter 3How does the time spent in business process modeling help me? Do I need to know how to do all the different types of models, like entity relationship diagrams?Chapter 13How do I get the business to give us information?Chapter 11Is there a holistic view of requirements and testing?Part Four: The ProcessThere are last minute changes made to the releases which are done directly with the project team. When this causes the delivery to be delayed or there are impact problems, the business analysts are blamed.Chapter 15—Checkpoint CharleyThere is no single point of responsibility for documenting and maintaining all the communications between business and technical teams about the project and requirements.Chapter 5—IntermediaryHow can we convince the users that we do more than prepare and maintain documents?Chapter 1 and PostscriptThere are user meetings every month, but the business analysts are not allowed to attend since we represent IT and the meetings are for the business.Chapter 7Are there any overall guidelines that will assist business analysts in doing their job successfully?This whole bookWhat can I do to increase collaboration among all the parties in the solution development effort?Chapter 5—DiplomatWhy is there always such a gap between the user requirements and the delivered product?Chapters 8, 9, and 15How can we make successful changes to the processes without encountering so much resistance from the users?Chapters 12 and 17I feel like we are an afterthought. Is there really a business analyst profession?Chapters 2, 4, and PostscriptWhat is the difference between the “what” requirements and the “how” requirements?Chapter 14—Anatomy of RequirementsWho defines acceptance test cases? Who executes acceptance test cases?Chapter 16How do we convince the customer to do something different, such as another approach?Chapters 7, 11, and 12

Acknowledgments

Thanks to all the hundreds, perhaps thousands, of business analysts I've worked with over the past 15 years in meeting rooms, lunch rooms, conference rooms, class rooms, hallways, parking lots, airport waiting areas, break rooms over the coffee machine, offices and cubicles, and hotel lobbies, each of whom has contributed a little to this book.

Specific thanks go to John Vervoort who was the first President of the New York IIBA chapter, and to Tyson Faircloth of CACI, and to the group down at Dominion Power in Virginia, and Phil Skepnic of CVS/Caremark, all of whom provided valuable information and/or allowed me to spend time with their business analysts and learn from them.

Thanks to a group of people who helped instill some agility into the business analyst processes in the book: Scott Ambler, Dr. Steven Gordon, Paul Oldfield, Pete Ruth, and Ron Jeffries.

Thanks also to the many who shared their ideas and concerns about business analysts and the business analysis profession especially Laura Brandenburg, Adriana Beal, Jon “Kupe” Kupersmith, Nathan Caswell, Leslie Munday, Mara Burns, who provided insights on the relationship of business analysts and the project management office (PMO) in major financial organizations, John Winter of the Internal Institute of Learning, and Kevin Brennan and Julian Sammy of the IIBA.

Thanks to those who helped make the pages read better: Dr. Roberta Simmons, Nancy Mingus, Judy Umlas of the International Institute of Learning (IIL), and Tim Burgard, Stacey Rivera, Helen Cho, and Chris Gage at John Wiley & Sons.

Thanks to those whose support and encouragement along the way helped keep me on track over a somewhat lengthy process, with a special tip of the hat to my family: children—Summer, Sean, Terry, and Brian—and grandchildren, as well as Elaine Lincoln, Rob Molina, John Kupiec, and Eddie and Karen Martinez. And a special thanks to Josefina Martinez, who never lost faith for a minute.

Thanks most of all to my wife, Sonia, who put up with vacations spent in writing and rewriting to hit deadlines and missed appointments and engagements, late nights and constant travel that come with the jobs that generated the ideas and examples included in the book.

Finally, thanks to all the business analysts everywhere who through their persistence and hard work are creating the profession that will be at the center of every successful business in the twenty-first century.

International Institute for Learning, Inc. (IIL)

With operating companies all over the world and clients in more than 150 countries, IIL is a global leader in training, consulting, coaching and customized course development. Our core competencies include: Project, Program and Portfolio Management; Microsoft® Project and Project Server; Business Analysis; Lean Six Sigma; PRINCE2®; ITIL®; Leadership and Interpersonal Skills.

Using our proprietary Many Methods of Learning™, IIL delivers innovative, effective and consistent training solutions through a variety of learning approaches, including Virtual Classroom, Traditional Classroom, Simulation Training, Interactive On-Demand Training and a blended approach. Our roster of international trainers is comprised of elite professionals whose industry experience is enhanced by their practical classroom expertise. To learn more please visit www.iil.com or email [email protected].

Note

* PMI®, PMP®, PMBOK® and the PMI® Registered Education Provider logo are registered trademarks of the Project Management Institute, Inc. registered in the United States and other nations. PRINCE2®, ITIL®, M_o_R®, MSP® and P3O® are Registered Trade Marks of the Office of Government Commerce in the United Kingdom and other countries. The Swirl logo™ is a Trade Mark of the Office of Government Commerce. Microsoft® is a registered trademark of Microsoft Corporation in the United States and/or other countries. CBAP® and IIBA® are registered trademarks of International Institute of Business Analysis.©2000-2011 International Institute for Learning, Inc. All Rights Reserved.

Part I

The Problem Solver

The business analyst solves business problems. The business analyst adds value to the organization. The business analyst does this not by defining a set of requirements so that a solution development team, at the behest of a technical project manager, can use them; nor does he run interference between the business wonks on one side and the technology geeks on the other. Being a business analyst means one is in the center of change in the organization, and that is a dangerous place to be without a map, or at least a good plan of action, or perhaps a better escape route.

The problems that face today's organizations and the fast pace of business change can seem overwhelming to one who is charged with solving those problems and keeping up with the pace. Being in the center can give the business analyst the uneasy feeling that BA stands for Blame Attractor.

The whole process of solving problems and implementing solutions, especially technological solutions, can be made easier by adopting a systematic approach, one that can be used each and every time and one that has gained credibility through successful use in the past. Thus we have the systems approach to solving business problems. And at the center of this approach is the business analyst.

Chapter 1

What Is a Business Analyst?

The job market is undergoing a shift in requirements from general computing knowledge and programming skills to those of interdisciplinary domain knowledge and integrated application development and problem-solving skills.

—Jiming Liu

What is a business analyst? Why is such a position necessary to organizations? Is the business analyst simply a middleman between the technologists and the businesspeople, acting as a go-between, translator, and conduit? Or is there some larger, more important role being played in the center of the organization? This chapter explores what makes a business analyst and what a business analyst does for the organization. It also takes a look at the potential of the position and the direction in which the business analyst role is evolving.

The Business Analyst in Context

There is a new position in the corporate hierarchy. A purebred technologist or an entirely business-oriented worker cannot fill this position. It is not management level and does not possess authority; however, it is a key contributor to most of the successful IT-related changes in an organization. Those occupying this position are fully versed in how to increase productivity, lower costs, and comply with regulations from both the business and technology perspectives. They can look at any problem from the perspective of the entire organization to determine the impacts, positive and negative, of any proposed change. They are adept at fashioning solutions to business problems, generally using computer technology. This position is the business analyst.

Since the first time a computer was used to support a business process, there has been a need for someone to talk to businesspeople. Until there is a time when businesspeople can solve their problems directly with the computer without needing a technologist to design the programs and change the code, there will be a need for someone to help businesspeople define the problem and describe the solution to the technical people who solve it.

“I've been a business analyst for twelve years. My new boss doesn't have a clue about business analysts. He thinks ‘business analyst’ is just a new term for requirements collector. Can you tell him the value of business analysts? He won't believe me.”