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
To Sonia: You are on every page and in every word.
Acknowledgments International Institute for Learning, Inc. (IIL)
THE PROBLEM SOLVER
What Is a Business Analyst?
The Business Analyst in Context What Is It All About? The Role of the Business Analyst The Business Analyst in the Center Business Analyst Focus The Ideal Business Analyst Last-Liners Notes
3 4 5 6 8 9 11 11
The Evolution of the Business Analyst
The Business Analyst Hall of Fame Where It Began Information Systems The Rise of the Business Analyst The Business Analyst Position The Business Analyst Profession The Question of Certification The Challenge of Business Analyst Certification The Value of Certification Notes
13 15 17 18 20 21 24 25 26 27
viii CHAPTER 3
A Sense of Where You Are
Business Analysts Coming from IT Business Analysts Coming from the Business Community Living with the Business The Lone Ranger Working Both Sides of the Street Central Business Analyst Organization
30 31 33 35 36 37
What Makes a Good Business Analyst?
The Skillful Business Analyst Is a Business Analyst Born or Made? So What Does It Take to Be a Business Analyst?
40 41 42
Roles of the Business Analyst
Intermediary Filter Mediator Diplomat Politician Investigator Analyst Change Agent Quality Control Specialist Facilitator Process Improver Increase the Value of Organizational Business Processes Build It and They Will Come Reducing Complexity Playing Multiple Roles Notes
49 59 63 65 68 69 70 72 73 74 79 79 80 82 83 84
The Business Analyst and the Solution Team
Business Analyst and Project Manager Business Analyst and Systems Analyst Trying to Do All Jobs Business Analyst and the Rest of the Solution Team Bottom Line Notes
89 94 98 100 107 108
The Business Analyst and the Business Community
Constituents and Constituencies Business Analysts and Upper-Level Management Product Stakeholders Subject Matter Experts Process Workers Managing Expectations Notes
110 110 113 119 122 126 130
Define the Problem
First Things First Challenge 1: Finding the Problem Challenge 2: The Unstated Problem Challenge 3: The Misunderstood Problem Define the Real Problem The Problem Determination Game Documenting the Problem Product Vision Define the Vision Checkpoint Alpha Focus on the Problem and Vision Note
135 138 139 140 141 145 154 155 157 159 161 162
Define the Product Scope
Project and Product Scopes Product Scope Product Scope Formula Strategic Justification Business and Product Constraints Business and Product Risks Functional Goals Political Success Factors Product Scope Formula Measuring Take the Technical Pulse Applying the Product Scope Notes
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
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
Problem Domain Analysis Defining the Domain Changes in the Problem Domain Neighboring Constituencies
253 256 261 263
Ancillary Benefits Change in the Problem The Essence Note
264 264 265 265
Determine the Solution
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
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
PRODUCING THE PRODUCT
Monitor the Product
Entering the Solution Domain Development Processes Implementing the Solution Keep the Light on Things Change Checkpoint Charley The Watchdog The Essence Notes
314 314 317 319 319 320 321 323 323
xii CHAPTER 16
Confirm the Business Problem Has Been Solved
Correct Behavior Acceptable Level of Confidence Circumstances of Interest The Testing Game User Acceptance Testing? Handling Defects Testing Does Not Stop at Delivery Note
326 326 327 328 333 335 335 336
Transition and Change Management
Steps to Ensure Successful Change in the Organization Orchestrate the Transition Facilitate the Transition Timing the Change Major and Minor Changes Do Not Change a Thing Wrapping Up Notes
339 341 342 344 345 345 347 349
POSTSCRIPT Where to Go from Here
Future of Business Analysis Why We Need Business Analysts The True Value of the Business Analyst Increasing the Value of the Organization Power to the Business Analyst Notes
351 352 353 354 356 359
Business Analyst Process
Why We Do Not Get Good Requirements
Comparison of the Roles of Business Analyst, Systems Analyst, and Project Manager
APPENDIX E APPENDIX F
Context-Free Problem Definition Questions
List of Nonfunctional Requirements Categories
About the Author
It is all about change. There is a problem that needs to be solved. Sales needs support for the new marketing initiative. Human resources (HR) wants the employees to be able to manage their own United Way Fund and other charity deductions online. Marketing needs to change the mailing preferences to allow customers to opt-out of various publications in order to be in conformance with new regulations. The accounts payable system is old and slow and getting more inaccurate by the day. The organization wants these problems solved. People running the business do not have the time to research, investigate, and determine the best way of solving the problems. Besides, today’s solutions require automation, computers, software, and so forth and businesspeople do not do those things. They do not have the expertise. Businesspeople do not want code. They do not want systems. They do not want networks. What they want is a solution to their business problems. The information technology (IT) department will make it happen. The technology professionals write the software, define and populate the databases, connect the networks, and install hardware. All they need to know is what the business wants done. Yet, who is defining what will be done to solve the problem? Who defines the solution in such a way that the business can agree with the solution and the technologists can understand what needs to be done to implement the solution? And when the technology is ready for the business, who will make sure the change is made efficiently and the transition from the current to new process is smooth? The answer to these questions is the business analyst. Over the past 10 years or so the position of business analyst has found its way into the Human Resources job description catalog of many organizations. It has also earned its own trade group, the International Institute of Business Analysis (IIBA) and its own certification, the certified business analyst professional (CBAP), which is administered by the IIBA.
The role of the business analyst is to solve business problems. Specifying requirements is a critical function of the business analyst, but so are the many other responsibilities a business analyst can and should undertake all of which lead to the successful solution of a business problem. Business analysis is all about change: changes in business processes, changes in the information technology systems supporting business processes; changes in the way the organization does business. Everything the business analyst does results in some kind of change to the organization. Most of what the business analyst does should be aimed at solving a business problem, and that requires changing the organization from the current situation in which the problem exists to a new process or operation in which the problem has been solved. First and foremost, the business analyst is a problem solver. Kathleen Barrett, President of the International Institute of Business Analysis, calls the business analyst the ultimate problem solver. The business analyst becomes the go-to person in both the business and development communities when there is a problem. Any kind of problem: political, technical, business, misunderstandings, ambiguities, social, technological, philosophical. Big problems, small problems. Problems that require an IT intervention and those that can be fixed by rearranging the office furniture. The business analyst accepts the job of proactively understanding what the business problem is and determining the consequences of not solving it and then defines a solution that will remove or ameliorate the problem. The business analyst does this before development starts and then ensures that the solution as built by IT, in fact, solves the problem and does so in such a way that those affected by the problem can use the solution. By solving business problems, the business analyst is continually adding value to the organization. In fact, all the activities that a business analyst performs add value. The business analyst adds value by: &
Acting as the organizational change agent to improve business processes (Chapter 5). Investigating the real problem so that time and energy are not wasted solving the wrong problem (Chapters 8, 9, and 10). Providing information to upper-level management so their 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).
Managing the organization’s expectations of the solution so that the stakeholders realistically understand and accept the solution to their problem (Chapters 7, 9, 10, 16, and 17). Applying analytical and creative thinking to ensure the organization is making the best decisions and acting on the best solutions to problems (Chapters 5, 8, 12, and 13). Assuring the product developed by the solution team solves the intended problem (Chapters 15 and 16). Orchestrating the transition from the current business operations to the changed operations so that the organization gains the benefits of the new process as quickly as possible (Chapter 17).
This is a daunting job, filled with challenges and obstacles, both technical and political. And it is also a job filled with satisfaction and personal reward. The business analyst sits in the center of it all, engaging technologists and businesspeople, mediating misunderstandings, defining functions and features, mollifying management, identifying impacts, creating constructive change, and solving business problems. I have been performing the various roles and activities of the business analyst for 40 years now. I have worked with hundreds of business analysts and have heard their opinions, stories, frustrations, fears, concerns, and questions. This book is in response to them. Their questions, presented as actual quotes from business analysts, appear at the top of each section in which there is an answer. Hopefully, I answered your questions along the way. My goal with this book is to demonstrate that the business analyst is more than a requirements recorder. The business analyst is a central cog in the successful organization’s driving wheel. The business analyst is the organizational change agent. The business analyst is the organizational problem solver. The business analyst is the repository of business process information. In essence, here are the business analyst’s marching orders: & & &
There is a problem—define it. There is a solution to that problem—describe it. We need to change the organization to solve the problem—make it happen.
How to Use This Book While one use of this book might be as a weapon to threaten recalcitrant users into submission, this book can also be used as a guidebook to the wild environs of business analysis. Reading it straight through, from cover to
cover, or at least from page one until the end, you will get a fairly complete description of the overall business analyst’s process for solving business problems. You can also use the book to bolster arguments for additional pay and benefits for business analysts or simply to provide supporting information in an effort to establish a centralized formal or informal business analyst group within your organization. However, if you need a quick answer to a question that has been bothering you, the book is also an F&IAQ (frequently and infrequently asked questions) as is described later. While the main thrust of the book is a description of the business analyst’s process for solving business problems, there are also a number of tips, tricks, techniques, and tactics to help to execute the process in the face of sometimes overwhelming political or social obstacles. The typical business analyst has a finely honed associative memory. It is associative memory that allows the business analyst to relate potential solutions to the business problem and see emerging and existing patterns in the business processes. In deference to that associative memory, the book is littered with sidebars. Some sidebars emphasize particular points or expand on them.
Example Associative memory also allows us to recognize mistakes we have made in the past when we are making them again. This, according to F.P. Jones is the definition of experience.
Throughout the book I highlight tips, techniques, and guerrilla tactics that will serve you in good stead during your business analyst career. Many of the tips are humorous or tongue-in-cheek in nature.
Tip When you end an information gathering meeting early announce the time you are ending to let people know you are ending early. This way you will be known as someone who ends a meeting on time. If you realize your meeting may be running late, make an announcement about five minutes before the scheduled end of the meeting that ‘‘It’s about five minutes until the hour and we’re about done here. Just a few more questions.’’ If you end ten minutes late most people will still remember the time you stated and have the impression your meeting got out on time.
The Just for Fun sidebars contain fanciful explanations of why things are as they are.
Just for Fun Whenever we brought changes to the Vice President who was acting as the Change Control Board he would either approve the change or defer it to a later release. He asked what the last scheduled release we had, and schedule it for the next release after that, which at the time was Release 9. When, later on after the first releases of the system were delivered, we began to schedule more releases, he told us to move everything that was in Release 9 out to the next release after the last one scheduled, or Release 12. It was his way of not saying ‘‘no’’ to the business requests for changes to the system. Prior to becoming a Vice President of this telecommunications firm, he has spent years as a consultant in the Washington DC area where he learned how to say ‘‘no’’ without ever saying ‘‘no.’’
Some of the sidebars contain some alternate ways for doing some of the activities you have been performing as a business analyst which might make your job just a little easier, or bring about better results.
May I Suggest? Instead of thinking ‘‘users’’ and referring and documenting user activities, needs, wants, etc., think instead ‘‘process workers.’’ This enlarges the potential population of people who might be involved in the business process. Users are only involved with the computer and as long as we restrict our views to users we will not see improvements that can be made in processes, especially those improvements that turn process workers into users by automating a part or all of their process activities.
Some sidebars track a case study to show the real-life application of the principles and practices of the business analyst process.
Case Study One of the case studies is an accounts payable system revision. It stars Charlie, the accounts payable voucher entry clerk whose primary goal is to get to Happy Hour on time.
Questions, Comments, and Complaints Being a business analyst is a complicated job. It is a new profession in many organizations and that newness brings with it confusion, questions, concerns, and the inevitable complaints. Rather than try to guess what the questions are, I asked the business analysts themselves. The following list represents an abbreviated collection of questions, concerns, and complaints that business analysts have voiced to me over the years. Many of these questions and concerns might have occurred to you as you go about your work as a business analyst. I index the questions to the chapter of this book where the question is answered. This provides a quick reference when the question comes up (again) in your day-to-day activities. Questions, Comments, 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 )
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?
Chapter 5 (Intermediary), 6 (Solution Team), and 15
Chapter 10 Chapter 15 Chapter 15
Part Four: The Process (continued )
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?
Chapters 7 and 12 Chapters 11 and 15 Chapter 6 Chapter 7 Chapter 15 Chapters 15 and 16
Chapters 3 and 6
Part One: The Problem Solver Chapter 3
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 1 and Postscript Chapter 7
This whole book
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