A Framework of Human Systems Engineering

With an estimate of the likelihood of the risk event, the last step is to assess the consequence(s) if the risk event happens and becomes an issue as mentioned above. This is again an opportunity for the AI to employ uncertain reasoning: taking a risk event and the likelihood that it will happen, what are the anticipated consequences? The assessment can be based upon historical data or generalized rules that categorize the risk and its associated consequences and iterate multiple outcomes based on actions taken to determine enterprise‐level success vice local optimization. Generally, the consequences will manifest themselves as a negative effect along the traditional lines for system development, impact on cost, an extension of the schedule, or a decrease in the capability or value delivered with the system increment. This mapping to the traditional measures of system progress facilitates the movement toward the use of AI to risk amelioration.

A conceptually straightforward approach for amelioration is to use AI to calculate the expected value of the impact of a given risk if it comes to fruition and then compare the costs of various amelioration activities with the expected value of the courses of action that could be taken. In general, taking steps to reduce risks that are more expensive than the expected value of the payoff is a poor decision. The other aspect of choosing a risk reducer is to consider the global effect that may have an aggregate cost that is unacceptable even though the local risk calculation may indicate a local improvement. Thus, having AI make a global assessment as to the possible future state to best calculate the expected cost is an important capability that will differentiate the fourth epoch of SE. Essentially, AI will conduct localized sociotechnical risk assessments and heuristic risk assessments and suggest corrective actions based upon a quantitative risk calculation and projections of the effects of the actions.

The concepts described above were used to analyze a large governmental IT development effort. The project was designed to modernize an antiquated system that provided benefits to hundreds of thousands of recipients. Initially, a traditional development effort was undertaken that focused almost solely on the technical aspects of the effort. While the technical engineering was adequate, the project failed in large part due to sociotemporal factors and inherent structural risks. After the project was halted, a new system develop approach was implemented. The project was put back on track and is successfully delivered its primary capability suite. Further development of ensuing capability is on track for successful deployment on time, at cost, and with the requisite quality. For the remainder of this discussion, the first effort will be called Project One, and the second will be called Project Two.

Project One started in a precarious position, but for all intents and purposes, the stakeholders were unaware. There was significant structural risk in that lines of communication were not fully open; the network had insufficient communication channels between the stakeholders, resulting in discontinuities in beliefs; discontinuities in beliefs resulted in disparate actions that can act at cross‐purposes. There was significant relational risk resulting from an apparent unwillingness of the stakeholders to change beliefs even after evidence was presented, which further contributed to the project inability to successfully deliver on time.

To further compound the situation, Project One suffered from type risk that resulted in an inability to recognize systemic risks and trends across the enterprise. In part, there was no mechanism in place to measure the trends, particularly in the area of sociotechnical risks. Further, there was individual cognitive anchoring as described above that further contributed to a lack of alignment. These risks compounded into a situation where the project began to fail, and the failure was not able to be corrected.

Project Two actively implemented changes specifically designed to address the reasons why Project One failed. First, recognizing that the misalignment of sociotechnical factors was a major cause of the failure for Project One; Project Two moved to a SAFe development paradigm as previously discussed. The frequent interactions of various components of the stakeholders, from developers to business owners, provided numerous opportunities to identify and address misalignment in beliefs and prevent actions that are counter to achieving the project objectives. Second, active measurement of sociotechnical factors allowed identification of hidden and emerging problems. This data‐driven approach provided a mechanism to flag biases as well as individual stakeholder risks. The net result was project stability that placed Project Two on a clear road to success.

The case study in Section 4 was used to model the development effort in Section 5. Figure 3.6illustrates a taxonomy of terms that were used to more fully characterize the project and the associated environment and how it directly influences the necessity and frequency for information updates: measurability, situational awareness, information availability, novelty, and complexity. Considerations such as uncertainty, novelty, and complexity also describe the inherent volatility and drive information requirements.

Figure 3.6 Project information ecosystem.

Achieving project objectives is directly dependent upon the quality of the project plans as well as the project sensors, where sensors are humans or project tools that collect the data over time. As the project is executed, the project sensors inform the comparison with the project plan. After the initiation of these actions in concert with or opposition to the plan, the progress is assessed and then repeats until the plan is successfully executed or the project is terminated.

To characterize the project environment, an information ecosystem classifier was developed to characterize the stability of the project environment and the alignment of the project team’s beliefs with what the beliefs of the organization requesting the project. Descriptive questions or phrases were used to provide a better and more consistent means of collecting perceptions versus using single word attributes. To fill out the classifier, each of the following 10 criteria was scored on a 0–10 Likert scale, where 0 means “fully disagree” and 10 means “fully agree.” The project team assessed their beliefs and then provided complementary ratings for the perception of the stakeholder procuring the project. The environmental analysis was developed using a cross section of common attributes identified in literature such as Relationships Between Leadership and Success in Diverse Types of Project Complexities (Muller et al., 2012). The criteria were as follows:

1 All stakeholders are committed to attaining the project objectives.

2 Stakeholders are willing to adapt/change.

3 Project objectives are known and measurable.

4 Timely information is available from stakeholders.

5 Sufficient time is provided to complete the project on schedule.

6 Budget is sufficient for the project.

The project classifier offered a translation to quantitatively assess each aspect of the project ecosystem in terms of where information and communication will be critical to the success of the project. Each aspect considered was assessed for both symmetry and stability/maturity. For example, the project team is wholly committed to the achieving the project outcome, but the stakeholder’s commitment is perceived as lacking, thereby creating an imbalance and likely area of risk. Similar assessments can be done for each of the criteria used in the project classifier.