Advanced Risk Analysis in Engineering Enterprise Systems

Cesar Ariel Pinto, Paul R. Garvey

• Publisher: CRC Press
• Year: 2016
• ISBN:
  9781000755657
• Edition: 1
• Topic: Negocios y empresa
• Subtopic: Operaciones

Since the emerging discipline of engineering enterprise systems extends traditional systems engineering to develop webs of systems and systems-of-systems, the engineering management and management science communities need new approaches for analyzing and managing risk in engineering enterprise systems. Advanced Risk Analysis in Engineering Enterpri

1

Engineering Risk Management

1.1 Introduction

Risk is a driving consideration in decisions that determine how engineering systems are developed, produced, and sustained. Critical to these decisions is an understanding of risk and how it affects the engineering and management of systems. What do we mean by risk?

In general, risk means the possibility of loss or injury. Risk is an event that, if it occurs, has unwanted consequences. In the context of engineering management, risk can be described as answering the question, “What can go wrong with my system or any of its parts?” (Kaplan and Garrick, 1981). In the past 300 years, a theory of risk has grown from connections between the theories of probability and economics.

In probability theory, risk is defined as the chance an unwanted event occurs (Hansson, 2008). In economics, risk is characterized by the way a person evaluates the monetary worth of participation in a lottery or a gamble—any game in which the monetary outcome is determined by chance. We say a person is risk-averse if he/she is willing to accept with certainty an amount of money less than the expected amount he/she might receive from a lottery.

There is a common, but subtle, inclusion of loss or gain in these definitions of risk. Probability theory studies risk by measuring the chances unwanted events occur. What makes an event unwanted? In economics, this question is answered in terms of a person’s monetary perspective or value structure. In general, “unwanted” is an adjective that needs human interpretation and value judgments specific to a situation.

Thus, the inclusion of probability and loss (or gain) in the definition of risk is important. Defining risk by these two fundamental dimensions enables trade-offs between them with respect to decision making and course-of-action planning. This is essential in the systems engineering community, which traditionally considers risk in terms of its probability and consequence (e.g., cost, schedule, and performance impacts). Understanding these dimensions and their interactions often sets priorities for whether, how, and when risks are managed in the engineering of systems.

What does it mean to manage risk? From a systems engineering perspective, risk management is a formal process used to continuously identify, analyze, and adjudicate events that, if they occur, have unwanted impacts on a system’s ability to achieve its outcome objectives (Garvey, 2008). Applied early, risk management can expose potentially crippling areas of risk in the engineering of systems. This provides management the time to define and implement corrective strategies. Moreover, risk management can bring realism to technical and managerial decisions that define a system’s overall engineering strategy.

Successfully engineering today’s systems requires deliberate and continuous attention to managing risk. Managing risk is an activity designed to improve the chance that these systems will be completed within cost, on time, and will meet safety and performance requirements.

Engineering today’s systems is more sophisticated and complex than ever before. Increasingly, systems are engineered by bringing together many separate systems that, as a whole, provide an overall capability that is not possible otherwise. Many systems no longer physically exist within clearly defined boundaries and specifications, which is a characteristic of traditional systems. Today, systems are increasingly characterized by their ubiquity and lack of specifications. They operate as an enterprise of dynamic interactions between technologies and users, which often behaves in unpredictable ways.

Enterprise systems involve and evolve webs of users, technologies, systems, and systems-of-systems through environments that offer cross-boundary access to a wide variety of resources, systems, and information repositories. Examples of enterprise systems include the transportation networks, a university’s information infrastructure, and the Internet.

Enterprise systems create value by delivering capabilities that meet user needs for increased flexibility, robustness, and scalability over time rather than by specifying, a priori, firm and fixed requirements. Thus, enterprise system architectures must always be open to innovation, at strategic junctures, which advances the efficacy of the enterprise and its delivery of capabilities and services to users.

Engineering enterprise systems involve much more than discovering and employing innovative technologies. Engineering designs must be adaptable to the evolving demands of user enclaves. In addition, designs must be balanced with respect to expected performance while they are continuously risk-managed throughout an enterprise system’s evolution.

Engineers and managers must develop a holistic understanding of the social, political, and economic environments within which an enterprise system operates. Failure to fully consider these dimensions, as they influence engineering and management decisions, can be disastrous. Consider the case of Boston’s Central Artery/Tunnel (CA/T) project, informally known as the “Big Dig.”

1.1.1 Boston’s Central Artery/Tunnel Project

Boston’s Central Artery/Tunnel (CA/T) project began in 1991 and was completed in 2007. Its mission was to rebuild the city’s main transportation infrastructure such that more than 10 hours of daily traffic congestion would be markedly reduced.

At its peak, the Big Dig involved 5000 construction personnel and more than 100 separate engineering contracts, and its expenditure rate reached $3 million a day. The CA/T project built 161 lane miles of highway in a 7.5 mile corridor (half in tunnels) and included 200 bridges and 4 major highway interchanges (Massachusetts Turnpike Authority, Big Dig).

The Big Dig was an engineering and management undertaking on an enterprise scale—a public works project that rivaled in complexity with the Hoover Dam (Stern 2003). From the lens of history, design and engineering risks, though significant, were dwarfed by the project’s social, political, environmental, and management challenges. Failure to successfully address various aspects of these challenges led to a $12 billion increase in completion year costs and to serious operational safety failures—one which caused loss of life.

Case studies of the CA/T project will be written for many years. The successes and failures of Boston’s Big Dig offer a rich source for understanding the risks associated with engineering large-scale, complex enterprise systems. The following discussion summarizes key lessons from the Big Dig and relates them to similar challenges faced in other enterprise engineering projects.

Research into the management of risk for large-scale infrastructure projects is limited, but some findings are emerging from the engineering community. A study by Reilly and Brown (2004) identified three significant areas of risk that persistently threaten enterprise-scale infrastructure projects such as the Big Dig. These areas are as follows.

System Safety: Experience from the Big Dig

This area refers to the risk of injury or catastrophic failure with the potential for loss of life, personal injury, extensive materiel and economic damage, and loss of credibility of those involved (Reilly and Brown, 2004).

On July 10, 2006, 12 tons of cement ceiling panels fell onto a motor vehicle traveling through one of the new tunnels. The collapse resulted in a loss of life. The accident occurred in the D-Street portal of the Interstate 90 connector tunnel in Boston to Logan Airport. One year later, the National Transportation Safety Board (NTSB) determined that “the probable cause of the collapse was the use of an epoxy anchor adhesive with poor creep resistance, that is, an epoxy formulation that was not capable of sustaining long-term loads” (NTSB, 2007). The safety board summarized its findings as follows:

Over time, the epoxy deformed and fractured until several ceiling support anchors pulled free and allowed a portion of the ceiling to collapse. Use of an inappropriate epoxy formulation resulted from the failure of Gannett Fleming, Inc., and Bechtel/Parsons Brinckerhoff to identify potential creep in the anchor adhesive as a critical long-term failure mode and to account for possible anchor creep in the design, specifications, and approval process for the epoxy anchors used in the tunnel.

The use of an inappropriate epoxy formulation also resulted from a general lack of understanding and knowledge in the construction community about creep in adhesive anchoring systems. Powers Fasteners, Inc. failed to provide the Central Artery/Tunnel project with sufficiently complete, accurate, and detailed information about the suitability of the company’s Fast Set epoxy for sustaining long-term tensile loads. Contributing to the accident was the failure of Powers Fasteners, Inc., to determine that the anchor displacement that was found in the high occupancy vehicle tunnel in 1999 was a result of anchor creep due to the use of the company’s Power-Fast Fast Set epoxy, which was known by the company to have poor long-term load characteristics. Also contributing to the accident was the failure of Modern Continental Construction Company and Bechtel/Parsons Brinckerhoff, subsequent to the 1999 anchor displacement, to continue to monitor anchor performance in light of the uncertainty as to the cause of the failures. The Massachusetts Turnpike Authority also contributed to the accident by failing to implement a timely tunnel inspection program that would likely have revealed the ongoing anchor creep in time to correct the deficiencies before an accident occurred.

(NTSB/HAR-07/02, 2007)

Design, Maintainability, and Quality: Experience from the Big Dig

This area refers to the risk of not meeting design, operational, maintainability, and quality standards (Reilly and Brown, 2004).

In many ways a system’s safety is a reflection of the integrity of its design, maintainability, and quality. In light of the catastrophic failure just described, of note is the article “Lessons of Boston’s Big Dig” by Gelinas (2007) in the City Journal. The author writes:

As early as 1991, the state’s Inspector General (IG) warned of the “increasingly apparent vulnerabilities … of (Massachusetts’s) long-term dependence on a consultant” whose contract had an “open-ended structure” and “inadequate monitoring.” The main deficiency, as later IG reports detailed, was that Bechtel and Parsons—as “preliminary designer,” “design coordinator,” “construction coordinator,” and “contract administrator”—were often in charge of checking their own work. If the team noticed in managing construction that a contract was over budget because of problems rooted in preliminary design, it didn’t have much incentive to speak up.

(Gelinas, 2007)

Cost–Schedule Realism: Experience from the Big Dig

This area refers to the...