Lessons Learned (structural engineering) Apr 2025

Lessons Learned Apr 2025 …


Overview
I have been involved with civil/structural (CS) engineering on numerous projects since the 70s.

Occasionally, projects get into trouble. Even when trouble is recognized. the recognition sometimes comes at a very late date. I offer my viewpoint on what might have contributed to the trouble and what might be done to avoid it.


Lessons Learned

Documentation
Is documentation lacking? Look through the CS calculation folder — is there a specification folder? A BEDD (Basic Engineering Design Data) document?

Folders
The CS folder should have separate subfolders for subcategories such as:

  • Specifications
  • Geotechnical
  • Foundation
  • Structural
  • Check Packages
  • IFA
  • IFC
  • RFIs (request for information)

RFIs are important requests from the client, the shop, or the field asking for clarification or resolution of a problem. The problem might be a concern about safety; a conflict within the specifications; a question about the design, the drawings, the sequence of construction, etc. These are critical to the safe and timely execution of the project.

Maybe there are RFIs on a project. You might search for them in the CS folder, but not find them unless you’re willing to search through emails. Even then, you might not find them all because when an employee left the company, his email became unavailable to the engineers following behind. If nothing else, there should be formal RFI forms for each incoming query and each outgoing response. Email should be a method of posting rather than a method of ‘documenting’.


Site photos
Are there no site photos in the project file system? How is this reasonable? Maybe there are laser scans but these can only be viewed with technical assistance. The ‘with assistance’ implies the engineer has little chance of observing something special, something out of the ordinary, something dangerous, something opportune that could make the project better. The engineer and the lead designer should visit the site together, should take their own photos together, discuss what they see together.

Plan
Is there no written plan? Where is the list of action items for engineering? How do you know where you’re at, what’s left, with what priority, or if you’re on schedule if there isn’t a task list?

Staffing
The typical arrangement shouldn’t be just one engineer per project. How does a team come to a consensus or learn from each other if the assignment is one per job? Even on the smallest project, a checker ought to be assigned from the project start. Using this approach, the checker can get up to speed at a natural pace, ask about specs, ask about progress, and take corrective action as needed.

Paper and pencil
I question the use of paper. Looking back over several years and several projects, I see very little handwritten work. The handwritten work that I do see makes me wonder if paper is some expensive commodity. Compared to the rates we are paid, to the costs of running an office, to the costs of a project, and certainly to the cost of mistakes and rework (or worse) — paper is cheap. Though cheap, it is of wonderful value.

It is a record, of thought and intent that cannot be captured any other way. Handwriting is intimately connected to the brain. It is quite different than monkeying with a spreadsheet or a PDF. The reason it is different is that the writer isn’t distracted by having to format or fit the thought in the prescribed manner demanded by the spreadsheet or PDF. At its best, it is free-flowing and yet disciplined. The discipline comes from neatness, clarity, penmanship, clear sketching, use of white space, and consideration of the bread crumb path the checker needs. Avoid being stingy with paper; give every calculation the space and the importance it deserves. Write out equations in full form: include units, include code references.

Here is an excerpt from The Richard Feynman Learning Technique:

Being able to explain something in a simple, accessible way shows you’ve done the work required to learn. Skipping it leads to the illusion of knowledge — an illusion that can be quickly shattered when challenged.


Patterns
Doing just as we please doesn’t lead to good results. Calculations should be presented in a standard form. In our work documents, our calculations and our sketches should be neatly and thoughtfully presented. The calculations should be augmented with written assumptions, givens, concerns, and warnings. Ask: is this acceptable?, is it checkable?, is it ready to be submitted to a client? Ask: how would this appear in court?

Templates
RISA load template. A template seems indispensable to me. Use of a template helps avoid errors and omissions. Develop, check, and publish a RISA template for code-required load cases and load combinations. Of course, the template must be reviewed and modified as needed on a per-project basis — the project template should be checked and kept as part of the project documentation.

Spreadsheets
Spreadsheet usage, in general, is disturbing. I could say this about almost any organization and be correct.

If a spreadsheet is downloaded from the internet, is it good to go? Is it according to the current code? Has it been checked, ever? Has it been checked by someone at your company? Thoroughly checked? Is there a list of FAQs, are there expectations for the input data, are there limitations to the method or technique used, are there clear error messages? Or is it a quick and dirty means to an answer with no real insight into why or if the answer might be correct?

Consider spreadsheets written in-house. In engineering spreadsheets, named ranges are of great importance.

Excel allows you to give names to cells and to cell ranges. Just select the cell or range and type into the small text box on the top left corner of the screen (next to the formula bar). In your formulas, you can use the name instead of the reference.

In a spreadsheet, Which would you rather see?

AS27 = BA18-BN21-BD24

   or

Gross_area_sq_feet = Overall_area - Angle_area + FlatBar_area

Which would you rather check? Which approach has instant meaning? Which approach might have fewer errors? Which approach might be quicker to develop and document?

Best practice for Excel: do not merge cells; when you merge cells, it prevents you from selecting individual columns in your formulas which can cause a lot of difficulty for you as you try to build out your spreadsheets. For centered headings, right click on the cells you want to merge, open the Format menu, go to the Alignment tab, and then in the Alignment section, select the dropdown box for Horizontal, and choose Center Across Selection.”


Checking
Drafting has an iron clad rule about checking. Why should engineering be different?

We all think we are smart. As we gain experience, we realize that smart people make mistakes, smart people have a hard time finding their mistakes, and really smart people take measures to mitigate errors. A cold check is imperative in engineering. If an employee thinks he is too good to be checked, we have to wonder why he has such an attitude, and wonder whether he is a desirable employee.

The check should be a formal signed off document with the usual yellow, green, and red marks. The checker should of course mark any questions he has regarding any concern or omission.

In engineering, using cryptic methods and formulas certainly conveys mystery but doesn’t imply intelligence.


Multiple solutions
We must all be willing to play our best game. We are trained engineers, getting paid to do the work — why not expect a full out performance. And not, for example, by shooting for minimum work-hours or least weight structures; rather by generating several design/construction approaches, alternate means of achieving objectives all using best practices.

Rapid response
When a significant problem is discovered (especially during construction), it must be dispatched ASAP. All hands on deck are required at times. All aspects of the problem must be brought out and a complete plan of action developed with full vetting of the problem, the cause, and the remedy.

The team must avoid being painted into a corner. Also, the team must avoid a slow start which inevitably leads to pressure from the client/field. Better to get done too early than too late.


Incremental release
This is of course the modern way to shorten schedules. It must be handled carefully and handled with discipline. The team must be able to look well ahead and, with little risk, know that the path forward works. This implies experience and discipline.

Multidiscipline
Each person on the project must be familiar with more than just their discipline. In CS alone, the engineer must understand safety, access, fire prevention, lifting, equipment, piping, pipe stress, cable tray, fabrication, and construction.

Good and fast
We expect good work. We expect fast work. We generally achieve both objectives.

I find it helpful to occasionally aim for a different objective: perfection. Of course, not really perfect, but complete and well-documented. I also find it helpful to develop general solutions just to ‘prove’ that I fully understand a problem.

To be clear:

  • Maybe once every say 5 times, perform a calculation much more completely
  • Maybe once every say 2 years, make a wholesale revision/upgrade to your spreadsheet

Flex
Problem solutions don’t fit neatly within each discipline.

Often the problem can be best solved by a compromise of sorts — a little shift by one group and a little shift by another and a problem might be solved.

~~~

One thought on “Lessons Learned (structural engineering) Apr 2025

  1. This is a beautiful guide.
    Thorough information – practical & beneficial steps to follow for the best possible result.

    Your section on paper & pencil applies to some of the issues students are having in school.

Leave a Reply

Your email address will not be published. Required fields are marked *