Mastering

Business Analysis
Standard Practices
Seven Steps to the Next Level
of Competency

Kelley Bruns, CBAP, PMP, PMI-PBA

Billie Johnson, CBAP, PMI-PBA, CSM
 Titles in the
Business Analysis Professional Development Series
include:

Successful Business Analysis Consulting:

Strategies and Tips for Going It Alone
by Karl Wiegers

Mastering Business Analysis Standard Practices:

Seven Steps to the Next Level of Competency
by Kelley Bruns and Billie Johnson

Mastering Business Analysis Standard Practices Workbook

by Kelley Bruns and Billie Johnson

Seven Steps to Mastering Business Analysis, 2nd Edition

by Jamie Champagne

Mastering Business Analysis Versatility:

Seven Steps to Develop Advanced Competencies and Capabilities
by Gina Schmidt

Agile Business Analysis: Enabling Continuous Improvement

of Requirements, Project Scope, and Agile Project Results
by Kevin Aguanno and Ori Schibi
Copyright © 2019 by J. Ross Publishing

ISBN-13: 978-1-60427-138-6

Printed and bound in the U.S.A. Printed on acid-free paper.

10 9 8 7 6 5 4 3 2 1

For this book’s Library of Congress Cataloging-in-Publication Data, please visit the WAV™ section
of our website at www.jrosspub.com/wav.

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 valid-
ity of all materials or for the consequences of their use.
IIBA, the IIBA logo, BABOK ® Guide, and Business Analysis Body of Knowledge are registered trade-
marks owned by International Institute of Business Analysis. CBAP and CCBA are registered certifica-
tion marks owned by International Institute of Business Analysis. PMI, the PMI logo, PMP, PMI-PBA, and
Pulse of the Profession® are all trademarks of Project Management Institute.
All rights reserved. Neither this publication nor any part thereof may be reproduced, stored in a re-
trieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, record-
ing 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., 300 S. Pine Island Rd., Suite 305, Plantation, FL 33324.

Phone: (954) 727-9333

Fax: (561) 892-0700
Web: www.jrosspub.com
 CONTENTS

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
WAV™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

CHAPTER 1—Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
What Is Business Analysis? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Who Does Business Analysis? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
What Qualities Do BAs Possess? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Organizational Structures and the BA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
BA Career Progression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Becoming a Trusted Advisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Business Analysis Competencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Core Concept Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Underlying BA Competencies and Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Business Analysis Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
The BI Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
The BPM Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
The IT Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
The Business Architecture Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
The Agile Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Key Business Analysis Terms, Concepts, and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
What Is a Requirement Versus Design Versus Business Analysis Information? . . . . . . . . . . . . . . . . . . 41
What Is a Project Versus Program Versus Initiative Versus Operation? . . . . . . . . . . . . . . . . . . . . . . . . . 48
What Is a System Versus a Solution Versus a Process Versus an Application
Versus a Software System? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
What Are Stakeholders Versus Actors Versus Users? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
What Are Enterprise Environmental Factors Versus Organizational Process Assets? . . . . . . . . . . . . . 52
Business Analysis Center of Excellence and Business Analysis Community of Practice . . . . . . . . . . . . . . 53

v
vi Mastering Business Analysis Standard Practices

Hone Your Business Analysis Information Elaboration Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Business Analysis Journey Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Summary of Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

CHAPTER 2—Step 1: Understand Your Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Types of Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Domain Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Solution Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Business Analysts and Project Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Product Owners and Scrum Masters/Agile Project Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Develop Stakeholder Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Understand Stakeholder Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Understand Stakeholder Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Understand Stakeholder Attitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Understand Stakeholder Influence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Understand Stakeholder Success Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Understand How Stakeholders Can Be Engaged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Balance Your Stakeholders’ Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Understand the Political Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Define Strategy for Navigating the Organizational Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Trust: It’s the Game Changer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Detecting Mistrust or Distrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Understand the Impact of Trust on Your Business Analysis Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Ongoing Stakeholder Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Capability Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Organizational Modeling (Organizational Charts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Stakeholder List, Map, or Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Summary of Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Chapter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

CHAPTER 3—Step 2: Understand the Business Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Understand the Enterprise Architectural Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Organizational Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Organizational Culture and Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Organizational Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Organizational Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Organizational Readiness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
EA Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Understand the Organization’s Business Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
 Contents vii

Frequently Identified Business Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Customer Satisfaction/Customer Impact Business Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Currency Business Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Compliance Business Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Market Position Business Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Needs Analysis/Needs Assessment Business Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Situation Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Feasibility Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Understand the Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Balanced Scorecard (BSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Benchmarking and Market Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Business Capability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Business Model Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Business Motivation Model (BMM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Business Value Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Decision Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Document Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Financial Analysis/Valuation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Project Portfolio Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Root Cause Analysis (RCA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
SWOT Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Summary of Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Chapter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

CHAPTER 4—Step 3: Plan the Business Analysis Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Iterative Nature of Elicitation, Collaboration, and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Where to Begin Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Plan the Business Analysis Work Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Elicitation and Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Scope Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Solution Requirements Analysis and Design Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Solution Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Scope Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Justify the Business Analysis Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Business Analysis Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Risk Analysis and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
viii Mastering Business Analysis Standard Practices

Summary of Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Chapter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

CHAPTER 5—Step 4: Set Initiative Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

What Is Scope? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Focus on Why First, before What . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Develop Success Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Now What?—Chunkify the Initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
At the Highest Level What . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
The Mid-Level What . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Solution Stakeholder Impact and Scope Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Gain Consensus on Scope Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Brainstorming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Business Process Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Business Value Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Collaborative Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Concept Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Customer Journey Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Focus Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Functional Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
House of Quality and Voice of Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Input, Guide, Output, Enablers (IGOE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Kaizen Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Kano Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Mind Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Process Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Purpose Alignment Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Scope Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Story Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Survey or Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Planning and Facilitated Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Summary of Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Chapter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

CHAPTER 6—Step 5: Develop Solution Requirements and Design Definition . . . . . . . . . . . . . . . . 245

Decompose Scope Definition into Effective Solution Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Elicitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
 Contents ix

Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Decompose Solution Requirements into Effective Design Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Doneness: How Do I Know When I’m Done? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Acceptance and Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Business Rules Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Data Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Data Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Data Flow Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
State Modeling (State Table/State Diagram) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Interface Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Lightweight Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Nonfunctional Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Prototyping (Storyboarding, Wireframes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Real Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Roles and Permissions Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Story Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Use Cases and Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Summary of Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Chapter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

CHAPTER 7—Step 6: Scope Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Verify Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Peer Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Inspections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Validate Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Recommend Solution(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Monitor Requirements and Design Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Tracing Requirements and Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Maintaining Requirements and Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Prioritizing Requirements and Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Monitoring Requirements and Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Scope Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Backlog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Change Control Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
x Mastering Business Analysis Standard Practices

Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

Item Tracking/Issue Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
RCMS and VCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Summary of Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Chapter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

CHAPTER 8—Step 7: Evaluate the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Evaluate Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Recommend Actions to Increase Solution Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Support Implementation SMEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Support Testers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Assess Organizational Readiness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Develop Transition Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Measure Solution Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Analyze Performance Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Collect Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Analyze and Communicate Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Definition of Done (DoD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Failure Mode and Effect Analysis (FMEA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Theory of Constraints (TOC) Thinking Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Specification by Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Lessons Learned/Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Metrics and Key Performance Indicators (KPIs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Product Portfolio Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Relative Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Vendor Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Summary of Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Chapter References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
 PREFACE

Why this book now?

You may be asking yourself questions like:
• “Another book on business analysis?”
• “In a world of ever-increasing change and mounds of information, is this book worth my time?”
Here is what makes this book different from other books on business analysis:
• Addresses the expansion of business analysis:
◽◽Levels of business analysis—many organizations are establishing business analysis as a rec-
ognized profession that can be utilized to enhance the organization’s success. In order to pro-
vide an environment that supports retention of business analysis practitioners, organizations
are providing a multi-level business analysis career path. This book will address work done
at both tactical and strategic levels.
◽◽ Expansion of problem/opportunity perspectives—because of the wicked (more than com-
plex) problems or the novelty of opportunities that organizations encounter in today’s mar-
ket, business analysis practitioners are expected to broaden their perspective of the initiative
space. This book will help fill this gap that the business analysis practitioner is seeking.
• Addresses collaboration points with project management—this book provides a guide to doing
business analysis, not a guide to doing project management. Certainly, there are other books about
each of these subjects; however, this book will note the intersection points between the business
analysis practitioner and the project management practitioner. Successful solutions result when
these two roles work together.
• Addresses collaboration points with solution providers—we find the support that business analysis
practitioners provide to solution providers is lacking in most business analysis books.
• Provides a structured approach in the form of a process—there is no silver bullet or any one way to
perform business analysis; however, this book provides a step-by-step approach that any business
analysis practitioner could follow, rather than having to piece the process together for themselves.
Granted, this book provides more breadth than depth into some topics, but your appetite can be
quenched with further exploration on individual topics.

xi
xii Mastering Business Analysis Standard Practices

• Provides a way to cement your learning and provide you with the confidence to put the process
into action. The supplemental Mastering Business Analysis Standard Practices Workbook is avail-
able for purchase, complete with exercises for a case study project in which you can practice what
you read.

SCOPE OF THE BOOK

This book is designed to represent good standard practices for performing business analysis work across
seven steps, five perspectives, and 74 techniques. However, on any project there is never enough time to do
everything related to business analysis so it is beneficial to know common accepted practices. The intent is
to deliver the breadth of business analysis. The depth or deep dives of business analysis knowledge areas,
domains, techniques, perspectives, tasks, processes, etc., are out of scope for this book. The primary focus
is on the intricacies for the role and work that the business analysis practitioner contributes on initiatives.
It will help the relatively new or junior business analyst develop and master the next or intermediate level
of capability and competency in business analysis. For those looking for deeper dives on business analysis,
this book serves as an appetizer to entice the reader to learn more, thereby advancing their career and role
to a more senior level.

FOUR KINDS OF READERS

This book appeals to people who perform business analysis work, use business analysis deliverables,
review or approve business analysis deliverables, and manage or mentor business analysis practitioners.
• Perform business analysis: whether you are new to business analysis, a seasoned business analysis
practitioner, or somewhere in between the two, this book will provide a roadmap journey to
guide you in your work. If you’re relatively new to business analysis, it will familiarize you with
effective business analysis practices and if you’re on the seasoned end of the business analysis
experience spectrum, it will refresh your knowledge and layer your learning.
• Use business analysis deliverables: when you are a consumer of business analysis work and deliv-
erables, it is extremely beneficial to know what to expect. If you are a solution provider, this book
will help you comprehend business analysis deliverables to create meaningful dialogue with the
business analysis practitioner.
• Review or approve business analysis deliverables: whether you are the person who reviews, verifies,
or validates the business analysis deliverables or you’re the person who ultimately makes the
final decision about business analysis deliverables, it’s critical that you have complete information
to make effective decisions. These business analysis deliverables will make or break the initiative as
they drive progress, financial decisions, and ensure integrity. This book will help you confirm that
the business analysis deliverables match the needs for the initiative.
• Manage or mentor business analysis practitioners: many managers of business analysis practi-
tioners are unsure of how to measure or evaluate the work and deliverables that a business anal-
ysis practitioner produces. Mentors of business analysis practitioners may be unsure of how to
 Preface xiii

guide new or developing business analysis practitioners. Part of this is due to misunderstandings
of the role of the business analysis practitioner and part of it is due to the expansion of the role.
This book will help you comprehend the role, responsibilities, and deliverables that ensure busi-
ness analysis success.

STRUCTURE OF THE BOOK

This book is divided into the following chapters:
1. Introduction
This chapter sets the stage for business analysis terminology, roles and responsibilities, the per-
spectives of business analysis, and business analysis competencies. Before embarking on the busi-
ness analysis process journey, a depiction of the roadmap for the business analysis process will
guide you through the rest of the book.
2. Step 1: Understand Your Stakeholders
This chapter provides guidance on stakeholder identification and then goes deeper into stake-
holder analysis to ensure a thorough understanding before planning or engaging stakeholder
involvement.
3. Step 2: Understand the Business Context
This chapter provides guidance for understanding the organization as a whole, performing situa-
tional needs analysis, and preparing situational justification for decision makers.
4. Step 3: Plan the Business Analysis Work
This chapter provides guidance on the areas to be planned for, not only the business analysis work
effort, but also developing a business analysis communication plan and a business analysis infor-
mation management plan.
5. Step 4: Set Initiative Scope
This chapter provides guidance on setting the initiative up for success by developing a clear and
concise scope definition boundary.
6. Step 5: Develop Solution Requirements and Design Definition
This chapter provides guidance on developing the business analysis information that directs the
building of the solution to meet stakeholder needs.
7. Step 6: Scope Management
This chapter provides guidance on maintaining agreement on scope and controlling scope in an
ever-changing environment.
8. Step 7: Evaluate the Solution
This chapter provides guidance on the business analysis practitioner’s role as the solution is being
built and throughout the solution’s existence to ensure solution value continues to be met.
9. Glossary
This book provides a glossary of terms that were likely defined in a chapter; however, this provides
the reader a quick reference.
xiv Mastering Business Analysis Standard Practices

HOW TO USE THIS BOOK

Some chefs prefer to follow a recipe in sequential order exactly as it is written. Others may need to begin in
the middle because some of the recipe was prepared and handed off to the chef by a sous chef. Additional
chefs may realize that they need to adapt the recipe to the changing circumstances and tastes of their cli-
entele. Using this book is much like a recipe. You can read through it sequentially from cover to cover. You
can pick it up in the middle of a step because a strategic business analysis practitioner hands off business
analysis information for you to use tactically. Or, you can use the book to enhance your existing business
analysis processes—what we like to call the spice! To enhance your reading experience, the book includes
downloads for you to use for your business analysis work. See the Web Added Value (WAV™) information
on page xix for details.

SEVEN SUGGESTIONS FOR GETTING THE MOST FROM THIS BOOK

We have seven suggestions to help you make the most of your reading experience:
1. Perform your own gap analysis: begin with your current state of business analysis processes and
identify what you want the future state to look like. Honestly assess your business analysis work
and determine where there are gaps and opportunities.
2. Plan where to start: begin with the introduction and then review the chapter overviews in the
preface to determine which step is the logical starting point based on your gap analysis.
3. Read appropriate steps: once you have planned which steps are applicable to you, read each chapter
to comprehend the information.
4. Purchase the supplemental Mastering Business Analysis Standard Practices Workbook: for business
analysis practitioners, the best way to digest the seven steps is to use the accompanying Mastering
Business Analysis Standard Practices Workbook. This workbook will help you practice key business
analysis concepts as you read.
5. Put together an action plan: for each step that you read, put together an action plan on how you
will implement applicable tools, techniques, or competencies by planning:
a. What actions will you take?
b. When will you take action?
c. How will you take action?
d. Whose support will you need to take action?
6. Implement appropriate steps: after completing your plan, it is time to execute. A plan with no ac-
tion is just a dream. This is where the rubber meets the road. If you want to improve, you need to
act on what you will do differently.
7. Evaluate your progress: after you implement your action plan, determine what worked well, what
didn’t work well, and what could be done differently. Perform your own lessons learned or ret-
rospective on your performance. Involving your manager, project managers or Scrum Masters,
solution providers, and sponsors in this step will help your career soar.
 ACKNOWLEDGMENTS

We are very thankful to those who have contributed to our discipline, so that we could have this oppor-
tunity to continue evolving the business analysis profession by writing this book. These practitioners,
authors, coaches, and mentors inspired us to provide our experiences and knowledge. We are thankful to
assist in continuing to advance our profession.

KELLEY BRUNS
I am grateful that Billie Johnson—my coauthor and friend—was willing to jump headfirst into this project
when I first called her with the idea of writing a book. We went through a roller coaster of emotions on this
initiative. Her strength and wisdom helped keep me going—even when I felt like stopping.
Thank you to my husband, Chad, who helped me to have more time to write by removing barriers.
He was even supportive when this endeavor took away from our adventure time. He made sacrifices to
be quiet so I could concentrate and he motivated me to persevere. I know it wasn’t easy for him. I greatly
appreciate the encouragement he provided along the way and I love him for that.
I also want to acknowledge Jan Scharingson, my high school English teacher, for creating a spark in me
to read and write. I enjoyed the novels she had me read, but I often struggled to write effectively, and Jan
patiently helped me to steadily improve.
I am grateful to the workplaces that helped frame me into the practitioner I have become and continue
evolving into throughout my business analysis journey. Many of my greatest struggles became the mo-
ments when I learned the most. I cherish the experiences and the people I worked with.
Finally, I want to thank my family. My mom, Betty Griffith, and Jack Lint provided me with love and
much-needed support that I greatly appreciate. I would like to dedicate my work on this book to my mom
and my dad, Carson Griffith. When I was a little girl, my mom suggested that I should write a book
someday—and she persisted through the years. My dad’s lifelong encouragement and positive enthusiasm
to follow my dreams (even when he didn’t agree) inspired me to fulfill this goal and many others in my
life. For everything, thank you!

xv
xvi Mastering Business Analysis Standard Practices

BILLIE JOHNSON
I am passionate about business analysis—the doing and the facilitation of eager business analysis profes-
sionals to further their toolkits and ultimately save the world with better requirements—but, write a book?
My response to my coauthor, Kelley Bruns, when she approached me with this opportunity was, “I’m not
sure, let me think about it.” This venture involved flexibility in order to keep up with our day jobs, travel
for our writing summit, and remote collaboration. Now that our journey is complete, I truly thank you,
Kelley, for the inclusion and encouragement to share these business analysis journey steps, tools, and
techniques with our readers.
My business analysis career path began at ACS in the early ’90s and I want to recognize my band of
brothers who supported the on-the-job type of business analysis work. This group included our leader,
Lee Harper, programmers (as we called them then), Charley Walter (gone too soon) and Ricky George,
and my fellow accountant (we did not realize we were performing business analysis), ByAnn Forte’.
Thanks for sparking the realization that we could not just make bad processes faster, but first analyze
processes for improvement. We were ahead of our time with the use of personas and use cases to achieve
user-centric solutions.
Sapient Consulting afforded me the opportunity to hone my business analysis skills on multi-year proj-
ects at Harvard University and Freddie Mac that foundationally changed the way the organizations con-
ducted themselves. Thanks to Shannon Mukundan for recognizing my potential and encouraging support
as the dream project manager for all of us on that Harvard team. On the Freddie Mac project and as I
transitioned to another five years as a business architect employed by Freddie Mac, there were so many
influencers, but I would especially like to recognize a few of them. Sue Ritchey—thanks for the structure
and support of the business analysis work to help ensure that we had viable solutions. Roger Belveal, Ex-
perience Design Strategist Extraordinaire—I thank you for your continued support and feedback through
the years for my course development and this book. Bill Farmer—thanks for being supportive of the
business analysis activities and time that is required to reach that good enough point as you balanced the
project management side of the coin.
Over the last ten years, I have had the pleasure of developing and facilitating business analysis seminars
and training sessions. I want to thank the participants who shared their experiences that I could learn
from, and for the pats on the back as well—which we all need—assuring me of a job well done. I have
been lucky to work with some great organizations, of which there are too many to mention. I do want to
recognize Carrie Harris at Walmart for her undying support through the years at her organization to offer
courses and certificates to the hundreds of business analysts in her organization. Through Todd Britton’s
leadership and support at New York State and the International Institute of Business Analysis (IIBA®)
Albany Chapter, I have been trusted to provide business analysis guidance for the business analysts there,
and I thank him. With over 6,000 students, there are certainly too many to mention, but know that it
warms my heart to hear from you when you have reached out with questions or share your successes.
Recently, I was afforded the opportunity to work on a global multi-year project for strategic scope
alignment. Thanks go out to Mary Jensen for providing support of the global workshops conducted in or-
der to understand the users’ needs and expectations. Getting my hands in the sausage-making invigorates
 Acknowledgments xvii

my business analysis passion. I highly recommend instructors occasionally getting out of the classroom
for an on-the-ground perspective.
Personally, I want to dedicate this book to my husband, Craig, since he listened for hours to content
for which he does not share my passion, yet still supports my crazy endeavors. My family who asked,
“How’s the book coming?” spurred me to the finish line. I appreciate all of my friends from the gym whose
support I rely on to keep me sane. Thanks to all for providing me the canvas to paint the difference that
business analysis can make for developing solutions that make life better.
 ABOUT THE AUTHORS

KELLEY BRUNS
Kelley Bruns is a veteran corporate trainer, coach, mentor, training man-
ager, course developer, and author with more than 25 years of experi-
ence helping enterprise project teams solve problems. She holds a master’s
degree in adult education with a concentration in training and develop-
ment from Drake University. Kelley has facilitated and consulted with
participants and clients throughout the world including corporations,
government, and nonprofit entities. She is a former vice president of busi-
ness analyst training at ASPE, and is a leading expert in business analysis
and various approaches to project management and product develop-
ment. Kelley is an International Institute of Business Analysis (IIBA®)
Certified Business Analysis Professional (CBAP®), Project Management
Institute certified Professional in Business Analysis (PMI-PBA)®, Proj-
ect Management Professional (PMP)®, and Agile Certified Practitioner
(PMI-ACP)®. She is also a Scrum Alliance accredited Certified Scrum
Master (CSM) and International Consortium for Agile accredited ICP,
ICP-BVA, and ICP-APM.
Kelley has dedicated her career to helping people transfer knowledge, skills, and abilities in both pro-
fessional and personal settings in order to provide a strong return on their investment. Ms. Bruns was
actively involved in the IIBA Enhanced Certification Redesign and the Endorsed Education Provider
Advisory Group. She is uniquely talented at helping others learn best practices without having to learn the
hard way. In her spare time, Kelley can be found hiking, whitewater kayaking, camping, and snowshoeing
with her husband and dogs in the mountains near her home.

xviii
 About the Authors xix

BILLIE JOHNSON
Billie Johnson is a leading project management and business analysis
expert and practicing professional who has been involved in establishing
business analysis direction, processes, and modeling for almost 30 years—
spanning financial, manufacturing, consulting, education, government,
retail, and mining industries. She was an early adopter of the Certified
Business Analysis Professional (CBAP®) certification, receiving her cer-
tification in May 2007; as well as achieving the Project Management
Institute Professional in Business Analysis (PMI-PBA)® certification as
soon as it was offered in July 2014. She is also a Certified Scrum Master
accredited by the Scrum Alliance. Billie was a reviewer team lead for the
IIBA Business Analysis Body of Knowledge (BABOK ® Guide) Version 3.
She periodically speaks at IIBA events, PMI events, and other professional
conferences. For the last ten years, she has been teaching and consulting
with large organizations and Fortune 500 companies. As a business anal-
ysis instructor, course developer, author, coach, and mentor, she enjoys
furthering the field of business analysis by touching those in the field with tools to face their unique prob-
lems and opportunities. In her spare time, Billie and her husband, Craig, enjoy building memories with
family and friends at their home on Lake Buchanan in Texas. Very special memories are the Grandmere
and Papa camps in the summer with the grandkids.
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 for Mastering Business Analysis Standard Practices include numerous templates and check-
lists for better performing business analysis work.
 1
INTRODUCTION

The purpose of this book is to provide guidance on mastering business analysis. First, as with any profes-
sion, there is a foundational understanding required prior to digesting guidelines for performing the work
of business analysis. This chapter is dedicated to providing that foundational information from the two
leading organizations on business analysis—the International Institute of Business Analysis (IIBA®) and
the Project Management Institute (PMI)—as well as some additional practical resources that are identified
throughout this book. The intent of this chapter is to help guide readers to understand the differences and
similarities between the IIBA and PMI that are related to understanding the profession of business analysis.

WHAT IS BUSINESS ANALYSIS?

Even though the business analysis profession has only recently been recognized, the problems and oppor-
tunities surrounding it have been analyzed since the beginning of time. Consider the creation of the wheel;
it came about because there was a need to move materials that were too heavy to carry quickly. Wheels
on an axle allowed materials to be loaded on open containers and trucked to the needed location more
efficiently. This is the result of a business analysis effort.
Business analysis is defined by both the IIBA and PMI as a set of activities to enable change in an en-
terprise by defining needs and recommending solutions that deliver continuous value to stakeholders.
This short definition is packed with exciting and rewarding opportunities for both the business analyst
(BA) and the enterprise. There is a natural gut reaction to identify an obstacle and immediately go into
solution mode rather than trying to identify the underlying problem. Most folks have no trouble seeing
the solution—­it’s the problem that eludes them.
The value that enterprises reap by investing in business analysis can be summarized as:
• Solutions that meet stakeholder needs and provide business value due to more reliable, higher
quality requirements;
• Higher buy-in for the change by ensuring stakeholder engagement in the process;
• Much higher probability of projects being delivered on time, within scope, and within budget; and
• A reusable pattern on future change initiatives by building business analysis competency.
Research clearly indicates that enterprise projects are failing to deliver their intended business value. From
2012 through 2016, project success indicators have remained fairly constant. Research conducted by PMI
1
2 Mastering Business Analysis Standard Practices

Table 1.1 Project outcomes

Project Outcomes 2012 2016
Met original goals/business intent 64% 62%
Experienced scope creep 44% 45%
Deemed a failure 15% 16%
Completed within original budget 55% 53%
Completed on time 51% 49%
Failed project’s budget lost 34% 32%

summarizes these results in Table 1.1. How much does this mean in dollars and cents? An estimated 12%
of the money invested on projects is wasted due to poor project performance. According to a whitepaper
by PMI called Business Analysis: Leading Organizations to Better Outcomes, the second leading cause of
project failure is inaccurate requirements (39%), preceded only by changes in an organization’s priorities
(41%). Enterprises that have matured their business analysis practices are dramatically improving their
probability of project success.
The necessary enterprise solutions are increasingly more complex and interrelated, providing business
analysis professionals with an opportunity to engage stakeholders with multiple viewpoints in order to
drive solutions. These solutions likely require changes in process, technology, and organizational struc-
ture. The need for these business analysis professionals has been predicted to grow by double digits, spe-
cifically 13–30% over the coming decade (see the Business Analysis Perspectives section of this chapter
for more on this trend). Specifically, business intelligence (BI) skills are predicted as the highest need.
According to a recent PwC report that was supported by data from Burning Glass Technologies, the 2020
estimate calls for 2.7 million job postings in the analysis space that require professionals with deep ana-
lytical (BI) skills. Also, business analysis is a profession that has been defined by Harvard Business Review
as the sexiest job of the 21st century.
To keep current, the BA has the following sources:
• Business analysis professional organizations, guides to business analysis practices, and certifications:
◽◽ IIBA
$$ Guides to business analysis practices
◾◾ A Guide to the Business Analysis Body of Knowledge (BABOK ® Guide), v3

◾◾ Agile Extension to the BABOK ® Guide

◾◾ IIBA Global Business Analysis Core Standard

$$ Certifications
◾◾ Entry Certificate in Business Analysis™—recognizes individuals entering the field of

business analysis
◾◾ Entry Certificate in Business Analysis Plus™ (ECBA™+)—provides hands-on experi-

ence to grow knowledge into application for targeted skills

◾◾ Certification of Capability in Business Analysis™ (CCBA®)—recognizes BA profes-

sionals who have 2–3 years of experience

 Introduction 3

◾◾ Certified Business Analysis Professional ™ (CBAP ®)—recognizes BA professionals

who lead and have over 5 years of BA experience
◽◽ PMI
$$ Guides to business analysis practices
◾◾ The PMI Guide to Business Analysis

◾◾ Business Analysis for Practitioners—A Practice Guide

$$ Certification
◾◾ PMI Professional in Business Analysis (PMI-PBA)®—recognizes professionals who

have business analysis and project experience

◽◽ Association of Business Process Management (BPM) Professionals International
$$ Guides to business analysis practices
◾◾ Guide to the Business Process Management Body of Knowledge®

$$ Certifications
◾◾ Certified Business Process Associate®—recognizes broad-based BPM foundation-level

skills and understanding

◾◾ Certified Business Process Professional®—recognizes BPM professionals who have at

least 4 years of BPM experience

◾◾ Certified Business Process Leader™—recognizes a BPM mastery level competency

◽◽ Business Architecture Guild

$$ Guides to business analysis practices
◾◾ A Guide to the Business Architecture Body of Knowledge®

$$ Certification
◾◾ Certified Business Architect ®—recognizes proficiency in the field of business

architecture
As of the end of 2018, approximately 84% of the over 12,000 individuals holding the previously men-
tioned business analysis-related certifications are IIBA certifications. All of these certifications require
re-­certification, which provides BAs with a chance to update their skills by earning development units that
are recognized by certifying bodies. The IIBA conducts annual salary surveys for business analysis pro-
fessionals, and most business analysis professionals with a minimum of one certification typically receive
between 7–31% more in earnings than those without certification. Business analysis professionals with the
CBAP certification receive 16–38% more in salary. Of note, in India business analysis professionals with a
minimum of one certification receive 52% more in earnings. These statistics remind us that there is value
in certifications. Other ways BAs can keep their skills sharp include:
• Networking opportunities
◽◽Professional organization chapter events
◽◽Online professional networking sites with opportunities to join business analysis groups
• Business analysis training
◽◽ Live instructor-led training sessions (virtual or face-to-face)
◽◽ Webinars
4 Mastering Business Analysis Standard Practices

• Reference material
◽◽ Blog posts
◽◽ Whitepapers
◽◽ Business analysis books (like this one)

WHO DOES BUSINESS ANALYSIS?

The profession of business analysis has been experiencing an evolution in recent history. Not all enter-
prises define the business analysis role exactly the same way in their job descriptions due to differences in
size, orientation, organizational structure, departments, and culture.
Consideration and care must be exerted by enterprises to be clear about the roles, responsibilities,
job descriptions, and hiring practices of business analysis professionals to ensure the right fit. Business
analysis professionals may be referred to by many different titles as noted in Table 1.2. This table is not
intended to be an all-inclusive list of job titles and is meant to show the diversity of titles that perform
business analysis work. According to the 2017 Global Business Analysis Salary Survey, 83% of business
analysis professionals have the following titles: BA, Data Analyst, Product Analyst, Business Process An-
alyst, Business Systems Analyst, or Systems Analyst. The exciting news—business analysis is not just for
IT anymore due to broadening perspectives and different solution outcomes that are not always techno-
logically based. Going forward in this book, all those conducting business analysis work regardless of title
will be identified as BAs.
Support from all levels of an enterprise is essential in order for BAs to successfully perform their re-
sponsibilities. This support must include senior level personnel of an organization, as well as project
teams. BAs need the support of project managers and sponsors to remove roadblocks that will impede the
BA from communicating effectively with stakeholders since most BAs do not possess any formal authority
within the organizational hierarchy. According to the whitepaper by PMI called Business Analysis: Leading
Organizations to Better Outcomes, 91% of respondents from highly mature business analysis practices re-
ported that the role of the BA is valued by management, sponsors, and stakeholders, as compared to 53%
of respondents working for less mature organizations. However, according to a recent survey by PMI, only
18% of respondents rated their business analysis practice as highly mature.

Table 1.2 Titles for business analysis professionals

Job Titles for Business Analysis Professionals
Business Analyst Business Systems Analyst Operations Analyst Requirements Manager
Business Architect Data Analyst Process Analyst Solution Architect
Business Change Facilitator ERP Consultant Process Manager Solution Designer
Business Consultant Functional Architect Product Analyst Strategic Business Analyst
Business Process Analyst Hybrid Business Analyst Product Coordinator Strategy Consultant
Business Process Engineer Information Architect Product Manager Systems Analyst
Business Relationship Manager IT Analyst Product Owner Technical Consultant
Business Requirements Analyst IT Business Analyst Requirements Analyst User Experience Designer
Business Solutions Analyst Operational Analyst Requirements Engineer
 Introduction 5

WHAT QUALITIES DO BAs POSSESS?

There are some key developments that are helping the business analysis profession to evolve, including:
• Finding value in having business analysis performed before a project is initiated in order to help
properly define the problem or strategic opportunity
• Expanding the business analysis profession into specialized roles to cover the entire initiative
• Discovering that business analysis work delivers value beyond software solutions
• Tailoring of business analysis services based on unique project characteristics to provide more
value to the organization
• Using a hybrid role for practitioners who are performing both project management and business
analysis activities
While many roles in organizations are static, the BA role is one that will be continuously evolving. As
this happens, knowing what qualities are essential will help a BA to become more effective. The following
qualities are critical for success in business analysis:
• Big picture view versus detailed information: this involves the ability to be a strategic thinker in
order to provide the big picture for an initiative, while at the same time being able to pinpoint
details. On the spectrum of these two qualities, most people are gifted at one, but not both. Both
strategic thinking and detail-oriented thinking can be learned. In business analysis, start with the
strategy—the business requirements—and decompose to the stakeholder requirements, solution
requirements, and transition requirements.
• Change advocates: this includes people who will help the stakeholders and the organization tran-
sition from the current reality to the desired future state by minimizing negative impacts and in-
creasing positive outcomes in terms of value to the organization. Effective BAs assess the culture of
the enterprise to accept change and the readiness of the enterprise to adapt to the cultural changes
that will occur.
• Forward thinking: this type of person needs to look at not only the here and now (current state), but
also examine what needs will be required in the future, including potential growth opportunities.
This quality includes being able to differentiate between potential solutions that appear to meet
current stakeholder needs and one solution that has the potential to meet future needs.
• Inquisitiveness: This would include someone who is curious and will investigate both strategic op-
portunities and the root causes of problems. Being interested, asking the right questions, and dig-
ging deeper to solve problems are some of the inquisitive and investigative qualities that help a BA
to be effective.
• Multi-dimensionality: this would include people who exhibit knowledge of the particular perspec-
tive or domain that is being analyzed. The business analysis profession has expanded beyond IT.
This multi-dimensional quality also includes paying attention to scope regarding impacts, change,
risks, and stakeholder engagement.
• Open-mindedness: this would require a person to have an impartial approach when engaging stake-
holders and is a critical quality for business analysis. The way BAs ask questions can reveal biases
and close-mindedness. The best way to alleviate close-mindedness is to ask a variety of questions.
• Solution and answer seeker: this type of person will pursue answers to root causes, perform what-if
analysis, challenge assumptions, and recommend viable solutions to address business needs.
6 Mastering Business Analysis Standard Practices

The qualities identified here are intended to be used in combination with the competencies, knowledge,
and skills that are discussed later in this chapter. When hiring BAs, each enterprise needs to determine
which of the qualities, competencies, knowledge, and skills to consider for interview questions. Due to the
continuous evolution of the BA role, organizations must also provide training, mentoring, and coaching
on techniques and skills to enhance successful outcomes for the business.

ORGANIZATIONAL STRUCTURES AND THE BA

Just as there are differences in roles and responsibilities for BAs, there are also unique organizational
structures related to business analysis. By 2020, employers in the U.S. will need 876,000 business analysis
professionals according to the U.S. Bureau of Labor Statistics Employment Projections Program. Appro-
priate organizational structures to support those BAs and their career progression opportunities will
become critical in order for enterprises to retain the most effective BAs.
One of the more tricky questions in workplaces is determining where to put the BA on an organiza-
tional chart. Part of this conundrum is due to differing job specifications for BAs and hybrid roles. For
organizations that have functional BAs and technical BAs, it makes sense to have the business BAs report
to functional managers in their respective business units and have the technical BAs report to IT manag-
ers; however, not every workplace is this straightforward.
When organizations view the BA as a project role, they tend to place the BA in IT. One of the disadvan-
tages of placing the BA in IT is that the BA doesn’t become involved in the project until after the business
case is developed and the project is recognized. More mature workplaces are realizing the value of having
the BA involved in the creation of the business case because of the analysis skills that are needed to ex-
amine the problem or opportunity. Oftentimes, when a business unit has subject matter experts (SMEs)
perform strategy analysis or needs analysis, that person does not have the analysis skills necessary to
adequately determine the best solution. It is in these situations where the BA serves a balancing role with
the business SMEs—the BA provides an unbiased viewpoint to the situation the business is experiencing.
Having BAs report to a functional area is beneficial in ensuring early involvement of BAs in initia-
tives and projects. Less mature organizations have not yet recognized the value of early involvement of
the BA role in understanding business needs and helping drive toward a feasible solution. Organizations
that do realize this value are reaping the benefits of cost savings, efficiencies, and increased stakeholder
satisfaction.
Understanding different perspectives can also influence reporting structures for BAs. For example,
BAs in BI, agile, or IT often report to IT or information systems (IS) leadership; while BAs in enterprise
architecture and BPM report to functional leadership or the IT/IS department.
In the 2017 Global Business Analysis Salary Survey, 46% of business analysis professionals report to
the solution space (IT/project management), 34% report to a functional business area/product, and 20%
report to the center of excellence/expertise/project management office (PMO).
Regardless of where the BA resides on an organizational chart, it is critical that BAs:
• Have access to key stakeholders
• Build relationships with stakeholders
 Introduction 7

• Engage stakeholders throughout each project, program, portfolio, or initiative

• Lead stakeholders without formal authority
• Become a trusted advisor
Each organization needs to examine the overall strategy, vision, goals, business drivers, job descriptions,
and perspectives to determine the best fit for placement of the BA role in the organizational structure.

BA CAREER PROGRESSION
When selecting a career, many practitioners are not familiar with the BA role and where it comes from.
Surveys show that most BAs do not consciously seek out the role. In fact, we (the authors of this book)
just kind of fell into it. One of us came from an education and accounting background and the other came
from a strategic and process improvement background. It’s not important where you come from; it’s crit-
ical that you have the appropriate skills to effectively perform business analysis work. BAs can be formed
through any of the following backgrounds or combinations:
• Formal degree programs: example programs include business administration, business analysis,
business analytics, BI, computer science, data analytics, etc.
• IT or technical background: knowledge of specific systems and solutions
• Department, functional areas, or lines of business experience in the business domain: knowledge of
processes and systems used in specific areas
• Industry or specific trade experience: knowledge of history, trends, and competitive advantages
There are many paths that a practitioner can take to become a BA. BAs typically begin in either the busi-
ness domain or the technical domain. The type of perspective a BA will engage for an initiative also needs
to drive your career progression. Perspectives include the types of tasks and techniques that a BA needs to
use in order to successfully complete an initiative.
The size of an organization and the number of BAs employed at an enterprise also have a direct influ-
ence on career progression. There are enterprises that do not recognize any levels of business analysis (es-
pecially smaller enterprises) while others acknowledge three levels: entry-level, mid-level, and senior-level
(see Figure 1.1). Larger enterprises often recognize five levels: entry-level, junior, intermediate, senior, and
advanced (see Figure 1.2). The factors distinguishing the levels and types of BAs include competencies,
knowledge, standard of work, autonomy, complexity/scope of work, and perception of context. In the
2017 Global Business Analysis Salary Survey, 52–69% of respondents shared that their workplace supports
multiple business analysis levels for career path progression. The number of business analysis career levels
varies: one to three levels (52–61%), four to five levels (17–39%), and even more than six levels (8–22%).
The percentage variations are based on country breakdowns.
Larger organizations have the benefit of having peer BAs provide coaching and mentoring to rising BA
professionals. This guidance helps to shorten the learning curve to becoming an effective BA. When work-
ing at a smaller organization, the BA can get help from local chapters or networks of BAs. The Internet,
training organizations, and books also provide resources that support career progression.
8 Mastering Business Analysis Standard Practices

Advanced
Senior-level
Senior

Intermediate
Mid-level
Junior

Entry-level Entry

Figure 1.1 Business analyst career Figure 1.2 Business analyst career
progression—three levels progression—five levels

The IIBA Business Analysis Competency Model version 4.0 includes five levels of proficiency for BAs,
including:
1. General awareness: having basic awareness, skills, and knowledge of business analysis
2. Practical knowledge: following rules, guidelines, and prescribed ways of performing business anal-
ysis work
3. Skilled: owning and completing small initiatives and business analysis tasks
4. Expert: retaining skills, knowledge, and abilities to complete any type of business analysis effort,
coaching and mentoring others, becoming a value manager, and sharing proficiency throughout
the organization
5. Strategist: influencing and expanding business analysis practices, advancing business analysis, and
creating innovative solutions
When a BA lacks essential business analysis skill sets, the business analysis effort and the initiative will
suffer. When this occurs, it’s important to identify the root cause of the variance in BA skill sets. Once
the root cause is identified, then appropriate responses can be taken to assist in career alignment, career
development, coaching, mentoring, etc.
The IIBA Business Analysis Competency Model version 3.0 also recognizes three types of business
analysis job profiles:
• Generalist: a practitioner who may or may not have domain expertise and uses a variety of tech-
niques to complete various initiatives
• Specialist: a practitioner who has greater expertise and is able to solve complex business problems
using more focused techniques for an initiative
• Hybrid: a practitioner who has varying business analysis competency, as well as expertise in an-
other discipline
 Introduction 9

Many enterprises are incorporating the following hybrid roles:

• BA/project manager: reasons for this type of role are due to the overlap of requirements (product
and project), risks (product and project), stakeholder identification and analysis, communication
with stakeholders, and quality (product and project)
• BA/user experience: reasons for this type of role are due to the overlap of stakeholder requirements
with specific user interface requirements
• BA/product owner: reasons for this type of role are due to the overlap of identification of require-
ments via user stories and prioritizing the value of the user stories based on the needs of the
stakeholders—­both the BA and the product owner roles serve as a liaison to the stakeholders
• BA/Scrum Master: reasons for this type of role are due to the overlap of facilitating, negotiating,
solving problems, and coaching of all the stakeholders
• BA/tester: reasons for this type of role are due to the overlap of requirements engineering leading
to the creation of test plans and test scripts
• BA/developer: reasons for this type of role are due to the overlap of the same person translating the
why and what of requirements into how
In the 2017 Global Business Analysis Salary Survey, business analysis professionals reported that they
spend 46% of their time on core business analysis work with the remaining time spent on product owner,
data analytics, Scrum Master, or project management responsibilities. These statistics support the increas-
ing need for hybrid roles.
There are several more reasons for having hybrid practitioners in organizations today. Some of the
additional motives include:
• Generalist roles: organizations that are striving to be more agile often require practitioners to be
able to perform multiple roles to avoid bottlenecks on projects and initiatives.
• Lack of BAs: in many situations, BAs are assigned to multiple projects and operational responsi-
bilities. When this occurs, there can be a shortage of BAs in the workplace, which can result in
employees performing hybrid responsibilities to get projects and initiatives completed.
• No BA roles: there are organizations that do not recognize or even know that the role of a BA ex-
ists. While the title might not exist in an organization, the business analysis work still needs to be
completed. When an organization doesn’t acknowledge the BA role, needs assessment is very easy
to overlook.
• Revolving BAs: for organizations that hire contract BAs or use offshore BA resources, there is the
risk of losing the BA. This risk is due to projects and initiatives getting completed, budget cuts, or
even situations where BAs use the organization to gain knowledge and acquire better paying posi-
tions elsewhere. Organizations that follow this strategy need to consider the loss of knowledge that
exits the door when these BAs leave.
• Role misalignment: very few organizations have pure BA roles that support what the IIBA and PMI
describe in its literature. This isn’t necessarily bad; this is a reality. There are practitioners with the
title of BA who do not perform any business analysis responsibilities, and there are practitioners
who do not have the title of BA and yet they perform multiple business analysis tasks.
10 Mastering Business Analysis Standard Practices

There are unique advantages to hybrid roles, including:

• Better refined project scope and product scope
• Capability to help when resources are scarce
• Easy access to the roles being fulfilled (both for the practitioner and for the stakeholders), thus
saving time trying to find the person
• Enhanced change control processes
• Improved quality due to ownership of the product, service, or result
Utilizing hybrid roles for enterprises makes sense on small, less complex, and low-risk projects or initia-
tives. Smaller enterprises often capitalize on hybrid roles out of necessity. These organizations might not
have enough staff to fulfill an individual role for the initiative or project.
There are some unique disadvantages to hybrid roles, which include:
• Conflicting interests and biases related to the triple constraints of time, cost, and scope: a con-
straint is a factor that will limit or restrict a solution, solution option, process, project, initiative,
program, or portfolio.
• Conflicting roles and responsibilities: projects and initiatives benefit from the healthy collabora-
tion and friction that exists between the different people performing the roles
• Confusion regarding responsibility and accountability
• Ineffective knowledge transfer of lessons learned
• Lack of career development opportunities for employees on projects that want to learn how to
perform portions of the hybrid roles
• Transitioning the project or initiative into an operation—often the hybrid person becomes respon-
sible for maintaining the solution and cannot move on to new work
Hybrid roles are challenging during large, complicated, and high-risk projects or initiatives. When enter-
prises violate the previously listed guidelines, the hybrid role becomes the bottleneck of the project. Two
of the most challenging aspects of the hybrid role are that only a portion of the practitioner’s experience
will qualify him/her for a higher level of certification in business analysis and that the business analysis
responsibilities can be misaligned with the practitioner’s career goals and experience.
A practitioner who is in a hybrid role has the opportunity to progress in more than one discipline. This can
be both an advantage and a disadvantage regarding your career development. Each practitioner needs to look
at their individual career goals to determine which job profiles will help determine the best career pathway.
If you are considering a potential hybrid position, consider these factors in your decision:
• The business analysis tasks and techniques you like to do or don’t like to do
• The business analysis tasks and techniques you perform effectively or ineffectively
• The type of roles and responsibilities you want to fulfill in the future and align this hybrid role with
your career progression
• The experiences and opportunities you will gain with hybrid responsibilities
• The type of business analysis certification you want to acquire
In addition to a BA progressing within the business analysis profession, there are also opportunities to
advance into other roles, including business architect, enterprise architect, manager of BAs, director,
vice president, and the C-suite. In years past, the only opportunity for most BAs to progress was to
 Introduction 11

become a project manager (PM). Now there are vast opportunities for BAs seeking growth within the
profession itself.

In Real Life . . .

While analyzing the current state of a healthcare IT platform provider, I learned

that they had four tiers of BAs. Two of the greatest challenges they faced
were: (1) ensuring consistency as to the responsibilities for the different lev-
els across the multiple lines of business, and (2) safeguarding how BA pro-
motions happened across the varied lines of business. Enterprises that are
considering the creation of different levels/tiers of BAs need to keep those
factors in mind, as well as ensuring appropriate progression documentation,
transparent communication, advancement work potential, and eliminating as
much bureaucracy as possible in the process.

BECOMING A TRUSTED ADVISOR

Basically, there are two functions of trust—character and competence. Keep in mind that trust levels
vary based on the situation. For example, someone might ask, “Do you trust your husband?” and I would
respond, “Implicitly.” Their response then might be, “So you would trust him to perform your dental
work?” I would respond, “Of course not, dental work is not his core competency.” Trusting someone does
not mean they can perform work competently.
Figure 1.3 helps in understanding the two functions of trust regarding character and competence:
• Low character and low competence results in distrust
• Low character and high competence establishes respect
• High character and low competence produces affection
• High character and high competence creates prevailing trust

Character

Affection Trust

Distrust Respect

Competence

Figure 1.3 Functions of trust

12 Mastering Business Analysis Standard Practices

The BA needs to consider the perceptions that stakeholders have of the BA—namely, how would they map
you on the character/competence matrix? When the perception is not in the trust quadrant, it is critical
for the BA to work to raise the character and/or competence level in the stakeholders’ eyes.
Building trust in business analysis cannot be taken lightly. Consider these factors when trying to build
trust with stakeholders to become a trusted advisor:
• Focus on the needs and requirements of stakeholders: always look out for their best interests on
projects and be careful with information—this helps a BA to build trust with stakeholders.
• Become attentive to others’ needs: the majority of trust breakdowns occur when a person pays
more attention to themselves than to others. Becoming a trusted advisor involves constructing
relationships.
• Master interaction and interpersonal skills: these skills are described in the Underlying Compe-
tencies section of this chapter. Trust is created through communication, conversation, and active
listening.
• Be willing to take risks in order to build trust: relationships begin when one or both parties take a
risk. According to authors Charles H. Green and Andrea P. Howe, trust is positively tied to risk; by
taking appropriate risks you can create trust in the relationship with a stakeholder.
• Rise above your natural instincts to build trust: it’s important to stop the following behaviors:
◽◽ Trying to influence people
◽◽ Being self-preserving
◽◽ Responding via fight or flight
◽◽ Trying to always win
One of the best ways to gain credibility with stakeholders is to admit it when we don’t know the
answer.
• Listen to others in order to build mutual benefits: a BA who listens to others is more likely to be lis-
tened to, which is the best way to begin to influence others. According to Green and Howe, mutual
benefit means, “If you listen to me, I will listen to you. If you do not listen to me, I will not listen to
you.” It is of great benefit for the BA to be genuinely interested in stakeholders.
• Make a good first impression: stakeholders will make trust judgments very quickly and consider
both rational and emotional factors during their first interaction with a BA.
• Own any and all mistakes: the occasional mistake made by a BA will be forgiven provided there is
deep trust with a stakeholder. Consistent patterns of mistrust in a relationship are the factors that
destroy trust. In a deep trusting relationship, owning up to mistakes actually increases trust.
• Trust the stakeholders: when a BA trusts a stakeholder, odds are that the stakeholder will behave
in a much more trustworthy way than if the BA was suspicious of that stakeholder. You get what
you give.
• Be a dependable advisor to the stakeholders: consistency in thoughts, words, and actions creates
credibility in the stakeholders’ mind.
 Introduction 13

In Real Life . . .

While working as a hybrid BA on a succession planning initiative at a large

manufacturer, I had the opportunity to work closely with both internal em-
ployees and contracted resources from our IT department. At the end of the
project, I provided feedback to the director of IT regarding the contributions
that each team member made to the project. I copied each team member
on what I included in my feedback. I wasn’t aware of the impact that gesture
made until the next phase of the succession planning effort where I needed
the expertise and work of the same team members. The director of IT told
me that he would be happy to provide as much as he could because I took
good care of his resources. The team members contributed even better on
the succeeding phase than the previous one because they knew that I trusted
and appreciated them.

The preceding factors focused on how to build trust, while the following elements are known as trust
crushers:
• Disclosing confidential information
• Creating a competitive environment
• Communicating within a hierarchy (rather than team-based communications)
• Not doing what you say
• Micromanaging
• Not making decisions
• Being incompetent
When trust is absent, the requirements elicitation process will take longer, be incomplete, and lead to
lower morale.
Becoming a trusted advisor means being more proactive than reactive in identifying areas of improve-
ment before being asked by stakeholders, but also validating that improvement is necessary with them.
Being proactive raises the value of the BA and increases the chances of retaining the role in the enterprise.
As the business domain sees the business value realized from solutions, they begin to trust the BA more
and more to help them be more effective in their work. When a BA is requested by stakeholders to work
on a project or initiative or when he/she is sought out by a stakeholder for advice, that is a sign that the BA
is progressing toward becoming a trusted advisor.

BUSINESS ANALYSIS COMPETENCIES

At first glance, it appears that the BA role involves mainly technical competencies. Upon further review, it
becomes evident that BAs need to possess an abundance of interpersonal skills in addition to the techni-
cal skills. For most BAs, the technical skills can be acquired and learned with practice. The interpersonal
14 Mastering Business Analysis Standard Practices

skills, which some people refer to as soft skills, are more difficult and need to be refined throughout a BA’s
career. This section includes the critical competencies for BAs to acquire and possess.

Core Concept Model

The BABOK ® Guide v3 includes the Business Analysis Core Concept Model ™ as a visual framework for BAs
to perform business analysis. The model represents six core concepts:
• Change: going through a transformation in response to a need
• Need : problem or opportunity that requires being addressed
• Solution: specific way to satisfy one or more needs
• Stakeholder: group or individual—has a relationship to the change, need, or solution
• Value: worth, importance, or usefulness to a stakeholder, considering the context
• Context: circumstances that influence, are influenced by, and provide understanding regarding
the change
Due to the relationships between the six core concepts, each has a dependency on one another regarding
change. The six core concepts also help BAs determine the quality of their work and the ability to identify
the definition of completeness.
There are multiple performance competencies within this model: 1) knowledge areas include the knowl-
edge and groups of tasks that are necessary for BAs to perform; 2) techniques are the different ways that
BAs perform the tasks or the format of a task output; and 3) underlying competencies include the skills,
abilities, and personal characteristics that BAs use to perform the tasks and techniques. The underlying
competencies are included in the next section of this chapter.

Underlying BA Competencies and Skills

The BABOK ® Guide v3 recognizes 29 underlying competencies that are divided into six categories. Under-
lying competencies are the skills, knowledge, behaviors, and personal qualities that help a BA perform
their tasks and techniques effectively.
The PMI Guide to Business Analysis recognizes 35 processes and six business analysis process groups
that are essential for BAs to perform across these six knowledge areas:
• Needs Assessment
• Stakeholder Engagement
• Elicitation
• Analysis
• Traceability and Monitoring
• Solution Evaluation
PMI also identifies 40 skills that are necessary for the business analysis role. Table 1.3 includes the skills
deemed necessary for the BA by the IIBA and PMI and where they overlap.
 Introduction 15

Table 1.3 Competencies business analysts use

IIBA BABOK ® Guide v3 PMI Guide to Business Analysis
Underlying Competencies Business Analyst Competencies

Communication Skills

Communication Skills
Tools and Technology
Business Knowledge
and Problem Solving
Analytical Thinking

Expert Judgment

Leadership Skills
Interaction Skills

Tool Knowledge
Analytical Skills
Characteristics

Personal Skills
Behavioral
Competencies
Active Listening X
Adaptability X X
Business Acumen X X
Business Analysis Tools and
X
Technology
Change Agent X
Communication Tailoring X
Communication and
X
Collaboration Tools
Communication Tools and
X
Technology
Conceptual Thinking X
Conceptual and Detailed Thinking X
Creative Thinking X X
Decision Making X X
Design Thinking X
Desktop Tools X
Enterprise/Organizational
X
Knowledge
Ethics X X
Facilitation X X
Industry Knowledge X X
Leadership and Influencing X
Learner X
Learning X
Life-cycle Knowledge X
Listening X
Methodology Knowledge X
Modeling Tools X
Multitasking X

Continued
16 Mastering Business Analysis Standard Practices

IIBA BABOK ® Guide v3 PMI Guide to Business Analysis

Underlying Competencies Business Analyst Competencies

Communication Skills

Communication Skills
Tools and Technology
Business Knowledge
and Problem Solving
Analytical Thinking

Expert Judgment

Leadership Skills
Interaction Skills

Tool Knowledge
Analytical Skills
Characteristics

Personal Skills
Behavioral
Competencies
Negotiation X
Negotiation and Conflict
X
Resolution
Non-verbal Communication X X
Numeracy X
Objectivity X
Office Productivity Tools and
X
Technology
Organization and Time
X
Management
Organization Knowledge X
Personal Accountability X
Personal Development X
Political and Cultural Awareness X
Problem Solving X X
Product Knowledge X
Professional Writing X
Relationship Building X
Reporting and Analysis Tools X
Requirements Management Tools X
Research Skills X
Resourcefulness X
Self-awareness X
Solution Knowledge X
Standards X
Systems Thinking X X
Teaching X
Teamwork X
Time Management X
Trusted Advisor X
Trustworthiness X
Continued
 Introduction 17

IIBA BABOK ® Guide v3 PMI Guide to Business Analysis

Underlying Competencies Business Analyst Competencies

Communication Skills

Communication Skills
Tools and Technology
Business Knowledge
and Problem Solving
Analytical Thinking

Expert Judgment

Leadership Skills
Interaction Skills

Tool Knowledge
Analytical Skills
Characteristics

Personal Skills
Behavioral
Competencies
Verbal Communication X X
Visual Communication X
Visual Thinking X
Work Ethic X
Written Communication X
Legend:
X = IIBA BABOK ® Guide v3 Competencies or PMI Guide to Business Analysis Competencies
X = Agreement on Competencies

In Real Life . . .

In a recent mortgage industry redesign project, the stakeholders expressed

that a new platform was needed for the agreement application because their
current platform was no longer supported. The contract life-cycle process
was perfect; hence, just build a new platform. This was seen as a technol-
ogy-only project. In eliciting more information about the expectations of the
new agreement application, a stakeholder mentioned that this new applica-
tion should help reduce the customer contracting life-cycle timeline—a major
factor for cost and time savings. This realization created a new, explicit goal
to reduce the contract life cycle. This technology-only project now became a
process improvement and organizational redesign project as well; something
that could only have happened once more questions were asked.

BUSINESS ANALYSIS PERSPECTIVES

The BA professional skill set is not just for IT projects any longer. These analytical skills are required for
working in different initiative contexts such as process improvement, strategic initiatives, reporting needs,
automated solutions, etc.
The BABOK ® Guide v3 defines these business analysis opportunities as business analysis perspectives.
The BA can expect an initiative to include multiple perspectives. Depending on the perspectives, the BA
will vary techniques and tasks. To guide practitioners in mastering business analysis, the steps that are
defined in subsequent chapters are applicable to all perspectives. The variation of tasks and techniques will
be outlined based on the following five perspectives.
18 Mastering Business Analysis Standard Practices

The BI Perspective
This perspective recognizes the need to focus on the data that provides value-added information. The
impact of information can be seen everywhere. Every mention of the cloud, which is frequently the topic
of conversation, is seeking to understand the best way to make information accessible. The BA who is
working in this BI perspective seeks to understand the impacts related to how data is sourced, trans-
formed, integrated, and enhanced in order to support business decision making. This decision-making
support can be strategic, tactical, or operational. Typically, executive-level staff are seeking strategic infor-
mation, management is seeking tactical information, and process personnel are seeking operational infor-
mation. The BA working on any change initiative should be aware of these needs. The astute BA will
ensure that these information needs are properly elicited to avoid gaps in the information that is available
upon implementation.
The key objectives are to have reliable, consistent, and accurate information. With data being sourced
from multiple internal and external places, this objective is hard to accomplish without a single point
of truth for this diverse business data. Approaching data from this BI perspective promotes an enter-
prise-wide view of information management. Figure 1.4 depicts a conceptual framework for this single
point of truth and indicates the need for information governance of data integration and information
delivery that must be maintained.

The BPM Perspective

This perspective seeks to ensure that delivery of value is optimized across end-to-end processes. The
processes may be manual, automated, or a combination of both. Enterprises that hold a process-centric
view treat BPM as an ongoing effort and an integral part of the ongoing management and operation of the

• Industry Ad hoc
External • Partner Reporting
Sources • Regulatory Decision
Data Integration Point

Analytic
Information Delivery

Tool
• Corporate Single
Internal
• Functional area Point Alerts
Sources • Performance of Truth

Other • Web data

• Documents Scheduled
Sources Reporting/
• Machine data
Dashboards

Figure 1.4 Single point of truth

 Introduction 19

enterprise. There are many BPM frameworks and methodologies that the BA may employ, but all of them
involve the steps depicted in Figure 1.5 and are explained in the following list:
• Designing: understanding current and future processes to develop a gap analysis. BAs often exam-
ine activities for these factors before considering automation of the business process:
◽◽ Bureaucracy
◽◽ Value-added versus non-value-added
◽◽ Redundancy
◽◽ Simplify
◽◽ Process time
◽◽ Cycle time
Automating an ineffective and inefficient business process will not fix the business process. Find-
ing and fixing areas of improvement is something that needs to be performed before even consid-
ering automation of the business process. Throughout this gap analysis, BAs are also investigating
how to prepare business stakeholders for the transition from the current state to the future state.
• Modeling: graphical representation of current and future states to analyze the potential value. Mod-
eling helps BAs and business stakeholders see potential bottlenecks, inefficiencies, and problems.
• Execution: actual execution of the processes to identify bottlenecks, defects, and/or errors.
• Monitoring: collection of analytical data to ensure value and recommend improvement opportu-
nities. This involves an ongoing effort to improve a business process and making adjustments as
necessary so the business process gets better over time.
• Optimizing: ongoing repetition of the designing, modeling, execution, and monitoring. BAs follow
a structured problem-solving approach to perform optimization and seek to make the business
processes adaptable to changing business needs.
BPM helps enterprises enhance business processes in order to accomplish more efficient and effective
outcomes. Performing this perspective allows BAs the opportunity to exceed stakeholders’ expectations.

Designing

Optimizing Modeling

Monitoring Execution

Figure 1.5 BPM cycle

20 Mastering Business Analysis Standard Practices

While performing BPM, BAs focus intently on the process to identify improvement and involve the busi-
ness process stakeholders.

In Real Life . . .

A manufacturing facility used a structured problem-solving approach to de-

crease both the process time and the cycle time days for new orders. The
process model took up all four walls of a 400-square-foot conference room.
Involving the business stakeholders in defining, measuring, analyzing, imple-
menting, and controlling helped them realize how big the problem truly was—
as well as gained their support and buy-in for the changes that would be
necessary to decrease the cycle time from 25 days to five days.

BPTrends reported in The State of the BPM Market 2016 that the business drivers causing organizations
to focus on business process change are:
1. The need to save money
2. To improve an existing process or create a new process
3. To improve customer satisfaction
4. To improve organizational responsiveness
5. To improve business coordination and control
6. Compliance with new regulations and IT upgrades
7. One-time events such as mergers and acquisitions
Of course, process improvement is nothing new since there are processes evident in just about every-
thing we do. Consider the processes at play from waking up in the morning to getting ready for the day.
These processes vary based on the day of the week and the calendar tasks involved. One typically is ana-
lyzing ways to reduce the amount of time it takes to get ready in the morning. The difference in using a
structured BPM approach is the diligence for continual improvement. Table 1.4 provides a timeline for
the evolution of BPM. As this table is reviewed, the tools used to manage processes have evolved as well.
Table 1.5 depicts the BPM methodologies and short descriptions of each that are being used today. These
methodologies lend themselves to being more appropriate based on the focus. The percentages in this
table reflect organizations that use multiple methodologies, thus the total percentage is greater than 100.
These areas of BPM focus are depicted in Figure 1.6. These tables and figures are certainly not meant
to intimidate. A savvy BA is aware of the BPM level of engagement, tools, and methodologies that are
available when assigned a project. As stated previously, multiple business analysis perspectives are likely
involved on any one project.
 Introduction 21

Table 1.4 BPM evolution

Organizational
Phase Time Frame Business Drivers Structure Technology Tools
Industrial Age 1750’s–1960’s •L abor •F  unctional • Mechanization •S  cientific
Specialization Hierarchy • Standardization Management
• Task Productivity • Command and • Record Keeping • PDCA Cycle*
• Cost Reduction Control • Financial
• Assembly Line Modeling
Information 1970’s–1980’s •Q uality •M  ulti-Industry •C  omputerized •T  otal Quality
Age—Phase Management Enterprises Automation Management
1—Process • Continuous Flow • Line of Business • Management (TQM)
Improvement • Task Efficiency Organizations Information • Statistical
• Mergers and Systems Process Control
Acquisitions • Manufacturing • Process
Resource Improvement
Planning (MRP) Methods
Information 1990’s •P  rocess • Flat Organization •E  nterprise •A  ctivity Based
Age—Phase Innovation • End-to-End Architecture Costing
2—Process • Best Practices Processes • Enterprise • Six Sigma
Reengineering • Better, Faster, Resource • Buy vs. Build
Cheaper Planning (ERP) • Process
• Business via the • Customer Redesign/
Internet Relationship Reengineering
• Speed to Market Management Methods
• Customer (CRM)
Intimacy • Supply Chain
• Operational Management
Excellence
Information 2000’s+ •A  ssessment, •N  etworked •E  nterprise •B  alanced
Age—Phase Adaptability, and Organization Application Scorecard
3—Business Agility • Hyper Integration • Self Service and
Process • 24×7 Global Competition • Service Oriented Personalization
Management Business • Market Growth Architecture • Outsourcing,
• Continual Driven • Performance Co-Sourcing,
Transformation • Process Management In-Sourcing
Effectiveness Software • BPM Methods
over Resource • Business
Efficiency Process
• Organizational Management
Effectiveness (BPM) Systems
over Operational
Efficiency
*PDCA—Plan, Do, Check, Act
22 Mastering Business Analysis Standard Practices

Table 1.5 BPM methodologies

Methodology % Used Description
Lean 34% Lean is a systematic method for the elimination of waste ( muda) within
a manufacturing system. Lean also takes into account waste created
through overburden ( muri ) and waste created through unevenness
in workloads ( mura). Working from the perspective of the client who
consumes a product or service, “value” is any action or process that
a customer would be willing to pay for. Essentially, lean is centered on
making obvious what adds value by reducing everything else.
Six Sigma 20% Six Sigma seeks to improve the quality of the process output by
identifying and removing the causes of defects and minimizing variability
in manufacturing and business processes. It uses a set of quality
management methods, mainly empirical, statistical methods, and
creates a special infrastructure of people within the organization who
are experts in these methods. Each Six Sigma project carried out within
an organization follows a defined sequence of steps and has specific
value targets.
Combined Lean Six Sigma 40% Lean Six Sigma is a methodology that relies on a collaborative team
effort to improve performance by systematically removing waste
by combining lean manufacturing/lean enterprise and Six Sigma to
eliminate the eight kinds of waste ( muda): transportation, inventory,
motion, waiting, overproduction, overprocessing, defects, and skills
(abbreviated as TIMWOODS).
Rational Unified Process 9% The Rational Unified Process (RUP) is an iterative software
(RUP) development process framework created by the Rational Software
Corporation, a division of IBM since 2003. RUP is not a single concrete
prescriptive process, but rather an adaptable process framework,
intended to be tailored by the development organizations and software
project teams that will select the elements of the process that are
appropriate for their needs.
Business Rules Approach 12% Business rules are abstractions of the policies and practices of a
business organization. In computer software development, the business
rules approach is a development methodology where rules are in a
form that is used by, but does not have to be embedded in, BPM
systems. The Business Rules Approach formalizes an enterprise’s
critical business rules in a language that managers and technologists
understand.
BP Trends Associates 18% A best practices methodology synthesizes the best of various
Methodologies approaches into a coordinated whole. Burlton-Harmon divide process
work between an enterprise methodology and a process redesign
methodology. At the enterprise level the goal is to create or organize
the tools and resources that senior managers and a business process
center of excellence will need to manage and coordinate process work
throughout the entire organization. Thus, phases in the enterprise effort
include organizing strategy and processes, creating a business process
architecture, organizing a process measurement system, establishing
a process governance system, and aligning processes with other
resources from IT, HR, etc.
Continued
 Introduction 23

Methodology % Used Description

Rummler Brache/PDL 7% Rummler Brache™ methodology defines 6 phases for BPM to include:
Methodology Phase 0: Performance Improvement Planning, Phase 1: Project
Definition, Phase 2: Process Analysis and Design, Phase 3: Managing
Implementation and Change, Phase 4: Process Management, and Phase
5: Managing the Organization as an Adaptive System. PDL Methodology
focuses on bridging the requirements gap between business needs
and IT solutions, including definition of the business and the drivers for
technology.
Process and Enterprise 6% The Process and Enterprise Maturity Model (PEMM™) is a corporate
Maturity Model (PEMM™) roadmap and benchmarking tool for organizations seeking to become
process driven organizations. Dr. Michael Hammer introduced PEMM™
in The Process Audit for the Harvard Business Review in April 2007.
This provided guidance for immediate application by corporations at any
level of process design/redesign.
Case Management 5% Case management solutions unite information, documents, process,
Methodology systems, and people to provide a 360-degree view of case details—
often called an electronic case file.
Framework Methodology 10% eTom—Enhanced Telecom Operations Map is a business process
(eTOM, SCOR) framework for telecom service providers in the telecommunications
and entertainment industries. The model describes the required
business processes of service providers and defines key elements
and how they should interact.
SCOR—The Supply Chain Operations Reference model is a supply
chain framework, linking business processes, performance metrics,
practices, and people skills into a unified structure.
Consulting Company 6% Catalyst is a set of repeatable processes and techniques for analyzing a
Methodology (CSC’s Catalyst) business situation and developing and implementing the best solution.
It is based on industry best practices and reflects the thinking and
experience of CSC employees globally.
CMMI Methodology 17% The Capability Maturity Model Integration (CMMI) is a process model
that provides a clear definition of what an organization should do to
promote behaviors that lead to improved performance. With five maturity
levels and three capability levels, CMMI defines the most important
elements that are required to build great products or deliver great
services and wraps them all up in a comprehensive model.
In-House Methodology 34% Custom in-house developed standards, tools, and practices for
managing business processes.
% Used based on BPTrends’ The State of the BPM Market—2016
24 Mastering Business Analysis Standard Practices

• Organizational Strategy
• Business Process Architecture
• Performance Measurement
Alignment
Enterpise • BPM Organizational Policies and
Level Practices

• Business Process Projects

• Redesign
• Improvements
Business • As-Is Documentation Projects
Process Level

• Human Capital Component

• Skill Set Design
• Training
• Knowledge Management
• Automated Component
Implementation
• Data Repository
Level • Application Development

Figure 1.6 BPM levels

The IT Perspective
This perspective is where the BA has traditionally been utilized. In fact, most references that were pro-
duced regarding business analysis refer to the work done to describe the needs of an automated solution.
When the BA is working from this IT perspective, there is likely a high degree of complexity and scope
of activities. The initiatives may vary from being very small, in the case of a defect resolution or minor
enhancement, to large re-engineering projects. The BA may be working alone on the IT business analy-
sis activities or as part of a team of BAs to help decompose the problem, define goals, and finally define
requirements to provide the most appropriate IT solution.
On IT initiatives, there is typically a solution approach that is identified prior to project funding and
then defined in the business case. This solution approach is influenced by the enterprise direction for IT
endeavors and may be defined in the enterprise architecture. The IT solution approach defines whether
 Introduction 25

this initiative will be a packaged solution (commercial off-the-shelf—COTS), a custom application built
in-house (homegrown), a custom outsourced application (organization specific), an outsourced industry
standard solution, or some combination of any of these approaches. The impact to the business analysis
effort is whether the system is intended to be user-centric or whether it forces the user to conform their
practices to the solution. Typically for a COTS solution, the enterprise has selected this approach to em-
ploy a best-in-class tool that has proven functionality that will meet the needs of like enterprises rather
than reinvent the wheel. The BA should validate this assumption with the sponsor and the PM and ensure
that business stakeholders understand that their processes may change, but their needs will be met. The
BA will ensure the solution is able to fulfill the needs of the business, but without dictating the exact steps
in the process—otherwise, the BA could be sabotaging the expected gains of purchasing a solution. The
detail requirements will be in the configuration of the COTS solution. For custom solutions, the BA will
take a user-centric approach, elaborating detailed, concise solution-level requirements.
There is a lot of discussion regarding the technical expertise that the BA should have in order to work
in the IT perspective. Generally, if the BA has a technical background, it is easier to communicate with the
IT development group, but the downside is to move into solution mode before understanding the problem.
Successful BAs in the IT perspective could possess any of the following backgrounds:
• Only worked with business users in the past on an IT system
• Designated liaison between the business group and the technical team
• SME who has experience on the current application
• Software user who is aware of the daily activities and focuses on usability
• Business process owner who understands business capabilities and processes but has no technical
or IT experience
• Technical person with in-depth technical experience
• COTS representative who will allow customization of the packaged solution while leveraging their
knowledge of the vendor’s package and past implementation experience
IT initiatives are typically triggered by identifying a new capability to transform the enterprise, achieve
objectives (regulatory or policy) that require technology, improve operations, maintain existing IT sys-
tems, or repair defective IT systems. These initiatives will likely require focus on multiple IT systems that
interact with one another for multiple user groups. This requires high collaboration among the stake-
holder groups with the BA being the facilitator to define solution requirements.
Consider the impact of an IT change initiative on other perspectives at play within the organization.
Has the process impact been considered? Will the business intelligence be enabled with this change? Is the
organization mature enough to utilize the solution to achieve the anticipated value? The BA working in
the IT perspective must ensure these considerations are addressed. In some cases, there may be separate
BAs working on other perspectives, but usually the BA must address all perspectives.
These perspectives, coupled with an ever-changing IT environment, have a huge impact on the busi-
ness. This impact is driving an increase in demand for BAs who are in tune with an environment that is
evolving at a rapid pace. The major contributing innovations in this decade include:
• The cloud computing platform, which provides large, mid-size, or small organizations a seemingly
level playing field. Traditionally, organizations were faced with large investments for information
26 Mastering Business Analysis Standard Practices

systems that could retrieve, collect, store, and distribute information. Cloud computing offers a
flexible platform for those mid-size and small organizations to scale their needs and pay only for
what they use. Cloud computing could make or break an organization, depending on how they
implement the solution. If implemented correctly, cloud computing may boost the organization to
greater success than what was thought possible with the old technology. The BA must understand
the risks of improper execution as well as the benefits for this solution approach to define the busi-
ness analysis information.
◽◽ Risks include network dependency, data security, and integration of systems (internal and
external to the organization)
◽◽ Benefits include cost reduction, increased efficiency, platform flexibility without investment,
security gains, and reliability
• On the coattails of cloud computing, the distribution of software has undergone a change. The
traditional model provided boxed software or custom applications implemented on-site. Software
distribution is moving toward Internet accessibility, known as software as a service (SaaS). The SaaS
focus has been on maintaining business applications such as accounting, database management
systems, messaging software, etc. Similarly, the BA must understand the risks of improper execu-
tion as well as the benefits for this solution approach to define the business analysis information.
◽◽ Risks include availability of hosted application, data security and privacy, a stringent regula-
tory environment, and vendor stability
◽◽ Benefits include cost reduction in personnel and hardware, increased efficiency in deploy-
ment, lower initial acquisition cost, no maintenance releases or patches to install, scalability,
security gains, and reliability
• The global community is changing the way the Internet is accessed, moving from desktop and
laptop access to adding mobile digital platforms, such as smartphones, tablets, smart TVs, watches,
etc. There is now a mobile workforce that can work from home, office, restaurants, or while
traveling—­just about anywhere. This speeds up the information flow, velocity and quality of de-
cision making, exchange of data between systems, collaboration, communication, and location
services. It provides the BA with new elicitation, communication, and collaboration vehicles, as
well as opportunities for solution design considerations.
Typically, IT projects are designed, constructed, tested, and delivered in a defined life-cycle framework.
This framework is known as a systems (or software) development life cycle (SDLC). The BA’s approach to
elicitation and analysis may or may not follow the SDLC of the solution development team; however, the
BA is influenced by the project’s SDLC because the BA will support the implementation of a successful
solution. There are a number of different SDLC approaches; however, most fall into one of the three cate-
gories that are shown in Figure 1.7 and explained here:
• Predictive approach: this is typically known as the waterfall approach. The predictive approach is
a sequential (non-iterative) process in which progress is seen as flowing steadily downward (like
a waterfall)—through the phases of conception, initiation, analysis, design, construction, test-
ing, implementation, and maintenance. The predictive approach dictates that one phase is com-
plete, reviewed, and verified before moving to the next phase. Figure 1.8 depicts the phases of the
 Introduction 27

Predictive Adaptive
“Waterfall” Iterative “Agile”

Well Understood Nebulous

Requirements Requirements

Example : Example:
Sales Tax Change Compliance Change
Requiring Interpretation

Figure 1.7 SDLC spectrum

waterfall approach. The predictive approach is a useful approach when the variables and outcomes
of a project are well known. This approach may be an appropriate choice for an organization if:
◽◽ The problem, requirements, and solution approach are familiar to the team
◽◽ The parameters of the project are stable
◽◽ The project team is large
◽◽ The project development process is thoroughly documented
◽◽ The organization prefers predictability to change
◽◽ The PM is inexperienced in other project methodologies
The predictive approach places a great deal of responsibility on the project team to understand and
implement requirements. If the BA fails to provide the team with complete and accurate informa-
tion, the final product will not meet the needs of the organization. Subsequent changes are always
more time consuming and costly. Until recently, waterfall was the dominant approach in software
development. However, Hewlett Packard (HP) conducted a survey in 2015 and found that this was
no longer the case (see Figure 1.9).
• Iterative approach: this hybrid of predictive and adaptive approaches is sometimes referred to as an
iterative or incremental approach. Due to the hybrid nature of this category, there are many vari-
ations in what aspects of predictive and adaptive organizations will choose to utilize. Figure 1.10
depicts this incremental delivery approach, which is also characterized by the following:
◽◽ Overall solution scope is defined up front at a high level
◽◽ Solution scope is split into iterations
◽◽ Iterations are defined in detail requirements, design definition is just-in-time, and documen-
tation typically needs formality and approval
◽◽ Each iteration’s work is performed sequentially with some overlap
◽◽ Product is developed iteratively, adding features incrementally
• Adaptive approach: this is typically known as the agile approach. The adaptive approach allows
for prioritization of features (sometimes referred to as user stories or technical debt) to be pulled
through an abbreviated SDLC. Figure 1.11 takes the traditional predictive SDLC and turns those
phases on their side in an adaptive approach. This allows high-priority features to be delivered in
28 Mastering Business Analysis Standard Practices

Analysis of an identified need for

alignment to organizational goals,
cost/benefit analysis, success
criteria, and initial risk assessment.
Decision package is provided for
direction.

Conception Elicitation, analysis, and approval of

business and stakeholder
requirements to define the scope.
<Funded Initiative>
Solution team is provided further
information to refine their estimates
Initiation and determine feasibility.

<Scope Definition> Elicitation, analysis, and approval of

solution requirements and
conceptual design.
Analysis

<Requirement Specification> Transforms solution requirements

and conceptual design into detailed
technical design of the solution.
<Enhancement Design
Needs, Defect
Resolution,
<Design Specification> Converts design into complete
Solution
solution which interfaces with all
Replacement>
solution components. Test cases
Construction are completed as well.

<Constructed Solution>
Demonstrates that the constructed
Testing solution meets the requirements
and design.

<Tested Solution>
Ensures organizational readiness,
Implementation any discovered defects are resolved
to meet needs, production
environment is set.
<Deployed Solution>

Monitors the solution to ensure

Maintenance success criteria continues to be
gained, provides post
implementation support.

Figure 1.8 SDLC waterfall

 Introduction 29

ORGANIZATIONS' REPORTED
PREDOMINANT SDLC APPROACH

Hybrid
24%

Pure Waterfall
Leaning Toward
2%
Agile
51%
Leaning Toward
Waterfall
7%

Pure Agile
16%

Source: HP online survey of 601 development and IT professionals.

Figure 1.9 HP survey showing predominant SDLC approach

small iterations, and this process is repeated until the solution is complete (or good enough). This
approach is detailed in the Agile Perspective section of this chapter. The adaptive approach may
appeal to an organization if:
◽◽ The parameters of the project are evolving or undetermined
◽◽ The organization adapts easily to change
◽◽ The team and/or project is somewhat small
◽◽ The timeline is flexible
◽◽ The organization represents an industry that is rapidly changing
◽◽ There is an experienced PM in this approach

These SDLC approaches provide a framework for IT projects; however, other solution-driven efforts have
adopted some of the practices. After all, project management roots are firmly planted in construction
and manufacturing arenas, so it is common to encounter these approaches even when IT is not involved.
Insight into the selected SDLC approach will help the BA be aware of the influence this may have on
the selected business analysis approach, which will be defined in Chapter 4. Table 1.6 provides some
insight into which project characteristics might lead organizations to select the predictive or adaptive
SDLC approaches for their projects. To summarize this section on SDLC approaches, Table 1.7 depicts a
comparison of advantages and disadvantages of predictive versus adaptive SDLC approaches.
30 Mastering Business Analysis Standard Practices

Conception Phase

12 34
Initiation Phase

Analysis Phase

Design Phase

Construction Phase

Testing Phase

Implementation Phase

Maintenance Phase

Figure 1.10 SDLC iterative

 Product backlog maintenance
occurs throughout the initiative

Daily check
point
Daily work

Iteration work
(typically
Vetting of 2–4 weeks)
Initial visioning backlog
and funding items to
prepare Potentially
Prioritization of Product for the shippable product
competing initiatives backlog next review and approval
development iteration’s Decomposition of
Definition of business and planning backlog items Team
and technical roadmaps maintenance meeting into tasks retrospective

Conception Phase Initiation Phase Analysis Phase Design, Construction, Implementation

and Testing Phase Phase

Figure 1.11 SDLC adaptive

Introduction
31
32 Mastering Business Analysis Standard Practices

Table 1.6 Project characteristics impacting SDLC approach

Project Factors Status Not a Factor Adaptive Predictive
Small X
Project Size Medium X
Large X
SMEs and decision makers are available
X
throughout the project
Stakeholder Availability
SMEs and decision makers cannot commit to
X
extensive involvement
Interface Complexity Simple and identified X
(Internal and External) Unidentified, numerous, or complex X
Flexible in budget and schedule (even
X
Tolerance for Scope and encouraged)
Cost Changes Budget and/or schedule are fixed or difficult
X
to change
Rapid deployment is required, even with
X
limited features available
Time to Market
All solution features must be delivered within
X
a set time frame

The Business Architecture Perspective

This perspective takes us out of the project-based or change initiative-based business analysis work and
defines the enterprise, organization, single-functional division, or line-of-business direction. Business
architecture is not a solution, but rather a tool. Through this business architecture definition (known as a
blueprint), executives and management are provided a common understanding of the enterprise for the
purpose of aligning strategic objectives with tactical demands. When considering this purpose of strate-
gic alignment with day-to-day activities and change initiatives at play, the BA (or the business architect)
is challenged to identify: (1) where to start, (2) how long this effort will take, and (3) how to continually
show business architecture value to the enterprise—especially when times are lean. So, let’s examine these
three aspects of this perspective.
First of all, the business architect should answer the questions in Table 1.8 to drive components of the
business architecture. Next, decide on how to capture the information—or as the business architecture
community would put it—what blueprint is being used? If the BA is working in an enterprise architec-
ture group, it may make sense to weave the business architecture blueprint into the chosen enterprise
architectural framework. Table 1.9 depicts the three leading enterprise architecture frameworks and an
 Introduction 33

Table 1.7 Pros and cons of predictive and adaptive SDLC approaches

Predictive Approach
Advantages Disadvantages
Time spent early in the software production cycle can Business stakeholders may not know their requirements
reduce costs at later stages. before they see the solution, hence requirements change
which requires revisiting design, constructed solution,
deployed solution, and testing which equals increased
solution cost.
Clearly defined procedures and controls that allow for Designers may not be familiar with new software or a
regulating every aspect of the project. feature that may reveal future constraints, requirements, or
other problems. This may require revision of the design.
Emphasizes documentation (requirements specification,
design specification, and source code) which provides for
knowledge transfer as needed.
This structured approach progresses in a linear fashion
through understandable phases with identifiable
milestones.
Adaptive Approach
Advantages Disadvantages
Provides for scope flexibility to accommodate business Crucial documentation may not be kept up-to-date based
needs. As functionality is created, the business is able to on decisions made in team discussions.
see the costs and remove any non-essential features or
add new features.
Product owner continuous feedback is provided as Due to the immediate feedback, scope can easily be
iterations (typically 1–3 weeks) are being developed and increased beyond the funded vision.
tested. This approach provides end users visibility to the
solution quicker, which allows for course correction with
less expense.
Fewer defects exist in the final product due to the Pricing is not fixed, thus the business is only provided
iterative cycles of develop, build, and test, increasing estimates.
the test coverage. This increases the level of quality in
organizations’ solutions.
Greater communication as the business stakeholder Business stakeholder resource availability may be scarce
involvement is required for this approach. and put a strain on the business community. Poor
stakeholder engagement directly affects product quality.
Project transparency provides all stakeholders with an The agile flavors, lingo, or processes may be challenging
understanding of work being done. to all stakeholders. The learning curve is steep and
constant.
Increased collaboration between teams that typically do
not work together.
Increases customer satisfaction.
Shortens time to market.
34 Mastering Business Analysis Standard Practices

explanation for parsing out the business architecture component. There is a plethora of other frameworks
developed through the following categories:
• Consortium-developed frameworks: developed by an association of two or more individuals, com-
panies, organizations, or governments (or any combination of these entities) with the objective of
developing common enterprise architecture
• Defense industry frameworks: developed by the U.S. Department of Defense
• Government frameworks: developed by the U.S. government
• Open-source frameworks: developed at no cost to the licensed user in which the copyright holder
provides the rights to study, change, and distribute the software to anyone and for any purpose;
may allow for development to occur in a collaborative public manner
• Proprietary frameworks: enterprise architecture frameworks defined as a company’s intellectual
property and protected through legal devices such as patents, trademarks, or copyrights.
Business architecture is not developed overnight. Assess the enterprise’s experience and key stakeholders’
experience with developing an enterprise architecture or a business architecture. In many organizations
an architecture stigma exists. The traditional view is that business architects sit in their ivory towers and
define theoretical views that are so far removed from the business that the architecture definition is per-
ceived as a waste. To combat this perception, communication and demonstration of value will be key for
this extended effort. A business plan and business case should be developed with realistic time frames.
At a large financial institution, an effort for the enterprise business architecture development team was
funded with the expectation that the full rollout and value realization would take two years. Executive
support was obtained and through frequent communication and small wins along the way, the effort was

Table 1.8 Questions targeting business architecture component discovery

Questions to be answered Business Architecture Model Components
Information and Data

Securities Strategy
Reporting and

Stakeholders
Management
Organization
Capabilities

Processes

Outcomes
Value

What does the business do? X X X X

Why is the business doing the things it does? X X
Who is doing these things and to whom? X X X
How are these things being done? X X X X
Where are these things being done? X X
How do all the things tie together into a common view? X X X
What information is being used? X X X X
Who uses the information? X X
Is there any consistency in terminology? X
 Introduction 35

Table 1.9 Top enterprise architecture frameworks

EA Framework/
Approach Description Business Architecture Component
Zachman The framework provides ontology of The business architecture component defines
Framework (1987) fundamental enterprise concepts that are the concepts associated with the top two
defined from the intersection of six probing viewpoints:
categories (what, how, where, who, when, and • Executive viewpoint is concerned with the
why) and six viewpoints (executive, business scope and context of the business
management, architect, engineer, technician, • Business management viewpoint is
and enterprise). concerned with business definition models
The Open Group TOGAF divides the enterprise architecture into The business architecture category
Architectural 4 categories: defines business processes used to
Framework 1. Business architecture meet organizational goals. This business
(TOGAF–2003) 2. Application architecture: describes how architecture drives the applications used, data
applications are designed and interact needed for business decisions, as well as the
with applications technical infrastructure required to support
3. Data architecture: describes how the data stores and applications.
enterprise data stores are organized and
accessed
4. Technical architecture: describes the
hardware and software infrastructure that
supports their interactions
Gartner Enterprise This practice is heavily weighted toward The business architecture portion of this
Architecture defining a future state and everything working practice focuses on representing the business
Practice (2005) toward that outcome. Gartner believes that owner constituents’ future state definition.
enterprise architecture is about bringing
together three constituents: business owners,
information specialists, and the technology
implementers. If you can bring these three
groups together and unify them behind a
common vision that drives business value, you
have succeeded; if not, you have failed.

completed. Developing business architecture at the organization, single functional division, or line of
business levels could take considerably less time.
The BA working from the business architecture perspective should be ready to justify his/her existence
at all times. Hence, an elevator pitch is helpful to have rehearsed. To craft this elevator pitch (or value
statement), focus on understanding the enterprise and stakeholder motivations along with these general
business architecture values:
• Providing the enterprise with a view that will help identify opportunities for rationalization, opti-
mization, and leveraging existing competencies of the enterprise
• Exposing root cause problems by providing transparency of dynamics and interdependencies
within the organization
• Demonstrating strategic alignment through traceability with implemented capabilities
• Providing a better way to balance risk and opportunity more effectively
• Providing a better way to conduct impact analysis of a change, thus unearthing hidden costs sooner
• Formalizing institutional knowledge
36 Mastering Business Analysis Standard Practices

The Agile Perspective

This perspective provides insight into how business analysis is performed where change is enabled in a
nimbler environment than traditional frameworks. The term agile is used generically to include many
approaches that have developed over time. Some examples of approaches that are currently in use as iden-
tified by practitioners are depicted in Figure 1.12. The BA can expect to encounter any of these approaches
on change initiatives.
First, a little background on this agile framework. Since the late 1950s, there has been a recognition
in software development practices that incremental development is valuable. In the 1970s, evolutionary
gains were made in project management and adaptive software development practices. However, as the
1990s emerged, projects were laden with methods and documentation, highly regimented, and micro-­
managed. During this time, the dot-com era emerged with a race for Internet presence and to be first to
market, which allowed these new business drivers to become prominent. In 2001, a group of software
developers (recognized leaders in the field) met to discuss “light-weight” software development methods.
They coined the term that these approaches would be referred to as agile and created the Agile Mani-
festo, in which they said that by uncovering better ways of developing software and helping others do it,
they have come to value “individuals and interactions over processes and tools, working software over

Figure 1.12 Agile approaches being used

 Introduction 37

comprehensive documentation, customer collaboration over contract negotiation, and responding to

change over following a plan.” The Agile Manifesto is based on 12 principles:
1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcoming changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals who should be trusted
6. Face-to-face conversation is the best form of communication (colocation)
7. Working software is the principal measure of progress
8. Sustainable development; able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly
Over the years, agile methodologies have progressed with time (see Table 1.10).

Table 1.10 Evolution of agile approaches

First Gained
Agile Approach Introduction Recognition Brief Description
Extreme 1960’s NASA Mid-1990’s Name was coined by taking beneficial software engineering
Programming techniques to the extreme. The focus is on the technical
(XP) development processes and features pair-programming, test-
driven development, and other expertise approaches to the
technical practices.
XP technical practices are used in conjunction with other agile
management frameworks.
Scrum 1986 Mid-1990’s A lightweight framework based on empirical process control. Work
is done in a series of fixed length iterations, called sprints, with
fixed durations of one month or less. At the end of each sprint the
team demonstrates working software of a high enough quality that it
could potentially be shipped or otherwise delivered to a customer.
Lean 1993 2007 A philosophy focused on improving flow of work, managing risk,
Information and improving (management) decision making. This philosophy
Technology complements other Agile approaches.
(Lean IT)
Dynamic 1994 2007 A project delivery framework focused on fixing cost, quality, and
Systems time at the beginning while contingency is managed by fluctuating
Development the features to be delivered. The most used prioritization technique
Model (DSDM) is based on MoSCoW (must, should, could, won’t) for scope
management. Time boxes (short, focused periods of time with
clearly defined outcomes) manage the work.
Continued
38 Mastering Business Analysis Standard Practices

First Gained
Agile Approach Introduction Recognition Brief Description
Crystal Clear 1995 2004 A part of the Crystal methodology family which are defined based
on hardness and color. Hardness is about business criticality
(potential for causing harm), which applies more rigor and predictive
planning as the criticality increases. Color is about the project
heaviness across many dimensions including the number of people
required and risk elements in the project.
Evolutionary 1996 1999 A project management method that focuses on developing and
Project delivering a system incrementally. It has a strong emphasis on
Management quantifying value for stakeholders and planning increments based
(EVO) on measurable value. EVO employs impact estimation tables as
a formal technique for assessing solutions’ value to stakeholders
within the given cost.
Feature Driven 1997 2002 An approach which derives a client valued functionality to develop
Development working software. For example, decomposing high-level scope
(FDD) and developing a feature list which drives planning, design, and
development based on these feature sets.
Agile Modeling 2000 2005 A methodology for modeling and detailing software systems
(AM) based on best practices. AM can be applied on an (agile)
software development project. This methodology is more flexible
than traditional modeling methods, supporting a fast-changing
environment. It is a part of the agile software development tool kit.
Agile Unified 2002 2005 This framework is a simplification of the Rational Unified Process
Process (AUP) (RUP) by IBM. The AUP applies agile techniques including test-
driven development, AM, agile change management, and database
refactoring to advance productivity.
Kanban 2004 2010 This methodology does not require fixed iterations, rather work
moves through the development process as a continuous flow of
activity. A key feature is to limit the amount of work in progress
at any one time. The team works only on a fixed number of items
and work begins on a new item when required to maintain flow
downstream and after the previous item has been completed.
Disciplined 2006 2011 A decision process framework which is intended to support a
Agile Delivery project from initiation through delivery. DAD incorporates principles
(DAD) from a variety of other agile approaches. DAD is not prescriptive
and allows for teams to customize their own life cycles and
approaches that supports initiation through delivery.
Scrumban 2009 2013 As the name reflects, this approach combines aspects of Scrum
and Kanban to allow teams to employ Scrum as their chosen way
of working and use the Kanban Method to understand work flow
and continuously improve.
Scaled Agile 2010 2011 A framework for scale agile practices to support enterprise level
Framework® implementations. Highlights include individual roles, teams,
(SAFe) activities, and artifacts required to scale agile from the team to
program to the enterprise level.
 Introduction 39

Agile Adoption Year

120%

100%
100% 90%

80%
67%

60%
46%
37%
40%

17%
20% 11% 13%
8% 8%
4%

0%
2004 or 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014
earlier

Source: HP online survey of 475 development and IT professionals with some adoption of Agile Methods.

Figure 1.13 Agile adoption over time

The BA today will likely be assigned a change initiative in which agile methods are being employed in
combination with any of the previous perspectives. The agile movement has progressed from infancy to
teenager and is now that young adult going about day-to-day involvement in contributing to society. Fig-
ure 1.13 represents the timeline of agile adopters in an HP survey conducted among 475 IT professionals.
Between 2010 and 2014, there was a sharp acceleration in the adoption of agile methods.
Agile could be considered disruptive to many traditional IT roles. Consider the following traditional
role shifts as software development engages agile approaches (see Table 1.11). BAs have an opportunity to
be effective members of agile teams because they clearly have value to add, but they need to be prepared to
rethink their approach to business analysis. This agile approach includes a greater focus on collaboration,
knowledge sharing, and skills transfer. The agile perspective requires BAs with greater flexibility, greater
discipline, and the willingness to work in an evolutionary manner.
The Agile Extension to the BABOK ® Guide provides a summarization of the following business analysis
principles to employ on agile initiatives:
• When engaged in discovery:
◽◽ See the whole
◽◽ Think as a customer
◽◽ Analyze to determine what is valuable
40 Mastering Business Analysis Standard Practices

• When engaged in delivery:

◽◽ Get real using examples
◽◽ Understand what is doable
◽◽ Stimulate collaboration and continuous improvement
◽◽ Avoid waste

In Real Life . . .

I had the opportunity to deliver an agile business analysis course to 25 uni-

versity employees and consultants who were involved in implementing a suite
of applications to support their core business processes (a.k.a. enterprise
resource planning—ERP). Regretfully, I was unable to engage leadership prior
to the delivery; thus, I went in cold regarding the participants’ goals, agile
experience, and backgrounds. The room was configured in pods in order to
facilitate hands-on group activity. As we went through the introductions and
individual goals at the first table, it became painfully obvious that their agile
experience had ended in chaos, wasted effort, and finger pointing, which was
of no value to the university. Before the class, I had written on flip charts the
12 Principles of Agile and the 7 Business Analysis Principles on Agile Projects.
We stopped at that point and discussed which of the principles were followed
on their project. They identified that none of the principles were followed on
their project. The lesson learned here is that even agile requires structure and
value management.

Table 1.11 Role changes within agile

Traditional Agile
Traditional Role Responsibilities Agile Role Responsibilities Initial Disruption
Project Manager Dictate tasks Scrum Master, Servant leadership Ego stature erosion.
Coach, Tracker removing team
obstacles
Developer Build solution by Team Member Final hour
detailed approved The team members achievements no
requirements all contribute to the longer rewarded,
analysis, design, rather accountable.
build, and testing of
Tester Test solution by Team Member the solution. Provide No formal
detailed approved daily status of documentation to
requirements and progress. test.
technical design
Business Analyst Gatekeeper to ensure Team Member, Provide just enough Is the BA role
all communication Product Owner, information just needed—after all, the
between the business Scrum Master in time through business is involved
and solution providers a conduit that and can provide
is disseminated opens the lines of needs.
through the BA. communication. This
Boiler-plate formal role becomes the
documentation. Value Manager.
 Introduction 41

These five perspectives do not presume to represent all of the possible perspectives from which busi-
ness analysis is practiced. These perspectives are further discussed in the BABOK® Guide and represent
some of the most common contexts of business analysis.

KEY BUSINESS ANALYSIS TERMS, CONCEPTS, AND DEFINITIONS

As in any profession, there is jargon used by those working in the field. In some cases, these words will
vary across industries and organizations and other times the same word will be used to mean different
things. This complicates the writing of a book like this while trying to ensure that the meaning is clear. In
this section, the goal is to provide some clarity to key business analysis jargon.

What Is a Requirement Versus Design Versus Business

Analysis Information?
The BA is expected to communicate solution needs and direction. What is this output called? Tradition-
ally, we have described these as requirements because customarily, the BA worked in the IT perspective.
A requirement is defined as a condition or capability that is necessary and is a usable representation. A
requirement represents what is needed for a product, service, or result. In reviewing business analysis
literature, you will discover that there isn’t any direction regarding how to format a requirement for every
business analysis effort. The BA is free to use any format that will convey the need, condition, or capability
in such a way as to promote understanding for all stakeholders. Some examples of the formats used to
express requirements include:
• A sentence (as in “The system shall . . .)
• A structured sentence (as in a business rule)
• A table or spreadsheet (as in a decision matrix)
• A diagram (as in a workflow)
• A prototype or simulation (as in a screen mock-up)
• A graph (as in acceptance criteria)
Most seasoned BAs have lived by the mantra that “My job is to define the what not the how—the how is
the design.” As the business analysis perspectives grow beyond just the IT perspective, the line begins to
blur between requirement and design, but a few things hold true:
• Requirements are independent of the design
• There may be (and likely are) multiple designs that could realize the requirements
• There is (and always has been) a difference between the conceptual design and technical design
While a requirement is focused more heavily on the needs of the stakeholders, design is more focused on
the solution and examining the value of building a solution. The design focuses on understanding how the
solution may realize intended value. The design representation may be a document (or set of documents)
or whiteboard capture and can vary widely depending on the circumstances. It could be argued that the
BAs working in the IT perspective over the years have performed conceptual design since they produced
prototypes, report mock-ups, data mapping, and process modeling—all of which do dictate design, but
42 Mastering Business Analysis Standard Practices

not the actual technical implementation design. Prerequisites when it comes to elaborating this concep-
tual design are: (1) a clear understanding of the need, (2) actors’ motivations, (3) some level of functional-
ity involved, and (4) some level of understanding of the information received, transformed, and provided.
So, there is some level of requirement understanding prior to developing the design.
With these definitions of requirements and design, it is easy to see that one person’s design may be
considered another person’s requirement. Both requirements and design may be high level or low level
depending on the purpose for consuming the information. Let’s face it, most folks discuss the why and the
what in the context of the how, so this elicitation and collaboration is an iterative and recursive discussion
of requirements and design. The BA must consider what formats and level of detail will be most appropri-
ate based on the audience, context, and purpose for communicating the information. Table 1.12 provides
some examples to differentiate requirements and design.
This leveling of requirements and design provides BAs an opportunity to express the decomposition of
requirements and design definition. In the subsequent paragraphs, we provide BA standards for naming
these levels and types of business analysis information. Based on the industry and organizations, these la-
bels may vary—just ensure that the aspects of level and type are captured in your variation. The important
aspect of creating the levels and types is that it forces decomposition (high to low levels) and reminds the
BA to elicit and elaborate the different types of requirements. Without these levels and types, the BA is less
confident that a thorough analysis is complete.

In Real Life . . .

I was working as a business strategist on a multi-year initiative to reinvent

the way the organization did business. In the initial discovery workshop,
we reached a consensus on a functional decomposition of their business.
To accomplish this, we had the business define their important aspects of
mortgage processing on 4×5 inch yellow sticky notes. These sticky notes
were arranged in a hierarchical fashion, which provided four major domains
(chunks) that were further defined beneath each domain to elaborate the mid-
level elements. This provided us a big picture perspective of functionality and
dependencies, and then allowed us to iteratively attack this large-scale initia-
tive. We called it the Yellow Box diagram with our stakeholders.
Two years into the project, one of the stakeholders came by my desk and
asked if I still had the Yellow Box diagram because he needed to come out
of the weeds and see where this piece he was working on fit into the whole.
Luckily, I still had it so he could make the connection. This project was follow-
ing an iterative methodology, but decomposition is valuable for all frameworks.

Decomposition of requirements (sometimes referred to as levels, types, classifications, or categories of

requirements) includes:
• Business requirements: describe why the business wants/needs the solution. Some stakeholders may
consider these to be goals or objectives. These business requirements are the justification for en-
gaging in these change initiatives—not the solution.
• Stakeholder requirements: describe what the stakeholders (particularly the users) will need to do.
These stakeholder requirements are likely a functional decomposition of the solution into defined
 Introduction 43

Table 1.12 Examples of requirements and design

Requirement Design
The system will provide payroll processing for employees. The solution approach is to outsource the payroll
processing with a specialized vendor.
If the required submitted company information is Screen mock-up of incomplete submitted company
complete, then update information, or else provide error. information with error depicted.
The system will provide a view of aged accounts Dashboard sketch of aged accounts receivable.
receivable.
The organization must provide a strategic view of its Defined enterprise architecture framework.
enterprise.
The system will streamline the accounts receivable Update to accounts receivable clerk’s standard operating
process by automating the payment receipt steps in the procedures.
process.
The system will ensure all contract negotiations are Creation of the contract champion role and responsibilities
progressing through the contracting life cycle. within the organizational structure.

goals that the users would expect to have fulfilled through the solution. The stakeholder require-
ments should trace to the business requirements in order to ensure that there is fulfillment of the
goals as well as to reduce the risk of over-building a solution that was not funded or intended.
• Solution requirements: describe the functions and features that are required of the solution at a level
that allows for the development of the solution. These solution requirements trace to the stake-
holder requirements. These solution requirements are typically categorized further into:
◽◽ Functional requirements: describe actor behavior and the information (data) being man-
aged. When we consider actor behavior, there is likely some aspect of information involved
whether that is creating new data, reading/reviewing data, updating data, or deleting data
(referred to as CRUD functions). This category is likely further divided between process,
data, and rules.
◽◽ Nonfunctional, quality of service, or product quality requirements: describe the conditions
that the system must maintain along with the system qualities. There are many categoriza-
tion schemes of these nonfunctional or quality of service requirements. The categorization
scheme will vary based on a number of conditions such as the methodology being used,
business analysis perspective, enterprise industry, enterprise environmental factors, organi-
zational process assets, organizational systems, project type, etc. The categorization scheme
should be flexible enough to meet the enterprise needs; however, some categorization is im-
portant in order to ensure the BA has not missed any requirements. For instance, if the
BA has this classification scheme, it becomes a reminder that during elicitation and anal-
ysis, these types of requirements must be considered. A common scheme depicted in the
BABOK® Guide includes:
$$ Availability: measures the operability and accessibility required for users—often ex-
pressed in terms of percent of uptime or downtime
$$ Compatibility: measures the operational effectiveness of the solution with other compo-
nents in the environment
44 Mastering Business Analysis Standard Practices

$$Functionality: measures the degree of meeting the user’s needs, including suitability, ac-
curacy, and interoperability
$$ Maintainability: designates how easy it is to correct a defect or to modify the software
and is necessary for software that will undergo frequent revisions or is being built quickly
$$ Performance efficiency: measures how well a solution or component performs its des-
ignated functions with minimum consumption of resources and is often expressed as
response time
$$ Portability: includes the effort required to migrate a piece of software from one platform
to another and internationalizing and localizing the software
$$ Reliability: measures the probability of the software executing without failure as a per-
centage of operations that should complete correctly or the average length of time the
system should run before failing
$$ Scalability: measure of a system’s ability to grow over time in order to accommodate more
data, processing capacity, handle increased amounts of work, etc.
$$ Security: includes ways to protect solution content or solution components from acciden-
tal or malicious access, user authentication and access, modification, destruction, protec-
tion, or disclosure
$$ Usability: includes the ease with which a user can learn to use the solution, organizational
user interface design standards, and consistency with other systems in use
$$ Certification: includes limitations on the solutions that are required in order to meet
standards or industry conventions
$$ Compliance: includes constraints and limitations associated with regulatory, financial, or
legalities based on the context or jurisdiction
$$ Localization: includes local languages, laws, currencies, cultures, spellings, and other
contextual characteristics of users based on the context of the initiative
$$ Service level agreements: formally agreed-upon constraints of the solution by both the
provider and the solution user
$$ Extensibility: measures the ability of a solution to integrate new functionality
These types of requirements should trace to the functional or stakeholder requirement in which
they should be realized. If no trace exists, this requirement is an orphan, so to speak, and will never
be initiated.
• Transition requirements: define the temporary capabilities that are essential to migrate from the
current state to a future state environment. Requirements that fall into this category include con-
version of data from the current system, ongoing work of parallel systems, business continuity,
process changes, and training needed to address skill gaps.
Other types of requirements that the PM is responsible for managing include:
• Project requirements: define the actions, processes, and other conditions that the project needs to
satisfy. These requirements focus on the execution of the work required to deliver the solution.
• Quality requirements: define the criteria needed to ensure completion of project deliverables and
demonstrate compliance with identified standards and quality metrics. A deliverable is a unique
 Introduction 45

and verifiable work product or outcome that is required to be provided to stakeholders upon com-
pleting a process, phase, iteration, project, or initiative. Quality requirements are associated with
project quality, while nonfunctional requirements are associated with product quality.
• Program requirements: define the specifications and outcomes for successful implementation and
delivery of the program benefits.
Decomposition of design to satisfy requirements:
• Solution approach: defines the design direction that the enterprise will use to realize the solution
to the problem needing to be solved or preventing the opportunity to be exploited. Through this
solution approach selection, the business case is better informed to estimate the cost of the solu-
tion; hence, this is not a detailed analysis of vendors if the solution approach is a COTS packaged
solution—­rather a rough order of magnitude (ROM) may be derived for financial analysis. Cer-
tainly, a custom IT build is estimated at a higher cost than a COTS solution. The analysis of the
solution approach requires definition, verification, and validation of business and stakeholder re-
quirements to ensure the selected solution approach(es) are the best fit to meet stakeholder needs.
Typical solution approaches include:
◽◽ Build: this approach seeks to create a custom solution to meet the need. An expert (in-house
or contracted) will assemble, construct, and develop the solution. This approach includes
modifying an existing solution and seeks out the most user-centric approach to the solution.
◽◽ Buy: this approach seeks to purchase a product or service that is owned by and maintained
by a third party (vendor). The solution components are selected from a set of offerings that
most closely fulfill stakeholder needs. This approach assumes that a best-in-class solution
is being procured; hence, the users will adjust their processes to accommodate the solution.
◽◽ Combination of build and buy: this approach recognizes that some components are bought
while some aspects will need to be created.
◽◽ Process improvement: this approach allows for actor (human and non-human) processes to
be changed in order to reach a more efficient solution.
◽◽ Organizational structure redesign: this approach is identified due to recognition that the ex-
isting organizational structure is preventing its ability to adopt and adapt to change. The
organizational structure may be too complex or too simple to allow a solution to perform
effectively. BAs must consider informal relationships in addition to the formal structure. In
addition, the chosen organizational structure was likely created to ensure that interactions
with external parties (customers, vendors, and regulators) are supported. In an organiza-
tional redesign, it is easy to keep the focus internal to the organization, so the BA should
ensure that these external interactions will be supported.
• Design options: provide guidance for how the requirements are realized by the solution or solution
components. Design options are typically more tactical and multiple options may be explored to
meet the requirements. This exploration will likely promote additional questions and encourage
the iteration through requirements analysis. Through these design option communications, there
46 Mastering Business Analysis Standard Practices

are likely trade-offs and negotiations that the BA will facilitate. Figure 1.14 depicts this iteration of
requirements and design. Some examples of design options elaboration include:
◽◽ Solution visualization (low fidelity)
$$ Report mock-up
$$ Screen flow (storyboard)
$$ Screen mock-up
◽◽ Solution visualization (high fidelity)
$$ Screen design
◽◽ Non-human actor interface
$$ Data mapping
$$ Sequence diagrams

Business analysis information comprises all of the information BAs elicit, create, compile, and
disseminate—­any kind of information at any level of detail that is used as an input or output to business
analysis work. Going forward in this book—as well as the IIBA and PMI definition—the term business
analysis information will refer to any information that is used by or produced by the BA. Examples
of business analysis information include elicitation results, requirements, assumptions, constraints,
dependencies, risks, issues, designs, solution scope, collaboration decisions, and change strategy. In
cases where specific types of business analysis information should be referenced, that specific type will
be identified.
Before moving to the next concepts, it seems appropriate to discuss some generic risks that would affect
the business analysis information effort. The BA and project leaders (the sponsor and the PM) should re-
view these risks and assess the likelihood of an impact to the initiative. Those risks in which the likelihood
and/or impact is high must have an agreed-upon course of action should these emerge during the business
analysis effort. Some risks to review include (but are not limited to):
• Insufficient stakeholder involvement: consider communicating the level of engagement required for
a successful solution with stakeholders, along with an escalation plan due to unavailability. This
engagement-level agreement is likely more valuable than the business analysis information sign-off
to the initiative.
• Creeping user requirements: ensure the scope definition (to include business and stakeholder re-
quirements and solution approach) is clearly defined. Change will occur; however, when it does,
the BA will identify the new user request as scope creep and follow the change control process to
either update scope or remove the new request. Scope creep occurs when features and functional-
ity are added without addressing the effects on the timeline, costs, and resources; or adding scope
without the customer’s approval. Scope creep can include product scope or project scope.
• Ambiguous business analysis information: ambiguity reveals itself when multiple readers have a dif-
ferent understanding of the same information. The BA should engage stakeholders in iterative, in-
formal reviews of the requirements. Of course, the BA is not intentionally writing the requirements
to be ambiguous. Only during these discussions will ambiguous requirements reveal themselves.
• Gold-plating: gold-plating is akin to creeping user requirements; however, gold-plating could come
from the business stakeholders or solution stakeholders. Gold-plating is the act of adding features
that do not add value or that add value but are not part of the scope definition. An appropri-
ate analogy might be purchasing a designer dress when an off-the-rack dress will serve the same
 Introduction 47

BPM Approach? –
Orientation? – Six Sigma,
Functional, Market, TQM, Lean,…?
Functional/Market Matrix,
Business Requirements or Projectized
and Stakeholder Requirements Solution Approach
Goals

uct onal

Im
Enterprise Strategy and Objectives

Pro veme
ure

pro
i
Re nizat
Business Problem Resolution

ces nt
Exploitation of Opportunities

str

s
a
Org
Support Constraints
Core Business Process People, Organizations, Rules, Technical Aspect
Information Needs Regulations, Policies,
Guidelines, Current Processes

Build, Buy,
Bend,
Outsource?

Solution Requirements Design Options

Non-Human
Visualization
Interaction

Process Data
Flows Mapping
Functional Nonfunctional
Sequence
Storyboard
Diagram

Mock-up

Technical Design
Transition Requirements Visualization
Non-Human
Interaction

• Data Conversion
Graphics / Code Base
• Training Color Differences
• Ongoing work of parallel systems
• Business continuity Style
Compliance
Data
Translation
• Process changes
UI Controls

Figure 1.14 Requirements and design iteration

48 Mastering Business Analysis Standard Practices

purpose. The BA must ensure that scope is clearly defined and a change control process is in place
to combat this risk.
• Minimal specification: as discussed previously in the Business Analysis Perspectives section of this
chapter, the business analysis information specification level and timing will vary greatly. It is key
that all stakeholders are aware of and agree with the specification level and timing. Without enough
information, the solution team’s work will likely be stalled or require rework.
• Overlooked user groups: the BA ensures that thorough stakeholder analysis is performed. When
user groups are overlooked, the following are likely missed:
◽◽ Interfaces: must discover these early due to impact on scope
◽◽ Requirements: these impacted users will have requirements that must be met and will likely
impact scope and rework
◽◽ Design definition considerations: these impacted users may have special considerations that
influence the design and will likely impact scope and rework
◽◽ Stakeholder engagement opportunities: these users feel overlooked, hence insignificant to the
project; they are not as likely to support the project or the BA on future initiatives
• Inaccurate planning: planning for the business analysis effort is a critical step toward ensuring effi-
cient and thorough business analysis is performed. Without this plan, the BA has no ammunition
for unrealistic time frames, and typically, this results in incomplete business analysis information
being passed on to the solution team. The cost of rework grows exponentially as the solution de-
velopment moves through the phases of the SDLC.
• Impact on reputation: the ability of the BA to elicit, analyze, collaborate, and gain ongoing consen-
sus of the business analysis information is critical to performing business analysis. If this output
does not meet the needs of all stakeholders given the consideration of project type, perspective,
and SDLC approach, the BA’s reputation will likely take a hit. The BA must reinforce with project
leaders the importance of business analysis information—the right level at the right time.

What Is a Project Versus Program Versus Initiative Versus Operation?

PMI defines a project as a temporary endeavor undertaken to create a unique product, service, or result. As
practitioners, that means a project has a beginning and an end and that it creates something distinctive.
Some projects will last longer than others, but if there is not an end, it’s possible the practitioner is working
on an operation or a program. An operation is oftentimes a transition as the result of a project ending or
an ongoing effort to sustain the business. Operations management is running and controlling constant
production of products and/or services.
A program is different than a project. A program includes projects that are associated, including ini-
tiatives and activities that are controlled in a synchronized way to achieve coordinated benefits that
are greater than individual benefits. A program can last for a very long time. Consider NASA’s space
program—­it has been in existence since October 1, 1958. While the space program has been around for
decades, the projects that support the space program have evolved over this same time. Just like projects,
programs can end at an enterprise when they are no longer in support of the vision, mission, and goals
of the business. According to the whitepaper by PMI, Business Analysis: Leading Organizations to Better
 Introduction 49

Outcomes, business analysis professionals spend roughly 73% of their efforts working and applying busi-
ness analysis to projects and programs. This increases to 83% for business analysis professionals who are
working in highly mature organizations. The remaining time that business analysis professionals have
available is spent on overhead tasks and activities for projects and programs.
An initiative is defined by the IIBA as a specific project, program, or action taken to solve some business
problem(s) or achieve some specific change objective(s). Initiatives can be:
• Strategic
• Tactical
• Operational
This definition reinforces the broadness of the business analysis profession. Multiple perspectives (defined
earlier in this chapter) can be used throughout an initiative.
Portfolios are at the top of the hierarchy of these definitions. A portfolio includes projects, programs,
subsidiary portfolios, initiatives, and operations. Managing all of these elements within a portfolio helps
an enterprise to accomplish its strategic goals and objectives. Figure 1.15 is designed to show the interac-
tions between portfolios, programs, initiatives, and projects.
As shown in these definitions, not every request that a BA receives is a project and not all business anal-
ysis endeavors are equal. First, the BA needs to determine whether the request is for a project, program,
initiative, or operation. Next, the BA needs to consider the factors contained in this book to determine
how to best approach the business analysis effort.
Going forward, the term initiative will refer to any portfolio, program, initiative, or project worked
on by the BA. In cases that specific types of initiatives should be referenced, that specific type will be
identified.

Portfolio

Program
or Initiative Project or
Program
Initiative

Project or
Initiative Project Project

Figure 1.15 Portfolio, program, initiative, and project interactions

50 Mastering Business Analysis Standard Practices

What Is a System Versus a Solution Versus a Process Versus an

Application Versus a Software System?
The terms system, solution, process, and application are generally used in business interchangeably. But,
there are times that the differentiation allows for more concise discussion; hence, in this text and accord-
ing to other experts, here are the definitions.
Systems are at play in all aspects of our lives. A system is simply a set of components (manual, auto-
mated, or a combination of both) that work together to accomplish a goal. An example of a system is
paying bills. Individuals, as well as organizations, need a system to pay their bills. The enterprise environ-
mental factors that are described later in this section determine many of the characteristics of a system.
Now there may be many solutions for a system, and typically a change initiative will provide a new
solution for a system. Solution is defined as a specific way of satisfying one or more needs in a context. It
is not very often that the BA is assigned a project that is an entirely new functionality. But thinking back
to the example of paying bills, the system has certainly evolved over the years to provide many solutions
for doing so:
• Bartering goods
• Paying with cash
• Writing a check and delivering to the vendor
• Vendor initiated draft from financial institution
• Online bill pay
• Wire transfers
All of these represent different solutions that could be part of a system that is used to pay bills.
A process is most similar in definition to a system; however, a system may be made up of many processes
in order to accomplish the desired outcome. A process is defined as a set of activities that are designed
to accomplish a specific objective by taking one or more defined inputs and turning them into defined
outputs. Typically, stakeholders will talk in terms of process when manual steps are involved, but discuss
the system when there are automated components involved. Within the business analysis perspective of
BPM, we will use the term process.
An application is a software program that runs on your computer. Web browsers, e-mail programs,
word processors, games, and utilities are all applications. The word application is used because each pro-
gram has a specific application for the user. For example, a word processor can help an author write a
book, while a video game can prevent that author from getting the book completed.
On the other hand, a software system consists of programs that run in the background, enabling appli-
cations to run. These programs include assemblers, compilers, file management tools, and the operating
system itself. Applications are said to run on top of the system software, since the system software is made
of low-level programs.

What Are Stakeholders Versus Actors Versus Users?

These terms are also used interchangeably, but as the BA, there are important differences to note.
A stakeholder is a group or individual with a relationship to the change, the need, or the solution. A
stakeholder is any person, group, or organization that may impact, be impacted by, or perceive itself to
 Introduction 51

be impacted by a project, program, initiative, operation, or portfolio. The biggest risks to the business
analysis effort revolve around stakeholders—which could be missed stakeholders or lack of stakeholder
involvement. The first step in mastering business analysis is understanding your stakeholders, which will
be elaborated on in the upcoming chapter, including stakeholder categorization.
An actor is a person, device, or system that fulfills a specific role in interacting with a solution. So,
when applying this definition in combination with the definition of a stakeholder, a human actor always
has a relationship to the change; hence, there is always a stakeholder. Even though the non-human actor
is not a stakeholder, it is likely that the BA will identify an owner of that non-human actor and uncover a
stakeholder that otherwise could have been overlooked.
A user or end user is defined as a stakeholder who interacts with the system and will use the product.
With this definition, a human actor is a user—making all users stakeholders. Some texts will differen-
tiate between the user and end user. The end user is considered to be the person for whom the solution
was ultimately created and the user is the community that is required to maintain the solution. Exam-
ples include:
• End user:
◽◽Internal business worker who is a payroll processor for the payroll system
◽◽Retail customer who will purchase products online
◽◽ Automobile assembler to install dashboards
• User:
◽◽ System administrator
◽◽ Database administrator
◽◽ Operational support

The complexion of the end user has undergone many changes in the last few decades. Consider this short
summary end user evolution:
• 1950s: end users did not interact with the mainframe; computer experts programmed and ran the
mainframe.
• 1960s–1970s: end users were generally programming experts and computer scientists.
• 1980s–1990s: the general public began using computer devices and software for personal and work
use. Some of these end users had high technical expertise and some did not. The challenge to
develop solutions to meet the needs of the technically savvy users while saving the low techni-
cal expertise users from themselves presented some difficulties. This required some user-centric
considerations.
• 2000s: user-centric design considerations became mainstream.
• 2010s: users now want to have more control over the systems they operate so they solve their own
problems and want to be able to change, customize, and tweak the systems to suit their needs.
The drawback would be the risk of corruption of the systems and data that the user has control
of due to his/her lack of knowledge as to how to properly operate the computer or software at an
advanced level.
BAs and solution providers are challenged to consider a good end user experience, while ever-increasing
high levels of security are required.
52 Mastering Business Analysis Standard Practices

What Are Enterprise Environmental Factors Versus Organizational

Process Assets?
An enterprise environmental factor (EEF) includes conditions that the BA does not have control over.
EEFs influence, constrain, and direct the initiative. An EEF can be external or internal to an organization
and serves as a necessary input to all business analysis activities. An organizational process asset (OPA)
includes plans, processes, policies, procedures, and knowledge bases that are specific to an organization.
An OPA is internal to the enterprise and serves as a necessary input to all business analysis activities. To
perform effective business analysis work, you need both EEFs and OPAs (see Table 1.13).

Table 1.13 EEFs and OPAs

Process, Policy, and Corporate Knowledge
External EEFs Internal EEFs Procedural OPAs Base OPAs
Academics Architecture and Change control processes Business knowledge
infrastructure repositories and sources
Commercialism Employee competence Financial controls Configuration management
processes knowledge repositories
Business analysis Geography for facilities and Guidelines and criteria Data repositories for
professional standards resources metrics
Finances Human resources Issue and defect Historical information and
management policies and management processes lessons learned knowledge
procedures repositories
Government or industry Information technology Organizational Issue and defect
standards communication management data
requirements for business repositories
analysis processes
Legal and contracts Business analysis results Processes, policies, or Team and SME
reuse and interest procedures Knowledge OPAs
Marketplace Market research and testing Project closeout guidelines Future state needs and
or requirements expectations
Physical environment Organizational culture, Project life cycles and Information and knowledge
structure, and governance methodologies
Social and cultural Other resource policies, Requirements management Insights and perceptions
influences procedures, and availability tool processes
Social and cultural issues Security policies, Risk management Product knowledge and
procedures, and rules templates information
Stakeholder expectations Stakeholder expectations Specific organizational
and risk appetite and risk appetite standards and policies
Standardized guidelines
Templates
Adapted from The PMI Guide to Business Analysis
 Introduction 53

BUSINESS ANALYSIS CENTER OF EXCELLENCE AND BUSINESS

ANALYSIS COMMUNITY OF PRACTICE
A Business Analysis Center of Excellence (BACOE) includes a team of employees or group of people
who join together to collaborate and create best practices to use for business analysis work. Business
Analysis Forum or Center of Business Analysis Practice are additional names that are preferred by some
organizations. Creation of a BACOE is a strategic advantage for enterprises who want to mature, con-
tinuously improve, and create consistencies within their business analysis efforts. The BACOE can also
benefit organizations that want to provide career development, lunch and learns, mentoring, and growth
opportunities for BAs by being centrally managed. A BACOE primarily focuses on business analysis and
is an organizational process asset.
A Business Analysis Community of Practice (BA CoP) includes practitioners who create shared prac-
tices and is also an organizational process asset. A Business Analysis Competency Center is an additional
name that is preferred by some organizations. A BA CoP starts with a champion and core group, then ex-
tends to other stakeholders, which is different than a BACOE. A BA CoP is also concerned with maturing,
continuously improving, identifying specific processes, using specific OPAs, conformance, and creating
consistencies within the entire project community—including all stakeholders. Support from the entire
project community could include a PMO and/or enterprise PMOs.
The BACOE or BA CoP can provide you with an excellent opportunity to network, learn from other
BAs, and help you with career development.

HONE YOUR BUSINESS ANALYSIS INFORMATION

ELABORATION TECHNIQUES
The BA should be equipped with techniques to manage business analysis information. As depicted in
Figure 1.16, the cycle for elaborating business analysis information is an iterative process. As business
analysis information is acquired, the BA is seeking collaboration on the information. With that collab-
oration, more questions surface and more information is elicited. As the business analysis information
gained is analyzed, the BA is looking for validity, corroboration, efficiencies, existing patterns, gaps, and
conflicts. However, this analysis is likely to require further collaboration and elicitation—at some point,
driving to stakeholder consensus. This consensus may require iteration back through the elicitation,
collaboration, and analysis. The techniques the BA employs for each of these aspects may vary based on
many factors such as business analysis perspective, stakeholder preferences, the specific point in the life
cycle of the initiative, or project type; but these aspects will be required of any business analysis effort.
Table 1.14 provides a map of commonly used techniques, as referenced by the IIBA and PMI for busi-
ness analysis efforts. Table 1.14 is not intended to dictate use of the techniques, but rather to provide
guidance as needed. Business analysis perspectives are indicated on the table. You will notice that some
techniques are not referenced in a particular perspective—however, given the BA’s own expert judg-
ment, one should not feel prohibited from using the table. As this book elaborates the steps to mastering
business analysis in the following chapters, more detail will be provided on how to perform the steps
and build on these techniques.
54 Mastering Business Analysis Standard Practices

Elicitation Collaboration

Analysis

Consensus

Figure 1.16 Elaborating business analysis information

Table 1.14 Techniques generally used in these contexts

Aspects of
Elaborating
Mastering Business Analysis Standard Business
Practices: Seven Steps to Achieving the Analysis Business Analysis
Techniques Next Level of Competency Information Perspectives

Business Architecture
4. Set Initiative Scope

Business Intelligence
Requirements and
 lan the Business
Business Context

Design Definition
 evelop Solution
 nderstand Your

 nderstand the

Business Process
6. Manage Scope
Analysis Work
Stakeholders

 valuate the

Collaboration

Management

Information
Technology
Consensus
Solution
Elicitation

Analysis

Agile
2. U
1. U

5. D
3. P

7. E

Acceptance and Evaluation

X X X X X X X X X X X X X
Criteria
Backlog Management X X X X X X X X X X X
Balanced Scorecard X X X X X X X X X X
Benchmarking and Market
X X X X X X X X
Analysis
Brainstorming X X X X X X X X X X X X
Business Capability Analysis X X X X X X X X X
Business Cases X X X X X X X X
Business Model Canvas X X X X X X
Continued
 Introduction 55

Aspects of
Elaborating
Mastering Business Analysis Standard Business
Practices: Seven Steps to Achieving the Analysis Business Analysis
Techniques Next Level of Competency Information Perspectives

Business Architecture
4. Set Initiative Scope

Business Intelligence
Requirements and
3. Plan the Business
Business Context

Design Definition
5. Develop Solution
1. Understand Your

2. Understand the

Business Process
6. Manage Scope
Analysis Work
Stakeholders

7. Evaluate the

Collaboration

Management

Information
Technology
Consensus
Solution
Elicitation

Analysis

Agile
Business Motivation Model
X X X X X X X
(BMM)
Business Process
X X X X X X
Architecture
Business Rules Analysis X X X X X X X X X X X X
Business Value Definition X X X X X X X X
Change Control Boards
X X
(CCB)
Collaborative Games X X X X X X X X
Concept Modeling X X X X X X
Customer Journey Map X X X X X X X X
Data Dictionary X X X X X
Data Flow Diagrams X X X X X
Data Mining X X X X
Data Modeling X X X X X X X X X X X
Decision Analysis X X X X X X X X X X X X
Definition of Doneness X X X X X
Document Analysis X X X X X X X X X X X X X
Estimation X X X X X X X X X X X X X X
Failure Mode and Effect
X X X X X
Analysis (FMEA)
Financial Analysis/Valuation
X X X X X X X
Techniques
Focus Groups X X X X X X X X X
Functional Decomposition X X X X X X X X X X X
Gap Analysis X X X X X X X
Glossary X X X X X X X
House of Quality/Voice of
X X X X X X X X X X
Customer
Impact Analysis X X
Continued
56 Mastering Business Analysis Standard Practices

Aspects of
Elaborating
Mastering Business Analysis Standard Business
Practices: Seven Steps to Achieving the Analysis Business Analysis
Techniques Next Level of Competency Information Perspectives

Business Architecture
4. Set Initiative Scope

Business Intelligence
Requirements and
3. Plan the Business
Business Context

Design Definition
5. Develop Solution
1. Understand Your

2. Understand the

Business Process
6. Manage Scope
Analysis Work
Stakeholders

7. Evaluate the

Collaboration

Management

Information
Technology
Consensus
Solution
Elicitation

Analysis

Agile
Input, Guide, Output,
X X X X
Enablers (IGOE)
Interface Analysis X X X X X X X X X X
Interviews X X X X X X X X X X X X
Item Tracking X X X X X X X X X X X
Kaizen Event X X X X X X X X X
Kano Analysis X X X X X X X X X
Lessons Learned
X X X X X X X
(Retrospectives)
Lightweight Documentation X X X
Metrics and Key Performance
X X X X X X X X X X X X X
Indicators (KPIs)
Mind Mapping X X X X X X X X
Nonfunctional Requirement
X X X X X X X X X
Analysis
Observation X X X X X X X X X
Organizational Modeling X X X X X X X X X X
Prioritization X X X X X X X X X
Process Analysis X X X X X X X X X X X X X
Process Modeling X X X X X X X X X X X X X X X
Product Portfolio Matrix X X X X X X X X X X X
Project Portfolio Analysis X X X X X X X
Prototyping X X X X X X X X X X X X
Purpose Alignment Model X X X X X X
Real Options X X X X X
Relative Estimation X X
Requirements Configuration
Management System (RCMS)
X X X X X
and Version Control System
(VCS)
Continued
 Introduction 57

Aspects of
Elaborating
Mastering Business Analysis Standard Business
Practices: Seven Steps to Achieving the Analysis Business Analysis
Techniques Next Level of Competency Information Perspectives

Business Architecture
4. Set Initiative Scope

Business Intelligence
Requirements and
3. Plan the Business
Business Context

Design Definition
5. Develop Solution
1. Understand Your

2. Understand the

Business Process
6. Manage Scope
Analysis Work
Stakeholders

7. Evaluate the

Collaboration

Management

Information
Technology
Consensus
Solution
Elicitation

Analysis

Agile
Reviews X X X X X X X X
Risk Analysis and
X X X X X X X X X X X X X
Management
Roadmap X X
Roles and Permissions Matrix X X X X X X X X
Root Cause Analysis X X X X X X X X X X X
Scope Modeling X X X X X X X X X
Sequence Diagrams X X X X X
Specification by Example X X X X X X X
Stakeholder List, Map, or
X X X X X X X X X X X X X X
Personas
State Modeling X X X X X X
Story Elaboration X X X X X
Survey or Questionnaire X X X X X X X X X X X
SWOT Analysis X X X X X X X
Theory of Constraints (TOC)
X X X X X X X
Thinking Processes
Traceability Matrix X X X X
Use Cases and Scenarios X X X X X X X X
User Stories X X X X X X X
Vendor Assessment X X X X X X X X
Workshops X X X X X X X X X X X X X
Legend:
X = The appropriate time to use the technique for the steps, elaborating business analysis information, and perspectives
X = The step in the book where the technique is explained

BUSINESS ANALYSIS JOURNEY MAP

The business analysis journey is an iterative process; hence a simple process model fails to do the job.
Instead, Figure 1.17 provides a business analysis map to guide you through the steps on the journey. We
suggest using this as a reference for any business analysis perspective and to vary the techniques that you
employ based on the initiative factors that you are presented.
 External Stakeholders

Business,
Step 1 – Understand Your Stakeholders
58
Organization, or
Enterprise Stakeholders

• Identify Stakeholders Domain Stakeholders

• Analyze Stakeholders Solution Delivery
Stakeholders
• Manage Stakeholders’ Collaboration
and Engagement
Solution

Marketing Marketing Marketing

Experiences Management Operations
Step 2 – Understand the Business Context
Customer
E-mail Marketing Marketing Data
Experience • Perform Needs Analysis
• Define Problem/Opportunity
Agile and Project
Mobile Marketing Testing
Management • Elicit/Analyze/Collaborate
Business Analysis Information
Display Advertising Optimization • Obtain Consensus

BHAGs Scope Definition Solution RADD

Step 2 Step 4 Step 5
Step 3 – Plan the Business Analysis Work
Elicit Elicit Elicit

• Determine Business Analysis Approach

Consensus
Consensus
Consensus

• Plan Business Analysis Work

Collaborate Analyze Collaborate Analyze Collaborate Analyze
• Plan Business Analysis Governance
• Plan Business Analysis Communication Plan
Mastering Business Analysis Standard Practices

Step 4 – Set Initiative Scope

• Elicit/Analyze/Collaborate
Business Analysis Information
• Obtain Consensus

Step 5 – Develop Solution Requirements and Design Definition As a credit card account holder,
I need to update my credit card information,
• Elicit/Analyze/Collaborate Business Analysis Information
so that my recurring payment clears.
• Obtain Consensus
Evaluate
the effects

Step 6 – Manage Scope

Isolate • Verify > Validate Requirements
implications Identify the
to costs and risks • Recommend Solutions
schedule
• Monitor Requirements and Design Definition
• Scope Change
Pinpoint the
necessary
work Step 7 – Evaluate Solution Analyze Communicate
Performance Measures with
Measurements Recommendations
• Provide Solution Design Feedback
• Requirement Allocation Support
Collect Measures
• Solution Team Support
• Monitor and Evaluate Solution
• Organizational Readiness

Figure 1.17 Business analysis journey map

 Introduction 59

SUMMARY OF KEY POINTS

Working as a BA is not just a job that we go to each day, but rather a profession that is supported by specific
tools, techniques, and processes that help organizations meet their goals. The BA may choose a general-
ized path or specialize in business analysis perspectives. We identified the five most common perspectives,
but know that as the business analysis space evolves in our ever-changing world, there will be additional
depths of these perspectives defined and new perspectives added. This chapter provided insights into key
terms that will be used going forward in subsequent chapters as we proceed through the steps to mastering
business analysis.

CHAPTER REFERENCES
1. Agile Modeling. Rethinking the Role of Business Analysts: Towards Agile Business Analysts? http://
www.agilemodeling.com/essays/businessAnalysts.htm.
2. Covey, Stephen R. (2008). The Speed of Trust: The One Thing That Changes Everything. Free Press,
New York, NY.
3. Dawson, Carla. (January 22, 2015). The Pros and Cons of Utilizing Agile Methodologies. http://www
.nearshoreamericas.com/agile-methodology-advantages-disadvantages.
4. Fernando, T. Shakthi (May 2014). Abstract: Changes in the Business Environment Brought by
Technology.
5. Green, Charles H. and Andrea P. Howe. (2011). The Trusted Advisor Fieldbook. John Wiley and
Sons, Hoboken, N.J.
6. Harmon, Paul. BPTrends (2016). The State of the BPM Market–2016. http://www.bptrends.com/
bpt/wp-content/uploads/2015-BPT-Survey-Report.pdf.
7. Hillman, Amy. (July 14, 2013). The Rise in Business-Analytics Degrees. http://www.huffingtonpost
.com/amy-hillman/the-rise-in-businessanaly_b_3273749.html.
8. International Institute of Business Analysis. (2015). The Agile Extension to the Business Analysis
Body of Knowledge (BABOK ® Guide). Version 1. Toronto, Ontario, Canada.
9. International Institute of Business Analysis. (2011). Business Analysis Competency Model. Version 3.0.
Toronto, Ontario, Canada.
10. International Institute of Business Analysis. (2017). Business Analysis Competency Model® v4 Com-
prehensive Edition. Toronto, Ontario, Canada. Toronto, Ontario, Canada.
11. International Institute of Business Analysis. (2017). IIBA® Global Business Analysis Core Standard:
A Companion to a Guide to the Business Analysis Body of Knowledge (BABOK ® Guide) v3. Version 1.0.
Toronto, Ontario, Canada.
12. International Institute of Business Analysis. (2015). The Guide to the Business Analysis Body of
Knowledge (BABOK ® Guide) v3. Toronto, Ontario, Canada.
13. International Institute of Business Analysis. (2017). Key Insights From the 2017 Global Business
Analysis Salary Survey. Toronto, Ontario, Canada.
60 Mastering Business Analysis Standard Practices

14. Lusk S., S. Paley, and A. Spanyi. (June 2005). BPTrends. Evolution of BPM as a Professional Discipline.
http://www.bptrends.com/publicationfiles/06-05%20WP%20ABPMP%20Activities%20-%20Lusk
%20et%20al2.pdf.
15. Page, Susan. (2010). The Power of Business Process Improvement. AMACOM.
16. Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge (PM-
BOK ® Guide) Sixth Edition. Project Management Institute, Newtown Square, PA.
17. Project Management Institute. (2015). Business Analysis for Practitioners: A Practice Guide. Project
Management Institute, Newtown Square, PA.
18. Project Management Institute. (2017). Business Analysis: Leading Organizations to Better Outcomes.
https://www.pmi.org/-/media/pmi/documents/public/pdf/white-papers/business-analysis-out
comes.pdf.
19. Project Management Institute. (2017). The PMI Guide to Business Analysis. Project Management
Institute, Newtown Square, PA.
20. Project Management Institute. (2016). Pulse of the Profession® 2016. http://www.pmi.org/learning/
thought-leadership/pulse/pulse-of-the-profession-2016.
21. PwC. What’s next for the data science and analytics job market? https://www.pwc.com/us/en/library/
data-science-and-analytics.html.
22. State of Performance Engineering 2015–2016. Survey: Is Agile the New Norm. May 25, 2015. http://
techbeacon.com/survey-agile-new-norm.
23. Ulrich, William and Neal McWhorter. (2011). Business Architecture: The Art and Practice of Busi-
ness Transformation. Meghan-Kiffer Press, Tampa, FL.
24. VersionOne®. 2015 State of Agile™ Survey. http://www.slideshare.net/WillyDevNET/state-of-agile
-development-survey-2015.
25. Whelan, Jonathan and Graham Meaden. (2012). Business Architecture: A Practical Guide. Gower
Publishing Limited, New York, NY.