Applying Reality to BABOK® Knowledge Areas

Gina Schmidt PMP CBAP

Fraser Michigan

BA Planning

Three Lessons Learned

Created a Requirements

Management Plan

• Did not have a requirements management process defined

• Provided for team guidelines and ensuring responsibilities were clear

Made Work Plan Visible

• Otherwise dates were dictated without knowledge of impact

• If you don’t ask for the time to do the work you won’t get it!

Documented Estimating

Assumptions

• Factors that influence my estimates

• Tools and techniques I plan to use

Medical Records Company: Coaching a BA

My WBS

Which techniques?

Estimate Assumptions:

How many interviews?

How long to conduct each?

How much time to

document?

BA WBS for Medical Records

Project

Assess the Problem

Review Existing Documentation

Identify and Interview

Stakeholders

Schedule Interview

Conduct Interview

Document Interview

Verify Information Obtained

Define Scope

Build Context Diagram

Build FDD Identify SUD Document In/Out

Assumptions

Produce Scope Definition Statement

Elicit Stakeholder

Requirements

Analyze and Refine

Requirements

Package and Document

Requirements

Which models to use?

Which deliverables to

produce?

More Detailed Example of a BA WBS

Requirement Management Plan

Contents

• Requirement Risk and Issues

• Organizational Overview

• Availability of Organizational Assets

• Standards for Capturing Requirements

(attributes)

• Standards for Documenting Requirements

• Requirement Metrics and Reports

• Glossary of Terms

• Quality Checklists

6

Enterprise Analysis

Three Lessons Learned

Must Assess Culture and Stakeholder

Needs

• Guides questioning

• Assesses risk

• Identifies problem or opportunity

Must Provide Alternatives

• I advised, they decided

• Criteria for decision making process critical (provided a scoring and ranking process)

Must Document Assumptions

• Assumptions become initial baseline

• Assumptions must be visible to be validated

Bank: Process Improvement Business Case

What to do More of:

Look for Opportunities

What to do More of:

Put on Your Architectural and

System Thinking Hat

Business Case Building Blocks

• Problem Statement

• Background

• Alternatives

• Proposed Solution

• Objectives

• Gap Analysis

• Scope Definition

• Risks

• Value Proposition

• Short Term Action

Plan and Roadmap

Can we justify do this initiative?

Elicitation

Three Lessons Learned

More Prep Time

• Time allocated did not account for enough time for participant prep – review of documentation

• Techniques used in workshop needed more detail planning

Consider Diversity of Audience

• English language more of a problem then originally thought

• Needed two facilitators to run two groups concurrently with one speaking native language

Visuals

• Planned visual process documentation for reference worked very well

• Tools to display visuals were extremely valuable

Auto Company: Performed Requirement Workshops

What to do More of

Don’t just ask “what are your requirements”?

Go from paper to people.

Change assumptions to questions.

Use analysis tools for uncovering gaps and

identifying additional questions.

Know the difference between a solution and

a requirement (have them work backward

from a solution).

Give them context.

Adapt to their communication style.

14

Gathering to Eliciting

15

Requirements Analysis

Three Lessons Learned

No As Is Model

• No current state documentation

• Knowledge across dozens of stakeholders

Scope of Model

• Needed to architect for the vision but consider approach to populate in releases

What to Call Things

• Needed data owners for decision making

Marketing Company: Created a Data Model & Dictionary

What to do More of

• Categorize requirements to find out what is

missing

• Reconcile data to processes and vice versa

• Use models to identify gaps

Data Model

Solution Assessment & Validation

Three Lessons Learned

Addressing the “What Ifs”

• Use case “happy path” done first

• QA involved in extension discussions

User Stories vs. Use Cases

• Both Waterfall and Agile used

• BA and QA approach different for each

• User stories had acceptance criteria defined in “conversations”

Trace-ability

• Trace-ability between use cases and test cases

• Which tools? No standard tool except for HP Quality Center for testing only

Financial Services Company: Map Use Cases to Test Cases

Use Case Basic Flow: Examining for

the “What Ifs”

22

(addition to Brief)

Basic Flow

1. ABC selects Buy Book of Stamps option

2. ATM shows price for acceptance and quantity

3. ABC accepts price

4. ABC enters quantity of books

5. ATM validates checking account for sufficient funds

6. ATM Debits Checking Account

7. ATM provides Book(s) of Stamps with quantity as requested

8. ABC takes book(s) of stamps

9. ATM Asks if Other Transactions

Scenario Paths Table Example

Basic

Flow

Alternate

Path 1

Alternate

Path 2

Exception

Path 1

Exception

Path 2

Scenario 1 X

Scenario 2 X

Scenario 3 X

Scenario 4 X

Scenario 5 X

Scenario 6 X X

Scenario 7 X X

Scenario 8 X X

23

Req Management & Communications

Three Lessons Learned

Roll-ups

• Took detail models and simplified them to fit on one slide for executive team

• Detail put in tabs in one spreadsheet with versioning

• Pasted in Visio docs.

Know Dynamics

• Prepared for some history (credibility issues with previous project) when meeting with executives

Decisions

• Had to ensure the right people took accountability for certain decisions that needed to be made

Sales Products Company: Presenting to different audiences

The Common Denominator:

MS Excel Spreadsheets

What to do More of

• Have a communication plan

• Track business value

• Know your audience

• Provide different views of requirements,

packaged different ways

Business Analysis

Communication Plan

28

Gina Schmidt PMP CBAP

Fraser Michigan

THANK YOU!