
- •Foreword
- •Preface the purpose of this book
- •Intended audience
- •Book organization
- •About b2t training
- •Chapter 1: Possess a Clear Understanding of Business Analysis overview
- •What is business analysis?
- •Business Analysis vs. Software Development
- •The Role of the Business Analyst
- •Business Analyst Traits
- •History of Business Analysis
- •Where Do Business Analysts Come From?
- •From it
- •Case in Point
- •From Business
- •Case in Point
- •Where Do Business Analysts Report?
- •Who makes a great business analyst?
- •Case in Point
- •Business Analyst Suitability (- відповідність) Questionnaire
- •Suitability Questionnaire
- •Answers
- •Business Analyst Career Progression
- •Key business analysis terms/concepts
- •What Is a Requirement?
- •Iiba Business Analysis Body of Knowledge® (babok®) definition of requirement:
- •Core Requirements Components
- •Why Document Requirements?
- •Why Do Requirements Need to Be Detailed?
- •High-Level Requirements Are Interpreted Differently
- •Many Analysts Only Use Text to Document Requirements
- •Complex Business Rules Must Be Found
- •Requirements Must Be Translated
- •Case in Point
- •What Is a Project?
- •What Is a Product?
- •What Is a Solution?
- •Case in Point
- •What Is a Deliverable?
- •System vs. Software
- •It Depends
- •Business analysis certification
- •Iiba babok®
- •Summary of key points
- •Bibliography
- •Chapter 2: Know Your Audience overview
- •Establish trust with your stakeholders
- •With whom does the business analyst work?
- •Executive or Project Sponsor
- •Case in Point: Giving the Sponsor Bad News
- •Project Manager
- •Why Does a Project Need a Project Manager and a Business Analyst?
- •Project Manager and Business Analyst Skills Comparison
- •Tips for Those Performing Both Roles
- •Other Business Analysis Professionals
- •Subject Matter Experts and Users
- •Getting to Know Your Subject Matter Experts
- •A Manager Who Does Not Understand His or Her Employees’ Work
- •When the Expert Is Not Really an Expert
- •When the Expert Is Truly an Expert
- •The Expert Who Is Reluctant to Talk
- •The Expert Who Is Angry about Previous Project Failures
- •The Expert Who Hates His or Her Job
- •Quality Assurance Analyst
- •When “qa” Is a Bad Word in Your Organization
- •Usability Professional
- •It Architect
- •Case in Point
- •It Developer
- •Case in Point
- •The Developer Who Is Very Creative
- •The Developer Who Codes Exactly to Specs
- •The Developer’s Industry Knowledge
- •Data Administrator/Architect/Analyst
- •Database Designer/Administrator
- •Stakeholder Analysis
- •Balancing stakeholder needs
- •Case in Point
- •Understanding the Political Environment
- •Working with dispersed teams
- •Physical Distance
- •Time Zone Differences
- •Nationality/Cultural Differences
- •Language Differences
- •Using Team Collaboration Tools
- •Using a Shared Presentation
- •Sharing a Document
- •Summary of key points
- •Bibliography
- •Chapter 3: Know Your Project
- •Why has the organization decided to fund this project?
- •Business Case Development
- •Case in Point
- •Project Initiated Because of a Problem
- •Case in Point
- •Project Initiated to Eliminate Costs (Jobs)
- •Project Initiated by Outside Regulation
- •Project Initiated by an Opportunity
- •Projects for Marketing or Advertising
- •Case in Point
- •Projects to Align Business Processes
- •Strategic planning
- •Portfolio and Program Management
- •How Does Your Project Relate to Others?
- •Enterprise Architecture
- •Business Architecture
- •The Organizational Chart
- •Locations
- •Swot (Strengths, Weaknesses, Opportunities, Threats)
- •Products
- •Information Architecture
- •Application Architecture
- •Technology Architecture
- •Case in Point
- •Security Architecture
- •Communicating Strategic Plans
- •Project Identification
- •Project initiation
- •Naming the Project
- •Initiation
- •Approach or Methodology
- •Statement of Purpose
- •Objectives
- •Problems/Opportunities
- •Stakeholders
- •Business Risks
- •Items Out of Scope
- •Assumptions
- •Scope of the Business Area
- •Scoping the Analysis Area Using a Context-Level Data Flow Diagram
- •Area of Study
- •High-Level Business Processes
- •Scoping the Analysis Area Using a Use Case Diagram
- •Project Initiation Summary Revisit Scope Frequently
- •Scope Creep
- •Summary of key points
- •Bibliography
- •Chapter 4: Know Your Business Environment overview
- •Case in Point
- •How does a business analyst learn about the enterprise?
- •Read the Company’s Marketing Materials
- •Read the Company’s Financial Reports
- •Review the Corporate Strategic Plan
- •Seeing things from the business perspective
- •Case in Point
- •Prioritizing Requests
- •Case in Point
- •How a business analyst learns the business: elicitation techniques
- •Review Existing Documentation
- •Case in Point
- •Observation
- •Case in Point
- •Case in Point
- •Interviews
- •Surveys and Questionnaires
- •Facilitated Sessions
- •Why Use a Facilitated Session?
- •Challenges for the Business Analyst as the Facilitator
- •Focus Groups
- •Competitive Analysis
- •Interface Analysis
- •Learn the current (as is) system
- •Case in Point
- •What is a business process?
- •Essential Analysis
- •Perfect Technology
- •No Storage Limitations or Constraints
- •Case in Point
- •Completely Error-Free Processing
- •Case in Point
- •No Performance Limitations
- •Technology Is Available at No Cost
- •Case in Point
- •Summary of Perfect Technology
- •Essential Business Processes
- •Case in Point
- •What Is the Difference between a Process and a Use Case?
- •Describing a Process
- •Seeing Things from the Top and from the Bottom
- •Implementation Planning
- •Training
- •Rollout Plan
- •Schedule
- •Metrics
- •Procedures/Organizational Changes
- •Summary of tips for learning your business
- •Summary of key points
- •Bibliography
- •Chapter 5: Know Your Technical Environment overview
- •Case in Point
- •Why does a business analyst need to understand the technical environment?
- •Understand Technology, But Don’t Talk Like a Technologist
- •Case in Point
- •What does a business analyst need to know about technology?
- •Software Development/Programming Terminology
- •Does a Business Analyst Need to Know How to Develop Software?
- •Software Development Methodologies
- •Methodology/Software Development Life Cycle
- •Waterfall
- •Planning Phase
- •Analysis Phase
- •Design Phase
- •Construction Phase
- •Testing Phase
- •Information Engineering
- •Joint Application Development/Design
- •Rapid Application Development
- •Iterative/Incremental Development Approaches
- •Object-Oriented Analysis and Design
- •Rational Unified Process
- •Agile Development Approaches
- •An Organization’s Formal Methodology
- •Why Don’t Most Methodologies Detail the Business Analysis Approach?
- •An Organization’s Informal Standards
- •Technical Architecture
- •Operating Systems
- •Case in Point
- •Computer Networking
- •Data Management
- •Relational Database
- •Structured Query Language
- •Software Usability/Human Interface Design
- •Software Testing
- •Case in Point
- •Software Testing Phases
- •Unit Testing
- •Integration Testing
- •System Testing
- •Regression Testing
- •Case in Point
- •User Acceptance Testing
- •Post-Implementation User Assessment
- •Working with it Communicating with Developers
- •When to Get it Involved in a Project
- •It Corporate Culture
- •Summary of key points
- •Bibliography
- •Chapter 6: Know Your Analysis Techniques overview
- •Case in Point
- •Categorizing and presenting requirements Collecting and Managing Requirements
- •What Is a Requirement?
- •Categorizing Requirements
- •Case in Point
- •Why Categorize Requirements?
- •Developing a System for Organizing Requirements
- •Iiba babok Categories
- •A Recommended Categorization System
- •Business Requirements
- •Functional Requirements
- •Technical Requirements
- •Core requirements components
- •Overview of Core Requirements Components Data (Entities and Attributes)
- •Processes (Use Cases)
- •External Agents (Actors)
- •Business Rules
- •Case in Point
- •Core Requirements Component: Entities (Data)
- •Core Requirements Component: Attributes (Data)
- •Attribute Uniqueness
- •Mandatory or Optional
- •Attribute Repetitions
- •Core Requirements Component: Processes (Use Cases)
- •Core Requirements Component: External Agents (Actors)
- •Internal vs. External
- •Core Requirements Component: Business Rules
- •Finding Business Rules
- •Analysis techniques and presentation formats
- •Glossary
- •Workflow Diagrams
- •Why Use Workflow Diagrams?
- •Entity Relationship Diagramming
- •Why Build a Logical Data Model?
- •Business Process Modeling with the Decomposition Diagram
- •Why Build a Decomposition Diagram?
- •Use Case Diagram
- •Use Case Descriptions
- •Why Use Use Cases?
- •Case in Point
- •Prototypes/Simulations
- •Why Use Prototypes/Simulations?
- •Other Techniques Event Modeling
- •Entity State Transition/uml State Machine Diagrams
- •Object Modeling/Class Modeling
- •User Stories
- •Traceability Matrices
- •Gap Analysis
- •Data Flow Diagramming
- •Choosing the Appropriate Techniques
- •Using Text to Present Requirements
- •Using Graphics to Present Requirements
- •Using a Combination of Text and Graphics
- •Choosing an Approach
- •Case in Point
- •Business Analyst Preferences
- •Case in Point
- •Subject Matter Expert Preferences
- •Case in Point
- •Developer Preferences
- •Project Manager Preferences
- •Standards
- •Case in Point
- •As is vs. To be analysis
- •Packaging requirements How Formally Should Requirements Be Documented?
- •What Is a Requirements Package?
- •Case in Point
- •Request for Proposal Requirements Package
- •Characteristics of Excellent Requirements
- •Getting Sign-Off
- •Requirements Tools, Repositories, and Management
- •Summary of key points
- •Bibliography
- •Chapter 7: Increase Your Value overview
- •Build your foundation Skill: Get Started
- •Skill: Think Analytically
- •Skill: Note Taking
- •Technique: Brainstorming
- •Skill: Work with Complex Details
- •Case in Point
- •How Much Detail? Just Enough!
- •Case in Point
- •Time management Skill: Understand the Nature of Project Work
- •Skill: Work on the Most Important Work First (Prioritize)
- •Case in Point
- •Technique: Understand the 80-20 Rule
- •Technique: Timeboxing
- •Build your relationships and communication skills Skill: Build Strong Relationships
- •Skill: Ask the Right Questions
- •Case in Point
- •Skill: Listen Actively
- •Barriers to Listening
- •Listening for Requirements
- •Skill: Write Effectively
- •Case in Point
- •Skill: Make Excellent Presentations
- •Skill: Facilitate and Build Consensus
- •Skill: Conduct Effective Meetings
- •Prepare for the Meeting/Select Appropriate Attendees
- •Meeting Agenda
- •Conducting the Meeting
- •Tips for Conducting Successful Meetings
- •Follow-Up/Meeting Minutes
- •Skill: Conduct Requirements Reviews
- •How to Conduct a Review
- •Step 1. Decide on the Purpose of the Review
- •Step 2. Schedule Time with Participants
- •Steps 3 and 4. Distribute Review Materials and Have Participants Review Materials Prior to the Session
- •Case in Point
- •Step 5. Conduct the Review Session
- •Steps 6 and 7. Record Review Notes and Update Material
- •Step 8. Conduct a Second Review If Necessary
- •Typical Requirements Feedback Corrections
- •Missing Requirements
- •Unclear Sentences
- •Scope Creep
- •Keep learning new analysis techniques Technique: Avoid Analysis Paralysis!
- •Technique: Root Cause Analysis
- •The Five Whys
- •Case in Point
- •Skill: Intelligent Disobedience
- •Continually improve your skills
- •Skill: Make Recommendations for Solutions
- •Understand the Problem
- •Imagine Possible Solutions
- •Case in Point
- •Evaluate Solutions to Select the Best
- •Skill: Be Able to Accept Constructive Criticism
- •Case in Point
- •Skill: Recognize and Act on Your Weaknesses
- •Technique: Lessons Learned
- •Business analysis planning
- •Technique: Map the Project
- •Examples of Mapped Projects
- •Skill: Plan Your Work
- •Technique: Assess Business Impact
- •Case in Point
- •Factors That Determine Business Impact
- •Case in Point
- •Technique: Conduct Stakeholder Analysis
- •Technique: Plan Your Communications
- •Skill: Choose Appropriate Requirements Deliverables
- •Skill: Develop a Business Analysis Task List
- •Skill: Estimate Your Time
- •Summary of key points
- •Bibliography
Seven Steps to Mastering Business Analysis
Barbara A. Carkenord, MBA, CBAP
J. Ross Publishing; All Rights Reserved
Copyright © 2009 by B2T Training
ISBN 978-1-60427-007-5
Printed and bound in the U.S.A.
Printed on acid-free paper 10 9 8 7 6 5 4 3 2 1
Library of Congress Cataloging-in-Publication Data
Carkenord, Barbara A.
Seven steps to mastering business analysis / by Barbara A. Carkenord.
p. cm.
Includes bibliographical references and index. ISBN 978-1-60427-007-5 (pbk. : alk. paper)
1. Business analysts. 2. Business planning. 3. Organizational effectiveness. I. Title.
HD69.B87C37 2008 658.4¢01—dc22
2008030941
This publication contains information obtained from authentic and highly regarded sources. Reprinted material is used with permission, and sources are indicated. Reasonable effort has been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use.
All rights reserved. Neither this publication nor any part thereof may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of the publisher.
The copyright owner’s consent does not extend to copying for general distribution for promotion, for creating new works, or for resale. Specific permission must be obtained from J. Ross Publishing for such purposes.
Direct all inquiries to J. Ross Publishing, Inc., 5765 N. Andrews Way, Fort Lauderdale, Florida 33309.
Phone: (954) 727-9333 Fax: (561) 892-0700 Web: www.jrosspub.com
DEDICATION
This book is dedicated to my Mom and Dad, Joann and Joseph Carkenord. My Mom taught me to be organized and always plan ahead. My Dad’s lifetime commitment to education gave me a love of learning, and taught me the discipline of hard work. Organization, planning, learning, and hard work are essential skills for mastering business analysis. In addition, my parents always told me that there wasn’t anything that I couldn’t do!
TOC
Table of Contents
Seven Steps to Mastering Business Analysis 1
Foreword 9
Preface 12
THE PURPOSE OF THIS BOOK 12
INTENDED AUDIENCE 12
BOOK ORGANIZATION 13
ABOUT B2T TRAINING 13
Chapter 1: Possess a Clear Understanding of Business Analysis 14
OVERVIEW 14
WHAT IS BUSINESS ANALYSIS? 14
Business Analysis vs. Software Development 15
The Role of the Business Analyst 15
Where Do Business Analysts Come From? 17
Where Do Business Analysts Report? 19
WHO MAKES A GREAT BUSINESS ANALYST? 20
Business Analyst Suitability (- відповідність) Questionnaire 22
Business Analyst Career Progression 24
KEY BUSINESS ANALYSIS TERMS/CONCEPTS 25
What Is a Requirement? 26
Core Requirements Components 26
Why Document Requirements? 27
Why Do Requirements Need to Be Detailed? 29
What Is a Project? 30
What Is a Product? 30
What Is a Solution? 30
What Is a Deliverable? 31
System vs. Software 32
It Depends 32
BUSINESS ANALYSIS CERTIFICATION 32
IIBA BABOK® 32
SUMMARY OF KEY POINTS 33
BIBLIOGRAPHY 34
Chapter 2: Know Your Audience 35
OVERVIEW 35
ESTABLISH TRUST WITH YOUR STAKEHOLDERS 36
WITH WHOM DOES THE BUSINESS ANALYST WORK? 37
Executive or Project Sponsor 37
Project Manager 39
Other Business Analysis Professionals 42
Subject Matter Experts and Users 42
Quality Assurance Analyst 47
Usability Professional 48
IT Architect 49
IT Developer 49
Data Administrator/Architect/Analyst 51
Database Designer/Administrator 52
Vendor 53
Stakeholder Analysis 54
BALANCING STAKEHOLDER NEEDS 55
Understanding the Political Environment 55
WORKING WITH DISPERSED TEAMS 56
Physical Distance 56
Time Zone Differences 57
Nationality/Cultural Differences 57
Language Differences 57
Using Team Collaboration Tools 58
SUMMARY OF KEY POINTS 58
BIBLIOGRAPHY 59
Chapter 3: Know Your Project 60
WHY HAS THE ORGANIZATION DECIDED TO FUND THIS PROJECT? 60
Business Case Development 60
Project Initiated Because of a Problem 63
Project Initiated to Eliminate Costs (Jobs) 64
Project Initiated by Outside Regulation 65
Project Initiated by an Opportunity 66
Projects for Marketing or Advertising 66
Projects to Align Business Processes 67
STRATEGIC PLANNING 68
Portfolio and Program Management 69
How Does Your Project Relate to Others? 69
Enterprise Architecture 70
Communicating Strategic Plans 73
Project Identification 73
PROJECT INITIATION 73
Naming the Project 74
Initiation 74
Project Initiation Summary 80
SUMMARY OF KEY POINTS 80
BIBLIOGRAPHY 81
Chapter 4: Know Your Business Environment 82
OVERVIEW 82
HOW DOES A BUSINESS ANALYST LEARN ABOUT THE ENTERPRISE? 83
Read the Company’s Marketing Materials 83
Read the Company’s Financial Reports 83
Review the Corporate Strategic Plan 84
SEEING THINGS FROM THE BUSINESS PERSPECTIVE 84
Prioritizing Requests 85
HOW A BUSINESS ANALYST LEARNS THE BUSINESS: ELICITATION TECHNIQUES 86
Review Existing Documentation 87
Observation 87
Interviews 89
Surveys and Questionnaires 90
Facilitated Sessions 91
Focus Groups 93
Competitive Analysis 93
Interface Analysis 94
LEARN THE CURRENT (AS IS) SYSTEM 94
WHAT IS A BUSINESS PROCESS? 95
Essential Analysis 97
Seeing Things from the Top and from the Bottom 103
Implementation Planning 104
SUMMARY OF TIPS FOR LEARNING YOUR BUSINESS 106
SUMMARY OF KEY POINTS 106
BIBLIOGRAPHY 107
Chapter 5: Know Your Technical Environment 108
OVERVIEW 108
WHY DOES A BUSINESS ANALYST NEED TO UNDERSTAND THE TECHNICAL ENVIRONMENT? 109
Understand Technology, But Don’t Talk Like a Technologist 110
WHAT DOES A BUSINESS ANALYST NEED TO KNOW ABOUT TECHNOLOGY? 111
Software Development/Programming Terminology 111
Software Development Methodologies 112
Technical Architecture 119
Operating Systems 120
Computer Networking 121
Data Management 121
Software Usability/Human Interface Design 124
Software Testing 124
WORKING WITH IT 129
Communicating with Developers 129
When to Get IT Involved in a Project 130
IT Corporate Culture 131
SUMMARY OF KEY POINTS 131
Bibliography 131
Chapter 6: Know Your Analysis Techniques 133
OVERVIEW 133
CATEGORIZING AND PRESENTING REQUIREMENTS 134
Collecting and Managing Requirements 134
What Is a Requirement? 134
Categorizing Requirements 135
Developing a System for Organizing Requirements 136
IIBA BABOK Categories 137
A Recommended Categorization System 138
CORE REQUIREMENTS COMPONENTS 140
Overview of Core Requirements Components 141
Core Requirements Component: Entities (Data) 142
Core Requirements Component: Attributes (Data) 143
Core Requirements Component: Processes (Use Cases) 146
Core Requirements Component: External Agents (Actors) 146
Core Requirements Component: Business Rules 147
ANALYSIS TECHNIQUES AND PRESENTATION FORMATS 148
Glossary 149
Workflow Diagrams 149
Entity Relationship Diagramming 151
Business Process Modeling with the Decomposition Diagram 152
Use Case Diagram 154
Use Case Descriptions 154
Prototypes/Simulations 156
Other Techniques 158
Choosing the Appropriate Techniques 162
Choosing an Approach 163
AS IS VS. TO BE ANALYSIS 166
PACKAGING REQUIREMENTS 169
How Formally Should Requirements Be Documented? 169
What Is a Requirements Package? 170
Request for Proposal Requirements Package 171
Characteristics of Excellent Requirements 172
Getting Sign-Off 173
Requirements Tools, Repositories, and Management 173
SUMMARY OF KEY POINTS 174
BIBLIOGRAPHY 174
Chapter 7: Increase Your Value 176
OVERVIEW 176
BUILD YOUR FOUNDATION 176
Skill: Get Started 176
Skill: Think Analytically 177
Skill: Note Taking 178
Technique: Brainstorming 178
Skill: Work with Complex Details 179
TIME MANAGEMENT 180
Skill: Understand the Nature of Project Work 180
Skill: Work on the Most Important Work First (Prioritize) 181
Technique: Understand the 80-20 Rule 182
Technique: Timeboxing 182
BUILD YOUR RELATIONSHIPS AND COMMUNICATION SKILLS 183
Skill: Build Strong Relationships 183
Skill: Ask the Right Questions 183
Skill: Listen Actively 185
Skill: Write Effectively 187
Skill: Make Excellent Presentations 187
Skill: Facilitate and Build Consensus 188
Skill: Conduct Effective Meetings 189
Skill: Conduct Requirements Reviews 191
KEEP LEARNING NEW ANALYSIS TECHNIQUES 195
Technique: Avoid Analysis Paralysis! 195
Technique: Root Cause Analysis 196
Skill: Intelligent Disobedience 199
CONTINUALLY IMPROVE YOUR SKILLS 200
Skill: Make Recommendations for Solutions 200
Skill: Be Able to Accept Constructive Criticism 203
Skill: Recognize and Act on Your Weaknesses 203
Technique: Lessons Learned 204
BUSINESS ANALYSIS PLANNING 204
Technique: Map the Project 204
Examples of Mapped Projects 206
Skill: Plan Your Work 206
Technique: Assess Business Impact 207
Technique: Conduct Stakeholder Analysis 209
Technique: Plan Your Communications 209
Skill: Choose Appropriate Requirements Deliverables 212
Skill: Develop a Business Analysis Task List 213
Skill: Estimate Your Time 214
SUMMARY OF KEY POINTS 214
Bibliography 215
List of Figures 216
Chapter 1: Possess a Clear Understanding of Business Analysis 216
Chapter 2: Know Your Audience 216
Chapter 3: Know Your Project 216
Chapter 4: Know Your Business Environment 216
Chapter 5: Know Your Technical Environment 216
Chapter 6: Know Your Analysis Techniques 217
Chapter 7: Increase Your Value 217
List of Tables 218
Chapter 1: Possess a Clear Understanding of Business Analysis 218
Chapter 3: Know Your Project 218
Chapter 4: Know Your Business Environment 218
Chapter 5: Know Your Technical Environment 218
Chapter 6: Know Your Analysis Techniques 218
Chapter 7: Increase Your Value 219
Foreword
I became a business analyst almost by accident. When I graduated from university, I went out into the workforce with a vague plan to find work as a technical writer. Unfortunately, my inexperience with software development derailed that plan, and I ended up working at a management consulting firm. I started by doing desktop publishing work, then ended up rewriting and eventually just writing the reports the firm did for its clients. When I left, I expected to find work as a consultant or project manager—but I lacked the credentials for those positions. Instead, I got offered a job as a business analyst at the mortgage division of a major bank. I took that job and found myself having to figure out what a business analyst did.
It turned out I wasn’t the only one who had that problem. Most of my co-workers had been pulled into the job from other roles in the business and had no formal background in the profession either. The bank had put the fate of a $20 million project in the hands of a bunch of people who had no real training in the role they were supposed to execute, and in my case in the hands of someone who didn’t understand the business either! Somehow, we muddled through, and the project went live. In fact, it’s still in use as I write this, a decade later, although at least one attempt to replace it has failed.
Several years later, I got involved as a volunteer with the International Institute of Business Analysis (IIBA™), a professional association of business analysts. The IIBA was formed with the goal of helping to define the business analysis profession and develop a certification program so that people coming into the profession, like myself and my colleagues, would have somewhere to go to find out what the job actually entailed.
However, in order to do that, the IIBA needed some people to figure out what business analysis actually is. One of the reasons my co-workers and I had had so much trouble figuring out what was expected of us when we first became business analysts was that nobody agreed on what exactly a business analyst does or what business analysis is. Pretty much everybody agreed that requirements were an important part of the picture, but that was about all they agreed on. Some viewed it as a junior project manager, others as a developer with an understanding of the business, and still others as a tester. The IIBA needed to reconcile all of those conflicting views before it would be possible to achieve its other goals, and so the Body of Knowledge Committee was formed, with Barbara and me as two of its earliest members.
In the four years since that group of people first met, we’ve come a long way. We’ve seen business analysis emerge from the shadow of project management, development, and testing and become accepted as a discipline in its own right. We’ve seen business analysts and their employers learn that business analysis is the critical link between business strategy and the implementation of new policies, processes, and information systems.
Barb’s place in the development of our profession is secure, as she led the creation and development of two knowledge areas in both version 1.6 and version 2 of The Guide to the Business Analysis Body of Knowledge®. But as version 2 of the BABOK ® nears completion (at the time I write these words, we are finishing the public and practitioner reviews), we can see that there’s still a lot more to learn. In Seven Steps to Mastering Business Analysis, Barb has gone beyond what we discuss in the BABOK to address the real challenges business analysts face in the workplace.
There are lots of books out there that can tell you how to write a use case, how to develop a process diagram, how to facilitate sessions with your stakeholders, and how to take all of that information and craft a requirements document. Certainly, those are skills that every business analyst needs to master. However, most of those books are written with the implicit premise that business analysts are working in a vacuum. They pretend that every business analysis effort starts with a clean slate—that you can walk into a room with your stakeholders and sketch a bright new world on your white board, with no concern for what came before.
The reality is, of course, very different. Seven Steps to Mastering Business Analysis recognizes that a business analyst has to work in a context. We have to work effectively as part of a team, understanding the roles and needs of each person involved in making a change happen. The project isn’t something that we do because it seemed interesting— it’s being done because we are trying to achieve certain business goals, and unless those goals are achieved, the project may not be worth doing. The project itself will change how the business works on a day-to-day basis and has to be implemented within a technical infrastructure that is already in place.
When we walk into that room with our stakeholders, even at the beginning of a project, many of the most important decisions have already been made. That’s the reality of a business analyst’s work. In order to master business analysis, you need to understand those decisions, understand the context in which you’re working, and help your stakeholders to find the solutions that will be most effective in that context.
Those analysis techniques that most other books spend all of their space on? Well, they’re in here, but they are discussed only after looking at the needs of the stakeholders, the project, and the business and technical environment. And that’s the way it should be, because the fine points of a diagramming notation are much less important than understanding the people, the goals of your project, and the business environment in which it takes place. If a solution isn’t right for a business, it doesn’t matter how well drawn the pictures are.
When I walked on to that project ten years ago, I didn’t know what my job was or what I was supposed to do there. I, and the other business analysts, had to figure it out as we went along. If we’d had access to Seven Steps to Mastering Business Analysis back then, we’d have had a much easier time of it. I’m sorry it wasn’t available to us back then, but I’m glad that business analysts today have the opportunity to benefit from Barb’s expertise!
Kevin Brennan, CBAP Vice President, Body of Knowledge International Institute of Business Analysis
ABOUT THE AUTHOR
Barbara
Carkenord, President, B2T Training, has over 25 years of
experience in business analysis. She earned an MBA from the
University of Michigan and is a Certified Business Analysis
Professional™
(CBAP®). She began her career in the information technology area as
a programmer, systems analyst, business analyst, and project manager.
Ms. Carkenord is a frequent speaker at industry conferences and has
authored many articles and white papers on business analysis. She is
the main editor and contributor of the bridge, B2T Training’s
business analysis magazine. Actively involved in the IIBA and a core
team member of the IIBA BABOK creation committee, she is regarded as
a thought leader in the industry and is highly respected by her peers
and competitors. She has been instrumental in the recognition and
growth of the profession.
Ms. Carkenord possesses detailed knowledge and experience in many structured approaches and methodologies. She is the primary writer of B2T Training course materials, which bring together proven techniques with real-world experience. Her areas of expertise include business analysis, high-level design, quality assurance, and project management. Her experience covers many industries, including insurance, banking, and manufacturing. She conducts formal and informal training sessions and consistently receives excellent student evaluations.
ACKNOWLEDGMENTS
Writing a book is not a solitary activity. Yes, I spent many hours alone drafting and revising, but this book would never have been completed if not for the dedicated work and encouragement of my team at B2T Training. Martha Scott, our Director of Marketing, diligently contacted publishers, working to make sure that we selected an organization that believed in business analysis with the same passion that we do. Angie Perris, our VP of everything, was my main subject matter expert for this project. Angie’s extensive business analysis, project management, and software development experience, along with her passion for research and learning, provided me with the support and feedback that I needed to make this book a useful resource for business analysis professionals. Dennis Perkins, our Director of Course Development, produced all of the graphics in the book with infinite patience. His attention to detail and commitment to excellence show through in this work, just as it does in our course curriculum. Thanks to Ian King and Jonathan “Kupe” Kupersmith for their time reviewing and their helpful suggestions.
Finally, I am most indebted to my business partner, our CEO, Tina Joseph. This book is just one of the ways that Tina has shown her commitment to furthering the profession of business analysis. Her work in helping to establish the IIBA and its local chapters has resulted in a strong organizational foundation upon which the profession will be built.
On a personal note, I would like to thank my friend Dolores Zabroske, whose constant support and confidence in my abilities have seen me through many challenges. Her love of books and love of life are a wonderful inspiration to me.
At J. Ross Publishing we are committed to providing today’s professional with practical, hands-on tools that enhance the learning experience and give readers an opportunity to apply what they have learned. That is why we offer free ancillary materials available for download on this book and all participating Web Added Value™ publications. These online resources may include interactive versions of material that appears in the book or supplemental templates, worksheets, models, plans, case studies, proposals, spreadsheets and assessment tools, among other things. Whenever you see the WAV™ symbol in any of our publications, it means bonus materials accompany the book and are available from the Web Added Value Download Resource Center at www.jrosspub.com.
Downloads available for Seven Steps to Mastering Business Analysis consist of business analysis white papers and business analysis planning templates that can be customized to fit each organization’s needs.