Figure 3.9 Confidence vs. stability.
For both projects, a retrospective study was employed in which the concept of digital twins was used to construct the model using the concepts described above. Six events were identified in which information from sensors was collected and reviewed. Figure 3.10 shows the project events used for the model. Different, yet equivalent, events were used because Project One followed a traditional SE and project management approach and Project Two employed SAFe, agile, and scrum methodologies to manage the project.
Figure 3.10 Case study project events.
3.12 Results
The case study comparison of Project One and Project Two demonstrates the effects of employing sociotechnical constructs, AI, and HSE into the development environment. Comparatively, the results from the model are plotted showing belief alignment and stability (see Figure 3.11). As noted, belief alignment is generated by calculating the geomean of belief coefficients derived from a series of questions, noted previously. Stability is calculated using 1 minus IE (S = 1 − IE). Four zones were defined to aid in analysis:
Zone 1 (belief > 0.6; stability > 0.6): Projects scoring in Zone 1 generally have a high probability of success.
Zone 2 (belief > 0.6; stability < 0.6): Projects scoring in Zone 2 demonstrate a high level of confidence in the alignment and cohesiveness of the stakeholders but present challenges in that the environment itself and/or the belief alignment is unstable due to exogenous influences.
Zone 3 (belief < 0.6; stability > 0.6): Projects scoring in Zone 3 demonstrate a low level of confidence in the alignment and cohesiveness of the stakeholders, while the environment itself and/or the belief alignment is relatively stable with minimal expected change or exogenous influences. Note that this stable structure does not mean it is good – only that it is deterministic.
Zone 4 (belief < 0.6; stability < 0.6): Projects scoring in Zone 4 exhibit one or more behaviors and associated risks that are commonly identified root causes of failed projects.
Figure 3.11 Belief alignment and stability results for case study.
Analysis was performed using the conceptual architecture for Epoch 4 as a means of comparing and determining value of evolving SE toward Epoch 4 (see Table 3.1).
Table 3.1 Case study comparative analysis.
| Project One | Project Two | |
|---|---|---|
| Systems engineering frameworks | Employed a generic and linear systems engineering model where each activity was independent and completed its full activity before moving to the next phase, e.g. all requirements gathered prior to development | The project team used SAFe, agile SW development, and scrum techniques to continuously evolve the solution and deliver incremental value where feedback was incorporated into future design considerations and development environment structure |
| Sociotechnical network models | Measures of belief were ascertained after events occurred and misalignment had already degraded relationships. In post‐project analysis, it was clear that stakeholders were unaware of belief misalignment or were anchored in their beliefs and unwilling to change | The project team developed a structure network of stakeholders identifying roles and responsibilities and used the network to ensure communications challenge were actively being used to ensure alignment between stakeholders |
| Temporal sociotechnical measures | Traditional project measures were used to measure progress – cost, schedule, and quality. No quantitative measures of stakeholder alignment nor stability were calculated. Small groups aired concerns among themselves created an environment where factions were actively working against project progress in order to protect their personal interests | Stakeholders used active measuring and a cultural shift toward seeking out and resolving misalignment of beliefs. Open communications were the norm where identifying and sharing risks, discrepancies, and differing opinions were seen as a positive behavior |
| Digital twin/AI | No modeling or use of AI to model the ecosystem transpired. Nor were there efforts to understand effects of events prior to their occurrence | The project team used basic model‐based engineering techniques and rudimentary AI techniques to assess alternative courses of action throughout the project life cycle |
Overall, for Project One, eroding belief alignment was evident over the life of the program as the stakeholders did not learn from previous activities and outcomes and instead hardened their own beliefs. Once these patterns were set, the culture of the project made it hard to change the patterns of behavior and project structure. As can be seen, the project had a consistent trajectory leading from initial confidence to the reality of a poorly run project. Conversely, the culture of Project Two employed open communications across all stakeholders and maintained the idea of being a learning organization that actively sought to improve throughout the project life cycle. Continuous alignment and high stability in the project are evidenced by the low variation in measurements for Project Two over time.
While this is an initial study, indications are that the constructs of Epoch 4 will improve success in quality project deployment. As more projects follow these constructs, it is hoped that future studies will prove the value of employing HSE and AI into the development environment.
3.13 Summary
As SE enters Epoch 4, the complexity and scale of projects have increased dramatically. While the advent of MBSE has brought a level of rigor and repeatability to the practice, formal methods that recognize the importance of the sociotechnical aspects of system development are lagging. However, quantitative real‐time analysis of the sociotechnical space has yet to be widely employed. Historically, the difficulties in using sociotechnical models could be traced to a lack of data and computational power. With the proliferation of digital communications, natural language processing, and methodologies, such as SAFe, these fundamental barriers are falling. Yet even with agile approaches, over half of projects fail to be delivered within the time, cost and performance constraints, or fail outright (Mersino, 2018).
This chapter explored how a quantitative model of the sociotechnical space can be used to identify incongruities between stakeholders and highlight risks. While SAFe provides a methodology for continuous communication and data exchange, in most implementations, the data is informal or at best captured in meeting