A Simulationist's Framework
for Business Analysis

Solving Complex Problems
(In Groups)

R.P. Churchill

Lean Six Sigma Black Belt

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.
35 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
1. All Methods Are Essentially the Same

Link to detailed discussion

2. 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.

3. Origins of My Framework

The aforementioned decades of experience serving in almost every role, in every phase through the entire life cycle, in widely varying environments, in different kinds and sizes of organizations, in locations all over the world.

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.

None of this is about a fixed series of steps. It is instead about situational awareness and continuous communication. It is a framework, a guideline.

4. 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
5. 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)
6. Basic Engagement Structures

Link to detailed discussion.

7. Engagement Structure Variations

Link to detailed discussion.

8. 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.

9. Extended Project / Program / Product Framework

Once a system is implemented, deployed, and accepted, it may be used, maintained, and modified over a long period of time, until it is removed and possibly replaced.

Ongoing modifications to an existing system will involve engagements with an existing As Is state which may have to be "re-discovered."

Ideally, ongoing work will be integrated and linked into the original project's core documentation.

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

Imagine the first six loops in a circle Test connecting back into Intended Use. Now communicate and iterate — forever (think continuous improvement) — like an ouroboros.

Link to detailed discussion.

10. Involve People with the Right Toolbags at the Right Times

Different people with different skills will be involved in different phases of an engagement.

Sponsors, Project Managers, (some) Business Analysts, Senior Customer Reps, and a few others should be involved in every phase through the whole life cycle.

Further information about each phase may be found in the backup slides.

Different approaches may inspire engagements to begin in almost any phase.

All phases will happen, even if they are abstracted away because they are obvious in context.

I have tools in a bunch of different bags to apply to your problem.

11. Approach Context for Potential Solutions
  • Internal vs. External Customers: Affects formality of engagement
  • Standard vs. Open-Ended Solution: Limits to Offers, both can be customized
  • Imposed By Competition: We need to keep up!
  • New Technology: Better(?) Ways To Do Things
  • Automation: Less drudgery, more consistency, lower cost(?)
  • Standardization / Modularization: Consistency plus speed (think Lego!)
  • Rearrangement or Streamlining: Another path to efficiency
  • Lean vs. Six Sigma: Do the same with less vs. Eliminate waste
  • Profiling: Attack the biggest problems first
  • Simplification: Understanding the problem better
  • Incremental vs. The Big Kill: Little steps or giant leaps
  • End-of-Life, Replacement, and Re-purposing: When the status quo becomes untenable
  • Entirely New Solutions: And now for something completely different!
  • Improved Management Techniques: Efficiency from How, not What
  • General Technical Solutions: Applying TRIZ and ARIZ
  • If It's Broke: FIX IT!

Link to detailed discussion.

12. Tracking Across the Engagement

Items are tracked using a Requirements Traceability Matrix.

Omissions recognized in later phases can cause items to be created in earlier phases.

Procedural requirements may apply to each phase.

Link to detailed discussion.

13. 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.

14. Tracking Across Engagement *AND* Design

Both methods of tracking have to line up.

Link to detailed discussion.

15. Phase Template

Items are tracked through each phase until they are completed.

Hierarchical information is embedded in each phase. Only the lowest-level items get individually tested, approved, and passed to subsequent phases.

Items can be created in each phase from items in the previous phase and in response to recognized omissions in subsequent phases.

Review and approval can involve many individuals and groups serially and in parallel.

Link to detailed discussion.

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


E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill

Backup Slides
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)

What we generally think of as BA work happens within the Executing and Controlling phases of the PM framework.

The representation shown is notional. The Executing and Controlling phases are continuous and intertwined, so it's not like some BA phases happen in Executing and others in Controlling.

BAs can absolutely be part of all the Planning and Closing activities — and should be.

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.

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

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

Sometimes assume values when data can't be had, rather than omit an effect.

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)

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 maps, data, and descriptions with customers and SMEs until all agree that understanding is accurate and complete!

  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.

I brought a particular (not quite Liam Neeson-like) set of skills to my first jobs, but I've continued to learn every day since.

  • Some domains require specialized knowledge, others can be learned more easily.
  • Here's where having a good personality and good communication is most important. Show respect to and interest in those you're learning from.
  • What skills have you brought to your work as a BA? What have you learned? What would you like to learn?

Learning in a new field is called Domain Knowledge Acquisition.

  Data Sources, Collection, and Conditioning

Refers to input items (nouns) processed, and parameters (adjectives) that describe the operation and characteristics of the system.

Map sources, sinks, and messages to the Conceptual Model.

Data sources (or assumptions) must be found that support the generation of all required output data items. Trace backwards from desired outputs to required inputs and calculations.

Items must be validated for accuracy, authority, and obtainability.

Interfaces should be abstract initially (e.g., with management and through initial discovery and scoping), and then detailed in design and implementation with proper SMEs.

Ensure that data and flags, states, formats, and metadata are captured in sufficient detail. Work with implementation SMEs as needed.

Link to detailed discussion

Data Collection and Integration
  • System Description: data that describes the physical or conceptual components of a process (tends to be low volume and describes mostly fixed characteristics)
  • Operating Data: data that describe the detailed behavior of the components of the system over time (tends to be high volume and analyzed statistically)
  • Governing Parameters: thresholds for taking action (control setpoints, business rules, largely automated or automatable)
  • Generated Output: data produced by the system that guides business actions (KPIs, management dashboards, drives human-in-the-loop actions, not automatable)

Links to detailed discussions.

  Requirements (To-Be State: Abstract)


  • 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.


  • 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.

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.


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.


Operation, Usability, and Outputs (Verification)

  • Tests to ensure the system operates as intended and produces outputs accurately from the inputs and calculations.
  • This process ensures that the system:
    • makes sense to the users
    • enables manipulation of all relevant elements
    • prevents and corrects errors
    • maintains users' situational awareness
    • includes documentation, training, and help
  • These types of tests are most able to be automated.

Outputs and Fitness for Purpose (Validation)

  • Tests to confirm that the results produced are targeted to the problem under investigation.
  • Ensures simulation behavior matches real-world system for known cases.
  • Validation of results may be:
    • Objective, e.g., measured comparisons to known values in a simulation or calculation
    • Subjective, e.g., judged as "correct" by SMEs for novel situations and realizations of business value
  • These types of tests are most likely to require expert judgment.

Link to detailed discussion.

  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.

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

  • Full Acceptance
  • Partial Acceptance with Limitations
  • Non-Acceptance
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 50 Techniques
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

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

Link to detailed discussion.

Software Tools
5Azure DevOpsSolution
4Team Foundation ServerEngagement
3Google DocsEngagement
2MS DynamicsEngagement
2Visual StudioSolution
2SQL ServerSolution

Software greatly aids sharing and communications, so BAs will concentrate on this. However, a huge amount of solutioning will be aided by specific, technical software or will be software, with which BAs will tend to be less involved.

Link to detailed discussion. Link to survey results.

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
Bob's Framework 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, Usability, and Outputs
x X
Test Outputs and Fitness for Purpose
x x X
x X
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 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)?
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.

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?

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 (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)

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, 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?

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 / 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.


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.