A Simulationist's Framework
for Business Analysis

Part 10:

BA Overlaps with Other Practice Areas

and Comparisons to Other Certifications

R.P. Churchill

Lean Six Sigma Black Belt

www.rpchurchill.com/presentations/BAseries/10_Practices www.rpchurchill.com | Portfolio | Presentations
30 Years of Simulation

Continuous simulation of the heating of a square billet and Discrete-Event simulation of a multi-phase process.
30 Years of Simulation


  • Paper (Chemical/Process)
  • Nuclear (Power Generation)
  • Metals (Steel, Non-Ferrous)
  • HVAC (Building Control)
  • Insurance, Banking, Legal
  • Security, Inspections
  • Passenger Processing
  • Medical Facilities
  • Evacuations
  • Area Control
  • Threat Response
  • Logistics, Supply
  • Maintenance and Reliability
  • Staff Level Determination
  • Fleet Management



  • Design and Sizing
  • Operations Research
  • Real-Time Control
  • Operator Training
  • Risk Analysis
  • Economic Analysis
  • Impact Analysis
  • Process Improvement (BPR)

Architectural Considerations

  • Continuous vs. Discrete-Event
  • Interactive vs. Fire-and-Forget
  • Real-Time vs. Non-Real-Time
  • Single-Platform vs. Distributed
  • Deterministic vs. Stochastic
What Is Business Analysis?
The Framework:
  • Project Planning
  • Intended Use
  • Assumptions, Capabilities, and Risks and Impacts
  • Conceptual Model (As-Is State)
  • Data Sources, Collection, and Conditioning
  • Requirements (To-Be State: Abstract)
    • Functional (What it Does)
    • Non-Functional (What it Is, plus Maintenance and Governance)
  • Design (To-Be State: Detailed)
  • Implementation
  • Test
    • Operation, Usability, and Outputs (Verification)
    • Outputs and Fitness for Purpose(Validation)
  • Acceptance (Accreditation)
  • Project Close
BABOK Knowledge Areas vs. Bob's Framework
Bob's Technique Business Analysis Planning and Monitoring Elicitation and Collaboration Requirements Life Cycle Management Strategy Analysis Requirements Analysis and Design Definition Solution Evaluation Requirements per BABOK
Project Planning X x
Intended Use x X x x x Business Requirements
Assumptions, Capabilities, Limitations, and Risks & Impacts x X x
Conceptual Model
(As-Is State)
x X X
Data Sources, Collection, and Conditioning x X
(To-Be State: Abstract)
x X X x X Stakeholder Requirements
(To-Be State: Concrete)
x x X X Solution Requirements
(Functional and Non-Functional)
Implementation x X x X x x Transition Requirements
Test Operation and Usability
x X
Test Outputs
x x X
x X
Project Close X x
The Framework: Simplified
  •   Intended Use
  •   Conceptual Model (As-Is State)
  •   Data Sources, Collection, and Conditioning
  •   Requirements (To-Be State: Abstract)
    • Functional (What it Does)
    • Non-Functional (What it Is, plus Maintenance and Governance)
  •   Design (To-Be State: Detailed)
  •   Implementation
  •   Test
    • Operation, Usability, and Outputs (Verification)
    • Outputs and Fitness for Purpose (Validation)
Business Analysis Core Approach

All practice areas follow a similar problem-solving procedure — because it is essentially a specific form of the scientific method.

(That has proven to be pretty effective, right?)

Business Analysis is about identifying and addressing the customer's requirements.

Engagement vs. System vs. Solution

The engagement is what we do to effect a change that serves customers.

The system is what we analyze and either build or change to serve customers.

The solution is the change we make to serve customers.

50 BA Techniques (from the BABOK)
1Acceptance and Evaluation CriteriaSolution
2Backlog ManagementEngagement
3Balanced ScorecardEngagement
4Benchmarking and Market AnalysisEngagement
6Business Capability AnalysisEngagement
7Business CasesBoth
8Business Model CanvasBoth
9Business Rules AnalysisSolution
10Collaborative GamesEngagement
11Concept ModellingSolution
12Data DictionarySolution
13Data Flow DiagramsSolution
14Data MiningSolution
15Data ModellingSolution
16Decision AnalysisSolution
17Decision ModellingSolution
18Document AnalysisSolution
20Financial AnalysisBoth
21Focus GroupsSolution
22Functional DecompositionSolution
24Interface AnalysisSolution
26Item TrackingEngagement
27Lessons LearnedEngagement
28Metrics and KPIsSolution
29Mind MappingSolution
30Non-Functional Requirements AnalysisSolution
32Organizational ModellingSolution
34Process AnalysisSolution
35Process ModellingSolution
38Risk Analysis and ManagementBoth
39Roles and Permissions MatrixSolution
40Root Cause AnalysisSolution
41Scope ModellingBoth
42Sequence DiagramsSolution
43Stakeholder List, Map, or PersonasEngagement
44State ModellingSolution
45Survey or QuestionnaireBoth
46SWOT AnalysisBoth
47Use Cases and ScenariosSolution
48User StoriesSolution
49Vendor AssessmentBoth
Solution: 30     Engagement: 11     Both: 9

Link to detailed discussion.

Popular Practice Areas for Comparison
  • Business Analysis (CBAP, CCBA, ECBA, PMI-PBA)
  • Project Management (PMP, PfMP, PgMP, PMI-RMP, PMI-SP)
  • Process Improvement (Lean Six Sigma, TQM, Deming)
  • Data Analysis (IIBA-CBDA)
  • Cyber Security (IIBA-CCA)
  • System Architecture (ITIL, TOGAF, BPMN, etc., or appropriate to industry)
  • Skill- or Product-based (typically by vendor, e.g., Microsoft, AWS, Oracle, etc.)
Practice Area vs. Sponsoring Organization
IIBA PMI Scrum Alliance, Scrum.org ASQ and others Other / Technical / Product
Business Analysis CBAP, CCBA, ECBA PMI-PBA
Project Management PMP, PfMP, PgMP, PMI-RMP, PMI-SP
Agile and Scrum IIBA-AAC, IIBA-CPOA PMI-ACP, Disciplined Agile CSM, CSPO, CSD, PSM, PSPO, PSD, plus many more
Process Improvement Lean Six Sigma, Six Sigma Green Belt, Six Sigma Black Belt, Total Quality Management, Deming, others
Data Analysis IIBA-CBDA
Cyber Security IIBA-CCA tons of certs from different vendors
System Architecture ITIL, TOGAF, BPMN, others appropriate to industry
Skill- or Product-based tons of specific vendor certifications for languages and tools
General Observations

The practice areas are all specifically targeted problem-solving methodologies, so overlap is inevitable.

The relevant bodies of knowledge and training materials all mention the same concepts, artifacts, and activities, so we'll highlight the differences in emphasis.

For example, I reviewed about forty hours of material on Agile, Scrum, and Kanban last week, and they mentioned things like ROI, but it isn't a core part of the practice. In Project Management, they mention a lot of things I've discussed with you in the past, but more to say that they're things you need to do rather than how to do them.

What Is Project Management (PMBOK 6)?
Area Initiating Planning Executing Monitoring and Controlling Closing
Integration Management X X X X X
Scope Management X X
Schedule Management X X
Cost Management X X
Quality Management X X X
Resource Management X X X
Communication Management X X X
Risk Management X X X
Procurement Management X X X
Stakeholder Management X X X X

See differences from PMBOK 4.

Project Management Observations

Project Management concentrates on the engagement, but more technical knowledge is always better.


"Tell them what you're gonna say. Say it. Then them what you said." (see Dale Carnegie and Will Smith) -> "Plan the work. Do the work. Monitor and control the work. Close the work."

Project Management Observations (continued)

Project Management practices were initially driven by working in the style of Waterfall, but good managers have always incorporated feedback, correction, and adaptability.

The other practice areas tend not to talk about things like building teams, budgeting, and resource allocation, but you can bet somebody is thinking about and acting in those areas.

I think of Project Management (and Program, Product, and Portfolio management) as a wrapper around all the other practice areas.

What Are Agile and Scrum?

The Wikipedia entries for Agile and Scrum crosslink to approximately a zillion related management, development, analytical, and organizational frameworks.

Agile is a set of principles designed to address specific problems extant in the late-90s, but even its creators have moved beyond those concepts to something more general.

Agile and Scrum can best be thought of as ways to push decision-making and autonomy down to lower levels of organizations, to make them more adaptable and responsive by allowing them to apply their local knowledge most effectively.

This does not obviate the need for higher-level awareness and planning!

Agile and Scrum Observations

This discipline is trying to swallow the world, but how much of a standalone practice is it?

Many practices and techniques can be seen as general or for specific skill areas. Most of the material in the books shown isn't about Scrum and Agile, and is instead about specific software development practices.

Is Test-Driven Development (TDD) really part of Scrum (and the CSD), or is it part of general software development, that sometimes happens in Scrum? Or does it just support the cottage industry of workshops, certifications, and consultants?

Is horizontal vs. vertical slicing part of Scrum or general software design practice? Is the admonition to "always" avoid horizontal slicing a guideline or a hard-and-fast rule?

Agile and Scrum Observations (continued)

The vast majority of Scrum certifications are at the basic level, and that's probably as it should be. The majority of those are for ScrumMasters.

Unless an individual is supporting multiple teams, it is my opinion that a full-time ScrumMaster is a ridiculous waste of resources. This individual should be at least one other kind of subject matter expert.

While there's something to be learned from the practice of Agile and Scrum (and Kanban and SAFe and ...), if the whole certification track and industry disappeared tomorrow I wouldn't miss it. It doesn't teach much not available in the other practice areas — with the following exception:

It does get people thinking about talking to each other and iteratively reviewing their situations. If something has to continue, it should be as a single certification for all kinds of practitioners (with maybe another one for general software subjects).

What Is Process Improvement?

Lean is about doing more with less (efficiency). Six Sigma is about reducing variation and hence errors and waste (quality). Lean is more of an art while Six Sigma embodies numerous specific analytic techniques.

Total Quality Management is driven by defining standards and finding ways to meet them.

W. Edwards Deming was a famous pioneer in statistical process control and overall quality. See his System of Profound Knowledge.

There are many different but related approaches to quality. The Toyota Production System is an overarching management approach with a strong emphasis on continuous improvement.

Process Improvement Observations

Process improvement is not only applied to existing systems. It should also be regarded as an integral part of the design process. For example, the design of the shuttle system at the DFW airport incorporated a full FMEA analysis.

PDCA, DMAIC, OODA loops, and so on are iterative approaches to solving problems, just like the iterative framework I have presented for business analysis.

The Lean Six Sigma Black Belt certification taught me the most and required by far the most effort and time.

Six Sigma materials often talks about "The Voice of the Customer" and "The Voice of the Process." The former is a strong overlap with Business Analysis, and of course all practices ultimately serve the customer, but the bulk of practices are technical.

What Is Data Analysis?

The collection, conditioning, movement, transformation, integration, storage, documentation, analysis, safeguarding, display, communication, and management of data can be explored and pursued to as much depth as you'd like.

I've mentioned previously that data is both enumerative (qualitative nouns and verbs describing what's in a system and what it does gathered through discovery) and descriptive (quantitative adjectives and adverbs that characterize the elements of a system gathered through data collection).

Activities associated with data include artificial intelligence, machine learning, simulation, display and reporting, and historical recording.

Applications using data include optimization, design, trends analysis, risk reduction, economic analysis, and process control. (Think nuclear particle physics!)

What Is Cyber Security?

Most of us frankly don't know much about cyber security, but we know...

  • it's important,
  • how to talk to experts in it to follow their advice,
  • how incorporate their solutions in other work, and
  • that their work involves software, hardware, people, and organizations.

We should know similar things about other practices we might encounter.

What Is System Architecture?

This is the specification of any system in any notation or language germane to and appropriate for its intended use.

Many different standards exist to define certain kinds of systems: TOGAF, BPMN, P&IDs, BIM, and more.

System specifications may have multiple facets or views (e.g., P&IDs vs. physical layout drawings for mechanical pulping systems, or P&IDs vs. isometric drawings for nuclear power plants).

Functional Decomposition

Business Analysis: Discovery to learn what's in a process (possibly embedded within the design phase), Functional and Non-Functional Requirements.

Project Management: Work Breakdown Structure (WBS)

Agile and Scrum: Backlog development and grooming.

Process Improvement: Problem Identification, Fishbone Diagrams, Root Cause Analysis, FMEA

Data Analysis: All data items must be understood and classified. Discovery must take place first so you know what data to collect.

Cyber Security: All parts of the system and related processes must be identified, understood, and secured.

System Architecture: A system is built up from all the components needed to serve an intended purpose.

Functional Decomposition (continued)


  • Work Breakdown Structure describing all tasks that need to be completed in each identified subsystem or sub-task
  • SAFe tracking diagram showing parallel work being conducted across multiple teams which may or may not maintain separate backlogs
  • Microsoft Project schedule of tasks and dependencies.
  • Critical Path analysis diagram.
  • MVP and releasable increment analyses.
General Observations

A lot of specific technical "how-to" information is buried in each practice area body of knowledge. It generally makes sense, but separating it out leaves the overall is-ness of each practice area.

Many practices appear in different bodies of knowledge.

While reading a book by visionary architect Paolo Soleri I realized that, no matter what you're trying to accomplish in life, you always end up trying to find the answers to the same questions. Examining the differences — and commonalities — between the different practice areas we've looked at, confirms this idea.


Business Analysis: How to analyze solve problems for (internal and external) customers, based on their requirements.

Project Management: How to arrange and manage the actual work, in whatever form it takes. It's a wrapper around the other practices.

Agile and Scrum: How to flatten teams and organizations to make them as autonomous, adaptable, and responsive as possible; how to push decision-making down to lower levels.

Process Improvement: How to make activities more consistent (and less error-prone) and use fewer resources.

Data Analysis: How to collect, condition, process, and analyze information in service of all other activities.

Cyber Security: How to ensure systems and organizations safeguard data and processes.

System Architecture: How to design and configure systems and use specific tools.

This presentation and other information can be found at my website:


E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill