Leveraging Business

Analysis for Project

Success
Leveraging Business
Analysis for Project
Success

Second Edition

Vicki James
Leveraging Business Analysis for Project Success, Second Edition
Copyright © Business Expert Press, LLC, 2019.

All rights reserved. No part of this publication may be reproduced, stored

in a retrieval system, or transmitted in any form or by any means—
electronic, mechanical, photocopy, recording, or any other—except for
brief quotations, not to exceed 250 words, without the prior permission
of the publisher.

First published in 2019 by

Business Expert Press, LLC
222 East 46th Street, New York, NY 10017
www.businessexpertpress.com

ISBN-13: 978-1-94858-081-6 (paperback)

ISBN-13: 978-1-94858-082-3 (e-book)

Business Expert Press Portfolio and Project Management Collection

Collection ISSN: 2156-8189 (print)

Collection ISSN: 2156-8200 (electronic)

Cover and interior design by S4Carlisle Publishing Services Private Ltd.,

Chennai, India

First edition: 2015

Second edition: 2019

10 9 8 7 6 5 4 3 2 1

Printed in the United States of America.

 Abstract
Only 39 percent of projects today are successful in adding value to the
product and the organization investing in the project. Nearly half of the
projects that fail do so because of “poor requirements management” (PMI
2014). Leveraging Business Analysis for Product Success explores the role
of the product manager in doing business analysis to set a project up
for success. It informs and educates product managers, project managers,
sponsors, and organization leaders on the prerequisites for project suc-
cess. This book goes beyond requirements management in exploring how
the product manager contributes to increased profitability through busi-
ness analysis: project selection, scope definition, and postimplementation
evaluation. The reader will learn about the history of business analysis,
the product manager’s role, professional organizations and resources to
support the profession, and what business analysis activities occur at each
phase of the project life cycle as presented in a case study throughout the
text. Product and project leaders will better be able to support the busi-
ness analysis needs of the project by understanding the skills, expertise,
tasks, resources, and time needed to do business analysis right and maxi-
mize the return on investment for each project.

Keywords
agile; business analysis; business analyst; business case; product manage-
ment; product manager; product owner; requirements; scrum; waterfall
 Contents
Foreword................................................................................................ix
Introduction.........................................................................................xiii
Part 1 Business Analysis Explained ........................................... 1
Chapter 1 Business Analysis Defined..................................................3
Chapter 2 The History of Business Analysis........................................9
Chapter 3 The Many Hats of the Business Analyst
(Typical Roles).................................................................17
Part 2 What Your Business Analyst Should Be Doing for You ...19
Chapter 4 The Setup.........................................................................21
Chapter 5 Before the Project.............................................................23
Chapter 6 Initiating the Project........................................................31
Chapter 7 Planning the Project.........................................................39
Chapter 8 Working the Project.........................................................51
Chapter 9 Monitoring and Controlling the Project...........................67
Chapter 10 Finishing the Project........................................................75
Chapter 11 After the Project...............................................................83
Part 3 Organizational Strategies for Business Analysis............. 87
Chapter 12 Understanding the Project Track Record..........................89
Chapter 13 The Project Power Team...................................................93
Chapter 14 Business Analysis Communities.......................................99
Afterword............................................................................................103
Appendix A.........................................................................................105
Appendix B.........................................................................................109
Appendix C.........................................................................................111
Appendix D.........................................................................................113
References............................................................................................117
About the Author.................................................................................119
Index..................................................................................................121
 Foreword

Product manager is the new business analyst! This is the theme of this
second edition.
A quick search of trends on Indeed.com shows that product manager
is fourth on the list of job titles in the software development category.

Source: Jobs Category Trends, Software Engineering, https://www.indeed.com/

jobtrends/techsoftware-category-trends (May 7, 2018)

This is a positive trend as often business analysts historically have been

pigeon-holed into a role heavily focused on requirements management.
Requirements management is just a small portion of the overall scope
of business analysis. The change to product manager is an indication of
an understanding of the true breadth of expertise and work needed to
­understand what drives value in the business.
One barrier to business analysis being taken seriously as a profession
is the historical use of analyst in the job title. You will read my discussion
x FOREWORD

with a peer who pointed out that analyst has the connotation of entry or
mid-level role. Product manager does a much better job of describing the
role that requires great skill and dedication in the practice of business
analysis to ensure products delivered add value to the organization. The
term business analysis professional will be used throughout the book to
cover a variety of job titles including, but not limited to, business analyst,
business systems analyst, product manager, and product owner.
I recently attended an International Institute of Business ­Analysis,
Seattle Chapter presentation, Product Management 101, by Angela
­
­Govila, where she describes product management in a nutshell.
Product management in a nutshell

1. Identify product market fit

2. Understand your customers and use cases
3. Determine target customer
4. Define success metrics
5. Establish hypothesis, validate and build feedback loop (a/b testing)
6. Design the minimum viable product (MVP) (prototypes, wireframing,
mock-ups)
7. Develop the product end to end (Agile, Scrum, Kanban)
8. Define product go to market (GTM) strategy and launch plan
9. Roll out product/launch
10. Measure feedback and continuously iterate

IIBA Seattle, presentation April 24, 2018, by Angela Govila—Visit https://

angelagovila.com/ for additional resources and information from Ms. Govila.

The above activities are noted alongside the complimentary section

What Your Business Analysts Should be Doing for You of this book.
I have come to realize that the original publication was a bit heavy
in the discussion of business analysis as it relates to creating internal,
­back-office solutions. This second edition provides additional informa-
tion on analysis for developing consumer-facing solutions.
Figures and trends are updated to the latest data available as of
May 2018.
 FOREWORD
xi

Finally, the discussion on Agile and Scaled Agile has been expanded to
accommodate this ever-growing trend.
I hope you enjoy Leveraging Business Analysis for Project Success, Second
Edition, but more importantly, I hope it brings about changes in your
organization that contribute to realizing an increase in the value delivered
from projects.
 Introduction

Challenges Today
Projects throughout the world are challenged. Think of your projects.
What percentage were completed on time, on budget, and with the antic-
ipated scope? What percentage never made it to the finishing line to land
in the big project junk pile in the sky? Organizations such as Gartner and
the Standish Group provide statistics each year that tell the same story.
The fact is only 36 percent of projects today are completed successfully,
with an additional 47 percent in the challenged category.

60%

50%

40%

30%

20%

10%

0%
2004 2006 2008 2010 2012 2014 2016

Challenged Failed Successful

Figure 1  Project resolution results from CHAOS research years

2004 to 2012. The Standish Group. 2014 and 2016, personal
correspondence. Jim Johnson, The Standish Group

The statistics on project success have not significantly changed in the

past 10 years, and neither have the cited reasons for the challenges that
the projects face.
The most cited reasons for challenged and failed projects are as follows:

1. Lack of clear requirements

2. Lack of executive support
xiv INTRODUCTION

Figure 2  Correlation between executive support, poor requirements,

and challenged projects

This book addresses both of these reasons for challenged projects. It

starts with the premise that lack of executive support contributes to the
lack of clear requirements. That’s right. It starts with the executives, not
with the unfortunate project line staff trying to do too much with not
enough time and the wrong set of skills. Figure 2 provides a visual of how
the reasons relate to result in the project challenges we see today.
Strategies for Project Sponsorship (Management Concepts 2013)1 pro-
vides ideas and information to project managers, product managers, and
business analysts to help get the needed executive support in general for
each project. Leveraging Business Analysis for Project Success focuses on
making the business case for strong business analysis by outlining the
executive and organizational support needed to mature organizations’
business analysis practice to improve project success rates. These books
together provide a holistic view on how to reduce the most common risks
that projects face today.

2014—A Turning Point

Business analysis gained a new proponent in 2014 that will change how
organizations view business analysis in the future. Well, to say a new pro-
ponent may be a bit strong as they have always had an interest in business
analysis. The organization I am talking about is the Project Management
Institute (PMI).2
In recent years, we have seen PMI taking a greater interest in b­ usiness
analysis with the latest editions of the Guide to the Project Management

1
V. James,  R. Rosenhead,  and  P. Taylor.  2013.  Strategies for Project Sponsorship
(­Virginia, VA: Management Concepts Press).
2
Project Management Institute (PMI), www.pmi.org
 INTRODUCTION
xv

Body of Knowledge (PMBOK Guide). The fourth edition, published in

2008, ­included Collect Requirements as a task for the first time (see the
next section for my thoughts on collecting requirements). You can see how
the role of business analysis has evolved for the PMI in their ­discussion
of the business case. The fourth edition states, “The requesting organiza-
tion or customer, in the case of external projects, may write the business
case.”3 Fast forward to 2013 and the release of the fifth ­edition, “  .  .  . 
such ­analysis is usually completed by a business analyst using v­arious
stakeholder inputs.”4 The sixth edition, published in 2017, now refers
the reader to Business Analysis for Practitioners: A Practical Guide. PMI
has fully embraced the fact that the business case is an artifact of business
analysis.

“Collect Requirements?”
I have a hard time with this as a project task. The International
­Institute of Business Analysis’s BABOK Guide refers to this activity
as elicit ­requirements. I think of project requirements like Easter eggs
at an Easter Egg Hunt. We can collect those that are right in front
of our face. But to get all of the Easter eggs, we need to do some
­analysis. We need to do a little digging, interview stakeholders (Dad),
and explore until we find the last Easter egg. Because if we don’t find
the last Easter egg, we may have a big stinky mess on our hands down
the road.
This is how we should treat our requirements to avoid a big stinky
mess in our projects. Thorough analysis makes for great requirements.

In 2012, the PMI introduced a new community of practice,

­Requirements Management Community of Practice. Here, PMI members
could share information and find education information on managing
­requirements. What came next should not be a big surprise.
In March 2014, the PMI announced a new credential program, P
­ roject
Management Institute Professional in Business Analysis (PMI-PBA).

3
PMBOK ® Guide, 4th edition, page 75.
4
PMBOK ® Guide, 5th edition, page 69.
xvi INTRODUCTION

While the credential name indicates that it is a general business analysis

credential, the information provided and examination content refer to
proficiency in requirements management within the project and program
context. This is a more narrow view of business analysis than the Certified
Business Analysis Professional (CBAP) credential offered by IIBA,5 which
extends beyond requirements management and the p ­ roject into manag-
ing solutions that add value to the business.
The year 2014 was truly the year of business analysis for the PMI,
with the publication of the PMI’s Pulse of the Profession: Requirements
Management—A Core Competency for Project and Program Success6
­
in A ­ugust of that year and the prerelease of Business Analysis for
­Practitioners—A ­Practice Guide in November.7

PMI’s 2017 annual global Pulse of the Profession study revealed that
“­inaccurate requirements gathering” remained a primary cause of proj-
ect failure (37 percent) in 2014 (up from 32 percent in 2013). This
fact, plus PMI’s focus on this practice area, led us to research this cause
of failure in-depth and publish our findings in this report. (Pulse of the
Profession, Executive Summary)

Note: Inaccurate requirements gathering is now attributed to 39 percent

of project failure as noted in the 2017 Pulse of the Profession.8

5
Credential offered by the IIBA. Credential holders have demonstrated 7,500 hours
of experience in business analysis activities in addition to 21 hours of education, and
have passed a rigorous exam proving expert knowledge in the area of business analysis.
6
A. Smith. 2014. “Requirements Management: A Core Competency for Project and
Program Success.” PMI’s Pulse of the Profession, 2014. http://www.pmi.org/~/media/
PDF/Knowledge Center/PMI-Pulse-Requirements-Management-In-Depth-Report
.ashx, (accessed October 5, 2014).
7
Project Management Institute. 2015. Business Analysis for Practitioners: A Practice
Guide (Newtown Square, PA: Project Management Institute).
8
Project Management Institute. 2017. “Success Rates Rise: Transforming the high
cost of low performance”. PMI’s Pulse of the Profession, 2017. https://www.pmi.org/-/
media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-
profession-2017.pdf
 INTRODUCTION
xvii

The PMI also states that this is the main reason for the creation of the
PMI-PBA credential.
The bottom-line is that the PMI is on a mission to enhance the core
competencies of those who elicit and manage requirements for projects
and programs. This is very much like the mission that IIBA has had
since 2003.

Business Analysis Certification Holders as of May 2018

Project Management Institute Professional in Business 2,237
Analysis (PMI-PBA)*
Entry Certificate in Business Analysis (ECBA) 842
Certification of Capability in Business Analysis (CCBA) 1,320
Certified Business Analysis Professional (CBAP) 9,168

*PMI Today, May 2018, Project Management Institute

Source: http://www.iiba.org/Certification/Certification-Registry.aspx, May 20, 2018

What I aim to add to the conversation is that projects need execu-

tive support to get skilled staff, sufficient time, and access to people and
­resources needed to elicit and manage quality requirements. This will
maximize the chance for project success and added business value. Read-
ing this book is the first step to realizing these benefits and for the mere
price of this book.

Recent Trends
You can see in some of the more current trends how organizations are
working to try improving the success rates of projects and bringing more
value to the business with these projects. They are finding that none pro-
vide the magic bullet that leads to project success.

Agile
Agile methods, especially Scrum, became all the rage rolling into the
­mid-2000s and going even stronger in 2018. It promised to be a way
to deliver projects without a heavy investment of documentation and
­requirements upfront. The problem isn’t that Scrum is not a way to
gain additional value from the projects an organization takes on. It is.
xviii INTRODUCTION

However, tell anyone that you are doing an Agile project, and the first
thing that comes to mind is that there is not any project documentation.
Wrong! The Manifesto for Agile Software Development9 states: “Working
software over comprehensive documentation.” Agile is not a license to
skip documenting the business need, but rather it provides processes
to do this in a just in time manner, a manner that may not be acceptable
to some organizations or project teams.

Agile methods are not an excuse to hack at breakneck speed to make

a quick buck. Instead, they are a disciplined new product develop-
ment process that is optimized for efficiency, speed, and quality.10

Let’s review the Agile Manifesto for Agile Software Development

together.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and
helping others do it.
Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.
http://agilemanifesto.org/

Starting with the title, we can see this is a manifesto for software
­development. The development of software is a small piece of the overall

9
Manifesto for Agile Software Development. http://agilemanifesto.org
10
D. Rico, H. Sayani, and S. Sone. 2009. “Future of agile methods (Chapter 24).” In
Business Value of Agile Software Methods: Maximizing ROI with Just-in-Time Processes
and Documentation (Fort Lauderdale, FL: J. Ross Publishing), p. 175.
 INTRODUCTION
xix

picture in implementing a solution that will be of value to the business.

The manifesto does not claim that processes and tools, comprehensive
documentation, contract negotiation, or following a plan do not provide
value. Instead, the manifesto states, “There is [more] value to items on
the left.”
One of the major challenges with Scrum is that the values of working
software over documentation and responding to change over following a plan
both lead to the need for rework. However, taking the time to do the
needed rework and refactoring often gets neglected, resulting in a solu-
tion that does not meet the business need or requirements. There are two
major contributors to this neglect.
The first is a natural tendency not to redo something that was once
considered complete. Engineers find this frustrating. I have heard my
project teams state that they would rather see the full picture and build it
right in the first place.
The other factor is that the project team does not provide adequate
time in the schedule, or sprint backlog, for rework. The need for rework
needs to be factored into team velocity or by adding user stories for the
rework to the product backlog. Explaining this need to sponsors and
­executive stakeholders is a challenge.
Another issue I have with Scrum is that it ignores the role of the
project manager. In Agile is Not a Project Management Framework,11
I fully detail the need, purpose, and role of the project manager in an
Agile project. In short, there is still a need for a project manager and
champion to orchestrate the project beyond the confines of the Scrum
team.
One big strength of Scrum is the use of the product owner role.
The product owner is the keeper of the product backlog (a prioritized
list of features) and has ultimate authority over this priority within
the development team. The product owner is the single wringable neck
on the Scrum team. The product owner role is best suited to someone
with strong business analysis skills. These skills will allow them to
gain an understanding of the cost–benefit of features and the overall

11
http://project-pro.us/2012/04/14/agile_not_pm_framework
xx INTRODUCTION

value they bring to the final solution. The product owner is also
­responsible for eliciting, documenting, and communicating the require­
ments for each of the user stories (features). This book is for the ­product
owner.
I am a fan of Scrum when the following conditions exist:

• Project management is a role outside of the Scrum team.

• The organization’s management understands and accepts the product
backlog process and prioritization.
• The team is fully trained, understands, and accepts the processes.
• Business analysis is a core component of story writing and backlog
management.

Only recently have I seen some organizational moves in this direction.

Hopefully, the practice will continue to mature across enterprises.

Scaled Agile
Organizations began to see the benefits that Agile and Lean brought in
delivering successful projects but were looking to apply the same a­ gility to
larger-scale projects. Scaled Agile12 came to the rescue with a new Scaled
Agile Framework (SAFe®). SAFe provides a framework to scale large
­organizational projects across many engineering teams. This is handled
through the use of various levels of backlog. A backlog is a prioritized
list of features or functions that will add value to the product and to
the ­organization. Depending on the level of SAFe needed, there may be
a portfolio-level backlog of features that can feed many program-level
backlogs. Each program-level backlog, in turn, feeds many team-level
backlogs. Many teams will work independently to deliver features that
will integrate into a single system. Thorough business analysis for clarity
in understanding the value, and therefore, the priority of each feature
or function is critical to success in SAFe. Business analysis is also a criti-
cal component for successful integration that results in a single cohesive
­integrated solution.

12
https://www.scaledagile.com
 INTRODUCTION
xxi

SAFe® for Lean Enterprises—Portfolio SAFe

Figure 3  Image reproduced with permission from Scaled Agile, Inc.

SAFe and Scaled Agile Framework are registered trademarks of Scaled
Agile, Inc. (c) Scaled Agile Framework reprint permissions.

With many product owners involved in the various backlogs it b­ ecomes

more difficult to see the single view of prioritized work that lies ahead.
Organizations must have a single source of prioritized work, so that teams
take on high-value features and functions are ­delivered with thought and
intention for a single cohesive integrated solution.
Please visit https://www.scaledagile.com for additional information
and resources on Scaled Agile.

Product Manager and Product Owner

Companies are using the job title of Business Analyst less. Instead, we
see Product Manager and Product Owner have more prevalence on job
boards. These roles are similar but tend to have a slight distinction worth
noting. Product managers focus on working externally to understand
business value and set product strategy. Product owners are internally
­focused, communicating the business needs of development teams. It is
also important to point out that the Product Owner role evolved from a
role specific to Scrum teams.
xxii INTRODUCTION

The Product Owner is responsible for maximizing the value of the prod-
uct resulting from work of the Development Team. How this is done
may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the
Product Backlog. Product Backlog management includes the following:

• Clearly expressing Product Backlog items;

• Ordering the items in the Product Backlog to best achieve goals
and missions;
• Optimizing the value of the work the Development Team
performs;
• Ensuring that the Product Backlog is visible, transparent, and clear
to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the
­Product Backlog to the level needed.

The Product Owner may do the aforementioned work, or have the De-
velopment Team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product
Owner may represent the desires of a committee in the Product Back-
log, but those wanting to change a Product Backlog item’s priority
must address the Product Owner.
For the Product Owner to succeed, the entire organization must
respect his or her decisions. The Product Owner’s decisions are visible
in the content and ordering of the Product Backlog. No one can force
the Development Team to work from a different set of requirements.
Source: Schwaber, K. and J. Sutherland. 2017. The Scrum Guide™, the Definitive
Guide to Scrum: The Rules of the Game.

The foreword included a list of Product Management in a Nutshell.

As this list indicates, the Product Manager typically has more responsi-
bilities in understanding the market and customers. However, a Product
Owner must understand the value of the solution, features, and func-
tions in the context of markets and users to effectively prioritize for
value-added d ­ ecisions. I believe these roles to be synonymous in many
cases. A ­Product Manager may be the Product Owner on a Scrum team.
 INTRODUCTION
xxiii

A Product Owner may do market research to determine which features

will bring the greatest value to prioritize the backlog. A Product Owner
may report to a Project Manager who has greater responsibility for market
research and understanding customers. Any of these may be true depend-
ing on the type of product, the size of the company, the adoption of
Scrum, or ­simply job title preference.

Lean

In 2007, Toyota passed General Motors to become the world’s larg-

est motor vehicle producer. The use of Lean Manufacturing (LEAN)
­processes is one important factor in Toyota’s success. “A manufactur-
ing/production system best characterized as relentlessly eliminating
waste from all of its activities and operations. Lean strives to produce
products.”13 The Lean Global Network, established in 2007, promotes
Lean principles and sets the stage for LEAN in the mainstream. This
methodology ­focuses on r­ emoving non-value-added tasks from the proj-
ect. LEAN may be problematic when the view of “non-value added task
does not take into ­account the full project, solution, and stakeholders to
the project.
These five principles of LEAN further articulate the need for strong
business analysis in organizations. Business analysis evaluates scope and pro-
cesses to ensure that each provides value to the customer—not to the lead
architect, not to the Chief Information Officer (CIO), but to the customer.

5 Lean Principles
Value: Identity what really matters to the customer
Value Stream: Ensuring every activity adds customer value
Flow: Eliminating discontinuities in the value stream
Pull: Production is initiated by demand
Perfection: Retaining integrity via Jidoka (autonomation) and
­Poka-Yoke (mistake-proofing)

13
Definition from the Lean Manufacturing Facilitator’s Glossary. http://tpslean.com/
glossary/leanproductiondef.htm
xxiv INTRODUCTION

We Do Analysis

Most organizations do the analysis, as discussed in this text. The challenge

lies in recognizing the value of a business analysis professional. I often hear,
“I am the project manager on my project, and I do the business analysis
work. Is this okay?” If you can effectively perform the tasks of the project
manager and the business analysis to provide the team with what it needs for
a successful project in a 40-hour workweek, then yes, this is okay.
The project manager will often possess some of the specific skills
­required for business analysis and may have some capacity for the work. It is
rare to find a project manager who can answer yes to the ­above-mentioned
question unless they, like me, are also trained in ­business analysis, and the
project is small enough to allow capacity for both.
I have worked on projects that were small and simple enough to play
both roles. It can work. However, I did find that there was an added chal-
lenge in this situation. I found my decisions leaned toward whatever dis-
cipline in which I am currently working. In other words, if I have been
looking at the schedule and cost of the project, I leaned toward project
recommendations that supported cost and schedule over business value.
If I had last been working with stakeholders in eliciting requirements and
understanding what they felt solution success would look like, I’d lean to-
ward recommendations that provided more value to the solution without
as much regard to project schedule and budget. A professional skilled in
both business analysis and project management may fill both roles, and
the only caution is that you continuously keep the overall s­olution and
project in mind in your decisions and recommendations. Take the time
and be willing to ask yourself the hard questions to make sure the overall
project and solution it brings will provide the right value for the right cost.
This book will provide specific examples of how a business analysis
professional can help your business see greater benefits from the projects
selected and implemented. You may find that there are those in your orga-
nization that performs these tasks. An employee does not need to have the
title of Business Analyst to be a business analysis professional. This book
will help you recognize the roles and individuals and provide information
about how to mature and expand the use of the role for better results.
 PART 1

Business Analysis Explained

 CHAPTER 1

Business Analysis Defined

As the past Seattle Chapter President of International Institute of

­Business Analysis (IIBA), I often get questions about how someone can
learn more about becoming a business analysis professional. Often, those
asking have been doing business analysis work for some time; only they
have not yet realized it.
Let us begin by reviewing a couple of definitions of business
analysis.

International Institute of Business Analysis Definition

Business analysis is the practice of enabling change in an enter-

prise by defining needs and recommending solutions that deliver
value to stakeholders. Business analysis enables an enterprise to
articulate needs and the rationale for change, and to design and
describe solutions that can deliver value. (Business Analysis Body
of Knowledge [BABOK] Guide, Version 3.0)

Project Management Institute Definition

The set of activities performed to support delivery of solutions

that align to business objectives and provide continuous value to
the organization. (The PMI Guide to Business Analysis)1

1
Project Management Institute. 2017. The PMI Guide to Business Analysis (Newtown
Square, PA: Project Management Institute).
4 LEVERAGING BUSINESS ANALYSIS FOR PROJECT SUCCESS

The following two lists, activities and work produced, offer additional
perspective on what a business analysis professional does.

Activities Work produced

• Brainstorming • Business case/statement of work
• Document analysis • Business analysis plan
• Focus groups • Communication to stakeholders
• Interface analysis • Data dictionary or glossary
• Requirements analysis • Data flow diagrams
• Organization modeling • Metrics and key performance
• Process modeling indicators
• Organization modeling • Scenarios/use cases
• Process modeling • Sequence diagrams
• Prototyping • User stories
• Survey • Requirements package
• Prioritize

When we compare our current project team roles with the activities
and work produced, you may find that many jobs do the activities and
product the work described of a business analyst. Some common proj-
ect roles that do business analysis include product manager, product
owner, data analyst, project manager, technical writer, and developer.
If the two preceding lists sound like what you do, then you do business
analysis.

What is a business analyst?

Common business analysis job titles:
• Business process analyst
• IT business analyst
• Requirements engineer
• Business systems analyst
• Systems analyst
• Program manager
• Product manager
• Product owner
• Data analyst

What Is a Business Analysis Professional?

The project manager, developer, and data analyst may use some tools and
deliver some of the same results as the business analysis professional does
 Business Analysis Defined 5

as it relates to their specific role. A business analysis professional works

with all the business analysis tools and techniques to deliver work that
supports defining, managing, and evaluating the solution or resulting
product (to recommend solutions that enable the organization to achieve its
goals). The project manager, data analyst, technical writer, or developer
rely on the work of the business analysis professional to provide clarity
on the solution and allow project work to focus on steps needed to most
efficiently deliver the desired result. The business analysis professional is
responsible for defining what will bring value to the business, ensuring
the requirements are fully vetted and understood, and that the solution
meets these expectations. A dedicated business analysis professional on the
project team allows the project manager to focus on the project process,
progress, team, risks, and all those other aspects that make project man-
agement a full-time job.

What Does a Business Analysis Professional Do?

A quick pick of the word analyze resulted in these synonyms (thank you
Microsoft Word for making my job of writing that much easier). Each of
these words conveys an activity that takes time. Business analysis profes-
sionals do not take things at face value. The toolkit of the business analysis
professional is to aid them in analyzing the business and to document find-
ings and conclusions. Using the results of our synonym search for analyze,
we can further explore what business analysis is. The following is not a
sequential list of actions; rather, any of these can happen at any time within
the project.

Synonyms for Analyze

• Examine
• Study
• Investigate
• Scrutinize
• Evaluate
• Consider
• Question
• Explore
6 LEVERAGING BUSINESS ANALYSIS FOR PROJECT SUCCESS

Examine

• What is the problem?

• What are the opportunities to the business?
• What is the impact of the current situation?
• What will happen if the problem is not addressed?

Often, projects are initiated to solve a business problem, but will the project
solve the right problem? Perhaps the project will result in simply a Band-Aid
that will alleviate some of the pain but doesn’t get at the root of the prob-
lem. Addressing a symptom rather than the root will result in a partial and
perhaps temporary fix. Business analysis will help identify the root cause, so
that the project can bring the greatest results to the organization.

Study

• What are the current processes?

• What are the rules that drive the processes?

Projects result in change. We have to understand how things are today to

understand the impact of the change. The business analysis professional will
help document the current process and any business rule that affects the
project. Study helps ensure that the implemented solution can support the
processes, make the processes more efficient and cost-effective, and ensure
that the result of the project will not break the overall process and need.

Investigate

• What do similar organizations do?

• What new tools and technologies are available?

Often, when we have a problem to solve or an opportunity to pursue, we grav-

itate to what we know. What we know today isn’t enough to stay ahead of the
game in our competitive world in this time of great innovation and advance-
ment. Business analysis means investigating the opportunities. Investigating
includes proactively finding out what the competition or other comparable
organizations do and researching emerging technologies and solutions.
 Business Analysis Defined 7

Scrutinize

• Do requests represent business needs or stakeholder desires?

• Are the current processes necessary as is?
• Do the processes add value to the business?

Business analysis professionals will hear many requests and requirements.

Each person who makes the request is stating an apparent need. The truth
is that not every requirement is a true need. The business analysis profes-
sional must scrutinize each one of these to ensure that it is truly needed to
meet the objectives of the project. The business analysis professional will
help identify whether there is any benefit to the project of inclusion or
whether there is any detriment to the project and business if not included.

Evaluate

• What is the potential financial benefit to the organization?

• What will changes mean to the end user?

Every idea or recommendation needs to be evaluated to determine the

potential impact on the system, the users, and the organization. There
will be impacts; the goal here is to gain as much information as possible
so that we can better predict what those impacts will be.

Consider

• Are there new approaches available?

• Have we considered all angles?
• Has anything been missed?

Business analysis professionals do not jump to, or accept recommendations,

without considering all aspects of the idea. They will consider the idea from
many different perspectives to make sure that it is a great all-around recom-
mendation. Often, this consideration will lead to refinement of the recom-
mendation to give it even more strength, but the consideration may also
lead to the understanding that the idea or recommendation is not as sound
as originally believed.
8 LEVERAGING BUSINESS ANALYSIS FOR PROJECT SUCCESS

Question

• What are the risks?

• Who are we missing?
• What can go wrong?
• What does it look like it if goes right?

The first rule of business analysis is to question. If we are not questioning,

we are not analyzing. A common, easy-to-remember tool for business
analysis is 5-Why’s, where for every idea we ask why up to 5 times or as
long as it takes to get to the underlying reason or need. You will find an
example of how this helped me bring value to a project I was managing
in Chapter 2. The bottom-line is that we cannot understand until we first
question and strive to find answers.

Explore

Each of us analyzes on a daily basis in both our personal and profes-

sional lives. The power of business analysis is looking at every decision
that ­affects the solution with the analysis mindset. The result is a solution
that will bring the greatest benefit possible to the business.

In Conclusion

Think about this in-depth analysis of the word analyze. Do your business
analysis professionals analyze the business or do they simply take orders?
Are there others in your organization who do business analysis? Do those
who analyze have access to and knowledge of the best practices of business
analysis? Part 2—What your business analysis professional should be doing
for you will go into great detail on how to conduct an analysis before,
throughout, and after each project to bring the greatest value.
 Index
Agile, 34 professionals, 4–8, 12, 17, 21, 52,
methods, xvii–xviii, 34 89, 93, 96–97
software development, xviii Project Management Institute
Agile-Product Backlog, 57 definition, 3–4
Analyst. See Business analyst roles and job titles, 17
Analyze requirements, 57–61 rule of, 8
Assumptions, 29 schedule, 44
setup, 21–22
BABOK® Guide, 13, 21, 34, 97–98 skills, xix
analysis tasks, 58 techniques, 5
tool for, 5, 8
Back-office type projects, 76 Business Analysis for Practitioners: A
Baseline requirements, 64 Practical Guide, xv
Body of knowledge, 13, 39 Business analyst, 4, 11–12, 18, 25,
Breakthrough business 27–28, 29, 31, 34, 39, 41,
analysis, 101 47, 52, 67, 68, 76, 78–79,
Business 81, 85, 95
job of, 22 acceptance by, 36
need, 23, 28 cookbook, 43
objectives, 3 responsibility of, 68
strategy, 21 Business case, xv, 27–29
Business analysis, xx, xiv, xxiv, 6,
12–13, 15, 23, 83, 96 Case diagrams approach, 31
activities, 94 Center of excellence, 99
best practices, 97–98 Certification language, 52
community, 99 Certified Business Analysis
definition of, 13 Professional (CBAP)®
deliverables and activities of, 18 certification, 17
features and functions, 10 Certified Public Accountant (CPA)
guide for, 21 credential, 17
International Institute of Business Change control, 68–71
Analysis definition, 3 CHAOS research, xiii
jobs, 98 Collect requirements, xv
mistakes, 11–12 Communication, 39
Pareto example, 9 considerations, 45
phases of, 22 plan, 45–46
plan, benefit of, 44 preferences, 63
power of, 8 requirements, 61–63
power users and technicians, 9 Communities of practice, 99
practices in, 18 Comprehensive documentation, xix
problem, 10 Conduct stakeholder analysis, 39–41
122 INDEX

Contract negotiation, xix Level of data, 76

Cost-benefit Long-term assessment, 84–85
analysis, 28–29, 84
of completing, 72 Manager, role of, 18. See also Product
of investments, 83 manager
of options, 73 Minimum Viable Product, 33
Cost of projects, 75 Mock screens, 11
CPA credential. See Certified
Public Accountant (CPA) Options analysis, 26–27
credential Organizational process changes, 24
CRM system. See customer Organizational projects, 34
relationship management Organizational readiness, 77
(CRM) system Organizations, 15, 21, 98
Customer relationship management readiness of, 75–77
(CRM) system, 72
Personal communication
Design preferences, 63
definition of, 11 Plan
document, 11 business analysis, 41–45
Development project, 72 communication, 45–46
Documentation, usefulness of, 80 to re-plan, 69
Planning for project, 39, 70
Elicit requirements, xv, 52–54 business analysis, 41–45
Evaluation measures, 29 communication, 45–46
Executive support, xiv conduct stakeholder analysis, 39–41
requirements management process,
Gathering sessions, 68 47–49
General Motors, xxiii PMBOK® Guide, 21
Guide to the Business Analysis Body PMI. See Project Management
of Knowledge, 13 Institute (PMI)
PMI-PBA. See Project Management
International Institute of Business Institute Professional in
Analysis (IIBA), 3, 13, 34–35, Business Analysis (PMI-PBA)
97–98 PMOs. See Project Management
Investment decision for project, 69 Offices (PMOs)
Portfolio management system, 23
Jobs, 17 Potentially releasable products, 36
Job titles, 17 Product backlog, xix
requiring certification, 17 Product Development and
Management Association,
Kennedy, Mary, 33 97–98
Knowledge areas, 13 Product investments, 92
Product manager, xxi–xxiii, 84
LEAN. See Lean Manufacturing Product owner, xxi–xxiii
(LEAN) Professional of business
Lean Global Network, xxiii analysis, 4–8
Lean Manufacturing (LEAN) Professional recognition, 13–14
principles, xxiii vision for tomorrow, 14–15
processes, xxiii Program-level backlog, xx
 INDEX
123

Project, 31–34 Project Management Institute

Agile, 34
Agile-Product Backlog, 57
analyze requirements, 57–61
approach, 34, 60
assessment, 30
audit, 69
baseline requirements, 64
benefits of, 84
business case, 27–29
communicate requirements, 61–63
customer (business SME), 93–94
deliverables, 18
determine need, 23–25
elicit requirements, 52–54
evaluate options, 25–27
investment for organization, 83
leadership team, 14
long-term assessment, 84–85
management, 13, 31
monitoring and controlling
change control, 68–71
changing business, 71–73
tracking requirements, 67–68
organization readiness, 75–77
portfolio
management, 89
solutions, 25
requirements gatherer, 96
return-on-investment, 84
scope, 31
short-term assessment, 83–84
solution sign-off, 81
sponsor, 95–96
stakeholders, 33, 40
success, 90
definition of, 14
statistics on, xiii
team, 39, 67
traceability matrix, 54–55
track record, 89–92
qualitative analysis of, 92
traditional waterfall, 35–36
validation of solution, 78–80
Project Management Institute (PMI),
xiv, xvii, 3–4, 13, 28, 34–35,
95, 98
analysis tasks, 58
references, 97
Professional in Business
Analysis (PMI-PBA), xv–xvi
certification, 53
Project Management Offices (PMOs),
99–100
Project management plan, 39
Project Management Professional
(PMP)® certification, 17
Project manager, 39, 43, 69, 71,
94–96
Project power team, 14, 93
business analysis, 96–98
project customer (business SME),
93–94
project manager, 94–95
project sponsor, 95–96
team dynamics, 96
Prototypes, 61
Quality requirements, characteristics
of, 59
Recommendation, 28
Reimbursement system, 51
Request for Proposal (RFP), 40
Requirements, xiv
analysis, 25
approval and change control, 64
baseline, 64
communicate, 61–63
inaccurate, xvi
management, xvi, 47–49
package and communication
plan, 63
progression of, 60
quality, characteristics of, 59
traceability matrix, 68
Requirements Management
Community of Practice, xv
Requirements Management Tools
(RMT), 25, 33, 35, 40, 44,
48, 77
for requirements, 36
Return-on-investment, 85
RFP. See Request for Proposal (RFP)
Risk mitigation strategies, 39
RMT. See Requirements Management
Tools (RMT)
124 INDEX
SAFe. See Scaled Agile Framework
(SAFe)
Scaled Agile Framework (SAFe), xx, 34
for lean enterprises, xxi
Schedule requirements, 48
Scope creep, 69
Shiny objects, 23
Short-cut readiness requirements, 76
Short-term assessment, 83–84
Simmons, Matthew, 33
Skilled business analyst, 14
SMEs. See Subject matter experts
(SMEs)
Software development project, 51
Solution deliverables, 28
Stakeholders, 3, 39, 51, 62
analysis, 39–41, 44
communication, 39
explicit approval of, 64
Standish Group, xiii
Strategies for Project Sponsorship
(Management Concepts
2013), xiv
Subject matter experts (SMEs), 14
Suitable for use, 67
System availability, 78
System constraints, 52
System documentation, 78
Team dynamics, 96
Timekeeping system, 75
Toyota, xxiii
Traceability matrix, 54–55,
67–68
columns of, 54–55
considerations for designing, 54
details of, 55
example of, 56
Traditional waterfall, 35–36
Usable representation, 52
Use case diagram, 32
User acceptance testing, 79–80
User community, 11
User documentation, 80
User experience (UX) design, 11
UX design. See User experience (UX)
design
Validation of solution, 78–80
Value-based practice, 101
Waterfall, 35
projects, 33
traditional, 35–36
Weaver Systems, 24–25, 33
Williams, Todd C., 69
Work breakdown structure, 31–32
 OTHER TITLES IN OUR PORTFOLIO AND
PROJECT MANAGEMENT COLLECTION
Timothy J. Kloppenborg, Editor
• Project Management and Leadership Challenges-Volume I: Applying Project
Management Principles for Organizational Transformation by M. Aslam Mirza
• Innoliteracy: From Design Thinking to Tangible Change by Steinar Valade-Amland
• Project Management and Leadership Challenges, Volume II: Understanding Human
Factors And Workplace Environment by M. Aslam Mirza
• Project Management and Leadership Challenges, Volume III: Respecting Diversity,
Building Team Meaningfulness, and Growing Into Leadership Roles by M. Aslam Mirza
• Why Projects Fail: Nine Laws for Success by Tony Martyr
• Scrum for Teams: A Guide by Practical Example by Dion Nicolaas
• Project Management and Leadership Challenges, Volume IV: Agility in Project
Management and Collaboration by M. Aslam Mirza
• Producing Value from Your Projects the Solent Way by Paul Summers
• Project Management Lessons from the World’s Greatest Projects and Project Leaders
by Sherif Hashem
• Developing Strengths-Based Project Teams by Martha Buelt and Connie Plowman
• Project-Based Learning: How to Approach, Report, Present, and Learn from Course-Long
Projects by Harm-Jan Steenhuis and Lawrence Rowland
• Agile Working and the Digital Workspace: Best Practices for Designing
and Implementing Productivity by John Eary

Announcing the Business Expert Press Digital Library

Concise e-books business students need for classroom and research

This book can also be purchased in an e-book collection by your library as

• a one-time purchase,
• that is owned forever,
• allows for simultaneous readers,
• has no restrictions on printing, and
• can be downloaded as PDFs from within the library community.

Our digital library collections are a great solution to beat the rising cost of textbooks. E-books
can be loaded into their course management systems or onto students’ e-book readers.
The Business Expert Press digital libraries are very affordable, with no obligation to buy in
future years. For more information, please visit www.businessexpertpress.com/librarians.
To set up a trial in the United States, please email sales@businessexpertpress.com.