A Simulationist's Framework
for Business Analysis

Many Practice Areas are Converging

R.P. Churchill

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

The Framework:

• Project Planning
• Intended Use
• Assumptions, Capabilities, Limitations, 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

Origins of My Framework

The aforementioned decades of experience.

Domain Driven Design

MIL-STD-3022 used for a large, Independent Verification and Validation (IVV&A) exercise for a simulation tool.

Validating and extending the framework across many years of maintaining certs, mentoring, and ongoing research.

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)

Basic Engagement Structures

Link to detailed discussion.

Engagement Structure Variations

Link to detailed discussion.

Continuous Iteration and Correction

Regardless of the structure of the engagement, the activities in each phase are carried out in an iterative fashion that continuously incorporates review, feedback, and correction both within and between phases.

Link to detailed discussion.

Tracking Across the Engagement

Link to detailed discussion.

Tracking Across the Design Hierarchy

Whether the work output is a process, product, or environment, the design elements should be consciously understood to be consistent within the overall concept.

The BABOK essentially only covers this form of traceability.

Tracking Across Engagement *AND* Design

Both methods of tracking have to line up.

Link to detailed discussion.

Phase Template

Link to detailed discussion.

Project Planning

Sets up and kicks off the project using traditional project management techniques.

Considers intended management framework (Waterfall, Agile, Kanban, etc.) and special requirements for the effort (existing assets/PMO, identify stakeholders).

In classical project management terms this is where you do the charter, build the team, work out the communication plan, and so on.

This step is bookended by a Project Closeout step at the end of the effort.

Project Planning (cont'd)

Link to detailed discussion.

  Intended Use

This defines the customer's goals for what the new or modified process, system, or product will accomplish.

It may describe technical and performance outcomes but must ultimately be expressed in terms of business value.

This information is included in the Project Charter from the PMBOK.

Assumptions, Capabilities, Limitations, and Risks & Impacts

Define the scope of the project and what capabilities and considerations will and will not be included.

Describe the risks inherent in the effort and the possible impacts of risk items occurring.

Really happens before, during, and after the Conceptual Model phase.

Assumptions, Capabilities, and Risks & Impacts (cont'd)

One way to think about (simplifying) assumptions as zeroing out terms in an equation when they don't apply.

  Conceptual Model (As Is State) (cont'd)

This is where BAs learn what they don't know.

Techniques used in this phase include subject matter expert (SME) interviews, document reviews, observation, training, research, guided tours, and experimentation.

Learning in a new field is called Domain Knowledge Acquisition.

  Requirements (To-Be State: Abstract)

The requirements include the criteria by which functional and non-functional elements will be judged to be acceptable. (Definition of Done)

  Design (To-Be State: Concrete)

The design of the solution is a description of how the solution will be implemented and what resources will be required.

The design may consider many options which have to be evaluated across many criteria (including cost-benefit analyses).

The BABOK kind of "ends" at Solution Evaluation (chapter 8), but BAs really should be involved in and understand the entire life cycle.

The design should also include plans for maintenance and governance going forward.

Design is more about the solution than the engagement.

This represents the To-Be State in concrete terms.

  Implementation

This phase is where the implementation is actually carried out, based on the design.

Implementation also means deployment.

Alternatively, deployment and delivery, and even handover and training, could be considered to be a new phase after testing, depending on the situation.

  Test

  Test (cont'd)

Specialized test SMEs may conduct the majority of system testing, but implementers, managers, customers, maintainers, and end users should all be involved.

Provisions for testing, V&V, and quality should be built into the process from the beginning.

Link to detailed discussion.

Acceptance (Accreditation)

This phase ensures that the customer's plans and criteria for acceptance are met. All of the stated acceptability criteria must be addressed.

This plan must include the process for handing the system or process over to the customer (internal or external). This process may include documentation, training, hardware, software, backups, licenses, and more.

Project Close

This phase bookends the Project Planning phase.

Ongoing projects and programs may effectively never have a closing phase, but this usually only applies to in-house efforts.

Work performed for third parties usually has a defined endpoint.

The Process/Product, Solution, Engagement, and Environment

• Process or Product: What you create or modify.
• Solution: The creation or modification.
• Engagement: The effort of doing the work.
• Environment: The environment in which you work.

How much of each element are you a part of?

Link to detailed discussion.

The 50 Techniques

I need to redo this to add the solution and the environment. See also artifacts.

Link to detailed discussion.

Software Tools

Extended Project / Program / Product Framework

•   Operation and Maintenance
•   End-of-Life and Replacement

Link to detailed discussion.

Structure of the BABOK

• Chapter 1: Introduction (structure of the BABOK)

• Chapter 2: Key Concepts (basic context of business analysis)

• Chapters 3-8: Knowledge Areas (the basic flow of what gets done)

• Chapter 9: Underlying Competencies (Analysis, Behavior, Domain Knowledge, Communication, Interaction, Tools/Tech)

• Chapter 10: Techniques (50)

• Chapter 11: Perspectives (Agile, BI, IT, Business Architecture, Process Management)

• Appendices

BABOK Knowledge Areas vs. Bob's Framework

Popular Practice Areas for Comparison

• Business Analysis (CBAP, CCBA, ECBA, PMI-PBA)
• Project Management (PMP, PfMP, PgMP, PMI-RMP, PMI-SP)
• Agile and Scrum (CSM, CSPO, CSD, A-CSM, CSP-SM, A-CSPO, CSP-PO, A-CSD, CSP, CAL-X, CTC, CEC, CST, PSM, PSPO, PSD, SPS, PAL, PAL-EBM, PSK, PSU, IIBA-AAC, IIBA-CPOA, PMI-ACP, Disciplined Agile)
• 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

General Observations

The practice areas are all targeted problem-solving methods, 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 cycle, and fifty more this cycle, 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, but more to say that they're things you need to do rather than how to do them.

When multiple practices are presented within a single organization, they tend to be presented in similar ways (as in IIBA's approach for data analysis).

What Is Project Management (PMBOK 6)?

See differences from PMBOK 4.

PMBOK 7 essentially dropped half the pagecount and said, "Do Agile."

Project management is mostly about resources and the working environment.

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.

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

Link to detailed discussion.

What Are Agile and Scrum?

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 (that came from eXtreme Programming or XP).

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)

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, management, leveraging, and utilization 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, demographic 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 to 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?

Functional Decomposition

Functional Decomposition (continued)

Compare:

• 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 / Gantt chart 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.

Summary

Everything Is a Loop!

Every management practice is converging on communication and iteration, each with a slightly different emphasis and bag of tools.

• DMAIC: Define, Measure, Analyze, Improve, Control
• DMADV (DFSS): Define, Measure, Analyze, Design, Verify (Design for Six Sigma)
• PDCA: Plan, Do, Check, Act
• OODA Loop: Observe, Orient, Decide, Act
• The Five Whys: Ask "Why?" deep and across
• Scrum, Kanban, etc.: Sprints, items
• "Agile is Dead!": Youtube video
• The Scientific Method: Observe, Question, Hypothesis, Test
• Thermodynamics: 150 years!
• The Fourth Phase of Water: Still something new?!
• String Theory: It may be a colossal dead end.

Link to detailed discussion.

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

rpchurchill.com

E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill