BABOK 2.

0
D. Berglund
Beyond the Basics of Business Analysis
 So What is a Business Analyst
2

 A Business Analyst can be defined a few different ways:

 BABOK 1.6: “Works as a liaison among stakeholders in order to
elicit, analyze, communicate and validate requirements for
changes to business processes, policies and information
systems…”
 BABOK 2.0: “Is any person who performs business analysis
activities, no matter what their job title or organizational role may
be…”

 Traditionally, a Business Analyst works as a liaison among stakeholders in order to elicit,

analyze, communicate, and validate requirements for changes to business processes,
policies, and information systems.

 My Definition
 A Business analyst works to understand business problems, gaps, and opportunities and
recommends solutions that enable the organization to achieve its goals via clearly defined
requirements (capabilities). Solutions may include IT systems, process improvements, or other
organizational changes.
 The Need for Business Analysts
3

Business Analysts help decision-makers determine the best way to meet the
business‟ needs through an understanding of

1. How an organization accomplishes its goals/objectives

2. Why the business exists (its purpose)

3. How users perform their roles

This grounding in business needs, provides clarity into the right solutions that allow
the business to more effectively meet its objectives and goals.
 What‟s the BABOK?
4

The BABOK is a standard, encompassing multiple knowledge

areas, tasks and activities, and best-practices that helps BAs
understand the sum of knowledge that is used within the Business
Analysis profession.

Defining a set of standards (the BABOK) provides the following benefits:

 Creates a shared understanding of business analysis

 so we‟re all on the same page
 It defines the Business Analyst role and activities
 so we know what to do!
 It describes the techniques that a Business Analyst should be able to
perform
 so we get the job done
 It describes the competencies that are required to be effective
 So we get the job done well
 What Else is the BABOK?
5


It‟s not just for software/application requirements

 It‟s not a “How-to Guide”: it‟s a discipline


It‟s Methodology-neutral
 You can use: PESTLE, HEPTALYSIS, MOST, SWOT, Five
Why‟s, etc.


It‟s scalable to all projects regardless of their size and complexity

 It‟s compatible with various Lifecycles: Iterative, Agile, Waterfall, etc.

So you want to be certified?

 Certification Requirements:
 5 years (7,500 hours) of business analysis work in the last 10
years
 “Acceptable” activities include:
 Hands-on business analysis activities (as described in BABOK)
 Coaching or mentoring Business Analysts with respect to business
analysis activities
 Development of an organization‟s business analysis methodology
and/or best practices (coming up with new/better ways to do BA work)
 Development of business analysis training courses
 Demonstrated experience and expertise in at least 4 of the 6
BABOK Knowledge Areas (we‟ll get to these)
 At least a high school diploma or equivalent
 21 hours of BA professional development in the last 4 years
 2 professional references (not your aunt Margaret)
 Don‟t you mean PMBOK?
7

 Think of PMBOK as the Project Management version of BABOK.

 PMBOK main focus is on project parameters
 BABOK main focus is on the product parameters

 Instead of focusing on knowledge areas, the PMBOK defines 5 main stages/processes

involved in a project:
1. Initiating
2. Planning
3. Executing
4. Controlling
5. Closing

 When combined, the PMBOK and BABOK:

 Complement each other with standardized definitions and terms for PM and BA activities
 This helps us all get along.
 Create local communities of PM and BA professionals to meet and discuss common experiences
 Provide certification models that establish consistent best practices and industry standards
 Provide a common understanding of knowledge and skills for PM and BA professions
 Origins of PMBOK/BABOK
8

 Project Management Body of Knowledge (PMBOK)

 First published in 1987 by the Project Management Institute (PMI)
 A framework that defines project management and related concepts, describes the
project management life cycle, and outlines related processes
 Written with Project Managers in mind – PMP certification

 Business Analysis Body of Knowledge (BABOK)

 First published in 2006 by the International Institute of Business Analysis (IIBA)
 A framework that describes Business Analysis areas of knowledge, their associated
activities and tasks and the skills necessary to be effective in their execution
 Written with Business Analysts in mind – CBAP certification
 Let‟s work Together
9

PMs and BAs: Dynamic Duos

Strong PM
A roaring success, great
Strong BA
balance between getting
accurate and thorough
requirements and moving
project along
Weak PM
Too much time developing
requirements, project falls behind
schedule, “scope creep” often
occurs

Requirements aren‟t well Project failure!

Weak BA
constructed, some may be
missed, rework needed late in
the process, schedule and
budget suffers
BA‟s Contribution to Delivery

Being a Business Analyst requires multiple skills and to be truly

successful, you need to look beyond what‟s in front of you and dig
deeper. As a Business analyst expect to:


Influence scoping and prioritization of features, sprints, and stories


Unfold the architecture, requirements, & business rules


Identify business opportunity and define the Business Architecture


Ensure that the solution meets the requirements


Collaborate with business and technical SME‟s


Manage requirements repository


Identify Product Risk
Effective Business Analysis

An Effective BA will go beyond checking boxes. To be truly effective a BA will:

•
Analyze & solve problems (meaning you need to dig in and research)
•
Understand the business (do you really know how the company makes
money from the project?)
•
Communicate effectively (write & speak clearly)
•
Manage customer/client relationships
•
Lead/Facilitate discussions
•
Negotiate & build consensus (from bottom up and top down)
•
Prototype data & processes
•
Plan & manage activities
•
Facilitate & develop business strategy
•
Understand & manage organizational change
•
Influence joint planning at all levels
Let‟s Define a Few Things


Each knowledge area describes the tasks performed by business
analyst to accomplish the purpose of that knowledge area.


What‟s a task?
 Formal or informal, universally applicable
 Necessary components of a given Knowledge Area
 Not limited to one knowledge area
 Creates a completed output that has value
 Becomes an input to another task
 Can be completed numerous times for one project
 Has consistently defined inputs and outputs
Techniques


How about a Technique?
 Describes how tasks are performed under specific circumstances.
 A task may have none, one, or more related techniques.
 BABOK techniques cover the most common and widespread uses
 Techniques may evolve, change with time

Methodology
 Determines which tasks and techniques are used to solve a business
problem
 Generally affects all tasks performed in a project
 BABOK acknowledges methodologies, but... Neither defines nor prescribes
methodologies

 Typically owned by individual authors

Techniques: Models

A few examples of Techniques


Class Model


CRUD matrix (access rights)


Data dictionary


Entity relationship diagrams


Process / Flow models


Use cases


More...
Here‟s an Example

 Your Task: Conduct Requirement Elicitation

 Possible Techniques:
 Brainstorming: you know…anything goes idea
generation
 Requirements Workshop: scoping, discovering,
defining, prioritizing
 Interview

 Prototyping: my favorite – map it out;

construct/create to show others how the product
might function
The Big Daddy Definition

Requirement are…
A documented representation of a condition or capability that is
either:

1. needed by a stakeholder to solve a problem or

achieve an objective.
2. that must be met or possessed by a solution to
satisfy a contract, standard, specification, or other
formally imposed documents.
Making A Shift Towards Excellence

If you want to do more, then start working on the following

behaviors.

 Expand from facilitating and transferring to visioning


Don‟t just accept face value. Question facts until you can
model them and gain consensus from all stakeholders.

 Link Analysis: How do the pieces fit together? Does this

make sense?


Empower your communication with collaboration

 Rather than specialize, expand your sphere of knowledge.

 Move from managing change to embracing change
 Abandon your space and be face-to-face
 Leadership: Recognize the future and influence stakeholders
 Organize: It‟s not just the Project Manager‟s responsibility to
be organized. You‟ll never be successful if you can‟t stay on
top of things.
Realize Your Opportunity For Success

 Unfold requirements iteratively by coupling with the implementation

of the business and the technical designers – make sure both
groups see the same things
 Lead as an Analyst. Assume no one else will pick up the pieces.
You may be the only one trying to tying everything together.
 Leverage the power of prototyping. Create visual representations to
ensure everyone is on the same page (process
flows, maps, prototypes, etc).
 Business rules are pervasive – seek them out, document them and
re-check. Are there exceptions?
 Adapt how you organize and characterize the requirements.
Businesses are a fluid beast – during a storm it‟s better to be in a
boat than on a dock. Get out there and see which way the tides are
flowing.
 Take on the Product perspective: Look at the business
case, consider the consumer, and recognize how the output will be
used.
Four BA Fundamentals

1.
Basic Skills
• Analysis, business / domain / IT knowledge,

2.
Advanced Skills
• Meeting management, presentation, decision-making, conflict,
negotiation

3.
Leadership Skills
1. Coaching, motivating, interviewing
4.
Peripheral Skills (e.g. sales)
Who is involved in Business Analysis?

Implementation Project
SME Manager

Domain SME Tester

Supplier Regulator

Customer
Business Sponsor
Analyst
 Knowledge Area Overview

Identify business problem, Influence scoping and prioritization

opportunity or unmet need and of features, springs, and stories Unfold the architecture,
define Business Architecture
requirements, & business rules

Business Analysis Planning

Solution
Enterprise Requirement
Elicitation Assessment
Analysis Analysis
and Validation

Requirements Management and

Communication
Fundamentals
Collaborate with
business and technical Mange repository of Ensure the solution meets
SME’s requirements the stated requirements
BABOK 2.0 Knowledge Areas
BA Planning and Monitoring:
What do I need to do?


Goal: Determine which activities are necessary to
perform and complete as part of a given business
request.
Purpose BABOK Definition
“This knowledge area “defines the resources
Identify tasks and tasks associated with the planning and
management of requirements gathering
and activities throughout the requirements process”
stakeholders
The Value Story

•Understand who you need to engage and what you

need to accomplish
•Track progress & provide input to project plan
•Coordinate/align with teammates
Requirements Planning & Management:
Realizing the Opportunity


You should plan to work in an iterative fashion to continuously deliver
value
 Just like a startup, plan to fail quickly. This is the idea that the
consulting firm Continuum touts. Why? Because it works!


Shorten planning time so you have more time for drafts, trials, and
tests. You learn much more by doing than by thinking of doing.


Assemble a team of stakeholders you trust. This may include BAs,
Product Managers, Project Managers, User Testing Specialists, etc.
As they say at Home Depot – each link in a fence is a potential place
for a squirrel to eat your flowers.


Welcome change. Business needs and priorities will shift and your
requirements will need to do the same.
Requirements Planning & Management:
Realizing the Opportunity


Before you get started with a project, ensure you understand and promote the
Business Analyst skills.
 You should be able to teach others the basics of BABOK. Plus, mentoring counts as experience
towards your certification!
 Teaching others on your project team will let them know more about your strategy and
expectations.


Skills are more important than roles
 To be successful as a BA, you‟ll need to do more than just collect and write requirements. Go
beyond listening mode and examine the issues from other roles POV.


Identify and estimate the work
 Why wait for others to tell you how much things will cost and how long it will take? Just like when
you‟re buying a house, you should have a fairly good idea of what the relative values are in your
field. Each time you estimate, you‟ll perfect your ability to project into the future.


Commit to the highest priority work
 You‟ve got limited resources from a project perspective, and it‟s not just money to consider. You
need to know leadership expectations regarding prioritizing work so you can do the same.


Manage the scope of the work incrementally
 You can‟t build a boat in the water, and similarly you shouldn‟t start working on solution analysis
until you‟ve gotten a good picture of the current state.


Dynamically respond to product and project change
 The product teams may need to adjust their product release strategy based on numerous factors.
Be ready to move as needed to keep the core product alive and on the road to market.
Requirements Planning & Management: Basics
of Agile Development

One popular method for technology

development is known as „Agile‟ – at its
core, agile development is a set of
methods based on iterative and
incremental changes where requirements
evolve through collaboration between
cross-functional teams. It‟s rapid, flexible
and promotes an adaptive mindset that
can respond to changes quickly.

Re-prioritize features for the Product
Backlog throughout iterations

Assign capabilities/features to a sprint

A sprint is an iteration of work

Decompose capabilities into stories

A story is a unit of business value

Prioritize and commit to stories to be
completed within a sprint

Image from Wikipedia.org

 Requirements Planning & Management

1.
Introduction: set the stage for the project. Very high level discussion
2. Understand Team Roles for the Project: who is assigned to work on the
project?
3.
Define BA WorkDivision Strategy: If there are multiple BAs, you need
to establish boundaries for workload planning.
4.
Define Requirements Risk Approach: What are potential fail points?
What are impacts of missing requirements?
5.
Determine Planning Considerations: Pull out the GANTT chart and
figure out your timing and dependencies! Look into cross-project
coordination as necessary – dollars and resources are finite in an
organization so you need to know how you‟re all connected.
6.
Select Requirements Activities: Figure out all steps needed to create
requirements
7. Manage Requirements Scope/Estimations: Ensure stakeholders realize
when scope is beyond capacity. It doesn‟t mean you‟ll remove
requirements, but you should draw a line in the sand for what is in an out of
scope for that release.
8.
Measure & Report Requirements Activity: Keep track of
conversations, metrics and other critical information so you have a paper
trail that shows your successes and so you can learn from mistakes.
9. Manage Requirements Change: Change happens so expect it. Keep
track of all changes and ensure stakeholders have visibility into changes.
Requirements Elicitation: Setting the Stage

 BABOK definition: “Provide a cohesive solution to a business

problem”
 Your goal in this phase is to translate stakeholder needs – even those
they don‟t recognize.
 You will “Own the problem, define the need.”
 When considering the requirements you‟ll write – remember
that stories are units business value so they are written in the
voice of the business user. Don‟t lose sight of the business
case.
 This knowledge area describes “how stakeholder needs are
analyzed, structured, and specified for use in the design and
“Eliciting requirements is a key task in business analysis because
implementation of aserve
the requirements solution.”
as the foundation for the solution to the
business needs it is essential that the requirements be complete,
clear, correct, and consistent.”
- BABOK 2.0
Requirements Elicitation

• So what‟s the purpose of elicitation?

• Elicitation answers the question: “What do
stakeholders need?”
• Your goal: Explore, identify and document stakeholder
needs
• When you meet, be sure to describe how you plan
to work with various stakeholders. Explaining your
understanding of the stakeholder list will give you
an opportunity to validate the organizational model
you‟ve established.
• Ensure you have a complete understanding of their
needs – restate what they told you. It sounds
redundant, but it works.
Elicitation: Ins and Outs

• Inputs:
• Business Case / Business Need
• It is absolutely critical you understand the fundamentals of the
business to create the „right‟ solution. Get to know your business
model and the needs you plan to address through this project.
• Organizational Process Assets required to Implement
• This may start as an informed guess. Be sure to validate this with
stakeholders.
• Output will be Requirements. We‟ll cover those next.
BABOK Requirements Elicitation Tasks

Tasks:

1.
Structure Requirements Packages

2.
Create Business Domain Model

3.
Analyze User Requirements

4.
Analyze Functional Requirements

5.
Analyze Quality of Service Requirements

6.
Determine Assumptions & Constraints

7.
Determine Requirements Attributes

8.
Document Requirements

9.
Validate Requirements

10.
Verify Requirements
Tips for Requirements Elicitation


Use the right elicitation technique at the right time with just the right
amount of rigor


Consider how much is known, how much still needs to be discovered,
and when the team needs the specifics
Wait, what is Elicitation?


Working with stakeholders to identify and understand their needs and
concerns, and understand the environment in which they work. The
purpose is to ensure that a stakeholder‟s actual underlying needs are
understood and captured. Sometimes the stakeholder doesn‟t know
them, it‟s up to you to get to the latent needs.
 Requirement Management and Communication

Describes how BAs manage conflicts, issues and changes in order

to ensure stakeholders an the project team remain in agreement Manage Solution
Scope and
on the solution scope, how requirements are to be communicated Requirements
to stakeholders, and how knowledge gained by Bas is maintained
for future use. Manage
Purpose Answers the Question Requirements
Traceability

Communicate the Does everyone Maintain

outcome; Identify and understand and Requirements for
Re-use

manage change agree?

Prepare
The Value Story Requirements
Package

Bring stakeholders to a common understanding; Communicate

formalizes the structure of communication Requirements
Requirement Elicitation: Realize the Opportunity


Co-locate with the Business:
 Remember that the most efficient and effective method of conveying
information to and within a development team is through a face-to-face
conversation
 If possible interact daily with the business and the development team. Walk
by your teammates desk, use teleconferencing, or any other way to have
face time with project team. Building relationships and a common
understanding is vital to your success.
 Keep in mind that the best requirements come from self-organized teams

Create an adaptable approach to documentation to welcome changing
requirements, even late in development
 But…sync up with the rest of the team to ensure evolving requirements
and potential designs remain in alignment across the board. In other
words, verify to cover yourself.


Only elicit requirements that lead to satisfying the customer through
early and continuous delivery
Requirement Management and Communication

Goal: Ensure stakeholders have access to BA work products


Communications of all doc types and updates
 Present the requirements in a format appropriate for the intended
audience.
 Don‟t plan to send a VP a 34 page requirement document. Walk
through it with them. Try asking them the format they‟d like to see it
in.

Ensure stakeholder agreement with solution scope (written
sign-off!)
 AKA Bring stakeholders to a common understanding
 Approvals (get it in writing)

Manage conflicts, issues and changes

Re-Use: facilitate enterprise consistency/efficiency (no sense
in re-inventing the wheel)
Requirements Communication


Per the BABOK
 This knowledge area is “the collection of activities and considerations for
expressing the output of the requirements analysis and documentation to a
broad and diverse audience.”

BABOK Tasks:
1.
Create Requirements Communication Plan
2.
Manage Requirements Conflicts
3.
Determine Appropriate Requirements Format
4.
Create a Requirements Package
5.
Conduct a Requirements Presentation
6.
Conduct Formal Requirements Review
7.
Obtain Requirements Signoff
Product Backlog


The Product Backlog is a set of features not yet completed but still
desired


A feature is functionality driven by business value


Prioritize the unmet features for the Product Backlog

 Keep this organized because you‟ll probably come back to it

eventually.
 Enterprise Analysis

Per the BABOK Define Business

This knowledge area describes “the Business Analysis activities Need
that take place for organizations to (1) identify business
opportunities, (2) build their Business Architecture framework,
and (3) determine the optimum project investment path for the Assess Capability
enterprise, including implementation of new business and Gaps
technical system solutions.”
Purpose Answers the Question
Determine
Understand the big Why are we even Solution Approach

picture doing this project?

Define Solution
Scope
The Value Story
Define Business
Provides the necessary context and Case
foundation on which you will evaluate all
future issues and challenges.
Enterprise Architecture: Applying Agile
Principles

 Your goal in this stage is to propose projects that meet

strategic needs
 Envision an Enterprise Architecture that harnesses
change for the customer's competitive advantage
 Elicit input from motivated individuals who welcome
change
 While developing the Enterprise Architecture and
Business Case, pull in all of the necessary experts as a
self-organized team
 Give the Enterprise Architecture effort the support
needed to get the key activities done
Enterprise Architecture: Setting the Stage

Enterprise Architecture: Realizing the Opportunity


Create vision of future business capabilities

Develop the Business Case
 Build the case for the requirements you put together. Make sure business
leaders support them, or don‟t expect them to see the light of day.


Facilitate portfolio investment decision making

Identify implementation priorities

Advocate that the most valuable projects launch first
 Consider customer perspective. Where do you make the most revenue or
what will allow the business to capture the most value?


Advise release packaging
 What‟s the best way to compile requirements? Think about what‟s actually
being done or what‟s expected to work when a user is utilizing the finished
product. Would it make sense to have button Z in release one if we don‟t
have button X? If not, find a new package of requirements that works
together.
Enterprise Architecture: Applying Agile
Principles


Envision an Enterprise Architecture that harnesses change for the
customer's competitive advantage.
 Change is always going to occur in the business world. Businesses may try
to be at the forefront of change or they may wait for change to come to
them, but in either case the processes, technology, and products will have
to be modified to incorporate what‟s happening outside the business.
 Customers (or the company you work for) are constantly looking for ways
to capture and maintain value. Staying agile and harnessing change will
make YOU valuable.


Elicit input from motivated individuals who welcome change


While developing the Enterprise Architecture and Business Case, pull
in all of the necessary experts as a self-organized team


Give the Enterprise Architecture effort the support needed to get the
key activities done
 Requirements Analysis

Goal: Progressively elaborate, validate, verify stated

requirements Prioritize
Requirements

Validate requirements meet business need

Enable solution definition Organize
Requirements

Specify and Model

Purpose Answers the Question Requirements

Analyze the Data What does the solution HAVE to Define Assumptions
and Constraints
do?
Verify
The Value Story Requirements

Validate
Transforms the business need into clearly defined Requirements
capabilities.
Requirements Analysis and Documentation


Types of requirements:
 Functional
 Non-functional

You‟ll need to: Identify gaps, ensure feasibility of capabilities

Your capabilities inform/define the solution to be implemented

Remember, your documentation is the basis for project estimating and
planning and if it‟s not written down, it‟s not going to happen.

Just like goal-setting, your Requirements should be SMART
 Specific
 Measureable
 Achievable (no sense in wasting others time here, determine what is
feasible)
 Results-Oriented (describe an end-state)
 Time-Related (define parameters of time as necessary)
Criteria for Assessing Requirements Quality

Beyond just being SMART, make sure your requirements are:

Allocatable 
Unambiguous

Attainable 
Understandable

Complete 
Verifiable

Correct 
Not design-specific: Pay continuous
 attention to technical excellence

Testable

Feasible

Necessary

Measurable

Traceable
 Solution Assessment & Validation

Goal: Assess solutions to ensure that strategic goals

are met and requirements are satisfied
Assess Proposed
Purpose Answers the Question Solution

Make sure that the best Does the solution do Allocate

Requirements
solution is chosen by what it‟s SUPPOSED to
business. do? Assess Organizational
Readiness

Define Transition
The Value Story Requirements

Evaluate and choose among options; assess Validate Solution

tradeoffs and alternatives.
Evaluate Solution
Performance
Solution Assessment/Scoping


Understanding Scope
 Solution Scope
 The set of capabilities required to meet a business need
 Project Scope
 The work required to implement the solution scope

Business analysis is required to define solution scope.
 Assess and select from proposed solutions
 Assess deployed solutions to see how they
met the original need


Per the BABOK: This knowledge area “covers the business
analysis tasks necessary to ensure that the solution meets the
stakeholder objectives, is thoroughly tested, and is implemented
smoothly.”
Solution Assessment & Verification


Each story must have validation criteria
 You need to make sure the completed product is, in fact, complete.
 You don‟t know if you‟re done, if you don‟t say what‟s a finished product.

To track story effort, give each story an assigned point value estimated
based on complexity and the time it will take to GTD (get to done)
 This is a useful way to explain to stakeholders how the project schedule
will align with technical deliverables and accompanying business value


In the Agile world, working versions of software are typically the
primary measure of progress


“Production ready” solution – what does it look like? You better get
sign off from stakeholders ahead of time so developers know when
their finished building.
Solution Assessment & Verification

 Emphasize that solution delivery must satisfy the client with

valuable software/outcomes

Pay continuous attention to technical excellence of the product
 Does it perform the way it was requested? Maintain high standards and your
customer will be happy. Now isn‟t the time to accept a solution design that you
wouldn't be happy using.

 Now that you‟ve seen how it fits together, is it all essential?

 Perform regular self-assessment to reflect on how to become more
effective
 Check in with stakeholders to see if their objectives are met
completely
 Complete a usability check – this is critical! You‟re going to have
many different types of users and you need to make sure it works
for people beyond the people who built it.
 Support QA and testing. Be available to answer questions and
ensure that testing gets done right.

 Manage problems, validate changes

Solution Assessment & Verification


Propose alternative solutions
 Not happy with a recommendation? Provide your own!

Ensure product fit and integrity
 Does the recommendation fit with the style of the product? Make sure that
the solution aligns not just with the technical requirements, but with the
design as well.


Verify that the solution fulfills envisioned business capabilities


Assess impact of solution on business operations
 How? Ask them! Have your operations staff use the product and see how it
works for a pilot client.


Simulate future business processes
 Underlying Competencies


All of the past slides require the below underlying competencies. The
skills are in you, now get to work and show them off.

Analytical
Behavioral Business Communication Software
Thinking and Interaction Skills
Characteristics Knowledge Skills Application
Problem Solving

Creative Business
Thinking Principles and Oral Facilitation and
Ethics Practices Communication Negotiation General
Purpose
Decision Making Applications
Industry
Knowledge
Personal Leadership and
Learning Teaching
Organization Influencing
Organizational
Knowledge
Problem Solving
Specialized
Applications
Written
Trustworthiness Solution Teamwork
Systems Communication
Knowledge
Thinking