Mike Albrecht, P.E.(AZ)

We welcome your problems with enthusiasm!

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.


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 


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


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.


     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.


 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.


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


 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.


 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.

· Registered Professional Engineer Arizona (Mining)

·  Licensed General Engineering Contractor California

·  ME – Colorado State University, Ft. Collins, CO

·  MBA - California State University, Hayward, California

·  BS Engineering - Michigan Technologi­cal University, Houghton, Michigan