A Framework of Human Systems Engineering. Группа авторов
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.
3.10 Case Study
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.
3.11 Systems Engineering Sociotechnical Modeling Approach
The case study in Section 4 was used to model the development effort in Section 5. Figure 3.6 illustrates 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.
The difference and the size for each element in the classifier was used to derive a coefficient that provided an indication of risk in achieving that element. Equation 3.1 describes the belief coefficient, a tunable coefficient derived from heuristics and project experience:
where
f is the difference for a given criterion
s is the value for stability/maturity
d and g are real values used to emphasize the contribution of size over maturity or vice versa
Belief values run from 0 to 1, where lower values indicate significant risk for project success for a given criterion
The belief coefficient equation was developed for large‐scale, contract‐based, custom IT projects in which a relationship with the stakeholder is integral to the delivery of the project. In essence, alignment with the stakeholder has been found to be equal to or greater in priority than maturity or stability of the environment as determined by the responses to the project classifier questions.
To assess the overall information risk profile