|


|
Disclaimer:
Opinions
expressed and
statements made in articles on this page are solely
those of the authors, and should not be
construed as referring to or about, or
representing the position of, any person or
company that is or has been associated with
the authors. This is NOT a blog, but we will
accept and post comments from readers.
PROJECT COST OVERRUNS - A NECESSARY EVIL?
05-Apr-10
It's my guess that senior oil company
management staff are fed up with the enormous cost overruns of
recent large-scale processing facilities projects (particularly in
the Tar Sands). This is supported by comments made a couple of years
ago by the CEO of a major petroleum company, deriding a certain EPCM
company's efforts on a major project. Were those comments deserved? Large
overruns have many causes, but are usually supply and demand related
(resources availability - materials and labour). However, even though
Automation/Instrument and Control Engineering (AE) costs are usually a very small percentage of overall
project costs (typically around 1-2%), the contribution of
late or inadequate AE work to these overruns
is considerable and is totally disproportionate to the AE costs. It seems to be hard for non-AE staff to
accept that even though AE costs are very modest, the complexity of
AE design
and resulting systems greatly exceeds all other project engineering
work!
You Can't Get From Here To There Without
A few Turns Around The Mulberry Bush!
Here are a few of my thoughts about the
state of the industry:
- When large industrial operating
companies (OpCo's, e.g. oil companies) see their bottom line seriously
eroding, cost cutting driven by accountability to shareholders takes place, and
usually focuses on staff costs. What better way to cut costs
than by getting rid of all those pesky technical specialists that
aren't part of company line functions? After all, you can
always outsource/contract this expertise when you need it.
Right?
Well, not necessarily.
Technical staff let go through this process scatter to the
winds, taking their knowledge of company processes, designs
and culture with them. Training programs once part of
mandatory engineering staff development are eliminated and not replaced
by equivalent training in contracting firms. As a result,
the general competency in the specialties drops. When the
need arises to manage a large project, this outsourcing is
used by OpCo's to bring on the necessary staff,
both internally to manage the work and externally using EPCM
resources to do the work. However, availability of
specialist staff
that are fully conversant with a company's specifications, standards, design
philosophies, etc. is now virtually non-existent.
This is particularly true in
the AE sector. If you think all AE specialists are similarly competent
in all process applications, think again. For
example, a person whose design expertise is in utilities
systems will have a very difficult time with froth treatment
processes, not to mention an instrument engineer/designer trying to
do control or wiring design. AE specialists also
usually have a significant background with a particular OpCo (most
often not the one contracting them for
the work) and the sparks fly. Perhaps you have heard the
phase "That's not the way we did it at (company name), and
we're going to do it my way!" ISA standards and
practices go a long way to leveling the playing field, but
have a generality to them that forces customization for a
given project.
When you can't get the right
wrench to remove the nut, you are forced to use what's
available. See if you can figure out what the impact of this
is on the bottom line of a major project. The irony is by
cutting specialist staff to save costs, OpCo project costs suffer
exponentially leading to large overruns. Anybody know who
wins?
- I am in awe of the folks at
OpCo's who make billion dollar decisions based
on recommendations from folks who don't know what they are
doing. Proposed project schedules are a prime example.
Probably because of severe economic pressures, many of the
ones I have seen over the years have been fairy tales and
were
totally unrealistic. I don't know who's at fault - business
development staff, schedulers, management? Maybe all of
them? They should realize that to meet impossible schedules requires a miracle.
So why are these kind of
schedules accepted by an OpCo? How about:
- "We are just
duplicating a similar facility - we'll use that
facility's designs" (not possible - very little
continuity from one project and project phase to the next, and
changes are inevitable)
- "The schedulers
must know what they are doing" (I have only met one
in the last 15 years that actually knew the correct
order, sequencing and prerequisites for AE work)
- "Just accept it -
if we don't get started (or do in on the proposed
timeline), we'll never get approval
for the job. We can sort this out later ..." (laughter!)
- And when the costs
really start to head north because of schedule
busts, you will likely hear "Shut the engineering
down - we'll finish it in the field" (hysterical
laughter!)
As we all know,
AE design work is always pretty much the
last to finish on a project. In order to complete
the necessary designs, AE staff must have
the finished work product from other disciplines
(notably, process and mechanical). Being virtually
"last in", AE staff take the brunt of abuse
about missed schedules and overruns by virtue of the
fact others have burned up any schedule float
available, and that AE staff are usually the last ones around
trying to complete the engineering scope.
- Another example
of an ill-informed decision is the decision to
split the instrumentation and control design
work on a project, giving each to a different
company. At risk here is the integrity of the
systems engineering, ensuring grossly
inflated design costs due to inherently
difficult inter-company communications and
conflicting company priorities.
Systems engineering as a
recognized engineering process has been around since the 1950's,
and basically applies to all aspects of the necessary
integration of equipment and designs to make a particular system
work, with specified availability and reliability. Whether you're
talking about the space shuttle or a processing facility, the
same basic principles apply. In the case of processing facility
projects, AE is responsible for the integration of
instrumentation, wiring/communications and control systems.
While the equipment can come from many different manufacturers,
only the AE design team can adequately ensure the systems
engineering targets are met. Split the team, compromise the job
- it's up to you.
Please don't misunderstand me -
I am not against having a DCS equipment manufacturer's
engineering staff doing the
necessary control design and configuration for a project.
However, if it does, it should also do the instrument
and wiring designs.
Conversely, I have no problem with EPCM staff doing all the
design work - after all, both the DCS manufacturer and the EPCM
contractor pull resources from the same pool of designers. The
argument that a long term relationship with the DCS vendor is a
reason for them to do the control work is misleading - just
buying the equipment from them will ensure the long-term
relationship, including overlife support. However, it's the
OpCo's money and risk, and as one of my supervisors said to me
long ago, "It's only money!", so keep splitting the
work if you are so inclined.
- Most of us in
the Automation industry have been subject to
bombast, name-calling, intimidation and threats
by Project Managers and OpCo staff
when project costs start increasing in a major
way.
Is it deserved? Partly, and usually because of
the scarcity of competent AE design
staff. But the real culprits are real time
design changes, and lack of change to current wiring
designs and to control design configuration
models/methods.
What will
always astound me is how much pleasure so
many Project
Managers take in
browbeating engineering staff on their
projects when impossible schedules start
slipping. Why are these managers so naive
and stupidly
quiet when they are asked by clients/senior
management to make the impossible happen?
You
Changed What ???!!!???
How Many Times
????!!!!???
Let's have a peek
at some of the changes that ruin any project schedule:
- Process
Engineering: I try not to pick on
process engineers too much, but they have a
lot to answer for. Since all AE designs are
based on the processes they are intended to
monitor and control, it should be obvious
that the process engineering has to be
correct and complete in a timely manner for
AE to proceed efficiently. I have managed AE
on several projects when the so-called final
P&IDs have had to be issued over five times!
Why? The smallest process change on a P&ID
requires all associated instrumentation be
reviewed and designs revised if necessary,
creating changes to equipment specifications
(instrument data sheets and databases) and
associated control design work. The
resulting rework due to the smallest process
change is significant - when you have
hundreds of changes, the costs increase
astronomically.
So, why is it that there have
been so many process changes on recent large projects (such as
those in the Tar Sands)? Clearly, the processes are constantly
under review by the OpCo for opportunities to increase safety
and efficiency - there are very few examples of processes which
are not tinkered with by OpCo specialist staff all through the so-called
detailed design stages of a project. This tinkering can
quadruple the AE costs in a heartbeat, and I guess you can
figure out who gets the blame.
- Mechanical
Equipment early procurement: To the
uninitiated, this is a no-brainer - when you
need to buy any major piece of mechanical
equipment with a very long delivery time,
you need to buy it as close to the start of
a project as possible. However, at that
point in a project, the instrument and
control specifications for the mechanical
equipment are preliminary at best, and often
turn out to be nothing like what OpCo staff
finally insist on having. Talk about putting
the cart before the horse!
The obvious culprit here is the
OpCo Project Management staff. They should insist that a final
set of complete and adequate instrument and control
specifications and system design premises be completed and
accepted before
any equipment is even bid! They should then tell their own AE
staff that, barring screw-ups with this spec work, there will be
no further changes! This concept also applies to the procurement
process - all vendor agreements should be in place before the
first quote is requested (more laughter).
- Those pesky
OpCo specialists: Ok - so now you have a
group of mismatched AE prima donnas on the
OpCo side of a project team who each insist
that his/her way is the right way. They
argue with each other and with specialists
on the other side, then tweak and mess with
a project all the way through detailed
design, costing the OpCo more big bucks.
Where were they at the DBM phase when a
complete set of standards /
specifications / system design premises
should have been in place and agreed by all
parties?
One of my favorites is OpCo AE
folks trying to make a supplier of major mechanical equipment
deviate from its standard instrument and control designs (which,
by the way, is either extremely expensive or impossible).
Another is applying OpCo lessons learned from previous projects
while on the fly through detailed design (a little late for that
don't you think?). And by the way, where are the OpCo operations
folks when the DBM is being developed? They show up during the
latter stages of detailed engineering, making life miserable for
everyone (more mega-changes).
It is clear that OpCo project
management staff lose sight of the overall project objectives when
faced with constantly changing designs, from civil engineering all
the way through to electrical/AE. Large scale project detailed
engineering is one of the few endeavors wherein I believe change is
bad - and everyone involved should make that their mantra. The simple
application of the concept "get it right, the first time, the best
way" will go a long way towards solving overruns, but only if that
concept is applied early in a project life, particularly before
detailed design starts!
A Ray of Sunshine on the Wiring Design Side
AE
design processes haven't changed
much in decades - instruments have
to be specified and purchased; a control
system design specified, equipment purchased
and programmed; and wiring/panel designs
completed and equipment purchased. A major
piece of this work is in the wiring/panel
design. I recently attended a presentation
regarding Emerson's new Delta V (c) release
of S-series hardware and V11 software. Using
this product line with its unique modularization of
the I/O should greatly reduce the amount of
wiring design and installation work
vis-à-vis current methods, and will
significantly reduce costs and actual design
time spent on wiring design changes. I am
truly impressed. As for the remainder of the
AE work, who knows what lies ahead?
Ed Huestis, P. Eng
President - ICSE Group Inc. |