The Problem with Projects

Serial engineering workflows and dated automation infrastructure practices contribute to poor project flexibility as well as cost, schedule risk

Capital project execution is under the microscope. Ever larger and more complex projects—especially in the energy sector—are proving increasingly difficult to manage. According to a 2014 Ernst & Young study, 64% of oil & gas “mega” projects faced cost overruns and 73% reported scheduling delays. The financial risks posed by this inability to deliver projects as planned has only intensified over the past several years in the oil & gas sector, as lower energy prices have raised visibility. Indeed, more than one multinational energy stock has taken a hit on news of cost overruns or start-up difficulties associated with new, multi-billion dollar production assets.

And while the largest and most complex projects attract the most attention, respondents to a recent study across Control’s broader process industry readership indicate that execution predictability remains a stubborn problem on projects big and small. The median survey respondent indicated that 25% of projects are delayed by 15% of original schedule, and that 20% of projects run over budget by an average of 15%. On the high end, however, a full 25% of respondents indicated that the typical project was delayed by more than 50% of original schedule and/or cost more than 50% of the original budget.

Automation on the critical path

While any number of unexpected developments can throw a project off track, automation is uniquely positioned to either absorb project risks—or to amplify them. This is because the design of process automation systems necessarily depends on the design of the processes they will control.

Traditionally, this serial dependency has been handled by a process “design freeze,” at which point all the essential control and automation requirements are fixed (in theory) and automation development can proceed in parallel with detailed process design. At this point, the automation team engineers the controllers, the enclosures, the marshalling panels, and the particular combination of input/output (I/O) modules and other hardware system components they think they will need based on pre-freeze engineering work.

But today’s projects are increasingly complex, and they may involve dozens or hundreds of equipment manufacturers, skid builders and other process technology suppliers. This adds up to incomplete information and new automation requirements that continue to trickle in long after the design-freeze milestone. These changes cascade through the project, resulting in expensive and time-consuming rework. And that adds up to cost overruns, delayed project delivery—or both.

Inflexible project practices

A big part of this inability to be more flexible—to respond to change and deal with incomplete information—derives from longstanding project practices based on outdated technology and workflows. A chief offender is the hard-wired analog instrument that, despite the availability of digital alternatives, persists in common use because of simplicity of operation, widespread familiarity and habit.

Analog instrumentation, in turn, has long relied on traditional, non-configurable multi-channel I/O modules that might include 8, 16 or 32 fixed input/output channels. While one module may accommodate a limited mix of common signal types, they’re fixed at the factory early in the project cycle, and can’t be changed after shipment. This requires the project automation team to know with a high degree of accuracy the exact mix of I/O channels that will be required for any given application—or face rework and delay.

Making matters worse, each control strategy or application program to be developed must be mapped to a specific controller (or redundant pair of controllers), and all of the I/O modules within the scope of that application connected to that particular controller. All of the associated field instruments must be marshalled to the correct type of I/O channel that is connected, in turn, to the correct controller.

Marshalling as work-around

Indeed, the decades-old practice of physical signal marshalling was created to help deal with all these interdependencies. Onsite, analog signal pairs from the field are landed on hundreds or thousands of pairs of terminal blocks in extensive marshalling cabinets. These custom-built marshalling cabinets also provide a platform for ancillary I/O functions needed for certain loops, such as intrinsic safety, isolation and circuit protection.

Marshalling, then, allows instruments themselves to be commissioned—and basic loop integrity verified—at the same time that the I/O modules, controllers, other hardware and system software undergo factory acceptance testing (FAT) back at the automation supplier’s staging facility. Once tested and shipped to the project site, each I/O module channel is wired, pair by meticulous pair, to the appropriate terminations in the marshalling cabinets. So it is that the two worlds of analog instrumentation and digital control come together. Finally.

Amid mounting pressure to reduce project risk, automation leaders at several large energy companies, including ExxonMobil and ConocoPhillips, challenged the automation supplier community to help keep automation off the critical path to project completion. The vision was that with new technology and new ways of thinking, the automation engineering community could dramatically streamline engineering workflows while increasing the ability of their designs to gracefully absorb even late changes. The remaining articles in this special supplement tell the story of how ABB has done just that. 

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments