Business Analysis: Best Practices for Success (2011) PDF

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...

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 xxv International Institute for Learning, Inc. (IIL) xxvii PART I THE PROBLEM SOLVER 1 CHAPTER 1 What Is a Business Analyst? 3 The Business Analyst in Context 3 What Is It All About? 4 The Role of the Business Analyst 5 The Business Analyst in the Center 6 Business Analyst Focus 8 The Ideal Business Analyst 9 Last-Liners 11 Notes 11 CHAPTER 2 The Evolution of the Business Analyst 13 The Business Analyst Hall of Fame 13 Where It Began 15 Information Systems 17 The Rise of the Business Analyst 18 The Business Analyst Position 20 The Business Analyst Profession 21 The Question of Certification 24 The Challenge of Business Analyst Certification 25 The Value of Certification 26 Notes 27 vii FTOC 09/12/2011 15:32:34 Page 8 viii Contents CHAPTER 3 A Sense of Where You Are 29 Business Analysts Coming from IT 30 Business Analysts Coming from the Business Community 31 Living with the Business 33 The Lone Ranger 35 Working Both Sides of the Street 36 Central Business Analyst Organization 37 CHAPTER 4 What Makes a Good Business Analyst? 39 The Skillful Business Analyst 40 Is a Business Analyst Born or Made? 41 So What Does It Take to Be a Business Analyst? 42 CHAPTER 5 Roles of the Business Analyst 45 Intermediary 49 Filter 59 Mediator 63 Diplomat 65 Politician 68 Investigator 69 Analyst 70 Change Agent 72 Quality Control Specialist 73 Facilitator 74 Process Improver 79 Increase the Value of Organizational Business Processes 79 Build It and They Will Come 80 Reducing Complexity 82 Playing Multiple Roles 83 Notes 84 PART II THE PLAYERS 85 CHAPTER 6 The Business Analyst and the Solution Team 89 Business Analyst and Project Manager 89 Business Analyst and Systems Analyst 94 Trying to Do All Jobs 98 Business Analyst and the Rest of the Solution Team 100 Bottom Line 107 Notes 108 FTOC 09/12/2011 15:32:34 Page 9 Contents ix CHAPTER 7 The Business Analyst and the Business Community 109 Constituents and Constituencies 110 Business Analysts and Upper-Level Management 110 Product Stakeholders 113 Subject Matter Experts 119 Process Workers 122 Managing Expectations 126 Notes 130 PART III THE PROBLEM 131 CHAPTER 8 Define the Problem 135 First Things First 135 Challenge 1: Finding the Problem 138 Challenge 2: The Unstated Problem 139 Challenge 3: The Misunderstood Problem 140 Define the Real Problem 141 The Problem Determination Game 145 Documenting the Problem 154 Product Vision 155 Define the Vision 157 Checkpoint Alpha 159 Focus on the Problem and Vision 161 Note 162 CHAPTER 9 Define the Product Scope 163 Project and Product Scopes 163 Product Scope 164 Product Scope Formula 165 Strategic Justification 165 Business and Product Constraints 167 Business and Product Risks 168 Functional Goals 169 Political Success Factors 171 Product Scope Formula 172 Measuring 173 Take the Technical Pulse 174 Applying the Product Scope 175 Notes 177 FTOC 09/12/2011 15:32:34 Page 10 x Contents CHAPTER 10 Confirm Alignment and Financial Justification 179 The Business Case 179 The Value of IT 180 Considering Alignment 181 Organization Mission 182 Organization Goals 184 Organization Strategies 184 Department-Level Mission, Goals, and Strategies 185 At the Tactical Level 187 Determining the Value of the IT Project 188 Provide Financial Justification for Solving the Problem 190 Proof of Solution: Feasibility Study 194 The Metrics Game 194 In the End... 195 Notes 196 PART IV THE PROCESS 197 CHAPTER 11 Gather the Information 199 Why We Cannot Define Good Requirements 200 Stop Gathering Requirements 201 Users Do Not Have Requirements 203 Gather Information, Not Requirements 204 Gathering the Information 205 Information-Gathering Plan 206 Information-Gathering Session 217 Solving Common Information-Gathering Issues 225 Iterative Information Gathering 227 Interviewing 228 Information-Gathering Meetings 239 Other Elicitation Methods 245 Are We Done Yet? 247 Notes 249 CHAPTER 12 Define the Problem Domain 251 Problem Domain Analysis 253 Defining the Domain 256 Changes in the Problem Domain 261 Neighboring Constituencies 263 FTOC 09/12/2011 15:32:34 Page 11 Contents xi Ancillary Benefits 264 Change in the Problem 264 The Essence 265 Note 265 CHAPTER 13 Determine the Solution 267 The Accordion Effect 267 Tools and Techniques 268 Determining the One Best Solution 278 Constraining the Solution 279 Stop Analyzing, Already 280 Confirmation 280 Checkpoint Beta 283 Notes 284 CHAPTER 14 Write the Solution Document 285 The Value of Documentation 285 The Anatomy of Requirements 289 Forms of Solution Documentation 300 Write the Right Thing 300 Write the Thing Right 302 Canned Brains 305 Requirements Ownership 306 Complete the Process 307 Note 308 PART V PRODUCING THE PRODUCT 309 CHAPTER 15 Monitor the Product 313 Entering the Solution Domain 314 Development Processes 314 Implementing the Solution 317 Keep the Light on 319 Things Change 319 Checkpoint Charley 320 The Watchdog 321 The Essence 323 Notes 323 FTOC 09/12/2011 15:32:34 Page 12 xii Contents CHAPTER 16 Confirm the Business Problem Has Been Solved 325 Correct Behavior 326 Acceptable Level of Confidence 326 Circumstances of Interest 327 The Testing Game 328 User Acceptance Testing? 333 Handling Defects 335 Testing Does Not Stop at Delivery 335 Note 336 CHAPTER 17 Transition and Change Management 337 Steps to Ensure Successful Change in the Organization 339 Orchestrate the Transition 341 Facilitate the Transition 342 Timing the Change 344 Major and Minor Changes 345 Do Not Change a Thing 345 Wrapping Up 347 Notes 349 POSTSCRIPT Where to Go from Here 351 Future of Business Analysis 351 Why We Need Business Analysts 352 The True Value of the Business Analyst 353 Increasing the Value of the Organization 354 Power to the Business Analyst 356 Notes 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 Contents xiii APPENDIX E Context-Free Problem Definition Questions 383 APPENDIX F 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 custom- ers 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, investi- gate, 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 data- bases, 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 de- fines 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 organiza- tions. 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 12:48:17 Page 16 xvi Preface The role of the business analyst is to solve business problems. Specify- ing 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 pro- cesses; 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 busi- ness 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, mis- understandings, ambiguities, social, technological, philosophical. Big prob- lems, 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 per- forms add value. The business analyst adds value by: & Acting as the organizational change agent to improve business pro- cesses (Chapter 5). & Investigating the real problem so that time and energy are not wasted solving the wrong problem (Chapters 8, 9, and 10). & Providing information to upper-level management so their decision- making can be faster and more effective (Chapters 5, 8, and 10). & Getting the business managers and process workers to talk directly to the technicians and technologists to reduce time and mis- communication (Chapters 5 and 15). & Creating an environment where there is an unfettered flow of informa- tion 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 in- tended 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 techni- cal and political. And it is also a job filled with satisfaction and personal re- ward. 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 ques- tions. 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 infor- mation in an effort to establish a centralized formal or informal business ana- lyst 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 (fre- quently and infrequently asked questions) as is described later. While the main thrust of the book is a description of the business ana- lyst’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 solu- tions to the business problem and see emerging and existing patterns in the business processes. In deference to that associative memory, the book is lit- tered 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 real- ize 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 ques- tions.’’ 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 Preface xix 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 busi- ness requests for changes to the system. Prior to becoming a Vice Presi- dent 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 im- provements that can be made in processes, especially those im- provements 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, con- cerns, and the inevitable complaints. Rather than try to guess what the ques- tions 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 ques- tions 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 Chapter 6 manager? What are the roles and responsibilities of a Chapter 5 business analyst? What is the connection between requirements Chapter 16 and testing? How do I know what questions to ask the Chapter 11—The Information- users? Gathering Session How can I do it right the first time and avoid Part Four: The Process rework? How can I write better requirements? Chapters 11, 13, and 14 How do we get management and users to Chapter 9 cooperate when they refuse to focus on requirements? Is it possible to create a common language for Chapters 6 and 7 IT and business? Is there a methodology or process for business This whole book analysts? (continued ) FPREF 09/12/2011 12:48:20 Page 21 Preface xxi How can I improve the communication This whole book between stakeholders and business and developers? Since I’m doing all three roles, what is the Chapter 6, Appendix B difference between the project manager, the systems analyst, and the business analyst? Are there any tools for business modeling, and if Chapter 13 so which ones should business analysts use? How do I negotiate with the business to Chapter 7 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 Chapters 13 and 14 requirements? I have to do everything from defining the Chapter 6 requirements to coding and testing; how can I effectively be a one-man band? How can we make sure there are no surprises at Chapters 11, 15, and 17 the end when we are delivering the solution? How do we deal with customers who give us Chapter 11—Interview Issues the solution and not the problem? What is the best way to objectively define Chapter 11—Interview Issues 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, Chapter 5 (Intermediary), including offshore developers. How can I 6 (Solution Team), and 15 make sure all the communications are consistent and effective? What’s the best way to create the business Chapter 10 case? Is it the job of a business analyst? Where does the business analyst fit into our Chapter 15 software development life cycle? We’re using agile development (Extreme Chapter 15 Programming). What is my role as a business analyst in this situation? Is it necessary to provide cost justification, such Chapter 10 as an ROI for projects, and if so, how do you do it? How do I separate the noise from the true Part Four: The Process requirements? (continued ) FPREF 09/12/2011 12:48:21 Page 22 xxii Preface How can I get good requirements when Chapter 11 management dictates schedules that don’t allow enough time? What are some techniques that can be used to Chapters 7 and 12 work with groups who won’t cooperate? What do I do about new requirements that are Chapters 11 and 15 defined after the project starts? How do I handle the project manager and Chapter 6 project team? How do I negotiate with the business to Chapter 7 change their expectations? How do we handle changes after getting sign- Chapter 15 off on a hundred-page document? The business analysts are tasked with testing Chapters 15 and 16 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 Chapters 3 and 6 years; how do I transition to my new job as business analyst? Communication with the developers is not Chapter 6 very satisfactory. They have no respect for what we do. Over-commitment—management is trying to Chapter 7 do too many things without evaluation or prioritization. How do I explain to my kids what a business Part One: The Problem Solver analyst does? I transitioned from system analyst to business Chapter 3 analyst. Will be technical background help me or hurt me? How does the time spent in business process Chapter 13 modeling help me? Do I need to know how to do all the different types of models, like entity relationship diagrams? (continued ) FPREF 09/12/2011 12:48:21 Page 23 Preface xxiii How do I get the business to give us Chapter 11 information? Is there a holistic view of requirements and Part Four: The Process testing? There are last minute changes made to the Chapter 15—Checkpoint releases which are done directly with the Charley 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 Chapter 5—Intermediary 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 Chapter 1 and Postscript more than prepare and maintain documents? There are user meetings every month, but the Chapter 7 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 This whole book business analysts in doing their job successfully? What can I do to increase collaboration among Chapter 5—Diplomat all the parties in the solution development effort? Why is there always such a gap between the Chapters 8, 9, and 15 user requirements and the delivered product? How can we make successful changes to the Chapters 12 and 17 processes without encountering so much resistance from the users? I feel like we are an afterthought. Is there Chapters 2, 4, and Postscript really a business analyst profession? What is the difference between the ‘‘what’’ Chapter 14—Anatomy of requirements and the ‘‘how’’ requirements? Requirements Who defines acceptance test cases? Who Chapter 16 executes acceptance test cases? How do we convince the customer to do Chapters 7, 11, and 12 something different, such as another approach? 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, confer- ence 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 Bran- denburg, 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 organi- zations, 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 11:25:11 Page 26 xxvi 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: Proj- ect, 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 innova- tive, effective and consistent training solutions through a variety of learning approaches, including Virtual Classroom, Traditional Classroom, Simulation Training, Interactive On-Demand Training and a blended approach. Our roster of international trainers is comprised of elite professionals whose industry experience is enhanced by their practical classroom expertise. To learn more please visit www.iil.com or email [email protected].  PMI1, PMP1, PMBOK1 and the PMI1 Registered Education Provider logo are reg- istered trademarks of the Project Management Institute, Inc. registered in the United States and other nations. PRINCE21, ITIL1, M_o_R1, MSP1 and P3O1 are Regis- tered 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 busi- ness 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 system- atic 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 sys- tems approach to solving business problems. And at the center of this ap- proach 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 inter- disciplinary domain knowledge and integrated application develop- ment 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 organiza- tion? This chapter explores what makes a business analyst and what a busi- ness 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 man- agement level and does not possess authority; however, it is a key contributor to most of the successful IT-related changes in an organization. Those occu- pying 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 pro- posed 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 com- puter 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 organiza- tion, 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 compa- nies 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 defini- tion 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 opportu- nities 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 per- son who performs business analysis activities, no matter what their job title or organizational role may be.’’ Business analysis activities involve ‘‘under- standing 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 investi- gating 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: ana- lyst, liaison, communicator, internal consultant, improver of business sys- tems, and business problem solver. Putting it all together, the business analyst is an agent for change in the business, summoning the forces of tech- nology to make changes in the organization, solving problems, and improv- ing 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 busi- ness 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 tempo- rary basis. In some organizations, it is divided among several positions, such as requirements engineer, quality assurance analyst, quality control special- ist, product owner, project manager, business champion, software configu- ration 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 sup- port 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, presenta- tion skills, and analytical/critical thinking. Sprinkled in with all these skills, it is important for the business analyst to have a surface under- standing 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 Development Community Management Community ULM EDM Business IT Manager Manager Problem Project Owner Manager BA Defines Process Solution Workers Products Produce Team Solve (solutions) Problems 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 in- volved 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 organiza- tional 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 per- ceived 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 sys- tem, 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 govern- ment 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 prod- uct 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 technol- ogy 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 develop- ment community looks on the business community as nothing but one big problem. This is good. If the business did not have problems, the develop- ment 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 proj- ect. 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 prob- lem, only that the project is a success. The project manager and solution team rightfully assume that the business has done due diligence and deter- mined that the product to be developed is necessary and will provide a ben- efit 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 man- agement 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 manage- ment 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 posi- tion 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 What Is a Business Analyst? 9 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 be- cause 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 coales- cence 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 ana- lyst 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 Both facilitates and moderates in the organization. meetings. Understands the business issues and Delivers informative, well-organized challenges of the organization and presentations. industry. Identifies the organization’s strengths and Understands how to communicate weaknesses and suggests areas of difficult/sensitive information improvement. 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, Possesses enough understanding in specifications, business processes, and technical disciplines to be able to recommendations related to proposed converse intelligently with solution solution. team. Documents the solution to the business Mediates conflicts between business problem in a form approvable by the and the solution team and different business, acceptable to the solution team, business units being impacted by and understandable to management. the solution Pushes creative problem solving beyond Generates enthusiasm for the product the boundaries of existing organizational among product stakeholders and practices and mind-sets. solution team members Identifies areas for improvement in internal Facilitates decision making among processes and suggests potential solutions. organization executives Product Delivery Product Quality Assurance Receives input from managers and Evaluates requested changes from the appropriately and accurately provides business and communicates needed comments/feedback. changes to development team. Communicates non-technical product and Ensures product issues are identified, business standards and constraints. tracked, reported on, and resolved in a timely manner with both the solution team and the business. Facilitates the business-community Leads and/or participates in transition from current problem state to acceptance testing efforts. 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 cov- ered 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 cen- turies, perhaps as long as there has been business or at least accounting for business. Business analysts are not quite the oldest profession, but the posi- tion 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 pro- gression 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 his- tory is much more difficult. The need for a business analyst would exist without computers or information systems, although the present-day busi- ness analyst role has roots in the evolution of business computer technol- ogy. The role is a melting pot of professions and disciplines, technology and intuition, solitary analysis and personal interaction, engineering and busi- ness 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 12:33:31 Page 14 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 peo- ple in the country every 10 years. The 1880 census took seven years to com- plete 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 busi- ness 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 scien- tific 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 (The- ory of 14 points, among others) might also be added to the list of people who have significantly influenced the business analyst profession. Feigen- baum’s book Total Quality Control established a holistic approach to in- stilling 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 com- panies 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 sprin- kled 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 fo- cus 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 12:33:32 Page 16 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 some- what 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 misun- derstandings between the business community and the programmers. As a result, data processing departments created the programmer ana- lyst 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 business- people 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 gradu- ates from the programming schools came from professions and businesses already possessing insights into how business worked. As technology became pervasive in business and government organiza- tions, it became increasingly difficult to merge the demands of the organiza- tion and the technological advances of computers. Computer scientists added more complexity to the technology with newer, faster computers and periph- eral devices. Businesspeople then discovered the many things computers could do to make their work easier, and started demanding computer depart- ments 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 an- alyst 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 them- selves 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 inter- face at that time was a simple terminal on which questions were displayed. The responses were entered in a scrolling, sequential fashion in gray charac- ters 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 ana- lysts 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, room- sized mainframe computers to mini-computers, then micro-computers, and then personal computers. The software industry expanded and changed, creating new programming languages, m