All of us have written technical reports for clients or other stakeholders. It is one of the tasks that are central to an engineer’s job. In this edition of the technical brief, I will provide a checklist that should be relatively comprehensive. This has been taken from several of my old reports, and each of these were their own section (1.0, 2.0, etc.)
This is a good place to state the basic premise of the project. Who is the owner? Why is the project being undertaken? What are the parameters of the project?
What is the existing structure and what is its condition? Are the any residual effects because of this condition? What inventory information exists from the owner? This is also a good place to put survey or similar information.
This is where you itemize the parameters that the design must conform to. In the case of a bridge project, you could have sections called roadway alignment, cross-section, stream alignment, environmental permitting, debris, and any other items of significance affecting the design. We don’t necessarily need to provide all of the mitigative solutions at this point, but it’s good to include this section because of the opportunity to analyze all of the issues. There’s nothing worse than having a discussion after the report is submitted about an issue that was not mentioned or thoroughly analyzed.
Obviously each project is technically different but for a bridge project you might have sections entitled Hydrology, Substructure Design, or Superstructure Design. Here you would detail the design methodology. It’s time to state what the design was and why that design was chosen.
Most engineering reports are initiated because there are multiple alternatives available and the owner must decide on a course of action. The alternatives section should itemize each alternative with the primary design features (for example, abutment type, bridge length) and an associated cost. This is usually best in a table format. A net present value analysis is often important to compare life cycle costs between options that have different life spans.
Regulatory and other Secondary Stakeholder Issues
Most engineering projects have some sort of secondary stakeholder issues like government regulators, adjacent landowners and so forth. What is required to keep the project on track with these stakeholders? State each one and make sure you are comprehensive in addressing their concerns, or the client might wonder if you’ve done enough to ensure a smooth project.
Of course, we have to provide a recommendation to make it worth the money. The option with the lowest net present value is the cheapest and should be chosen unless there are compelling reasons to choose another option. Sometimes when the recommendation is complicated I have found it helpful to contact the client and have some discussions before submitting a recommendation. This ensures a speedy resolution and makes you look better because your recommendation was adopted.
Good luck with your projects!