An End-To-End Model for Business Analysis

R.P. Churchill

CBAP, PMP, CLSSBB, CSM, CSPO, CSD

What the BAs do:

• Intended Use Statement
• Assumptions, Capabilities, and Risks and Impacts
• Conceptual Model (As Is State)
• Data Source Document
• Requirements Document (To Be State)
• Design Document (Functional and Non-Functional, including Maintenance and Governance)
• Implementation Plan
• Test Plan and Results (Verification)
• Evaluation of Outputs and Operation Plan and Results (Validation)
• Evaluation of Usability (Validation)
• Acceptance Plan and Evaluation (Accreditation)

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

• Key Questions

• Application

• Outputs and Data

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:

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

• Outside of natural organizational boundaries

• Insufficient data or understanding

• Impact on results is small (benefit not worth cost)

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

Reasons to omit features and capabilities:

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.

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

Data sources, sinks, and messages should be mapped to the Conceptual Model (As Is State representation).

Data items must be validated for accuracy, authority, and (most importantly) obtainability.

Interfaces should be identified at a high level of abstraction initially (e.g., with management and through initial discovery and scoping), and then progressively elaborated through design and implementation with process and implementation SMEs.

BAs that do not have experience working with code and databases directly should work closely with appropriate implementation SMEs (software engineers) to ensure that data and flags, states, formats, and metadata are captured and defined in sufficient detail.

Functional:  What the system does.  The operations carried out and the data consumed, transformed, and output.  The decisions made or supported.  The business value provided.

Non-Functional:  What the system is.  Expressed in terms of "-ilities," e.g., maintainability, availability, reliability, flexibility, understandability, usability, and so on.

This represents the To Be State.

All items in the requirements should map to items in the Conceptual Model in both directions.  This mapping is contained in the Requirements Traceability Matrix (RTM), which can be implemented in many forms.

The requirements include the criteria by which functional and non-functional criteria will be judged to be acceptable.

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

All elements of the design must map in both directions to all elements of the Conceptual Model and Requirements.  This is accomplished by extending 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.

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

BAs help create the plan for how the implementation will be carried out.  This involves project management methodologies and strategic decision-making for prioritizing items for implementation (according to business value and architectural logic), bringing capabilities online (including training), taking existing capabilities offline, and so on.

All elements of the implementation plan must map in both directions to all elements of the Conceptual Model and Requirements.  This is accomplished by extending the Requirements Traceability Matrix (RTM).

Waterfall, Agile, and other methodologies may be used as appropriate to the scope and scale of the effort.

The test plan describes how the system will be tested and the process for reporting, tracking, and resolving issues as they are identified.

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

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.

This process ensures that the system generates accurate results that meet the intended use of the system and provide the desired business value.

All elements in the Requirements Traceability Matrix (RTM) in need not be addressed, but all of the stated acceptability criteria must be.

Validation of results may be objective (e.g., measured comparisons to known values in a simulation or calculation) or subjective (e.g., judged as "correct" by SMEs and managers with respect to novel situations and realizations of business value).

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

The BAs ensure 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

The process described includes the greatest amount of detail.  All projects and efforts perform all of these step implicitly, but some may be streamlined or omitted as the size of the effort scales down.

Appropriate to processes that have a defined beginning and end.  Not for ongoing, reactive, support and maintenance operations.

Works in Waterfall, Agile, and other project management environments.

The framework does not inhibit the ability to explore and test multiple options.

Tell 'em what you're gonna do, do it, tell 'em what you did!

Customer sets framework, BAs and Implementers work within it.

Map and document the existing process (As Is)

Find out what the customer needs

Create a new or modified process (To Be)

Implement the Solution

• Describes what comes in, where it goes, how it is 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 process can be split and combined.
• Processes and entities may be continuous or discrete.

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

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

• 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 transformations
• counts or quantities of what's stored
• velocities, frequencies, and fluxes 

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

• What you need to know to capture the process details
• What you need to know to analyze the operations
• What you need to know to perform calculations
• What you need to know to make sure you don't miss anything

• Incremental improvement vs. Quantum Leap (The Big Kill!)
• Rearragement (Lean)
• Compression (Lean) (subclass of Rearrangement)
• Substitution / Elimination / Automation
• Modify a sub-process and see how it affects the whole process
• See what the new constraints are (Theory of Constraints)

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

rpchurchill.com

E-mail:  bob@rpchurchill.com

LinkedIn: linkedin.com/in/robertpchurchill