by E. Mitchell Swann, PE, MDC Systems®’s Consulting Engineer
o originally the intent was for me to write something about green buildings and sustainability. However, in the context and aftermath of Hurricane Sandy, the many faceted world of sustainability got laser beamed into a narrower frame – survivability, and resiliency. To be able to “sustain” one must be able to survive, and to survive with resilience is a valuable trait. In the world of engineering, construction and projects, survivability is a term more often than not applied to military or defense systems; resilience (and\or redundancy) to data centers and other critical systems. But as has been illustrated by Ms. Sandy, survivability and resiliency should not be considerations for just the hardened operations set.
Many a project has been postured as “world class” and “iconic” – a project that will stand the test of time. Hurricane Sandy has removed a bit of the mental varnish that we’ve lacquered onto our assessments of just how ‘good’ our projects are … and in the process, what passes for real value in a project. You might expect that right now on some hospital project, someone is recalculating the ‘value’ of the cost premium of mounting emergency gen-sets well above a basement level to protect against flooding; or someone else is ordering a small emergency gen-set for a gas station to power its pumps in the event the grid is down.
Of course, hindsight is 20/20. So let’s turn our laser corrected vision forward to get a better view of the road ahead. Are there tools and techniques that can be used to help handle the inherent (and varied!) risks in a capital project or on-going operation? The most common approaches are to eliminate it; transfer it; mitigate it or manage it. Certain risks cannot be eliminated. Nor can they always be transferred – and it is not always wise to do so. The last two approaches typically involve making an immovable object to withstand some undetermined irresistible force. This might also not be the best or most feasible solution either.
There are a number of different risk assessment tools or techniques that one can apply to projects. There are two approaches which I think can work very well to help clarify the implications of a particular risk and to help unpack the interrelationships between systems (both inside and outside the project) that can create unexpected risks.
The first technique is a Fault Tree Analysis or Fault Tree Study. An FTA has similarities to a Failure Mode and Effects Analysis (FMEA). However while the FMEA is very good at isolating a particular process and drilling down into the specific risk elements for that process, an FTA tends t be better suited for a more interdependent or “complex” collection of processes – a situation where a sequence or collection of events or actions are necessary to trigger the critical event. A “hard” FTA will look at a combination of probabilities, fault logic, hierarchical structures, Monte-Carlo simulation and graphical displays to provide a more complete analysis than FMEA by itself. In very complex analyses, the analysis is typically done with software packages due to the large array of combinatorial methods and simulations. A “soft” FTA can be conducted using less ‘computer-driven’ approach, but it will require the input of all of the key stakeholders and good facilitation and record keeping. The FMEA is more like a Process Hazard Assessment in its application and may be better suited than an FTA for certain types of systems. Many large-scale owners will conduct both analyses and marry the results.
A “fishbone diagram” analysis (Ishikawa Diagram ), called such because of the way the diagram looks, is commonly used for TQM, or quality defect prevention or to identify factors feeding into an overall ‘effect’. Causes or factors are usually grouped into major categories to identify sources of variation. Fishbone ‘sessions’ often feel like brainstorming sessions in that the search for ‘causes’ can result in some fairly wide ranges in the types of causes and how they interrelate. Any Lean Six Sigma-ers out there should be familiar with this approach.
The FTA is useful in working thru the impacts of various failure situations and what steps are best situated to either prevent or recover from the event. As a result of the FTA, you should be able to identify “workarounds” and recovery plans. Another “hidden” value of the FTA is that by analyzing failure situations and challenges and how best to avoid or recover from them, you will identify the features, configurations, equipment of systems necessary to keep the facility operating. This forms a sort of ‘baseline’ from which to develop or evaluate a ‘value engineering’ approach – it can help keep things “off the list” simply because of expense.
The fishbone process provides a useful framework to collect at a higher level the universe of factors that can play into a project’s or process’ execution. The fishbone exercise does not typically take the same quantitative analysis steps that an FTA does, but since it can be more free-wheeling, the inputs can take on both a bit of a ‘blue sky’ view – “why not?” – and/or a ‘black swan’ view – “what if…?”. Both of these frameworks are valuable in that give the project team a chance to look outside of the box in sort of a “SWOT” analysis of the project as conceived.
Clearly, the greatest value of the fishbone exercise is had in the early phases of the project whereas the FTA might be more effective after some degree of design development has taken place. In either case, waiting to the end of the project pretty much insures frustration and the undesirable “uh oh” moment. Fishboning, in conjunction with an FTA can tap into synergies that might otherwise been missed and unearth weaknesses that might otherwise have been overlooked.
So how does this all tie back to Sandy and her cousins – earthquakes on the east coast; 2010’s “Snow-mageddon,” droughts, mudslides, frogs and locusts (ok; no frogs and locusts…yet!) and of course Katrina? Simple, those events – some of which were considered unthinkable are moving closer to becoming periodic. But now that we know a power outage at a metropolitan hospital created by a flood is bad, do we really need to repeat it with a blizzard or windstorm to understand that it’s not the flood part that bothers us? What steps do we take or accommodations do we make to deal with the power outage part? More generators and waterproof rooms? Or better distribution of health care capacity such that fewer eggs are in smaller baskets?
Survivability and resiliency can be achieved through hardening facilities to withstand the most irresistible force imaginable – within the limits of our imagination (see “earthquakes in Washington DC”) or we can also look at building in the capacity for ‘work arounds’ (resiliency) within a project system or we can look to expand our project’s “network” so that the pathways of delivery are more flexible and distributed. The solution depends upon the criticality and the situation. Think “rock/ paper/ scissors” – in any given scenario any one of them is “strongest”.
Systems that can survive and rebound are inherently more sustainable than those that cannot. Establish a process at the start of your projects to assess the survivability needs, the resiliency needs and the sustainability objectives. Challenging the definition of ‘impossible’ in the process today can make you less susceptible to sudden extinction by unexpected events tomorrow.
