A Simulationist's Framework
for Business Analysis

Part 09:

How to Unsnarl a Problem

When You're Dropped In the Middle of It

R.P. Churchill

Moschitta-Hawking Scale

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

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

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

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)

  Intended Use

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

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

Each goal can be described in terms of:

• Key Questions - questions to be answered
• Application - decisions to be made
• Outputs and Data - specific outputs to be generated

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

Assumptions, Capabilities, 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.

Reasons to omit features and capabilities:

• Outside of natural or organizational boundaries
• Insufficient data or understanding
• Impact on results is small (benefit not worth cost)
• Components aren't active in modes being investigated

  Conceptual Model (As Is State)

If an existing process is to be modified, improved, or automated, discover all operations and data items. This defines the As Is State. (In simulation this is known as building a Conceptual Model.)

If there is not an existing process, work backwards from the desired outcomes to determine what operations and data are required.

Map out the discovered process and document and collect data and parameters for each operation and communication.

The conceptual model is not a specific type of drawing, but is a representation of an existing system using any appropriate techniques.

Iteratively review the maps, data, and descriptions with customers and SMEs until all parties agree that understanding is accurate and complete!

  Data Sources, Collection, and Conditioning

  Requirements (To-Be State: Abstract)

Functional

• What the system DOES
• Describes components, behaviors, entities, actions, inputs, and outputs.
• Contains the details of the design the user sees and the mechanisms that generate results.

Non-Functional

• What the system IS
• Describes qualities (in terms of "-ilities," e.g., reliability, modularity, flexibility, robustness, maintainability, scalability, usability, and so on).
• Describes how the system is maintained and governed.
• Describes how the system is hosted.

  Design (To-Be State: Concrete)

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

The design of the system also includes plans for maintenance and governance going forward.

All elements of the design must map in both directions to all elements of the Conceptual Model and Requirements via the Requirements Traceability Matrix (RTM).

BAs may or may not participate in the design of the system directly, but must absolutely ensure that all elements are mapped to previous (and subsequent) elements via the RTM.

  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, could be considered to be a new phase after testing.

  Test

  Test (continued)

All elements of the test plan and results must map in both directions to all previous elements in the Requirements Traceability Matrix (RTM).

Specialized test SMEs may conduct the majority of system testing, but implementors, 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.

The customer is the final judge of acceptance and may make three judgments:

• Full Acceptance
• Partial Acceptance with Limitations
• Non-Acceptance

Communication Models

There are multiple barriers to clear communication.

These can be mitigated by error-checking mechanisms — and by being clear in the first place.

The end blocks can be improved by review, mutual expertise, patience, and empathy.

The middle blocks can be improved by clearing up the communication medium.

Customer Feedback Cycle

Agile is Dead (in a rigorously formal sense)

Requirements Traceability Matrix

• Best represented by a relational data structure but any method will work.
• Needs discovered later could require the creation of earlier elements.
• Methodological requirements (at bottom) can each be thought of as a kind of non-functional requirement that doesn't need to be mapped.

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.

Framework Summary

All of these things happen - even if any individual doesn't see them.

The more everyone understands about the process and how they fit into it, the better off the whole organization will be.

If this is done properly, the problems (like UI/UX) practically solve themselves in some cases. (See Solving the Problem Abstractly.)

Specific expertise is always valuable, but you can't realize its greatest benefits if the basic process and understanding are disorganized.

Why do so many business analysis activities look so different?

• If you talk to different BAs they often seem to be doing very different things.
• Job ads seem to vary quite a lot.
• I've surveyed five groups of BAs now. They report a lot of things in common, but a lot of things that are different, too.

Different Teaming Concepts

Limited View of Engagement Process

Every participant — especially BAs — might not be participating in every phase of an effort, and so may miss out on some background and some follow-through.

Different Solution Concepts

Types of Solutions

• IT: web, microservices, distributed, client-server, HPC, desktop, mobile, embedded, IOT
• Physical Process: retail, manufacturing, service, transportation, utility, hospitality, medical
• Information: financial, media, research, education/training, communications, entertainment
• Hybrid: combinations of above
• Process vs. Product: characteristics of doing something or characteristics of being something (especially for physical items)
• Creation/Greenfield vs. Improvement: improvement encompasses rearrangement, substitution, compression, and automation
• Scope and Scale of Problem: may vary widely from very small and limited to very large and far-reaching

Different Engagement Concepts

The framework phases all happen, the question is when. In Waterfall the phases proceed in order. In Scrum you might have many offset phases working though parallel pipelines. In a hybrid situation you might do the implementations by priority in the context of an overarching design.

Link to detailed discussion.

Different Engagement Concepts (continued)

Building a simulation or tool is often embedded into a larger analytical effort. Existing system: Create Conceptual Model based on what's already there. New System: Conceptual Model process is really part of the Design exploration. These processes are iterative.

Link to detailed discussion.

Different BA 50 Techniques (from the BABOK)

Link to detailed discussion.

Different Software Tools (from surveys)

What To Do? Questions and Razors

Are there champions for the effort?

• What are they like and what do they want?
• How much and how well do they inform their people?
• How much do they empower their people?

How much is the effort empowered to look at or change?

• Who has it been arranged to talk to?
• Can you talk to people or research independently? (It's not always bad if you can't; people's time is valuable.)
• Are there any areas you aren't allowed to investigate or technologies or solutions you aren't allowed to discuss?
• Do you know the scope and scale of the effort, and its boundaries and limitations?
• Will managers and other stakeholders change based on your findings and feedback?

What To Do? Questions and Razors continued

How much do you know as a BA?

• ...about the business, industry, technical tools, other job functions, competitors, data, BA practice, etc.
• How comfortable are you in talking to people, taking initiative, and recommending change?
• How persistent are you in obtaining (demanding!) clarification and iterative review?
• How flexible and adaptive are you?

How much do other practitioners know?

• Are there iterative cycles of review and feedback to ensure everything is covered and people know what they need to know?
• Are there internal or external communities of practice that can be started or leveraged? (Some of this will depend on the size of the organization.)
• Do people need training? Is it available? Is it effective? Do people want it?

What To Do? Questions and Razors continued

Is the effort focused on incremental changes, quantum leaps, or something in between?

• Is the scope and scale well defined, and do all the practitioners and stakeholders know what is intended?
• Does everyone know what the goal is?

What inspired the effort?

• Strengths: leveraging or improving existing capabilities
• Weaknesses: general unease or specific problems and issues? (There's never enough time to do it right but there's always enough time to do it over...)
• Opportunities: take advantage of new technologies, methods, gaps, market niches, or competitor missteps
• Threats: external competitive or regulatory threats
• These points of view make up a SWOT analysis.
• New people may want to shake things up.

What To Do? Questions and Razors continued

Profiling current activities or products

• Find out where most of the costs or resources are going, and try to address those first.
• Could be related to speed, time, money, materials, personnel, memory/storage usage, etc.

Does everyone have a clear picture of what's going on now? Does anyone?

• Get guided tours by experts and consult existing documentation (drawings, data, manuals) if available.
• If not, then nothing beats finding out what's going on...
• ...so let's talk about process mapping!

Process Mapping

• Describes what comes in, where it goes, how it's transformed, and what comes out.
• Describes the movement and storage of information, material, people, and other entities.
• Maps define the scope of a process. Links to connected processes or "everything else" are called interfaces.
• Are presented at the level of detail that makes sense.
• Process elements within maps can themselves be processes with their own maps.
• State, timing, and other data can be included.
• Entities in a process can be split and combined.
• Processes and entities may be continuous or discrete.

Process Mapping (continued)

Processes may be mapped differently based on needs, industry standards, and the information to be represented.

Mechanical Pulping Mill, Quebec City, QC

Offgas System in BWR Nuclear Power Plant, Richland, WA

Land Border Port of Entry, Columbus, NM

Architecture Study: General Purpose Discrete-Event Simulation

Process Mapping (continued)

• S-I-P-O-C vs. C-O-P-I-S
• Any number of inputs and outputs are possible.

Process Mapping (continued)

Process Mapping (continued)

Process Mapping (continued)

Dispensables Consumables Utilities Information Procedures Interfaces User Interaction Maintenance Cleaning Advertisements Regulations

Process Mapping (continued)

I give specific names to modular components.

Link to detailed discussion.

Process Mapping (continued)

• Operations inside a process block can be examined to any depth.
• The level of detail should be appropriate to the problem.

Process Mapping (continued)

• Procedures and state transitions can be represented in any way that makes sense.
• Procedures will sometimes be random from definable results and percentages.
• Can consider the emotional or customer satisfaction level in a Customer Journey Map as part of Service Design.

Making Sure The Analysis Is Thorough

• Consider all elements from all angles.
• UML is a formal example. The BABOK is more diffuse.
• Simulation is great for understanding because the results show if everything's included.
• Formal mathematical proofs of correctness and optimality exist for some problems.
• Customer review and realized results are the best proof for most BA engagements.

Discovery vs. Data Collection

Discovery is a qualitative process. It identifies nouns (things) and verbs (actions, transformations, decisions, calculations).

Data Collection is a quantitative process. It identifies adjectives (colors, dimensions, rates, times, volumes, capacities, materials, properties).

Discovery comes first, so you know what data you need to collect.

Imagine you're going to simulate or automate the process. What values do you need? This is the information the implementation teams will need.

Context of Discovery

Elicitation is discovering the customer's needs. Discovery is about mapping the customer's existing process.

If there is no existing process, i.e., a new (greenfield) process is being built from scratch, then a form of discovery will occur during Requirements and Design.

Link to detailed discussion.

Data Collection (Process Characterization)

• Captures qualitative descriptions of entity types and characteristics, process types and characteristics, and decisions made.
• Captures quantitative data:
• physical dimensions, volumes, and storage capacities
• arrival and departure rates and times
• diversion percentages (what parts of outputs go where)
• process durations
• whatever is needed to describe transitions
• counts or quantities of what's stored
• velocities, frequencies, and fluxes
• number of stations in each sub-process

Link to detailed discussion.

Data Collection (Process Characterization) (continued)

Data collection corresponds to the Observation technique in the BABOK. Methods include:

• Walkthroughs: guided and unguided (Waste Walk)
• Drawings, Documents, Manuals, Specifications
• Electronic Collection (real-time vs. historical, integrated vs. external sensors)
• Visual / In-Person (notes, logsheets, checklists, mobile apps)
• Interviews (with SMEs)
• Surveys
• Video
• Photos
• Calculations
• Documented Procedures and Policies

Domain Knowledge Acquisition

• BAs should learning machines (and also communication and translation machines)
• Domain knowledge is acquired from prior experience or training or from the process SMEs as you go.
• What you need to know to:
• capture process details
• analyze the operations
• perform calculations
• make sure you don't miss anything

Link to detailed discussion.

IVV&A Inspiration for the Framework

Tell 'em what you're gonna do. Do it. Tell 'em what you did.

Process Improvement

• Incremental improvement vs. Quantum Leap (The Big Kill!)
• Center to target and reduce variation (Six Sigma)
• Rearrangement and Compression (Lean)
• Substitution / Elimination / Automation
• Modify a sub-process and see how it affects the whole system
• Theory of Constraints: The Five Focusing Steps:
• Identify the constraint
• Exploit the constraint
• Subordinate to the constraint
• Elevate the constraint
• If constraint is "broken" go back to step 1

Example Simulation

Simple pass-through simulation using basic component types.

Independent link

Project link

Monte Carlo Analysis   "It was smooth sailing!" vs. "I hit every stinkin' red light today!"

• Randomly generated outcomes may include:
• event durations
• process outcomes
• routing choice
• event occurrence (e.g., failure, arrival; Poisson function)
• arrival characteristic (anything that affects outcomes)
• resource availability
• environmental conditions
• Random values may be obtained by applying methods singly and in combination, which can result in symmetrical or asymmetrical results:
• single- and multi-dice combinations
• range-defined buckets
• piecewise linear curve fits
• statistical and empirical functions
• rule-based conditioning of results

Organizations Exist To Provide Value!

Every activity in an organization must provide value directly or indirectly.

Every object in an organization must provide value directly or indirectly.

Business analysts are a contemporary embodiment of the problem-solving, value-creating aspects of organizations, but there's a lot of overlap with other roles.

Tomorrow the role may be called something different. The Wikipedia page for seemingly every management idea has a section for criticisms.

There Are No Silver Bullets Or Final Answers

Facts and Fallacies of Software Engineering describes 50 years of incremental advance.

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

rpchurchill.com

E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill