Stephen R. Gelman: Lessons Learned in My 40-year Engineering Career (Part 5)

April 21, 2023

Over the next few days, the Bagley College of Engineering will be publishing Stephen R. Gelman's "Lessons Learned in My 40-year Engineering Career" in multiple parts.

Join us as Gelman imparts wise advice and lessons from his many years in engineering.

Gelman is a two-time graduate from the BCoE, graduating with his B.S. in civil engineering in 1973 followed by an M.S. in civil engineering with a concentration in environmental engineering.


Project Management

If the technical content of a project is the “entree," project management is the whole meal, from preparation to putting up the clean dishes. Projects are remembered by clients (for better or worse) more for how they are managed than for the technical content. A project does not have to be a design or construction project. Studies, pilot plants, master plans, and other assessments are projects and require project management. When I left college with my bachelor’s degree, I had no concept of project management. Even in my first job, I was on several projects, but at my level, there was no communication of the concepts of project management. There were “tasks.”

I have no intention of delving into all the aspects of project management. You can study Harold Kerzer’s Project Management, A Systems Approach to Planning, Scheduling, and Controlling. It is an excellent reference. On a much simpler basis, a colleague of mine once said that managing projects was really three C’s: cost, change, and cash. He was a financial person, and, certainly from controlling the budget and financial success, he was correct. I would add another C, customer satisfaction, a big Q, quality, and an R for risk management to the list. In defense of my cohort, one indicator of customer satisfaction is whether they pay on time (cash) and deal with change. And any project with poor quality typically experiences negative cost and cash impacts.

The key elements of project management include: 1) scope definition; 2) defining cost and schedule requirements; 3) putting a competent team together and defining roles, responsibilities, schedule and milestones; 4) tracking progress; 5) managing change; 6) communicating with the client; and 6) closing the project.

The scope of work is often described in detail in a proposal which is often incorporated or referenced in the contract. It is critical for the entire team to understand that the contract is the controlling document. It is good practice for all lead engineers to have a copy of the contract and to read and understand what has been committed to.

A clear set of project instructions and work plan is imperative to communicate pertinent information required to successfully execute the project. The document should outline roles and responsibilities, deliverables with due dates and the person accountable for the deliverable, a schedule, and pertinent instructions on procedures for the project. These can include travel requirements, documentation required by the client, meetings, and more detailed design procedures and standards, including document control when applicable. As an associate told me once, the value of a plan is the thinking that goes into the plan. Writing down these items forces the project manager and team to think through the project. I always found it important to convey my concept of the project and my initial thoughts on how we should approach it.

In consulting and design proposals, there is tension to be competitive with the level of effort and costs while providing enough time to adequately engineer the project. So, it is really important at the outset to have a plan to do that. The real challenge of project management is to have realistic schedules and budgets and to have systems to track actual progress. As a rule (of thumb?), if you fall behind schedule, you will almost certainly overrun the project budget.

All engineers should have some concept of critical path scheduling. You need to understand the order and precedence of the tasks to arrange your work, so you do not unduly impact later critical tasks. You may need to contact vendors early if you need their input for certain design details or to evaluate options if the project is a study. On design projects, equipment and materials delivery times often set the critical path and need to be incorporated as soon as possible in the project or even in the proposal phase. Often long-lead equipment may be purchased before the design and designed around.

The Project Team Charter

One useful tool that we used was a project team charter. The chartering process is one that is useful for any project type activity—i.e., one that has a start and a stop and a defined set of outcomes. In a nutshell, the purpose of the team charter is to have the team understand project goals, expectations, measurements, and individual and group responsibilities. There are numerous online outlines and processes that I will not repeat here. What I found most critical (and the most difficult) about the chartering process is hashing out boundaries: where one’s role stops and another’s begins. Getting this worked out at project kickoff can save a lot of miscommunication later in the project. Another important area is to get company and customer endorsement. The company endorsement should commit the team and company leadership to agree on resources and needs the team expects in order to meet its commitments. The customer endorsement ensures the engineer’s team and the customer sponsors align on key elements and expectations and what the team needs from the customer (e.g., timely reviews, access to facilities and data, and client standards).

Experience says

  • Document all meetings and client decisions and make sure you get their endorsement. A useful approach is to always say if you do not hear back in due time, your notes are the final record.
  • There will almost always be scope changes. Be prepared to document and cover with the client.
  • The last 10 percent of a project always takes more than 10 percent of the budget. You need to plan accordingly.
  • Beware of “assuming” that your assumptions relieve you of liability. Here is an example. When we did groundwater projects that involved well installation, we always included an assumption of the number of wells and depth. On one project, we had to drill wells deeper than was assumed, and the client refused to allow us to recover costs even though we stated our price was based on a certain number of feet. His response was that we were the experts, and he was not liable for our assumptions. This was the ONLY client I ever heard this from, and we did hundreds of projects with similar statements. A clearer statement of the need for deeper drilling and who pays in the contract would have been helpful.
  • Most project overruns occur because the original estimate is overly optimistic. Some of this is optimism. Of course, a poor job of execution can cause any project to overrun. But it is important to be totally aware of the basis of the proposal and track and manage all deviations. A key deviation can be internal—e.g., a less experienced team that costs more to complete tasks and deliverables.
  • Manage to the contract.
  • While every project does not need a detailed critical path schedule, it is important to know the precedence of events and dependencies of tasks. One useful tool is some of the duration estimates used in the schedule. One is that the most likely duration of a task is Td = (a +4b+c)/6. In this example, “a” is the best case, “b” is the average case, and “c” is the worst case. Since the worst case is almost always farther from “b” than “a” is, it tends to give a more realistic estimate of project duration. This is how many schedules enter the duration of all tasks.

Risk Management

There are two components of risk management to discuss. One is business risk management, and the other is project risk management. The former covers an overall approach to business — what projects you pursue, customer selection, contract and fee arrangements, practice areas, cash management, staff selection, training, and retention, etc. The latter is primarily the responsibility of the project manager. It is specific to the project and involves a detailed identification and qualitative assessment of the risk, development of mitigation plans, monitoring and remedial actions. Risks can be schedule driven, or they can be due to a lack of key staff availability in the timeframe needed to execute the project, client-driven constraints, lack of sufficient data, technology risk, handling of dangerous materials, and performance of key partners in many cases. These risks should be in very close alignment with those the client would identify. Both business and project risk management can be subjects of entire books, so I will try to hit the high points.

As I put this paper together and look back at the table of contents, I realize the whole point of what I am doing is hopefully helping individuals learn something about comprehensive business risk management. Business risk management includes everything from hiring practices to project and client selection to specifics of insurance policies regarding errors and omissions. I believe the biggest risks firms can take involve taking on inherently risky projects. This includes those where the company has limited experience and is trying to step into a new service set. An example is an engineering company that wants to enter construction, especially fixed-price construction. There clearly are technical and business differences between engineering and construction. In many cases, the major difference can be how each manages the customer relationship. Companies that are good at fixed-price construction have excellent estimating skills and make decent margins by aggressively managing the change process. This can lead to conflicts with a client, especially when you are delivering other projects for them under a more service-based approach.

Another area of inherent risk is working with new or first-of-a-kind technologies. This includes technologies that are new to the industry but, as importantly, new to the engineer doing the design. There is a risk of not knowing what we do not know.

Client selection is important in business risk management. Some clients are by nature litigious. Similar to technology, first-time clients for a company (or first-time engineers for the company hiring them) will inherently carry more risk. So, it is best to work for a new client on something you are very good at. The more you work with a client, the better you know them — how they deal with cost and schedule issues, how consistently and efficiently they provide information and make decisions, how they pay and general contract management.

Technical risks are another area that can arise. These are often not deal breakers if you are operating in an area you have experience in, but they can destroy margins and customer relationships. I have found the best way to manage these risks is to make sure there are some creative people on your team who are good at thinking critically about what can go wrong and developing a risk register that includes mitigation measures. Project checklists are a decent start, but often a team will go through a pick list and not consider items specific to their project.

Here is an example of a risk-laden project. An oil company wanted a fixed-price design-build contract for a wastewater plant on a Caribbean Island. The proposal took months to develop as a partial design had to be done to develop a decent estimate. One clause in the contract gave the owner the right to make any change at any time in the project with no ability to recover costs for the design-build company. On one level, this made some sense, such as an obvious safety issue in the design. But as worded, the client could change almost anything, and the contractor would not be able to recover costs. A more reasonable approach would be to freeze the cost at some point in the design, and that would still not relieve the contractor of some liability. Any time we brought these issues up, the client would say, “Just add it to your fixed price.” It is impossible to put a number on an open-ended liability. And it is not a fair deal. Offshore work on islands also adds liability on availably of materials and construction equipment. So the odds were stacked that this was not a good deal at any price.

The key point in risk management is the word management. You cannot avoid risk, but you can manage it.

Cost estimates

At some point (and usually at many points), you will be asked to give a cost estimate for the projects you are working on. There may be nothing more fraught in engineering than dealing with cost estimates. The first thing to understand when a client asks for an estimate is the purpose of the estimate. There is a big difference between an estimate to get an understanding of the scale and scope of the project versus one that will be used to get project funding. There are great online resources on cost estimating, but here are some key points:

  • The estimate “accuracy” depends on how much detailed engineering work is completed as the basis of the estimate. I highly recommend you read and study work by the American Association of Cost Estimators (AACE) to understand the standard definitions of Class 1 - Class 5 estimates and the amount of engineering work needed to make each class of the estimate.
  • There is a difference between “contingency” and management reserve. Contingencies typically cover a specific scope. If, for example, you find that there are major issues with the existing electrical components that you expected to use in your project and you have to include these in your project, you cannot expect to have that covered by a contingency. So it is critical that estimates be accompanied by a clear scope. Contingencies cover bid uncertainties and price variation of certain components (for example, steel price variability). Uncertainties not known should be identified as a reserve for unknowns, not simply added to contingency.
  • Estimates should have accompanying verbiage that says the engineer does not control the market or commodity prices, etc.
  • Estimates are no better than the amount of engineering work done to get the estimate. You simply cannot get a +/-10% estimate off of a cursory alternatives study. The AACE definitions explain this.

All of this may lead to tough discussions with clients who want precise numbers with less engineering work done to get them. That is why you need these standard guidelines to back up what you are doing. The bottom line is often that the customer does not want to go to senior managers and ask for more money to finish a project that was under-budgeted. This can be very detrimental to their careers.

The other area of misunderstanding, besides the estimating class, is that the owner typically has other costs over and above construction costs. I have heard the terms “capital cost” and “construction cost” used interchangeably. They are different. You also have “installed equipment cost,” which is less than the construction cost. It is important to understand these terms. At a conceptual level, it is not difficult to get major equipment estimates and estimates of installation costs. It helps the client to see that part—but it is not the final construction cost. Contractors add mobilization, profit, overhead, insurance, and bid contingency to get their bid number. Capital costs can include other owner costs and the cost of amortization.

One sign that costs will be a big deal is when a client tells you what the estimate must be. Telling you on the front end what they can afford is good guidance. But after developing a solution they need, it is irresponsible to purposefully misrepresent the cost. The truth will come out!

As you can see, estimates are a big deal. The best advice here is to use good estimators to do the estimate, understand the client and their needs for the estimate, and communicate clearly on risks and unknowns at the time of the estimate. Also, note that all my experience does not account for the huge unknowns of the current supply chain issues, which just compound the uncertainty in both schedule and budget.

Budgets

No matter what direction your career takes, most likely, you will have to deal with budgets. Depending on the organization, budgets have different meanings, and there are different ways of dealing with change. In many private organizations, you can move money around as long as you meet some bottom-line budget. In others, such as many government programs, there are distinct processes to “reprogram” budgets. In some government organizations, overrunning a budget is illegal, while in many private businesses, you may receive a reprimand or poor review or a reward if your extra “investment” reaped great returns.

To have any budget control, you need a few things. First, you must have a good estimate and understanding of what is in the budget. It is hard to meet an unrealistic or unjustified budget. Second, as time progresses, you have to accurately know where you are project-to-date. (Everything is a project!) And third, you must have a good estimate of cost-to-complete. Budget control fails on projects due to not knowing where they are, as well as having overly optimistic costs-to-complete estimates. Facing the music and reality is important in assessing where the project is and what it will take to complete.

Procurement

The closer you get to construction and schedule concerns, the more you can appreciate the importance of the procurement process. In a lot of municipal work the construction contractor buys most of the equipment and materials. Thus, the burden of procurement falls on the contractor. Most industries, however, purchase much of the equipment themselves to save markups and because they are willing to procure much earlier in the design process or even before design. The procurement professionals are responsible that the right items are purchased and that they get the best delivery conditions they can get to meet project goals. Getting the right materials and equipment to the site at the right time is critical to cost and schedule control. For some projects, procurement drives the boat by finding materials and equipment that may not be the engineer’s first choice but will work and allow timely completion. Never underestimate how important this step is to a successful project.

Commissioning

A construction project is not ready to be handed over to the owner until it has been fully commissioned. This is a process that tests and checks that all systems and equipment are working properly and as designed. I mention it because it is often not scheduled or scheduled but not adequately budgeted. You can get details online about how this process works. I just did not want to omit it because we so often think of design and then construction phases and fail to mention commissioning. It may seem obvious that mechanical systems need to be commissioned. But the process applies to buildings and other facilities. Simple things such as “Do the windows, doors and locks function as planned?” Another key aspect of building commissioning is the HVAC system. This process needs consideration and careful planning well before construction is complete.

The project isn’t over until?

Some engineers tend to see the project as the design. In the eyes of the owner or end user, most projects have to be constructed, started up, commissioned, operated, maintained and, at some point, decommissioned. The important point here is that the engineer has a key role in construction, startup, and commissioning, and in operations. The involvement of the designer during construction adds value and is good liability protection for the engineer to be able to spot potential problems and field conflicts and resolve them before they become contractor claims. Many projects are slow to reach their full use because of a lack of proper commissioning. Designers need to work with the owner to be involved in this phase. Some owners have the staffing and technical capabilities to do construction oversight, startup, and commissioning and tend to cut out the designer. You should endeavor to get some involvement.

Sophisticated owners, such as large industries, particularly in chemicals and petroleum, tend to assume their engineers are technically competent and place a very high value on project management performance. I was once on a large remediation for an oil company. We had a quarterly evaluation that entered into our fee. The project was large and technically challenging, and our scores were average. What changed is that we deployed a savvy business leader to get our scheduling, project controls, billing, and reporting in order, and our scores dramatically improved. Many technical people do not want to be engaged in those areas and can make great lead engineers or scientists. But clients hate surprises, especially on cost or schedule. So that is a good lead-in to the next section.


Join us tomorrow for the next installment of “Lessons Learned in My 40-year Engineering Career”!