New liaison, new priority. Screw doing it right - we need to save money. Thus...
“I know the pipe spec calls for 316 stainless, but we can
save some money if we…”
“I know the pump spec is for [insert good pump manufacturer]
but we can save money if we…”
“I know the design called for a redundant spare, but we can
save money if we…”
“The DCS vendor wants too much money. Let’s go with these other guys…”
“Nobody told us we would have to interface our PLC with your
DCS…”
I just picked five at random. There were many more. Let’s focus on the second one for
giggles. The difference in purchase
price between the pumps was $1000. Great
– we saved a grand. BUT. Now the EPC writes an ECN (Engineering Change
Notice), re-designs the piping or the base or even the electrical, and now your
$1000 savings might have only saved $200 and now you are stuck with a sh_tty
pump (since start up I've already had to replace it once – so much for that inspiring
idea).
There are direct costs to any change – that’s easy (a cool
grand – we’re geniuses) – but no one understood the indirect costs. Neither of the two guys gave it much
thought. They relied on the EPC,
thinking that since the contract was cost-plus it wouldn’t change the amount of
money oozing out of our bank to theirs (that would be the “plus” part). The EPC was shrewd enough (and they are all
shrewd) to know that any change would increase the “cost” part, and though they
weren’t supposed to be making any money on it they most assuredly were since
(as I averred before) they game the system to ensure profit no matter what.
Suppose we had picked a real pro to run this thing and given
them their priorities. Since we would
have been in a rush to get it done because we knew financial Armageddon was a
distinct possibility, the priority would have been schedule, not money. The first task would have been a schedule,
starting with a work breakdown structure – process design, detail design,
procurement, construction and start-up.
Pick your start-up date and work back.
If you end up with a kick-off date in the past (often due to
procurement) then you move your start-up date later and see what tasks take
priority and which ones will sort themselves out. Whatever moved the kick-off is your critical
path – manage it and keep tabs on the rest.
Once you pick the schedule as your priority, the crazy and
petty money issues have less traction.
The question becomes “Can we save a day?” instead of “Can we save a
buck?” Inevitably you actually save a
buck by focusing on schedule, because the plant can run earlier rather than
later, and the great part about a running plant is that it, you know, makes
money.
I had an old project manager brag to me once that anyone on
his project could submit an ECN. The
caveat was that he/she had to submit a letter of resignation along with it, and
the old PM would decide which one he wanted to sign. Feel free to call BS. I did.
But though the bluster is crap, the sentiment is dead on. Every change costs you money and time. On this project we changed too many things,
too late, and for misguided reasons.
Compounding the delay from all the changes was an
indifference to the schedule. I
mentioned earlier that for whatever reason our PM (the ex-maintenance manager)
and the EPC PM (camel spit) did not manage to a schedule. They had one – I saw it – but I remember
being shocked that a well-known EPC such as ours would be so callous with
it. They never updated it based on
reality. They never added all the
changes. It’s a “working document”. Work it.
I take that back. The
EPC changed it to makes themselves look good and make the contractor look
bad. That goes back to the old joke
about you and a friend running away from a bear – you don’t have to be faster
than the bear. Make the contractor look
bad and fewer eyes will pry into your mistakes.
It works. I’ve seen it over and
over.
Just a quick sidebar on schedules. When you create the schedule you start with a
work breakdown, and then figure out how long each item will take (duration) and
how to fit them all together (precedence).
Some PMs like very detailed WBSs (tasks into the 1000s) and some like
thumbnails. Either one can work. But once you start, you need a way to track
progress. Microsoft Project invites
tracking with percentages. So if the
task is half done, you write 50% into the report and call it good. My issue here is “50% of what?” The broader the scope of your WBS, the harder
it is to determine your progress and the more likely any percentage will be
misleading. The narrower your WBS scope,
the more bureaucracy it takes to track it.
Either way, if mgmt sees you are 50% complete, they will assume that 50%
of the money has been spent. And they
will assume the half the duration has been used, as in, “You’ve been working
this task for 2 weeks, you’re 50% done, so you will be complete in 2
weeks.” Wrong, mister. I’m not against tracking duration with money,
but it is a huge pain in the backside, and I’d rather be a PM than an
accountant. Track with hours. Do not say you are 50% complete and allow
someone to imagine what 50% means. Use
“hours-to-complete”, e.g. task 123 had an estimate of 100 hours, we have spent
40 hours and we estimate we need 60 hours to complete. Easy to track, not ambiguous, and fits the
mgmt need for numbers. Bear in mind that
it your estimates will almost always be wrong, because life is a bell curve and
sometimes you get something more than 3 sigmas.
If mgmt wants to be dickheads and pick on your estimates, so be it, but
the law of large numbers implies that some will be long and some will be short,
and when the pudding finally gels you will likely come in close to the original
composite duration. Sorry. That wasn’t quick.
Now, finally getting back to our project. Our PM should have whipped the EPC like a
govt mule until he had a working, living, breathing schedule. The EPC PM should have used said schedule to
direct his engineers and contractor forces and adjust to surprises. The schedule should have been updated daily
to show progress, and it should have shown where the project stood, especially
in regards to the critical path. (By the
way, since I’m a TOC guy I should say “critical chain” – see here and here for
explanations.) Mgmt would have seen how
late the project was and they would have been able to communicate to interested
parties (investors in this case) the facts long before the information became a
runny cow pie that was eventually dumped in everyone’s lap. When it became clear to the board of
directors that the project was FUBAR, they did what pissed-off managers always
do. They fired someone – in this case
the VP in charge of operations. Now,
when you are fixing to begin operations of a new plant, I would imagine that
one of the key people involved in the process would be the VP of operations. Unusual, I know. But he played Charles I and we got stuck with
a sorry sack of an Oliver Cromwell and now we’re still pulling out ear wax with
our pinkies waiting for something to happen.
All because we were too cheap/stupid/arrogant to hire a
decent project manager…
Comments
Post a Comment