BA vs. PM Assignment
FFIRS
09/15/2011
19:16:49
Page 2
FFIRS
09/15/2011
19:16:49
Page 1
Business Analysis
FFIRS
09/15/2011
19:16:49
Page 2
FFIRS
09/15/2011
19:16:49
Page 3
Business Analysis
Best Practices for Success
STEVEN P. BLAIS
John Wiley & Sons, Inc.
FFIRS
09/15/2011
19:16:49
Page 4
Copyright # 2012 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, (978) 750-8400,
fax (978) 646-8600, 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, (201) 748-6011, fax (201) 748-6008, 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 (800) 762-2974,
outside the United States at (317) 572-3993 or fax (317) 572-4002.
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 0 013—dc23
2011029140
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
FFIRS
09/15/2011
19:16:49
Page 5
To Sonia: You are on every page and in every word.
FFIRS
09/15/2011
19:16:49
Page 6
FTOC
09/12/2011
15:32:33
Page 7
Contents
Preface
xv
Acknowledgments
International Institute for Learning, Inc. (IIL)
xxv
xxvii
PART I
THE PROBLEM SOLVER
1
CHAPTER 1
What Is a Business Analyst?
3
CHAPTER 2
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
3
4
5
6
8
9
11
11
The Evolution of the Business Analyst
13
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
13
15
17
18
20
21
24
25
26
27
vii
FTOC
09/12/2011
15:32:34
Page 8
viii
CHAPTER 3
Contents
A Sense of Where You Are
29
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
30
31
33
35
36
37
What Makes a Good Business Analyst?
39
The Skillful Business Analyst
Is a Business Analyst Born or Made?
So What Does It Take to Be a Business Analyst?
40
41
42
Roles of the Business Analyst
45
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
49
59
63
65
68
69
70
72
73
74
79
79
80
82
83
84
PART II
THE PLAYERS
85
CHAPTER 6
The Business Analyst and the Solution Team
89
CHAPTER 4
CHAPTER 5
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
89
94
98
100
107
108
FTOC
09/12/2011
15:32:34
Page 9
ix
Contents
CHAPTER 7
The Business Analyst and the Business Community
109
Constituents and Constituencies
Business Analysts and Upper-Level Management
Product Stakeholders
Subject Matter Experts
Process Workers
Managing Expectations
Notes
110
110
113
119
122
126
130
PART III
THE PROBLEM
131
CHAPTER 8
Define the Problem
135
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
135
138
139
140
141
145
154
155
157
159
161
162
Define the Product Scope
163
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
163
164
165
165
167
168
169
171
172
173
174
175
177
CHAPTER 9
FTOC
09/12/2011
15:32:34
Page 10
x
CHAPTER 10
Contents
Confirm Alignment and Financial Justification
179
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
179
180
181
182
184
184
185
187
188
190
194
194
195
196
PART IV
THE PROCESS
197
CHAPTER 11
Gather the Information
199
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
200
201
203
204
205
206
217
225
227
228
239
245
247
249
Define the Problem Domain
251
Problem Domain Analysis
Defining the Domain
Changes in the Problem Domain
Neighboring Constituencies
253
256
261
263
CHAPTER 12
FTOC
09/12/2011
15:32:34
Page 11
xi
Contents
Ancillary Benefits
Change in the Problem
The Essence
Note
264
264
265
265
Determine the Solution
267
The Accordion Effect
Tools and Techniques
Determining the One Best Solution
Constraining the Solution
Stop Analyzing, Already
Confirmation
Checkpoint Beta
Notes
267
268
278
279
280
280
283
284
Write the Solution Document
285
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
285
289
300
300
302
305
306
307
308
PART V
PRODUCING THE PRODUCT
309
CHAPTER 15
Monitor the Product
313
Entering the Solution Domain
Development Processes
Implementing the Solution
Keep the Light on
Things Change
Checkpoint Charley
The Watchdog
The Essence
Notes
314
314
317
319
319
320
321
323
323
CHAPTER 13
CHAPTER 14
FTOC
09/12/2011
15:32:34
Page 12
xii
CHAPTER 16
CHAPTER 17
Contents
Confirm the Business Problem
Has Been Solved
325
Correct Behavior
Acceptable Level of Confidence
Circumstances of Interest
The Testing Game
User Acceptance Testing?
Handling Defects
Testing Does Not Stop at Delivery
Note
326
326
327
328
333
335
335
336
Transition and Change Management
337
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
339
341
342
344
345
345
347
349
POSTSCRIPT Where to Go from Here
351
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
351
352
353
354
356
359
APPENDIX A
Business Analyst Process
361
APPENDIX B
The Principles
365
APPENDIX C
Why We Do Not Get Good Requirements
373
APPENDIX D
Comparison of the Roles of Business Analyst,
Systems Analyst, and Project Manager
379
FTOC
09/12/2011
15:32:34
Page 13
xiii
Contents
APPENDIX E
APPENDIX F
Context-Free Problem Definition
Questions
383
List of Nonfunctional Requirements Categories
385
Bibliography
387
About the Author
395
Index
397
FTOC
09/12/2011
15:32:34
Page 14
FPREF
09/12/2011
12:48:17
Page 15
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.
xv
FPREF
09/12/2011
xvi
12:48:17
Page 16
Preface
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 decisionmaking 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).
FPREF
09/12/2011
12:48:17
Page 17
Preface
&
&
&
&
xvii
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
FPREF
09/12/2011
12:48:17
Page 18
xviii
Preface
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.
FPREF
09/12/2011
12:48:18
Page 19
xix
Preface
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.
FPREF
09/12/2011
12:48:20
Page 20
xx
Preface
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, Complaints
Answers found in
What is my relationship with the project
manager?
What are the roles and responsibilities of a
business analyst?
What is the connection between requirements
and testing?
How do I know what questions to ask the
users?
How can I do it right the first time and avoid
rework?
How can I write better requirements?
How do we get management and users to
cooperate when they refuse to focus on
requirements?
Is it possible to create a common language for
IT and business?
Is there a methodology or process for business
analysts?
Chapter 6
Chapter 5
Chapter 16
Chapter 11—The InformationGathering Session
Part Four: The Process
Chapters 11, 13, and 14
Chapter 9
Chapters 6 and 7
This whole book
(continued )
FPREF
09/12/2011
12:48:20
Page 21
xxi
Preface
How can I improve the communication
between stakeholders and business and
developers?
Since I’m doing all three roles, what is the
difference between the project manager, the
systems analyst, and the business analyst?
Are there any tools for business modeling, and if
so which ones should business analysts use?
How 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?
Is there an efficient, effective way to define the
requirements?
I have to do everything from defining the
requirements to coding and testing; how can
I effectively be a one-man band?
How can we make sure there are no surprises at
the end when we are delivering the solution?
How do we deal with customers who give us
the solution and not the problem?
What 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?
I deal with both internal and external teams,
including offshore developers. How can I
make sure all the communications are
consistent and effective?
What’s the best way to create the business
case? Is it the job of a business analyst?
Where does the business analyst fit into our
software development life cycle?
We’re using agile development (Extreme
Programming). What is my role as a business
analyst in this situation?
Is it necessary to provide cost justification, such
as an ROI for projects, and if so, how do you
do it?
How do I separate the noise from the true
requirements?
This whole book
Chapter 6, Appendix B
Chapter 13
Chapter 7
Chapters 13 and 14
Chapter 6
Chapters 11, 15, and 17
Chapter 11—Interview Issues
Chapter 11—Interview Issues
Chapter 5 (Intermediary),
6 (Solution Team), and 15
Chapter 10
Chapter 15
Chapter 15
Chapter 10
Part Four: The Process
(continued )
FPREF
09/12/2011
12:48:21
Page 22
xxii
How can I get good requirements when
management dictates schedules that don’t
allow enough time?
What are some techniques that can be used to
work with groups who won’t cooperate?
What do I do about new requirements that are
defined after the project starts?
How do I handle the project manager and
project team?
How do I negotiate with the business to
change their expectations?
How do we handle changes after getting signoff on a hundred-page document?
The 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?
I have been a systems analyst for over five
years; how do I transition to my new job as
business analyst?
Communication with the developers is not
very satisfactory. They have no respect for
what we do.
Over-commitment—management is trying to
do too many things without evaluation or
prioritization.
How do I explain to my kids what a business
analyst does?
I transitioned from system analyst to business
analyst. Will be technical background help
me or hurt me?
How 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?
Preface
Chapter 11
Chapters 7 and 12
Chapters 11 and 15
Chapter 6
Chapter 7
Chapter 15
Chapters 15 and 16
Chapters 3 and 6
Chapter 6
Chapter 7
Part One: The Problem Solver
Chapter 3
Chapter 13
(continued )
FPREF
09/12/2011
12:48:21
Page 23
xxiii
Preface
How do I get the business to give us
information?
Is there a holistic view of requirements and
testing?
There 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.
There is no single point of responsibility for
documenting and maintaining all the
communications between business and
technical teams about the project and
requirements.
How can we convince the users that we do
more than prepare and maintain documents?
There 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.
Are there any overall guidelines that will assist
business analysts in doing their job
successfully?
What can I do to increase collaboration among
all the parties in the solution development
effort?
Why is there always such a gap between the
user requirements and the delivered
product?
How can we make successful changes to the
processes without encountering so much
resistance from the users?
I feel like we are an afterthought. Is there
really a business analyst profession?
What is the difference between the ‘‘what’’
requirements and the ‘‘how’’ requirements?
Who defines acceptance test cases? Who
executes acceptance test cases?
How do we convince the customer to do
something different, such as another
approach?
Chapter 11
Part Four: The Process
Chapter 15—Checkpoint
Charley
Chapter 5—Intermediary
Chapter 1 and Postscript
Chapter 7
This whole book
Chapter 5—Diplomat
Chapters 8, 9, and 15
Chapters 12 and 17
Chapters 2, 4, and Postscript
Chapter 14—Anatomy of
Requirements
Chapter 16
Chapters 7, 11, and 12
FPREF
09/12/2011
12:48:21
Page 24
FLAST01
09/16/2011
11:25:11
Page 25
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, E. LaVerne Johnson, Founder, President & CEO of International
Institute for Learning, Inc., John Winter of Internal Institute for 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 International Institute for 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.
xxv
FLAST01
09/16/2011
xxvi
11:25:11
Page 26
Acknowledgments
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.
FLAST02
09/15/2011
19:21:57
Page 27
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; Microsoft1 Project and Project
Server; Business Analysis; Lean Six Sigma; PRINCE21; ITIL1; Leadership
and Interpersonal Skills.
Using our proprietary Many Methods of LearningTM, 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 Learning@iil.com.
PMI1, PMP1, PMBOK1 and the PMI1 Registered Education Provider logo are registered trademarks of the Project Management Institute, Inc. registered in the United
States and other nations. PRINCE21, ITIL1, M_o_R1, MSP1 and P3O1 are Registered Trade Marks of the Office of Government Commerce in the United Kingdom
and other countries. The Swirl logoTM is a Trade Mark of the Office of Government
Commerce. Microsoft1 is a registered trademark of Microsoft Corporation in the
United States and/or other countries. CBAP1 and IIBA1 are registered trademarks of
International Institute of Business Analysis.
#2000-2011 International Institute for Learning, Inc. All Rights Reserved.
xxvii
FLAST02
09/15/2011
19:21:57
Page 28
PART01
08/17/2011
15:47:0
Page 1
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.
1
PART01
08/17/2011
15:47:0
Page 2
C01
09/15/2011
12:30:1
Page 3
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.
3
C01
09/15/2011
12:30:1
Page 4
4
The Problem Solver
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.’’
The business analyst position is relatively new in the organization. Many
organizations do not have a defined business analyst position as yet. The
reality is, though, that the business analyst is not a new role to the organization, but rather a role that has been played since the first business owner
challenged his staff to come up with a more efficient way to produce
wheels. While there may not have been an official position in most companies called business analyst, for years the role has been performed by other
positions in the organization, such as project manager, systems analyst, and
business manager.
What Is It All About?
‘‘Can you tell me in a nutshell, like an elevator pitch, what it is that a business
analyst does so I can tell my mother-in-law?’’
In Version 1.6 of its Business Analysis Body of Knowledge (BABOK), the
International Institute of Business Analysis (IIBA) has the following definition of the role:
A business analyst works as a liaison among stakeholders in order
to elicit, analyze, communicate and validate requirements for
changes to business processes, policies, and information systems.
The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions
that enable the organization to achieve its goals.1
In 2009, the IIBA updated its definition to ‘‘A business analyst is any person who performs business analysis activities, no matter what their job title
or organizational role may be.’’ Business analysis activities involve ‘‘understanding how organizations function to accomplish their purposes, and
C01
09/15/2011
12:30:1
Page 5
What Is a Business Analyst?
5
defining the capabilities an organization requires to provide products and
services to external stakeholders. It includes the definition of organizational
goals, how those goals connect to specific objectives, determining the
courses of action that an organization has to undertake to achieve those
goals and objectives, and defining how the various organizational units and
stakeholders within and outside of that organization interact.’’2
The British Computer Society proposes the following definition of a
business analyst:
An internal consultancy role that has the responsibility for investigating business systems, identifying options for improving business
systems, and bridging the needs of the business with the use of IT.3
These authorities have different slants on the business analyst job: analyst, liaison, communicator, internal consultant, improver of business systems, and business problem solver. Putting it all together, the business
analyst is an agent for change in the business, summoning the forces of technology to make changes in the organization, solving problems, and improving processes, thereby increasing the value of the organization.
The Role of the Business Analyst
‘‘I’m a project manager and it sounds like I have been doing the business analyst’s
job for quite a while. Is that possible? Should I get two salaries?’’
Over the years the work of business analysts evolved first into a role and
more recently into a position in the organization. Where there is not a business analyst position, the role has been played by other positions, such as
the IT project manager or a business line manager, on a part-time or temporary basis. In some organizations, it is divided among several positions, such
as requirements engineer, quality assurance analyst, quality control specialist, product owner, project manager, business champion, software configuration manager, and so forth. Organizations are now realizing that the
majority of IT project failures occur because no one person took on the role
of business analyst, but still there is no true agreement on what that role
should be. This section explores many of the options.
The following is a quote from an East Coast utility company’s internal
document entitled Business Analyst Handbook. Note the emphasis on the
business analyst’s roles:
At [company name], the business analyst serves many functions, from
operational business support of a business area to deep involvement
C01
09/15/2011
12:30:1
Page 6
6
The Problem Solver
in software development projects. The business analyst’s role
changes based on the customer area he or she is supporting. This
situation exists because the expectations for a business analyst are
customer driven. A business analyst can be focused on a business
area supporting many applications and processes or a single large
application (such as an enterprise application) or they may possess
extensive knowledge in a particular business area process and support technology associated with that process. Whatever the role, the
business analyst must possess a wide variety of skills and knowledge
ranging from strong relationships, excellent communication skills,
problem solving, facilitation, quality assurance techniques, presentation skills, and analytical/critical thinking. Sprinkled in with all these
skills, it is important for the business analyst to have a surface understanding of the technological infrastructure (network, applications,
software and hardware) that supports his or her business area.4
The Business Analyst in the Center
No matter how you look at it, the business analyst’s role is in the center. As
shown in Figure 1.1, there are three communities that the business analyst
must deal with throughout any project and thereafter.
Business
Community
Development
Community
Management
ULM
EDM
Business
Manager
Problem
Owner
IT
Manager
Project
Manager
BA
Defines
Process
Workers
Solve
Products
(solutions)
Problems
Produce
Solution
Team
Projects
ULM = upper-level management
EDM = executive decision makers
FIGURE 1.1 The Business Analyst in the Center
C01
09/15/2011
12:30:1
Page 7
What Is a Business Analyst?
7
The business community represents the slice of the business that is involved with the problem to be solved. It might be a large slice, such as
accounting, or it might be a small slice, such as the collections department.
Generally this business slice represents the problem domain.
The business manager is the highest-ranking person in the organizational hierarchy directly associated with the business area. For example,
when a problem exists in the collections department, the business manager
might be the manager of the collections department. When a problem exists
in accounting, replacing the accounting system for example, the business
manager might be the CFO.
The problem owner is the primary point of contact for the problem. The
problem owner is the person who has authority to seek a solution to a perceived problem in the business area. The process worker is anyone who
actually works with the system or business process in question as a part of
his or her daily job. The term user refers to a subset of process workers,
namely those who actually use a computer system and put data into a system, extract information from the system, and manipulate the information
within the system. I suggest instead the term process worker to expand the
business analyst’s view to include those in the business community who are
involved with the overall business process being improved, but who are not
necessarily users of a computer system. This helps to keep our focus on the
business rather than the technology.
The business community has problems. There are changes in government regulations to deal with, new products introduced by the competition
to keep up with, new markets to break into; there is expansion of sales and
support, mergers, acquisitions, divestitures, and personnel turnover. There
are old legacy systems that cannot cope with the new marketplace and product lines; and there are the inevitable defects that crop up and small changes
to be made to the computer system. When the business community can
solve these problems, it does. Because of the impact of computer technology on every aspect of the business for most organizations, the business
community generally needs the help of development community personnel
to solve the business problem. In fact there are many times that the development community looks on the business community as nothing but one big
problem. This is good. If the business did not have problems, the development community would not have work.
The development community in Figure 1.1 represents all of IT. So the IT
management circle is the highest-ranking person on the IT side, such as the
CIO or vice president of management information systems (MIS).
The job of the development community is to execute a successful project. A successful project is defined as being within budget, meeting the
scheduled deadline, and delivering everything that was promised for that
budget and schedule. Except for ongoing operations, everything on the
C01
09/15/2011
12:30:1
Page 8
8
The Problem Solver
development side is a project. From a project perspective, the team is not
concerned with whether the result of the project actually solves the problem, only that the project is a success. The project manager and solution
team rightfully assume that the business has done due diligence and determined that the product to be developed is necessary and will provide a benefit to the organization. The solution team’s job is to make it happen within
the budget and timeframe.
So here is the situation: The business community has a problem and the
technical community creates a product purportedly solving that problem,
and there is no correlation that the problem is solved until the project is
done, if then.
Perhaps the coordinating function is upper-level management. The
management box across the top of Figure 1.1 represents upper-level management and executive decision makers up to and including the CEO and
board of directors.
Upper-level management charts and monitors the strategic direction of
the organization. Since projects are tactical, upper-level management is not
typically concerned with the details of projects. When upper-level management does get too involved in the project details, we have a word for it:
micromanagement. Process workers also have a word for the upper-level
managers who do this sort of thing, but that word is better left unsaid.
So we still have a situation. The business community has a problem, one
of a tactical nature, and the development community has a project, also of a
tactical nature. This project is designed to produce a product. That product
should be the solution to the business problem. However, there is no formal
correlation between project and problem. The solution team assumes that the
business has determined why the project is needed and what value the results
of the project will provide to the business. The business assumes the solution
team is going to come up with a solution to their problem and that it should
be obvious why the project needs to be done and what the results have to be.
So who will verify that the result of the project—the product—completely
solves the business problem? The role that ensures the results of the project
solve the business problem is the business analyst. That is why the ideal position in the organization for the business analyst is in the center, unaligned
with either community. The business analyst independently evaluates the
business problem and specifies the solution for the solution team and then
makes sure that the solution solves the problem it was intended to solve.
Business Analyst Focus
The business analyst focuses primarily on the business. In some cases, this
means that the business analyst is not involved with IT at all. For example,
the business analyst may be involved in rearranging job descriptions and
C01
09/15/2011
12:30:1
Page 9
9
What Is a Business Analyst?
reorganizing manual tasks as part of a process improvement effort, assisting
upper-level management in determining business strategy, or gathering the
information and performing benchmarks for requests for proposals (RFP).
Regardless, the focus is always on the product, the solution to the business
problem. The ultimate goal of the business analyst is to solve that business
problem, nothing less. When technology is involved the business analyst is a
member of the solution team, but is still focused on the solution. In many
situations, the business analyst is the only one so focused.
‘‘I’m not really sure of my job duties as a new business analyst. What is a
business analyst supposed to be doing? What do other business analysts in the
industry do?’’
The truth is that the industry has not really come up with a standard
definition of what a business analyst does, even with the definitions in the
IIBA’s Business Analyst Body of Knowledge and other sources. This is because business analysts have come from both the technical and business
sides of organizations and the role is still evolving (see Chapter 5 for a view
of the various roles of the business analyst), so there has not been coalescence on a single definition. Here is an analogy that I think captures the
essence of the business analyst: the business internist.
The Ideal Business Analyst
‘‘Can you tell me what to expect when I start my job as business analyst next
week? What do management and everyone else expect from me?’’
Table 1.1 provides a generic job description for the ideal business analyst broken down into task-related categories.
TABLE 1.1 The Ideal Business Analyst
Problem Analysis and Solution Definition
General Communication
Determines the actual problem to be solved
in the organization.
Understands the business issues and
challenges of the organization and
industry.
Identifies the organization’s strengths and
weaknesses and suggests areas of
improvement.
Both facilitates and moderates
meetings.
Delivers informative, well-organized
presentations.
Understands how to communicate
difficult/sensitive information
tactfully.
(continued)
C01
09/15/2011
12:30:1
Page 10
10
The Problem Solver
TABLE 1.1 (Continued )
Problem Analysis and Solution Definition
General Communication
Reviews and edits requirements,
specifications, business processes, and
recommendations related to proposed
solution.
Documents the solution to the business
problem in a form approvable by the
business, acceptable to the solution team,
and understandable to management.
Pushes creative problem solving beyond
the boundaries of existing organizational
practices and mind-sets.
Identifies areas for improvement in internal
processes and suggests potential solutions.
Possesses enough understanding in
technical disciplines to be able to
converse intelligently with solution
team.
Mediates conflicts between business
and the solution team and different
business units being impacted by
the solution
Generates enthusiasm for the product
among product stakeholders and
solution team members
Facilitates decision making among
organization executives
Product Delivery
Receives input from managers and
appropriately and accurately provides
comments/feedback.
Communicates non-technical product and
business standards and constraints.
Product Quality Assurance
Evaluates requested changes from the
business and communicates needed
changes to development team.
Ensures product issues are identified,
tracked, reported on, and resolved
in a timely manner with both the
solution team and the business.
Leads and/or participates in
acceptance testing efforts.
Facilitates the business-community
transition from current problem state to
solution state.
Product Stakeholder Relationship
Corresponds effectively with the business to identify needs and evaluate alternative
business solutions.
Identifies and manages product stakeholder expectations effectively.
Ensures that the organization will be ready to accept and affect the change.
Conducts effective product evaluations to ensure the problem is being solved in the
business environment.
This is quite a responsibility for a business analyst to undertake. It is
all part of a holistic view of the organization, the business problems, and the
IT solutions.
Creating positive change for the organization is the essence of the
business analyst. Problem solver, communicator, facilitator, analyst—the
business analyst works in the center of the organization improving
C01
09/15/2011
12:30:1
Page 11
What Is a Business Analyst?
11
processes, clarifying communications, investigating problems, producing
solutions, and adding value to the organization.
Last-Liners
Reviewing the list of jobs a business analyst does from Table 1.1 there seems
to be very little in the organization that the business analyst does not do.
I did not include in that list random tasks mentioned, such as prepare for
executive meetings and make coffee. The business analyst position seems to
be the epitome of what we call last-liners, referring to the last line on most
job descriptions, which says something like ‘‘and any other activity or task
required by management.’’ Last-liners are those whose entire workday is
filled with tasks and activities not listed on their job description but are covered by that last line.
So is the business analyst really the new kid on the block? Has there
been a sea change in business and IT that has resulted in the creation of this
position? No. Actually, the role of business analyst has been around for centuries, perhaps as long as there has been business or at least accounting for
business. Business analysts are not quite the oldest profession, but the position actually predates the modern computer, giving further support to the
contention that business analysts solve business problems rather than write
software requirements. Don’t believe it? The next chapter describes a bit of
the evolution of the business analyst and identifies some of the famous and
infamous business analysts throughout history.
Notes
1. International Institute of Business Analysis, A Guide to the Business Analysis
Body of Knowledge, version 1.6 (2006), page 9.
2. International Institute of Business Analysis, A Guide to the Business Analysis
Body of Knowledge, version 2.0 (March 31, 2009), page 4.
3. Debra Paul and Donald Yeates, Business Analysis (British Informatics Society
Ltd, April 2006), 4.
4. Excerpted from internal corporate business analyst handbook for an East Coast
utility company, published 2006.
C01
09/15/2011
12:30:1
Page 12
C02
09/15/2011
12:33:31
Page 13
CHAPTER
2
The Evolution of the
Business Analyst
It is our responsibilities, not ourselves, that we should take seriously.
—Peter Ustinov
Every profession has its history and heroes. The medical profession’s progression from Hippocrates to Gregory House is well documented. The legal
profession can point to Clarence Darrow and Daniel Webster, among many
others. These luminaries stand as models and beacons of their profession.
Defining the origin of the business analyst and tracing the profession’s history is much more difficult. The need for a business analyst would exist
without computers or information systems, although the present-day business analyst role has roots in the evolution of business computer technology. The role is a melting pot of professions and disciplines, technology and
intuition, solitary analysis and personal interaction, engineering and business practice. Let’s look at the history of the business analyst and some of
the influences on the profession.
The Business Analyst Hall of Fame
There have been people playing the role of business analyst for centuries
now. Perhaps our first recorded business analyst might be Adam Smith, who
documented the business process of manufacturing a straight pin to make a
point about separation of skills. Smith’s assertion that the economy and all
business is ruled by the invisible hand of self-interest has great influence on
13
C02
09/15/2011
14
12:33:31
Page 14
The Problem Solver
the business analyst’s work, as stated in this oft-quoted passage from Wealth
of Nations:
It is not from the benevolence of the butcher, the brewer, or the
baker that we expect our dinner, but from their regard to their own
interest. We address ourselves, not to their humanity but to their
self-love, and never talk to them of our own necessities but of their
advantages.1
This may be the original WIIFM (What’s in It for Me?) statement. As we
will see, the business analyst who understands this philosophy in business
will have a much easier time obtaining his or her own goals.
Another who might be placed in the Business Analyst Hall of Fame
would be Herman Hollerith, who solved a compelling business problem in
the late 1800s. The U.S. Census Bureau is legally mandated to count the people in the country every 10 years. The 1880 census took seven years to complete and by 1890, the country had grown so much more it would have
taken more than 10 years to conduct the census. Hollerith borrowed an idea
from the textile industry and created a mechanical counting device based on
cards with holes punched in them. While the machine was a computing
device (thus qualifying Herman for the Computer Hall of Fame as well),
Hollerith was truly a business analyst solving a business problem using
computer technology. Hollerith, incidentally, founded a company called the
Computing Tabulating Recording (CTR) Corporation. You have probably
not heard of the company, except that later on, when the president of CTR
was Thomas Watson, the company was renamed International Business
Machines (IBM) Corporation.
Also in our Hall of Fame is Frederick Winslow Taylor, who solved business productivity problems with innovative workforce management
approaches. Taylor was the first to apply systematic observation and study to
the workplace. He also believed that by analyzing work activities and flow,
the one best way to perform the work could be determined. Business analysts
today use systematic observation and analysis to determine the one best way
to solve the business problem they are assigned to solve. They routinely find
the best practice wherever it exists, decompose tasks into essential parts, and
remove things (e.g., operations, activities, etc.) that do not add value.
A special niche is reserved for Sherlock Holmes, Arthur Conan Doyle’s
fictional detective. He established, fictionally of course, the basics of scientific investigation and examining all the available data before coming to a
conclusion about a solution. We discuss the advice that Mr. Holmes makes
to the business analyst throughout the book. We might also find nearby a
plaque with the face of Mark Twain, who provided significant guidance in
gathering data and assembling facts from a reporting perspective. For
C02
09/15/2011
12:33:31
Page 15
The Evolution of the Business Analyst
15
example, he is reputed to have said, ‘‘Gather the facts first. You can distort
them later.’’ This is sage advice for the practicing business analyst. We see
more of his counsel later when we discuss elicitation and investigation.
Quality gurus such as Armand Feigenbaum (Total Quality Management
or TQM), Phil Crosby (Quality Is Free), and William Edwards Deming (Theory of 14 points, among others) might also be added to the list of people
who have significantly influenced the business analyst profession. Feigenbaum’s book Total Quality Control established a holistic approach to instilling quality in the workplace. The business analyst uses a similar holistic
approach to solving business problems.
We would have to include Alex Osborn, an advertising manager from
Buffalo, New York, who was one of the founders of BBDO (Batton, Barton,
Durstine, and Osborn), one of the largest and best-known advertising companies in the world. An advertising manager in the Business Analyst Hall of
Fame? Yes. Alex Osborn developed the brainstorming method and other
techniques used often by business analysts, as well as other creative thinking
and problem solving methods.
Influencers of more recent vintage are Michael Hammer and James
Champy, who coined the term business process re-engineering (BPR) in the
seminal volume, Re-Engineering the Organization; Bill Smith of Motorola,
who brought Six Sigma to the attention of business and IT; and others whose
words of wisdom and guidance to the business analyst are liberally sprinkled throughout this book.
You might notice that the honorees in the Business Analyst Hall of Fame
are primarily non-IT people. Where are John Van Neumann, father of the
computer, and Vint Cerf, father of the Internet, and Tim Berners-Lee, father of
the World Wide Web? How about Bill Gates, Larry Ellison, and Steve Jobs?
Certainly, these illustrious gentlemen would grace any technological or IT
Hall of Fame—but not our Hall of Fame. These titans of the IT industry gave
us better means to solve problems, not the solutions themselves. Some might
even argue that their contributions have created more obstacles to solving
business problems because the technological advances tend to move our focus from the business to technology. Our hypothetical shrine is for luminaries
who have developed and practiced methods for solving business problems
with technology and improving the organization’s business processes.
Where It Began
Back in the 1960s when I started in the computer business as a programmer,
there were no business analyst positions. In fact, there were few systems
analysts or software architects, or any other intermediary role. We were all
programmers and we met with the businesspeople directly. Since user
C02
09/15/2011
16
12:33:32
Page 16
The Problem Solver
nowadays refers to someone who interacts directly with a computer system,
we cannot even say there were users at the time. There were employees
performing work that might be done better and faster on a computer. The
user interface was limited to what was punched onto Hollerith cards (called
5081 cards or simply punched cards) and the reports that were generated by
the computer. The people we talked to were cooperative, although somewhat skeptical, and certainly a bit fearful. Despite that, we communicated
fairly well. We paid no attention to the business processes these computer
systems supported; that was not our job.
Most of the programmers and computer technicians at that time came
from engineering and mathematics curricula in college or from the fledgling
Computer Science departments, and were not skilled in human interaction
and tact, much less business. Programmers and other computer technicians
lived behind the glass walls of computer rooms whispering incantations over
their machinery and posting large ‘‘Keep Out’’ signs on the doors. A sizable
contingent of the data processing populace believed that computer technology
was a science or engineering discipline and that producing reports for business
was a sideline, something to be tolerated. This, of course, led to severe misunderstandings between the business community and the programmers.
As a result, data processing departments created the programmer analyst role. Technicians given this role talked to the business and translated
the business requests into program specifications for the programmers. This
excused programmers from having to converse directly with the businesspeople who were, in turn, much relieved. Interestingly, those assigned the
role to talk directly to the business tended to be graduates of vocational
schools teaching computer programming rather than the computer scientists
matriculating from colleges. Colleges and universities at that time did not
teach business courses to computer scientists and engineers, and the graduates from the programming schools came from professions and businesses
already possessing insights into how business worked.
As technology became pervasive in business and government organizations, it became increasingly difficult to merge the demands of the organization and the technological advances of computers. Computer scientists added
more complexity to the technology with newer, faster computers and peripheral devices. Businesspeople then discovered the many things computers
could do to make their work easier, and started demanding computer departments to harness computer power for business processes. This, in turn,
caused the computer scientists to build bigger, better, and faster computers to
keep up with the business demand, which caused the business to create new
demands for the better and faster computer technology, and around it went.
Unfortunately, the advances in both arenas did not proceed in the same
direction. As a result, the programmer analysts became too technical for the
business and the business became too complicated for the programmer analyst.
C02
09/15/2011
12:33:32
Page 17
The Evolution of the Business Analyst
17
Then the data processing department, as it was called then, invented the
position of systems analyst to reconcile the divergent areas. The systems analyst was supposed to talk to the business and arrive at a technical solution
for an entire system consisting of hardware, data, and software (networks
were not an issue then), which was then turned over to the programmer
analyst to write program specifications, which were then turned over to the
programmer to code. However, systems analysts still did not concern themselves with business process. They focused solely on computer support of
those business processes.
On the business side, senior managers drew straws to see who would be
the one to have to explain their needs to the computer guys. The user interface at that time was a simple terminal on which questions were displayed.
The responses were entered in a scrolling, sequential fashion in gray characters on a green background. Secure in the notion that we knew best what
the users wanted, we designed the systems without consultation with those
users. We occasionally consulted with the managers of those users, but they
rarely understood exactly what their people did. Because we systems analysts ignored the impact of the systems we were designing on the business
processes in place, the newly minted users of the systems were forced to
change everything they were doing and use keyboards instead of paper
and pen and then wait for hours, if not days, to see the results printed on
1114-inch green bar (striped) paper.
Just for Fun
This was also when the first occurrence of the now legendary Stupid
User Error happened. The exchange went something like this:
Business manager: The system crashed when the user entered the
date wrong.
Programmer: Well, if the user entered the date right, it wouldn’t
have crashed. My code works. Tell your users to enter the date
right. (To himself) Stupid users!
Information Systems
Even though it was still a back-room function in the 1970s, data processing
was coming into its own as a viable department in the organization. With the
newfound power it was experiencing, data processing renamed itself
C02
09/15/2011
12:33:32
Page 18
18
The Problem Solver
information systems (IS) or the management information systems (MIS)
department, which elevated it to a larger influence in the business.
Those in IS/MIS making direct contact with the businesspeople were
still the same technically-oriented engineers who were not familiar with the
business and, for the most part, did not care to be. These technicians were
too busy dealing with rapidly evolving computer technology that went from
second to third generation computers and trimmed down from large, roomsized mainframe computers to mini-computers, then micro-computers, and
then personal computers. The software industry expanded and changed,
creating new programming languages, moving from second-generation languages to third generation to fourth generation, and then to visual development environments. Software development progressed from the controlled,
linear approaches typical of engineering with structured design, to objectoriented analysis and design, to iterative and incremental approaches, to agile software development methods. Coders became programmers and then
became developers. The computer technician became a technologist and
had to become more technology focused, just to stay viable in the industry.
And the business started selling internationally, dealing with regulations of
multiple nations and varying cultures. As we entered the last decade of the
twentieth century, businesses started merging and acquiring, growing bigger
and more complex, becoming global in their scope.
The Rise of the Business Analyst
Businesspeople found themselves increasingly unable to communicate with
the staff working in information technology (a term more reflective of the
prevailing attitude). Business management was forced to delegate members
of its staff to meet with the IT people and explain what the business needed,
and saw its employees relegated to the role of user. The thinking went like
this: ‘‘He uses the computer, therefore he is a user, therefore he knows what
he wants to use the computer for, therefore he can explain it clearly to those
technical people. Better him than me.’’ Usually the one designated was a
super-user (an IT term) who was not cowed by the computer or technology,
and was the user other users called when they had computer problems and
were too afraid or embarrassed to call in the nerds. (Nerd is a term invented
in 1950 by Dr. Seuss in the book If I Ran the Zoo. The term evolved over the
years to connote a person more interested in esoteric and technological activities than in social interactions. The word described the stereotypical computer programmer back in the early days of the industry.)
This super-user was, most likely, the first official business analyst but
probably did not have that title. We do not have a date or name or location
to commemorate the first time a businessperson was assigned the job of
C02
09/15/2011
12:33:32
Page 19
The Evolution of the Business Analyst
19
crossing the no-man’s land between business and IT to solve a problem.
We do not even know whether that representative was issued a white flag
to wave.
Just for Fun
How it might have happened . . .
Anne, an accounts receivable supervisor, went to the VP of Finance
saying that she was spending all her time with the computer guys discussing new systems and was not getting her accounts receivable work
done. The VP of Finance decides to create a new job for Anne, and
made her a full-time business analyst.
Or, on the IT side, David, the developer, complained to the Director of Software Development that he did not have time to code or
design because he was spending too much time in meetings trying to
find out what he was supposed to code and design. The Director gave
him the choice of continuing to meet with the business or go back to
coding and designing. When David chose the former, the Director
assigned him the title of business analyst and banished him from the
technologists’ lunchroom.
IT also recognized the communication problem. Perhaps IT departments saw the business sending representatives over the wall to talk with
them and decided that IT needed its own representatives. Perhaps the IT
department was tired of having all its systems analysts and programmers
talking directly to the users, which caused all sorts of havoc, and decided to
funnel the communications to the few technologists who could string
together a meaningful English sentence and possessed enough tact to keep
from insulting the other parties for at least the first half hour. In any case,
IT began assigning and appointing the role of point person to meet with the
business and discuss what really had to be done to solve the problems of the
business.
The actual term business analyst had been used in business in a different context for a long time. The title referred to someone who analyzes business processes or activities to discern better ways of operating and making a
profit, such as analyzing the competition’s product line to locate holes that
can be filled by the analyst company’s products. Another type of business
analyst also analyzes other businesses and reports his or her findings to
stockholders, investors, financial institutions, market researchers, and so on.
These business analysts are found on Wall Street and in companies like
C02
09/15/2011
12:33:32
Page 20
20
The Problem Solver
Gartner and Forrester. Typically, neither of these types of business analysts
have direct interaction with a software development team.
Throughout the history of business there has been a need to search for
the solution to business problems. Businesspeople, inventors, technicians,
managers, company founders, innovators, and workers have all sought to
solve new and recurring business problems, some achieving Hall of Fame
status with their efforts. Over the years a key role has emerged whose specific purpose is to solve those business problems: the business analyst.
The Business Analyst Position
Think as you work, for in the final analysis, your worth to your company comes not only in solving problems, but also in anticipating
them.
—Tom Lehrer
‘‘My position is business systems analyst. Is that the same thing as a business analyst?’’
There are a multitude of titles describing the business analyst. Each organization seems to have its own view of what a business analyst is and
does. I worked in some organizations where the definition of system analyst
is indistinguishable from that of business analyst. I also worked with business analysts who shared the same title but do completely different jobs. A
large U.S. government agency had about 30 business analysts all working in
the same large room in cubicles. The agency assigned about half of the business analysts to define the requirements and assigned the other half to do
testing of completed systems against those requirements. The testers never
defined the requirements and the requirements group never tested. They
were all called business analysts.
In a health insurance company in New York, the business analysts are
referred to as customer champions. A New England insurance company
assigns the business analyst role to an IT function called business relationship manager, whose job it is to keep the business informed and satisfied
with the work that IT is doing. In a large U.S. federal government agency,
the business analyst is drafted from the line managers and wears the business analyst hat for the duration of the project before returning to their regularly assigned duties. In one of the larger U.S. banks, the business analyst
position is split into technical business analyst (TBA), who focuses on specifying the software requirements, and business business analyst (BBA), who
creates the business requirements.
C02
09/15/2011
12:33:32
Page 21
The Evolution of the Business Analyst
21
In fact, without too much of a stretch, sales support people might well
fall within the overall category of business analyst. They bridge the gap between external customers who have problems and may be in need of the
products the organization is offering, and the solution represented by those
products.
The bottom line is that the role of the business analyst is the
customer-facing member of the solution team, or, looking at it from
the other direction, the representative of the business on the solution
team. In all cases, the business analyst, under whatever guise or title, determines the business problem, analyzes the situation, identifies the best solution, and ensures that the solution solves the problem in the business
environment.
The Modern Analyst Forum Web site for business analysts and systems
analysts lists the following variations for business analyst roles, each variation defined in detail by the Modern Analyst Forum:
&
&
&
&
&
&
&
Business analyst (general)
Business process engineer/analyst
Data analyst/modeler
Product manager/functional architect
Requirements engineer
Systems analyst
Usability/UX professional
The Web site goes on to list related roles:
&
&
&
&
&
Designer/architect
Developer
Quality Assurance analyst/tester
Project manager
Technical writer2
The Business Analyst Profession
The most likely way for the world to be destroyed, most experts agree,
is by accident. That’s where we come in; we’re computer professionals. We cause accidents.
—Nathaniel S. Borenstein
‘‘Are there any business analyst organizations where I can meet other business analysts?’’
C02
09/15/2011
12:33:32
22
Page 22
The Problem Solver
One indication of the maturity of a profession is the existence of professional organizations devoted to the advancement of those members of that
profession. Business analysts have a range of professional organizations that
relate to some of the roles business analysts play, predominant of which is
the International Institute of Business Analysis (IIBA) and the Project Management Institute (PMI). Business analysts become members of other professional societies and related organizations, such as the American Society
for Quality (ASQ), the Institute of Electrical and Electronics Engineers Computer Society (IEEE), the International Standards Organization (ISO), the
British Computer Society (BCS), the Institute of Analysts and Programmers
(IAP) in the United Kingdom, the Australian Business Analyst Association
(ABAA), and others.
The International Institute of Business Analysis (IIBA) describes itself:
The IIBA is an independent, non-profit, international professional
association that is dedicated to advancing the professionalism of its
members as well as the business analysis profession itself. IIBA recognizes the important contributions business analysts make to organizations every day . . . The IIBA is seeking to establish common
standards of knowledge within the BA profession and is committed
to work with practitioners around the globe to continually add
to those standards through education, research, and the sharing of
effective tools and techniques.3
The IIBA was formed in October 2003 with 28 founding members. In
April 2006, it became incorporated federally as a nonprofit association under
the Canada Corporations Act with headquarters in Toronto, Canada. The organization has grown to more than 18,000 members (as of 2011) and over
100 chapters worldwide.
The Australian Business Analysis Association (ABAA) describes itself:
The ABAA was formed in 2003 to define, promote and support
Business Analysis as a profession nationwide. ‘Business Analysis’ as
a term, provides a collective umbrella for professionals working in
the areas of ‘Commercial, Process, Technical and Systems Analysis.’
ABAA seeks to provide a professional framework supporting those
who work in this area.
The Australian Business Analysis Association is a nonprofit, vendor
independent, professional association with the objective to:
&
&
Define the profession of Business Analysis,
Promote the profession and increase public awareness of Business Analysis,
C02
09/15/2011
12:33:32
Page 23
The Evolution of the Business Analyst
&
&
&
&
23
Develop a Business Analysis competency framework,
Improve the practice of Business Analysis and the knowledge,
competence and standing of its practitioners,
Represent the profession nationally and internationally,
Provide a forum for the free exchange of information and ideas.4
‘‘Are there any business analyst best practices?’’
The Guide to the Business Analysis Body of Knowledge (BABOK), the
current version of which is 2.0 released on March 31, 2009, is:
The collection of knowledge within the profession of Business Analysis and reflects current generally accepted practices. As with other
professions, the body of knowledge is defined and enhanced by the
Business Analysis professionals who apply it in their daily work role.5
The BABOK is similar to what is perhaps the most important document
in the project management profession: The Guide to the Project Management Body of Knowledge (PMBOK) compiled by the Project Management
Institute (PMI). The PMBOK:
Offers a set of processes, generally recognized as good practice,
which delivers results across industries and organizations.6
The BABOK describes its mission this way:
The primary purpose of the BABOK Guide is to define the profession of business analysis. It serves as a baseline that practitioners
can agree upon in order to discuss the work they do and to ensure
that they have the skills they need to effectively perform the role,
and defines the skills and knowledge that people who work with
and employ business analysts should expect a skilled practitioner
to demonstrate. It is a framework that describes the business analysis tasks that must be performed in order to understand how a solution will deliver value to the sponsoring organization.7
The BABOK divides the activities of a business analyst into five knowledge areas. Knowledge areas ‘‘define what a practitioner of business analysis
needs to understand and the tasks a practitioner must be able to perform.’’8
The BABOK defines the knowledge areas this way:
1. Enterprise analysis. ‘‘Describes how business analysts identify a business need, refine and clarify the definition of that need, and define a
C02
09/15/2011
12:33:32
Page 24
24
2.
3.
4.
5.
The Problem Solver
solution scope that can feasibly be implemented by the business.’’ The
knowledge area includes problem definition, developing and justifying
the business case, and defining product scope.’’
Business analysis planning and monitoring. Concerned with determining ‘‘which activities are necessary in order to complete a business
analysis effort’’: It covers stakeholder identification, selection of business analysis techniques, defining a process for managing requirements,
and assessment of progress.
Elicitation. Addresses working with stakeholders to determine what
their needs are and ‘‘the environment in which they work,’’ and ensuring that we have correctly and completely understood them.
Requirements analysis. Progressively elaborating the solution definition to enable the solution team to ‘‘implement a solution that will meet
the needs of the sponsoring organization and stakeholders.’’ Within this
knowledge area, the business analyst analyzes the stakeholder information within the current state of the business to identify and recommend
improvements and solutions. The knowledge area also addresses validation and verification of the solution.
Requirements management and communication. Describes the
techniques for managing conflict, issues, and changes and ensuring that
stakeholders and the solution team are in agreement on the solution.
This knowledge area also is concerned with ‘‘how knowledge gained
by the business analyst is maintained for future use.’’
& Solution assessment and validation. Covers the role of business
analysis once the solution team proposes a solution: assessing proposed solutions, ‘‘identifying gaps and shortcomings in solutions,’’
and assessing ‘‘deployed solutions to see how well they met the
original need.’’9
The BABOK goes on to describe underlying competencies that describe
the ‘‘behaviors, knowledge, and other characteristics that support effective
performance of business analysis.’’10 These include analytical thinking and
problem solving, behavior characteristics, business knowledge, communication skills, interaction skills, and software applications.
The Question of Certification
‘‘Is it necessary to get certified as a professional business analyst?’’
Business analysts in the field seem to be split on the subject of certification. Many already have other certifications. Some, because they are accidental business analysts, do not consider business analysis as their lifelong
C02
09/15/2011
12:33:32
Page 25
The Evolution of the Business Analyst
25
profession and are not interested in getting certified. Others, new to the
field, are seeking a certification route to establish their credentials in the
business analyst world to enhance their careers.
Many business analysts have earned a number of other certifications,
mostly from their previous life before becoming a business analyst. A large
number of business analysts have the Project Management Professional
(PMP) certification from the PMI. This certification may reflect the collateral
duties business analysts perform and also that some project managers
choose to move in the direction of business analysis even after they have
achieved the PMP status.
The IIBA offers the CBAP (Certified Business Analyst Professional) specifically for the business analyst professional. There are also commercial
training companies that offer certifications for passing exams after taking
their courses, and colleges and universities, such as Boston University, University of California–Irvine, and Villanova have certification programs. There
are a number of degree programs for business analysts mostly located in the
United Kingdom. Current working business analysts tend to have computerrelated degrees, management degrees, or MBAs.
The British Computer Society (BCS) has a certification program called
the Information Systems Examination Board (ISEB) that includes a certification in business analysis. The ISEB and the BCS are well respected in the
United Kingdom and in Europe. The certification consists of three levels:
foundation, practitioner, and higher levels. To gain a diploma in business
analysis a candidate must pass two core examinations and two other examinations in selected topics. The ISEB allows candidates who have received a
CBAP from the IIBA exemption from the requirements engineering core
examination.
The ABAA offers the qualified business analyst practitioner (QBAP)
certification:
The qualified business analysis practitioner (QBAP) is a base-level
certification readily available to practicing BAs based on an initial
audit of their competencies and experience. This accreditation represents a base level of competency for a business analyst and confirms the bona fides of the skills, training and experience a business
analyst asserts at the time of registration.11
The Challenge of Business Analyst Certification
‘‘Is there really a way of assessing a business analyst’s competence and experience? How would they determine my skills in health care business analysis? It
has got to be different than someone in finance or manufacturing.’’
C02
09/15/2011
12:33:32
Page 26
26
The Problem Solver
Because of the breadth of knowledge and skills that a business analyst is
required to possess, many of which cannot be determined with a written
exam, the concept of certifying a business analyst as a competent professional may be beyond any organization’s capability. Consider that it is universally agreed that communication skills are central to the success of the
business analyst. How can you assess the professionalism of a business analyst’s communication abilities with a multiple-choice exam?
Most certification programs include a number of years experience along
with a requirement to pass the exam for requisite knowledge of the profession. None of the programs evaluate that experience to determine whether
the experience proves that the professional has been successful at any point.
A business analyst who has continually failed to grasp the responsibilities of
the role and as a result moves from job to job and failed project to failed
project can certainly amass enough time-in-grade to qualify for the certification. Studying for exam and memorizing a manual or taking a class might get
this business analyst past the knowledge hurdle. If the business analyst is
still unable to communicate successfully or analyze and produce successful
solutions to business problems, how is it possible to grant such a person a
certification that bestows the prestige of professionalism on them?
It is not a matter of rejecting certification as a means of separating levels
of quality in the ranks of business analysts. The real question is whether the
current means of certifying really addresses the qualities needed by a business analyst to be successful, much less labeled as professional.
The Value of Certification
‘‘Is the CBAP certification really worth getting?’’
That said, the IIBA certified business analyst professional (CBAP) certification is becoming the standard for assessing the basic knowledge of a business analyst. As of the middle of 2011 there are over 1,000 recipients of the
CBAP from over 20 countries.
The IIBA lists the following benefits of acquiring the CBAP certification:
&
&
&
&
&
Demonstrated knowledge of the skills necessary to be an effective business analyst.
A proven level of competence in the principles and practices of business analysis.
Participation in a recognized professional group.
Recognition of professional competence by professional peers and
management.
Advanced career potential due to recognition as a professional business
analysis practitioner.12
C02
09/15/2011
12:33:32
Page 27
The Evolution of the Business Analyst
27
The certification requires a level of experience and passing an exam
based on the current official version of the BABOK. The first exam was given
in Orlando, Florida, on November 10, 2006. The exam is now available in a
computerized version at various test centers so that applicants no longer
have to sit for the exam in specific locations at specific times.
The CBAP establishes a level playing field for all professional business
analysts, organizations hiring business analysts, and organizations considering the establishment of a business analyst function in their organization.
The certification provides proof of a basic level of knowledge and understanding of the precepts of business analysis that are essential to the successful execution of the business analyst role.
Knowing the history of the business analyst and seeing that the history
of the profession basically mirrors the history of business, what does that
mean to you? Well, for one thing it means that the noble profession is not an
afterthought of the onslaught of computer technology in business. The business analyst solves business problems, regardless of whether the problem or
solution involves information technology. Now that we know where we
come from, the next question might be where are we now? Most business
analysts appear to work for IT, but is that the right place to be for a profession whose mission is in the business realm? In the next chapter we explore
the alternatives.
Notes
1. Adam Smith, An Inquiry into the Nature and Cause of the Wealth of Nations.
2. Modern Analyst Media LLC. Available from www.modernanalyst.com.
3. International Institute of Business Analysis. Available from www.theiiba.org.
4. www.aaba.org.au.
5. International Institute of Business Analysis. Available from www.theiiba.org.
6. Project Management Institute. Available from www.pmi.org.
7. International Institute of Business Analysis, A Guide to the Business Analysis
Body of Knowledge, version 2.0 (March 31, 2009) 2
8. Ibid., 6.
9. Ibid., 9.
10. Ibid., 9.
11. www.abaa.org.au.
12. International Institute of Business Analysis. Available from www.theiiba.org.
C02
09/15/2011
12:33:32
Page 28
C03
09/12/2011
14:14:9
Page 29
CHAPTER
3
A Sense of Where You Are
Strive to make proposed solutions as self-executing as possible. As the
degree of discretion increases, so too does bureaucracy, delay, and
expense.
—Donald Rumsfeld, Secretary of Defense
From a vice president in the PMO of a large New York bank: ‘‘Most of our staff are
senior project managers with their PMPs. I was thinking of adding some of our
senior business analysts to the staff to fill in spaces that the project managers
don’t have. Does that make sense, or should I leave well enough alone?’’
So, where do you hail from? Today, business analysts are mostly draftees or volunteers; that is, they did not start out in professional life to be business analysts. They were not members of the Future Business Analysts of
America club in secondary school or majors in business analysis in college.
As more colleges and universities create business analysis curricula, the next
generation of business analysts may well be professionals who have chosen
business analysis as their life’s work. Today, however, business analysts generally started as systems analysts, product managers, project managers, architects, or any number of other professions and ended up as business
analysts by either showing a predilection for the role, at least as perceived
by management, or were the only ones available when the position was announced. So, are you a former technologist or did you work in some capacity for a business before becoming a business analyst? There is no evidence
that a business analyst’s previous life has any affect on whether a person is
successful in the role of business analyst.
29
C03
09/12/2011
14:14:9
Page 30
30
The Problem Solver
Business Analysts Coming from IT
CIO of a Midwest manufacturing firm: ‘‘We’re new to the business analyst position, just creating it now. I think we are going to assign the business analysts to
work for IT. I’m thinking that each business analyst will be assigned to a project
manager. Is that a good way to go?’’
The majority of business analysts today gravitated to their position from
the technical side of the organization. Most were drafted. Some simply had
their job title changed from requirements analyst to business analyst with no
change in duties. Others left the technical field for a more hands-on role
with the customer or stakeholder.
There are positive aspects for having a technically oriented business analyst. The business analyst with a technical background:
&
&
&
&
&
Has a better understanding of computers and technology and can filter
out the operational errors from real problems.
Can provide quick fixes to the business in emergency situations.
Generally knows what technology is available to solve problems.
Can be an extra technical resource on the solution team and can relate
to the rest of the team.
May bring a different perspective or objectivity about the business problem than a business analyst from the business side.
‘‘I transitioned from system analyst to business analyst. Will my technical
background help me or hurt me?’’
The primary drawback with business analysts coming from the IT side is
that they do not have independence. Although their job is to define an IT
solution to a business problem, they are constrained to define that solution
within the framework of the current IT structure and are not free to discuss
the business problem with real platform and solution independence. They
are usually in the role of IT emissary, counseling the business as to what IT
has available to solve the problem.
When the business analyst has an IT background they:
&
&
Will tend to view all business problems from the perspective of how
computer technology can be applied rather than how they can be
solved. Many business analysts think of themselves as IT emissaries to
the business. They are paid by IT so it is a logical assumption.
Carries with them the baggage of the ongoing historical distrust of the
business for IT and vice versa. The business will naturally view the business analyst as one of them rather than someone to independently
C03
09/12/2011
14:14:9
Page 31
31
A Sense of Where You Are
TABLE 3.1 Benefit and Concerns of a Business Analyst Coming from IT
Benefits
Concerns
Independent from the influences of
business management.
May understand the technical impacts
and induce the business impacts to a
given solution.
Has a good relationship with the
technicians on the solution team.
Is a better filter to discern real problems
from the noise due to lack of training
or technological unfamiliarity.
Conflict of interest trying to represent
business to the IT project.
Influenced to come up with an IT
solution rather than a business
solution.
Looks ahead at the solution instead of
studying the problem.
Does not have that feel for business. The
technician may not really care about
the business as much as about the
technology.
Keeps solution within the confines of
existing systems and knowledge.
Jumps to solutions.
Can be an additional resource on the
solution team.
Will be able to diagnose technical issues
faster.
&
assess the problem and produce a satisfactory solution. This makes elicitation that much harder.
Will exhibit a tendency to circumscribe solutions within the framework
of existing systems and facilities rather than explore unique business solutions that may increase the value of the organizational unit, IT, and the
organization as a whole.
This leads to another issue: lack of understanding of the real problem.
Since many IT people suffer from Gerald Weinberg’s NPS (No Problem Syndrome), it is natural for IT people to arrive at an early solution before the
problem is fully defined, implement the solution, and then spend years adjusting the resulting product until it finally solves the original unstated problem. A business analyst from IT is subject to that form of groupthink.
Table 3.1 summarizes the benefits and concerns of a business analyst
hailing from IT.
Business Analysts Coming from the Business Community
A director of business relations at a large Pennsylvania bank: ‘‘Our business analysts primarily come from the business side. I’d like to keep their affiliation with
the businesspeople with which they have relationships. I’m thinking of keeping
C03
09/12/2011
32
14:14:10
Page 32
The Problem Solver
the current business analysts with their business units and creating new business
analysts for all the other business units.’’
There is much to be said for business analysts with solid business experience working directly for the business area rather than for IT. The business
analyst is able to build strong relationships with process workers and others
in the business unit. This enables the business analyst to get a deep understanding of the problem domain. The business analyst is more likely to suggest non-IT solutions to business problems, and be more concerned with all
the nonautomated activities, such as forms redesign, job description
changes, training, and so on that accompany a typical business process. The
transition from the current process to the changed process is typically
smoother.
As with IT-side business analysts, there are also concerns with the
business-side business analysts. There are technical considerations for
practically all business processes in an organization today. The business
analyst from the business side may not be aware of the technical considerations that may impede their solution, and may not know of technological
advances that may bring about a better solution.
When the business analyst reports to a single business entity within the
organization, he or she will likely be unduly influenced by that business
entity, and especially the head of that entity. The business analyst will most
likely not perform due diligence in verifying alignment with overall organizational strategy. They may not verif...
Purchase answer to see full
attachment