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.
The following a mixture of my thoughts from managing many
projects
What Was The Goal Again?
Part 1: Where
it came from.
The
view at the PM table
What
am I doing here?
Getting A Project
Started
DCF, NPV, IRR,
VIR, OMG, WTF
Final
Thoughts On Project Management
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.
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
A
project is one small step for the project sponsor, one giant leap
for the project manager
When you sit down at the table for
a project the view on how things are going and what needs to be
watched is different depending which side you sit on, owner or
engineer/contractor.
Much of the publish information on
Project Management is from the view of the engineer/contractor, what
he or she has to do and look out for.
But for most projects this is only half of it.
There are two sides (unless of course you use a round table).
There
are no good project managers - only lucky ones.
The more you plan the luckier you get.
If you take all the small projects
I guess I have worked on as many projects being the owner’s manager
as I have being on the engineers/contractors side
(https://www.linkedin.com/pulse/good-judgment-comes-from-experience-bad-mike-albrecht-p-e-).
The
owner’s engineer has one view; he needs to get as much done with as
few changes as possible.
The engineer/contractor is (or should be) always looking for
changes. There is some
discussion that the type of contract makes a difference, and from my
experience it does, mostly as to who has to keep an eye on what.
When I was first starting out it was common to hire the
engineer (and sometimes the contractor) on a negotiated fee basis
(what would relate to a T&M (time and materials) these days.
Currently the trend is to
competitively bid the whole project, including engineering.
This bidding gets the engineering done on a lump sum basis.
Owner’s purchasing and accounting people like lump sum as they
consider that the costs are fixed.
But having managed from both sides I will argue against this,
rather you are getting a project that will be a constant fight
against any changes by the owner and constantly for changes by the
engineer/contractor.
Also the engineer will generally not provide his best personnel as
his incentive is to minimize his costs and maximize profit.
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.
On a lump sum contract, the
engineer/contractor is always looking for changes, even shades of
paint color can make a difference.
The engineer/contractor is trying to do the least amount of
work as fast as possible and still (barely) meet the specifications.
The owner’s manager, while interested in schedule, is
striving to make sure the project exceeds the minimum
specifications. He is
also constantly striving to prove that items are really in the scope
and not an extra.
I have never really liked lump sum
projects from either side.
When on the owner’s side the specifications and scope had to
be fixed before bidding, and I had to fight against any scope
changes from both directions.
Since any unapproved changes comes out of the
engineer/contractors profit, his goal (at least mine generally was)
to accomplish the stated goals using the lowest cost personnel with
the cheapest equipment that met specifications.
I have generally found that you do not get the
engineer/contractors best personnel on this type of project.
Unfortunately the other extreme has
issues on management too. On a T&M (time and materials) contract,
the engineer/contractor will listen to anybody who wants things
different than the scope.
The owner’s manager is spending almost as much time watching
his own people, because everybody has a better idea.
On one project I was working on in
Nevada where a major expansion project was being developed, and I
was the owner’s manager located in the engineer’s office, I found
the engineers team working on a redesign of the administration
building.
I cornered the engineer’s project
manager and asked who had authorized this.
It seems during the last review meeting at the site one of
the secretaries asked about the location of the restrooms and
wondered about relocating them. I
not too subtely reminded the PM that all changes need to be cleared
through me. And wrote a
project directive.
Letters
to the file: "I believe I must protect myself with this note to the
file."
T&M NTE (time and materials – not
to exceed an amount without approval) is the easiest to manage, in
my experience. You have
a fairly fixed top end, but the challenges over small changes is
generally less. Also
you need less well defined specifications and scope (note you still
need good specifications and scope, just more can be left to define
during the project).
Also since you are paying for what you get, your project team will
generally be better than on a lump sum.
While I cannot list all the
projects I have worked on 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).
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.
Early in my career I learned that the hardest part of
justifying a project was not explaining the technical details, but
rather the financial ones.
This was true for both costs and value of the project.
Which is one of the reasons that I early on got an MBA.
But it still seems like hardest part is the financial
justification, especially with the assortment of acronyms.
https://www.linkedin.com/pulse/evaluating-project-dcf-vs-npv-vir-what-mike-albrecht-p-e-
Evaluating a Project: DCF vs NPV vs VIR or what
You have been working on your project for a long time. You
love your project. You
have even given it a name. You are ready to proceed to the next
level. But the money
people are throwing a bunch of funny letters at you; DCF, IRR, NPV
and such. Why won’t they take your word for it?
This is a good project.
When
seeking financing for a project the money people want to know if the
investment is worth it. Some of the more common ways are to use
financial tools such as DCF, NPV, IRR, Payback, and VIR.
Which are a mouthful of acronyms used in capital
budgeting to analyze the profitability of a projected investment or
project. It can be
helpful knowing what they are and the pros and cons of each.
DCF
DCF or ‘Discounted Cash Flow’ uses a
projection of future cash flows and discounts at a given
interest rate to arrive at a present
value estimate.
Pros - DCF is a forward-looking approach which depends on
future expectations of the project and estimates of the value
drivers. It is the basis of other evaluation tools such as NPV, IRR,
and VIR.
Cons - The accuracy of the results s highly dependent on the
quality of the assumptions regarding Cash Flows, and Discount rate.
The value derived is highly sensitive to the inputs used, leading to
wildly different valuations by different analysts based on their
judgment. DCF works
best when there is a high degree of confidence about future cash
flows. But things can get tricky when it’s difficult to predict
future cash flow trends. Owing to this, it is not considered prudent
to value early stage enterprises using this methodology.
NPV
NPV or ‘Net Present Value’ is the difference between the
present value of cash inflows and the present value of cash
outflows. If the NPV of
a project is positive, it should be accepted. However, if NPV is
negative, the project should probably be rejected because cash flows
will also be negative.
Pros - Accounts for the fact that the value of a dollar today
is more than the value of a dollar received a year from now - that's
the time value of money concept. The other strength of this measure
is that it recognizes the risk associated with future cash flow -
it's less certain
Cons - Does not give visibility into how long a project will take to
generate a positive NPV due to the calculations simplicity. Our NPV
rule tells us to accept all investments where the NPV is greater
than zero. However, the measure doesn't tell us when a positive NPV
is achieved. Does it happen in five years or 15? If it happens at
all. Another limitation of the NPV approach is that the model
assumes that capital is abundant - that is there is no capital
rationing. If resources are scarce, then the analyst has to look
carefully at not just the NPV for each project they are evaluating,
but also the size of the investment itself. Fortunately, there is
another measure that can help overcome this weakness - the
calculation of internal rates of return.
IRR
IRR or ‘Internal Rate of Return’ is the discount rate where
the NPV of cash flows are equal to zero (assuming the NPV is greater
than zero). With
respect to capital budgeting or when evaluating a project is to
accept all investments where the IRR is greater than the opportunity
cost of capital.
Pros - It is widely accepted in the financial community as a
quantified measure of return and it's also based on discounted cash
flows - so accounts for the time value of money. And when used
properly, the measure provides excellent guidance on a project's
value and associated risk.
Cons - There are three well known pitfalls of using IRR that are
worth discussing:
1. Multiple or no Rates of Return - if you're evaluating a project
that has more than one change in sign for the cash flow stream, then
the project may have multiple IRRs or no IRR at all.
2. Changes in Discount Rates - the IRR rule tells us to accept
projects where the IRR is greater than the opportunity cost of
capital. But if this discount rate changes each year then it's
impossible to make this comparison.
3. IRRs Do Not Add Up - one of the strengths of the NPV approach is
that if you need to add one project to an existing project you can
simply add the NPVs together to evaluate the entire project. IRRs on
the other hand cannot be added together so projects must be combined
or evaluated on an incremental basis.
Payback Period
Payback period allows us to see how rapidly a project returns
the initial investment back to the company. In practice, companies
establish "rules" around payback when evaluating a project. For
example, a company might decide that all projects need to have a
payback of less than five years. This is also referred to as the
cutoff period.
Pros - Allows for an easy understanding by management and
stakeholders of when the initial investment will be recouped. This
allows go, no-go, decisions to be made based on simple cutoff date
rules.
Cons - Does not take into account the time value of money.
Discounted cash flow should be the preferred way to evaluate payback
since it does recognize the time value of money. That is cash in the
future is not worth as much as much as cash today. Payback period
also ignores all cash flows that occur after the payback period is
reached.
VIR
VIR or ‘Value/Investment Ratio’ is either the NPV dived by
the total investment or the total investment divided by the NPV.
The first is the more common method.
The higher the VIR the better, the greater the return.
Pros – Being a unit less number, investments of differing
sizes can be compared.
Other methods are impacted by the size of the investment, but VIR
can compare two investments of very different sizes.
Similarly by adding together the VIRs, different groupings
can be evaluated.
Cons – As with DCF and others, it is still dependent on the
accuracy of the inputs and the assumptions used for the NPV
calculations.
Now what?
While using any financial tool can give you a reading of how
viable a project is, it is only as good as the data you use.
Poor quality estimates of reserves, capital requirements,
operating costs, and similar will give poor results.
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.
