As part of the product analysis methods, I was discussing with my project management training class when these discussions really made me feel that there is a lack of fundamental understanding on model- based system engineering (MBSE) and its relationship to value. Much of the value decomposition was conceived by the professionals in my training class relating to the product backlog breakdown splitting a product epic into separate components and subdividing them into features and user stories for MVP and MBI/MMF. The focus was of requirements analysis splitting stories into smaller chunks for estimation and delivery lost the connections to the model-based system engineering (MBSE) concepts, such as the system engineering, systems analysis, value engineering, and value analysis, and their tight coupling to technical subsystem interfaces for a simple, secure, safe, stable, and sustainable product.
Some of the familiar concepts of model-based system engineering also pave their connections with the processes for procurement and agreement management, project enablement and related outcome management, technical management, and the technology related management itself. Such concepts can be found in the ISO 15288 on how system related processes are mapped not only in designing the system but also in designing the processes around the system (Hall, 2018), which is not the product alone but the processes around operations (which is a portfolio component), programs (which focuses on benefits management) and projects (which focuses on outcome management).
The concepts of managing these processes within a software context can be seen in the capability maturity model integration (CMMI) and the processes of continuous quality management (both QC and QA) can be seen in 6-sigma concepts. Even ISO 9000 umbrella of the ISO 9001 series to total quality management espouse these processes related to both technology and management of technology to ensure quality in numerous standards and regulations (Rajagopalan, 2023). This is what is emphasized by the agile principle, "Business and Technical stakeholders must work together daily!" While each industry may create different models depending on the specific products and their impact on clients and customers, a few generic MBSE concepts apply in all the industries.
The MBSE concept is analogous to the fable that I heard in India about six blind children touching an elephant and describing the elephant. If elephant is the system and the blind children are the various stakeholders, we are describing the system from what we think we see/feel. Security, for instance, has a different meaning for the technical team members compared to the end users.
For simplicity, let us define the model as a feature-box (functional requirements and non-functional specifications) that adequately represents the set of inputs that can interface requiring the model to prioritize and the set of outputs it will generate. The model's behavior is controlled by a set of complex rules that are manageable. This model now represents the system that must be viewed closely and from far! This requires the system architect not only to see the auditability of the system for diagnosis (such as behavior, but paths also taken and the trails left, considerations for gracious shutdown, etc.). So, how do the system analysis and system engineering differ?
The system analyst will use a combination of techniques (e.g.: data modeling, interface analysis, data flow diagram, and alerts & event triggers) to refine the model! This is reviewing the model at a close distance. So, the system analyst frequently will consider using class diagram, functional decomposition, sequence diagram, network diagram, entity-relationship model, and deployment diagram as well as the total-quality-management (TQM) foundations like the flowchart, scatter diagram, checklist, root cause analysis, and histogram. But the system engineering discipline observes the model from a long distance.
Therefore the system engineer focuses on interference defining the boundary of the system (where the system can no longer sustain itself to be valuable), behaviors that exposes the system's vulnerabilities (model is no longer safe or secure without subjecting itself for damage or causing harm to others). The system engineer then uses market analysis, business rules analysis, concept modeling, scenario analysis, risk analysis, state modeling, interface analysis, decision-modeling, Gemba Walks, workshops, focus interviewing, SWOT/TOWS analysis, benchmarking, and brainstorming further supplemented by TQM techniques like control chart and pareto charts. Please note that these are additional techniques beyond the techniques used in the system analysis.
Now, both the system analysis and system engineering concepts can be extended to the extent of benefit (value) derived by the users and the performing organization. These values can be looked at from multiple angles. One approach is the approach that I normally recommend as custom value, business value, technical value, and process value (Rajagopalan, 2019). The goal of these exercises is not only to protect the customers and business but also look at efficiency gains through the combination of both the process and technical value giving a competitive market value! When all these areas are reasonably protected, they also enhance the future value (that can be measured using ROI, NPV, IRR) of the product within the product portfolio. The short-term focus will be value analysis and the long-term focus will be value engineering.
Another lens, that in my humble opinion, extends from the previous discussions is how the model is sustained and supported. From this lens, we can evaluate model from flow (hence Lean), governance (hence Change Management), behavior (Systems Engineering and Value Engineering concepts mentioned earlier) and decision-making (hence Risk Management discipline, Costing Principles, and Costs of Quality considerations). A few refinements are required here.
- Flow is often thought of as work progressing across various statuses. This is horizontal flow. Flow also should be looked at vertically between projects, programs, and portfolios and multiple systems or projects that must work together.
- Change Management concepts extend in such vertical value flow in terms of risk management, decision-making, funding, and resource planning that happens in program management, PI planning in scaling agile approaches, etc.
- Governance can be supported at a lower level with workflows that enable faster decision-making and system traceability & auditability.
- Behavior can vary very widely depending on the organizational processes as well as the maturity/direction required by the team. Hence, it could range from as simple as time tracking, waiting time evaluation, burn rate as well as evaluating negotiation considerations, team health, conflict resolution, etc.
- The decision-making can be supported by some of the governance considerations, but it could also transcend other work authorization systems based on extensive funding considerations (e.g.: Efficient Frontier, portfolio balancing, resource optimization, etc.).
References
Hall, D. (2018). Systems Engineering Guidebook. Toney, Alabama: Hall Associates. https://www.incose.org/docs/default-source/default-document-library/systems-engineering-guidebook---isbn-9780692091807bb88028572db67488e78ff000036190a.pdf?sfvrsn=365365c7_0
Rajagopalan, S. (2023). Risk Management: Birds' Eye View of some Standards and Regulations. https://agilesriram.blogspot.com/2023/08/risk-management-birds-eye-view-of-some.html
Rajagopalan, S. (2019). Requirements Management: A value mapping exercise. https://agilesriram.blogspot.com/2019/02/requirements-management-value-mapping.html
