A Simulationist's Framework
for Business Analysis

Part 04:

Engagement Phases In Detail


R.P. Churchill

CBAP, PMP, CSPO, CSM, CSD
Lean Six Sigma Black Belt

www.rpchurchill.com/presentations/TWSLseries/04_Phases 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

Industries

  • 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

             

Applications

  • 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
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
Solution vs. Engagement vs. Environment

Business analysis techniques, and this engagement framework, can be applied to analyze, improve, and manage the overall environment of the organization.

How much of any process are you a part of?

Link to detailed discussion.

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)
Customer Feedback Cycle

The work is carried out in each phase pretty much the same way in every management schema.

This framework is good for providing situational awareness of what to do when. It provides specific vocabulary so people can communicate, and communication is what makes it all work.



Agile is Dead (in a rigorously formal sense)

Basic Engagement Structures

Link to detailed discussion.

Engagement Structure Variations

Link to detailed discussion.

Requirements Traceability Matrix

All items in the engagement should map to items in both directions across all phases.

Items should also map in some kind of internal hierarchy, especially in the design.

You can imagine (roughly speaking) that the two mappings should correspond in some cross section.

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, SAFe, 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, acquire resources, and so on.

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

Project Planning (cont'd)

The business analysis process is embedded within the project management process

Project management creates the environment and manages the resources. Business analysis solves the problem.

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, and indeed through the entire engagement.

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.

Another way is to use a constant, assumed value for a term when data cannot reasonably be obtained. Such values should be based on expert judgment. Parametric studies may be performed to gain insight into what values make the system "work."
  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.

Conceptual modeling work encompasses research into and awareness of solution components and methodologies, so this work can be thought of as taking place at any time.

Map out the discovered (or created) 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.

  Conceptual Model (As Is State) (cont'd): Process Mapping

S-I-P-O-C vs. C-O-P-I-S

Any number of inputs and outputs are possible.
  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 Sources, Collection, and Conditioning (cont'd)
  • 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)

This is where the needs of the organization, users, stakeholders, and solution are identified, and represents the abstract To-Be State. This process is usually iterative.

Many people perceive this to be the primary role of the BA, but that's far too limiting.

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.

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

Link to detailed discussion

  Design (To-Be State: Concrete)

This represents the To-Be State in concrete terms.

The design of the solution includes descriptions of how the solution will be implemented and what resources will be required.

It is possible that multiple designs will be proposed and explored. The chosen design should usually be the lightest and simplest that will meet identified requirements, and yields the greatest benefit vs. cost.

Many considerations will drive the design.

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

  Implementation

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

If the proper analysis is done, the implementation should be straightforward. The process will be less iterative in predictive situations and more so in adaptive situations.

This phase may involve the greatest number of practitioners with specialized skills. It is good for those people to be aware of the other phases of the engagement and be involved where possible. ("I know you don't want the nerds to talk to anybody but...")

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

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 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
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 close of an engagement that builds something new only hails the start of managing the full life cycle.

So remember:

We're doing it like this...
...and we're keeping track of it like this.

Requirements Traceability Matrix

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
Requirements
(To-Be State: Abstract)		 x X X x X Stakeholder Requirements
Design
(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
(Verification)		 x X
Test Outputs and Fitness for Purpose
(Validation)		 x x X
Acceptance
(Accreditation)		 x X

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

rpchurchill.com

E-mail: bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill