A Simulationist's Framework
for Business Analysis
Basic Framework Summary
R.P. Churchill
CBAP, IIBA-CBDA, PMP, CSPO, CSM, CSDLean Six Sigma Black Belt
www.rpchurchill.com/presentations/Framework
www.rpchurchill.com | Portfolio | Presentations
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
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.
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.
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.
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!
Customer Feedback Cycle
Agile is Dead (in a rigorously formal sense)
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)
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)
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 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
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 Solution vs. The Engagement
|
|
How much of either process are you a part of?
Link to detailed discussion.
The 50 Techniques
|
|
|
Link to detailed discussion.
Software Tools
| 24 | Excel | Both |
| 14 | Jira | Engagement |
| 14 | Visio | Solution |
| 13 | Word | Both |
| 8 | Confluence | Both |
| 7 | Outlook | Engagement |
| 6 | SharePoint | Engagement |
| 5 | Azure DevOps | Solution |
| 4 | Team Foundation Server | Engagement |
| 4 | PowerPoint | Engagement |
| 3 | Engagement | |
| 3 | Google Docs | Engagement |
| 2 | MS Dynamics | Engagement |
| 2 | Visual Studio | Solution |
| 2 | Notepad | Both |
| 2 | OneNote | Engagement |
| 2 | SQL Server | Solution |
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.
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
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
| 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:
E-mail: bob@rpchurchill.com
LinkedIn: linkedin.com/in/robertpchurchill