Thoughts on Managing a Project
From 40 years of project work in
mining, petro-chemicals, and industrial operations some thoughts on
managing projects from both sides of the table. Having been (and
still am) a project manager for both the owner and for the
engineer/contractor, I can state that the view is very different
depending which side of the table you are on.
WHERE THEY
CAME FROM.
Good judgment comes from experience.
Experience comes from bad judgment
Recently someone asked how many
projects I have worked on, and that got me thinking.
To be honest, I cannot remember all the projects, in
particular the numerous small projects and studies.
I was able to come up with this list of major projects:
There are a couple of other
projects that are not on that list, mostly because they were not
mining related. The
Zimmer Nuclear Power plant – Over $500 million, Project engineer for
Kaiser Engineers (more on this one later) and several oil refinery
and industrial mineral projects in the $50 to $150 million range
WHAT AM I DOING HERE?
While I cannot list all the projects I have
worked on (see above) some are more memorable than others.
With the best intentions projects can go wrong, and we all
have had projects that just did not go right.
I had one memorable experience with a project that just could
not go right.
No
major project is ever installed on time, within budget, with the
same staff that started it.
Yours will not be the first.
Years ago, while working for a major
engineering and construction company, I had the dubious pleasure of
working for a while on a nuclear power plant.
The project had been ongoing for several years and was at
that point where it was 90 % complete.
Projects progress quickly until they become 90 percent complete,
then they remain at 90 percent complete forever
The company was striving to get the
project completed by adding a more staff at the site.
By the time I got there, the on-site engineering group was
well over 100 people.
Spread over a large trailer complex.
Construction personnel were probably over a thousand.
Too
few people on a project can't solve the problems - too many create
more problems than they solve
After spending several hours just
trying to find out where I was supposed to be I got to work. My
assignment was to walk down the reactor emergency shutdown control
system. This involved
checking out a set of drawings every morning.
Take them to reactor building, trace out the piping, mark-up
any discrepancies, and turn the drawings in for review by another
engineer for either field correction or drawing correction.
It seemed every drawing had several
errors on them. As the work progressed I saw construction crews
modifying the work I had previously checked.
On the second week I started asking why so many errors.
It seems that regulations were being changed and this
required modifications.
If
project content is allowed to change freely, the rate of change will
exceed the rate of progress.
I was there for over three months,
and at the end there were just as many marks on the drawings as at
the beginning.
Construction crews were still making the changes and designers were
still working on the drawings.
The plant final did get completed a
few years later, when they converted it to coal fired
(http://en.wikipedia.org/wiki/William_H._Zimmer_Power_Station).
It should be noted that the Wikipedia article
is not totally correct.
This was the second nuclear power plant that the corporation worked
on in Ohio. The other
one did startup and operate.
The difference being that one was built EPCM and the other
EPC, and a I believe one was union and the other non-union.
This required different local legal entities, but the same
parent corporation. In
fact much of the management team from the first plant (the one that
was completed) transferred to the second (which was the reason I
only spent three months there).
SO WHAT IS
PROJECT MANAGEMENT?
There are no good project managers - only
lucky ones.
Looking up the individual parts you
will find management is defined as:
“the act of controlling to get things done.”
And a project is defined as:
“an organized undertaking to get something done.”
Then Project Management would be defined as:
“the act of controlling an organized undertaking to get
things done.” Two key
words appear: controlling and organized.
Both of these imply structure.
And that is my goal: to help the Project manager develop a
structure for their project that they can control it with.
Project management is much more
than scheduling and estimating.
Project management is a process to allow management to know
how things are going both financially and physically during a
project. And the
Project Manager is the one who does the organizing and controlling
of the day to day activities.
GETTING A
PROJECT STARTED
A project is one small step for the project sponsor, one giant leap
for the project manager.
An old adage of
once begun, half done is
just as valid in Project Management.
A proper start, well organized and prepared makes the rest of
the project go smoothly.
The worst projects I have ever been on all got off to a poor
start primarily from lack of a good project definition.
And the best projects have all started well with a detailed
project definition. The
better the project is defined, the smoother it runs, at least from
my experience.
Defining the
Project
If
it looks like a duck, walks like a duck and quacks like a duck, it
probably is a duck.
The
first step in any project is to define the project, this is
determining the who, what, when, where, why and how of the project.
A
project usually starts with someone saying to you, "Can you build,
produce, study, do this for me?"
This request (often called an RFQ (Request for Quote) or an
RFP (Request for Proposal)) may be as simple as being stopped in the
hall, or as formal as a several hundred page document.
During this intial review, whether
a formal meeting or bid walk, or just a review of the documents, is
the time to firmly fix in your mind what the project is.
Read or listen carefully, and ask questions if you are not
sure. Ask questions
even if you are sure.
Clarify all the terms.
I have been burnt twice by assuming that I understood what was being
said.
Case 1
Many years ago, I was at a kick-off meeting
with a client for a study on a new mining project.
The client said, "I want an economic study as part of this
work." The same
phrase appeared in the written package he presented.
As part of the work we produced a comprehensive
look at the project economics.
At the final meeting with the client, I sensed that he seemed
not totally satisfied with the final results.
Afterwards I found out that the "economic study" he referred
to meant he wanted it to be low cost.
Case 2
A few years ago, three others and
myself attended a meeting with a new client.
He asked us to provide a quote for a certain piece of work.
After the meeting all of us wrote down what he asked for, and
we all were in general agreement, and prepared a quote based on that
work.
We did not get the work.
At a follow up meeting the client stated that our proposal
was not even close to what he was looking for.
Either he changed his mind or when he said blue and we
thought royal blue, he meant sky blue.
It is always important to put the
request in your own words and then compare them to the original
request. This is
preparing your own Project Scope.
Project Scope
There is no such thing as scope creep,
only scope gallop.
What is
your project? One of
the first steps is to come up with a brief project title and
description. These need
to be concise and yet informative.
Often this is the only part of the project documents many
will read.
What are
you trying to do and why!
Before you take any steps, write down what you are trying to
do. A brief one or two
sentences, that can be used as a keyword summary to describe the
project, especially to people outside the team.
Top management does not have time to read a long discussion,
unless problems have occurred and they are looking for causes (or
heads). This is
your first (and maybe only) time to sell your project.
This summary has to be clear and concise.
A good check is to have someone unfamiliar with what you are
doing read it, if it makes sense to them go for it.
Install
SV-367 to provide overpressure protection to D-372 to mitigate
SDB-2354.
Upgrade
SC-101 to match CV-135.
Both of
these would make sense to the project team, but to few others.
They use "plant speak" that only people familiar with that
particular operation will understand.
Many of the people who will be reading this title are not
familiar with your plant, or may have their own way of referencing
the same items.
To
resolve safety items (SDB-2354) a pressure relief valve (SV-367)
will be installed on the fuel gas knock-out drum (D-372) ahead of
the feed furnace at the Crude Unit.
This will provide overpressure protection when the valve on
the outlet of the fuel gas knock-out drum is closed.
Replace
the primary sizing screen (SC-101) to match the feed conveyor
(CV-135) capacity to increase plant feed rate and screening
efficiency. Currently
plant capacity is limited by this screen.
The feed conveyor ahead of the screen and the product
conveyors are capable of higher operating rates.
This replacement will increase overall capacity by 15%.
While
somewhat wordier, these two are more descriptive.
Starting
with a good scope and then a good project definition will help
getting the project done safely, correctly, on time, and on budget.
Estimating:
contingency and accuracy – not the same thing
Recently I made a presentation on a project and reported that
the project estimate was $12 million with a +/- 50% accuracy and
that I had used a 25% contingency on the estimate. One of my
co-works asked how I could have a contingency less than the
confidence, weren’t they the same thing.
This lead to a lengthy discussion of what contingency and
accuracy are in an estimate.
Contingency is a measure of how well you have defined your
project. Accuracy is a
measure of how confident you are that you have defined the right
project.
The
amount of contingency used on an estimate is NOT a measure of the
estimates accuracy.
Contingency is for items that will be spent, but have not been
identified at the time of the estimate.
The amount of contingency is a measure of the projects
definition (high definition, low contingency and the reverse).
At the same time confidence and accuracy are related yet
different. An estimates accuracy should be regarded as an assessment
of how far a project’s final cost may vary from the single point
value that is selected to represent the estimate. Estimate accuracy
is traditionally represented as a +/- percentage range around the
point estimate; with a stated confidence level that the actual cost
outcome will fall within this range.
A friend of mine, who was an excellent estimator, once said,
that contingency was not for changes or mistakes, but for costs that
would be in the project that had not yet been defined.
The contingency represents the amount of definition in the
current estimate.
A low contingency does not mean a high accuracy, and a high
contingency does not mean a low accuracy.
An estimate can have an accuracy
of +/- 50% and yet have a contingency of under 10%.
A
good example would be the installation of a new pump that is a
direct replacement for an existing pump.
You may know exactly the amount of manpower and time needed
to replace the pump, and know every item required to replace the
pump (you have a high degree of project definition), but if you have
not verified the cost of the pump, you have a low accuracy estimate.
Similarly,
you may be duplicating an existing facility that was recently
installed, so you have a good handle on the requirements.
So you prepare a new estimate and verify a few key costs,
such as large items of equipment.
Your estimate is very accurate, yet since you have not
verified all the costs, you may have a high contingency.
ELEMENTS
OF A PROJECT EXECUTION PLAN
The
nice thing about not planning is that failure comes as a complete
surprise rather than being preceded by a period of worry and
depression.
Once you
have a simple scope definition, it is time to flesh it out.
The next step is the project execution plan.
This should be a general description of the project. Provide
enough information so that all readers have a clear picture of the
work to be accomplished.
For some projects this may not be feasible since the scope
develops as the work progresses.
Some
specific items that need to be covered in the detailed project
execution plan are: the scope of work; project objectives and
priorities; key assumptions; business purpose; and risk management.
Scope of Work
(What & Where)
First step is a brief (not
more than one page) summary description of the work to be performed,
including support facilities and utilities.
This is an overview of the project, and maybe the only
description most people read.
Reference should be made to other, more detailed project
definition documents, such as the equipment list, P&IDs, etc. or
other detailed scope documents.
Items that may be addressed:
·
Location,
size
·
Major
pieces of equipment
·
Sub- and
super-structures
·
Site work
·
Control
room
·
Storage,
loading, transportation and other peripheral facilities
·
Environmental control systems
·
Laboratories
·
Locker,
lunch room, etc.
Project Objectives
and Priorities (How 1)
First Law of Project
Management: Fuzzy project objectives are used to avoid the
embarrassment of estimating the corresponding costs.
Present short, concise
bullets summarizing all pertinent project objectives. Relative
priorities should be identified as a basis for future decision
making. The following
items should be considered:
·
Quantity,
quality, variety, cost of product(s)
·
On-stream
time, yield objectives, etc.
·
When it is
needed
·
Project
cost objective
·
Project
"Drivers": cost vs. schedule (what is the cost to the client of
delays? What saving can the client realize if the project is
completed early?)
·
Safety
requirements for construction, operation and maintenance
·
Environmental objectives
·
Design
life
·
Staffing
requirements for operating/maintenance
·
Shutdown
requirements
Key Assumptions
(How 2)
What
is not on paper has not been said.
Assumptions have been made
when the concept for the project was first conceptualized.
Even if the project is a duplicate of an existing facility or
unit, it is assumed that another one will work the same as the first
and produce identical results.
(N.B. the second is seldom the same as the first,
improvements are almost
always made.) In addition the first plant was probably not built
exactly per the drawings,
field changes were made.
What
you don't know hurts you.
I saw this several years ago
when the company I was working for had just completed a large coal
facility in Canada and where asked to put in an additional bank of
flotation cells. This
had been planned for and a space had been left for it.
We got started the engineering with what was supposed to be
the final drawings of the original work.
Just to be sure we sent a team to the site to verify
dimensions.
The client was wondering why
since we had built the plant.
Luckly we did send them, as two floor beams were each off by
1½” in opposite directions.
The cells needed to fit between these beams and now they
wouldn’t. A work around
was needed by placing the cells 6” higher than planned.
Identify any assumptions
that, if incorrect, would have a major impact on the project
schedule, project cost, or performance of the completed facility.
Typical key assumptions might include the following:
·
Technology
assumptions: physical and chemical properties of materials, yields,
cycle times, materials of construction, etc.
·
Procurement assumptions: availability of materials and equipment,
price escalation, etc.
·
Construction assumptions: availability of skilled labor, labor
productivity, weather conditions, etc.
·
Others
Business Purpose
(Why)
Cash
in must exceed cash out.
Every project is done for
some business purpose, even if it is an environmental or safety
issue, the project is still being done to keep the business
operating. And the
management team out of trouble.
Designing, building and starting up a project is a
business management process,
not just an engineering and construction activity.
A successful project serves clients by meeting their needs of
commercial or manufacturing interests.
·
What is
the business reason for
this project?
·
How does
the project benefit the client?
Risk
Management
If
you don't attack the risks, the risks will attack you.
After evaluating all the
risks associated with this project, briefly describe here only the
major projected risks and plans for mitigation.
Risks in all areas should be considered (including those
related to key assumptions) e.g.,
·
Commercial
·
Process/Technology
·
Cost
·
Schedule
·
Contracting and procurement
·
Errors in
underlying assumptions
·
Weather,
etc.
Analyze risks in terms of:
·
Impact on
project
·
Probability of occurrence
·
Plan and
cost to lessen
·
Probability that improvement plan
will succeed.
Do You
Have a Project?
"Never
underestimate the ability of senior management to buy a bad idea and
fail to buy a good idea."
It is now time to make a major decision, do you
have a viable project?
Is this something your company should do?
Before you go any farther, the answer to these questions must
be yes. If any one of
them is no, do not proceed.
This is not meant to say that there
will not be risks. All
projects have risks, but the risks should be manageable, and the
rewards should balance the risks.
Gordon's Law: If a project is not worth doing, it is not worth doing
well.
If the answers are no, before you reject the
project complete go back through all your definitions and
assumptions and make sure you have not made a mistake.
Actually even if the answers are yes, review everything to
make sure there are no mistakes.
Once you start proceeding further it gets more and more
expensive to quite.
Many a project was completed because somebody did not want to admit
that that it was a mistake.
PROJECT
COMMUNICATIONS & REPORTING
“ it
is not that engineers cannot write, they just prefer to have a
peaceful coexistence with the English language”
While it may seem true, I believe that actually
another issue is involved.
Most project teams (at least the ones I have dealt with) are
made up of engineers and other technical people.
And they are more into “doing” things than writing about them
or even explaining what they are doing.
A few years ago I was the
Engineering Manager on a large copper project. One of the first
steps in the project was for each discipline head (mechanical,
piping, electrical, civil/structural, and such) to prepare a brief
description of their work and a list of major deliverables
(drawings, equipment lists, specifications, and such).
We had given them an overall scope and description; also we
gave them a template for the deliverables.
The purpose was as a start on
manpower planning, and preparing a final project estimate. We had a
meeting to describe what we were looking for and why.
We gave them a goal of completing it within three days, which
would have been on a Friday.
By the following Monday and I had received two of them, and
sent one of them back for clarification.
A week and a half later, after
sitting down individually with three of them, I had the rough input.
I then spent two days editing and revising all of it to the
same format.
During a review meeting at least
half of the discipline heads added more deliverables to their lists
and more manpower.
Just getting them to put in words
what they propose to do can be difficult.
It was not that they did not understand what had to be done
or how much effort it would take, they just were more oriented to
doing the work then reporting on it.
On this same project, at least once
a month one or another of the discipline leads would state that they
were falling behind because they needed some piece of information
from another group.
Several times I found that the person who needed the information and
who had it, sat on opposite sides of a cubical wall, and if they
stood up could easily talk to each other.
It seems it had been common
practice on a previous project that all requests needed to go up and
down in a formal manner.
I got the team to start working as a team and not separate
groups and actually talk to each other.
An old saying that I have heard
often repeated is:
“project
teams detest progress reporting because it vividly manifests their
lack of progress”.
Recently I asked a designer to
describe how he was going to run a pipe, so he opened up his cad
program and started a sketch.
SCOPE
CREEP
Scope Creep & Safety
The impact of scope creep on budget
and schedule is often discussed, to the point that there is a tongue
in cheek saying: Scope,
Schedule Cost – you can control any two”.
And I have to agree that there is a lot of truth in that
saying, but…scope creep also has an impact on safety which will
impact a project even worse.
I always like to say Safely, Correctly, On Time
and On Budget in that order are the keys.
If you do not work a project safely it will not be completed
on time or on budget as safety holds and stand downs will ruin a
schedule and budget fast.
If you do not do the work correctly the first time, the
re-work will also kill a schedule and a budget fast.
From this perspective, scope creep will impact
safety in several ways.
First by causing a sense of hurry which can lead to losing your
safety perspective by not keeping your
eyes on the job, eyes on the task, and not avoiding line of
fire situations. And
yes injuries are serious and the impact on the personnel involved
can be tragic, but an on the job accident will also cause issues
with the overall project.
A second way is in bypassing safety and
operability reviews.
Early in the project effort is often (and should be) put in
evaluating constructability and operability issues, with the goal of
improving the schedule and the safety of the project. Scope changes
(scope creep) can bypass these evaluations, and changes can be made
that impact the constructability and operability.
This can lead to changes that impact how safely a project can
be built, and worse the ability to operate a project safely.
Most projects have a formal system
for approving scope changes with their impact on schedule and
budget. I propose that
the safety impact should also be evaluated.
Cutting
Scope can cost
We all “know” that scope creep will
negatively impact the cost and schedule (scope grows, cost go up,
schedule lengthens).
Interesting point, reducing the scope can also negatively impact the
cost and schedule. This
usually occurs during detail design, but it can occur anytime during
a project.
Even small changes can have an
impact. One of the
first times I saw this was many years ago on a coal preparation
plant in Canada, the client decided that one of the auxiliary
process water pumps was not needed and asked us to delete it. We
were well into detail design and starting to issue drawings to the
field. The first step
was to prepare a change notice.
The change noticed indicated that deleting the pump would
cost more than cost of the pump.
Deleting the pump would require updating one
process flow diagram, three P&IDs, two general arrangements, two
mechanical installation, two structural, three electrical, and four
instrumentation drawings.
It would also require updating the equipment list, equipment
specifications, vendor data sheets, and several other documents.
As several of these drawings were already
issued for construction, a hold would be needed on some construction
work. The extra
engineering and the construction hold would cause a couple days slip
in the schedule.
When the client got the change notice a meeting
was scheduled (after some heated exchanges).
The result was to leave the pump on all the drawings,
purchase it, but not install it.
Big changes can end up almost not
worth the trouble. Another more recent experience involved a large
milling project where a portion of the flotation circuit was
deleted, but before that portion of the circuit was designed.
But the building design was already at 80% complete. The
plans had been to install the flotation circuit in two stages, but
build the entire building at the beginning.
The client decided to cut off 1/3
of the building along the long axis.
This required redesigning the whole structure to include
foundations. Because of
the new building configuration all structural calculations had to be
redone (it was in an active seismic zone); the structural and civil
drawings all needed redoing, let alone the mechanical drawings.
The impact was a six week project
slip, but there was a cost savings.
The client had anticipated a 30% cost reduction on the
building, but the final numbers were closer to 10% savings.
These savings were only direct costs and did not include the
time value of the six week slip on project economics.
While scope creep can be bad,
removing scope can also be not good.
Oh, and the latest word is the client is considering putting
the portion of the building back on.
WHAT
WAS THE GOAL AGAIN?
Often in the early stages of a project keeping your
eyes on the goal can become difficult, as side opportunities come
along. This can be
especially true in doing process and equipment development.
I have been asked several times why
I keep talking about old technology and processes.
Part of it is that we seem to be in a phase where if it is
not new it is not good.
This seems especially true in research.
Emphasis seems to be on what has happened in the last 5 to 10
years, and in some areas that is important.
While I was doing some research on simulation
and modelling the last few years was important, to see what others
are working on. But in
mining and minerals looking back 50 or more can be important.
Years ago, while I was working for
a major engineering company, a mining company that was investigating
recovering oil from Utah tar sands asked us to evaluate some
technology they were developing. This being in a previous push to
develop alternative oil sources.
They had been working with a major
research organization on this technology and wanted to know if we
thought it was viable.
The company and the research people came to make their presentation
all cheerful and as one team all intermixed.
They described the equipment and
its advantages and were very exuberant as to its potential.
They wanted to know if we felt that they should go ahead and
how long would it take to produce one for full scale testing.
What
you don't know hurts you
My boss turned to me and indicated that I
should answer. Being as
subtle (sic) as I knew how, I said “it will work, as to how long
depends on the shop availability and if you want Dorr-Oliver’s
version or Eimco’s.”
The silence was very noticeable, the company lead asked,
“what do you mean?”
I asked for a minute went to my desk and got
two brochures showing Dorr-Oliver’s
and Eimco’s bowl classifiers.
After showing them the meeting quickly broke up and the
company and the research group left as two separate groups.
Apparently they had spent most of a year
developing a bowl classifier similar to Dorr-Oliver’s bowl rake
classifier and Eimco’s bowl spiral classifier.
Interesting that the original goal had been to develop a a
tar sands process. They
got sidetracked into equipment development. Their version did have
some feature that would be especially useful for tar sands
processing. Once
they found out that the basic process was not unique the interest in
developing it went away.
Their equipment application was the unique
part, but forgetting the goal was process development got them on to
a different path. At
times the alternate pathc could be the better alternative.
I had a similar experience several years later
while doing the development of a centrifugal jig (US Patent No.
5,616,245). Several
times I had to sit down with the financial backers and confirm that
we were in the equipment development business and not trying to get
into gold mining. We
did several of our tests on fine gold ores, usually tailings from a
dredge or dredge sands.
When we got the assays results back the talk of
how we could build a plant and process that material would start.
I sometimes wonder if I had lead them into actually
developing a process plant using existing technology it might have
been better. We
developed the equipment and even built a pilot facility, but then
the funds ran out so it never went anywhere, but I did get a patent.
FURTHER
THOUGHTS ON PROJECT MANAGEMENT
The most
valuable and least used WORD in a project manager's vocabulary is
"NO".
The most
valuable and least used PHRASE in a project manager's vocabulary is
"I don't know".
Everyone
asks for a strong project manager. When they get him they don't want
him.
The most
successful project managers have perfected the skill of getting
comfortable being uncomfortable.
A good
project manager admits a mistake that’s why you rarely meet a good
project manager.
One
advantage of fuzzy project objectives is that they let you avoid the
embarrassment of estimating the corresponding cost.
When things are going well,
something will go wrong.
- When things
just can't get any worse, they will.
- When things
appear to be getting better you have overlooked something.
If project content is allowed to
change freely, the rate of change will exceed the rate of progress.
A carelessly planned project will
take three times longer to complete than expected; a carefully
planned project will take only twice as long.
The same
work under the same conditions will be estimated differently by ten
different estimators or by one estimator at ten different times.
Too few
people on a project can't solve the problems - too many create more
problems than they solve.
A change
freeze is like the abominable snowman: it is a myth and would anyway
melt when heat is applied.
Overtime
is a figment of the naïve project manager's imagination.
There
is such a thing as an
unrealistic schedule.
The
person who says it will take the longest and cost the most is the
only one with a clue how to do the job.
There's never enough
time to do it right first time but there's always enough time to go
back and do it again.
Warning:
dates in a calendar are closer than they appear to be.
