It takes a smart dog to find hidden treasures


Thinking about projects

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.

 Part 1: Where it 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

 The view at the PM table

 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 (

 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.


What am I doing here?

 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 (

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.

 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 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 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 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 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.


Final 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.


MIke Albrecht, P.E.

o   40+ years’ experience in the mining industry with strong mineral processing experience in precious metals, copper, industrial minerals, coal, and phosphate

o   Operational experience in precious metals, coal, and phosphate plus in petrochemicals.

o   Extensive experience performing studies and determining feasibility in the US and international (United States, Canada, Mexico, Ecuador, Columbia, Venezuela, Chile, China, India, Indonesia, and Greece).

o    E-mail: