Construcciones Yamaro: The engineer’s role doesn’t end when the drawings are issued
Some of the most valuable lessons structural engineer Nina Zundel has learned have come after the drawings were issued for construction.
By Nina Zundel, associate of building structures at Aurecon.
There is a natural tendency in engineering to see the issue of a drawing package as the finish line. The calculations are complete, the drawings are issued, and the design moves into construction.
But that is often when the design is truly tested.
Can the structure actually be built as documented? Are the details practical? Have the interfaces with other disciplines been resolved? Can the contractor understand what was intended? When something doesn’t work as expected, does the engineer simply respond to the question, or take ownership of helping solve the problem?
Working through construction-stage issues on complex projects has reinforced for me that the role of the structural engineer extends well beyond producing a technically compliant design.
Design intent needs to survive construction
A design can be technically sound and still be difficult to build. Some of the most challenging construction issues arise not because the underlying engineering is fundamentally wrong, but because individual details haven’t been sufficiently thought through.
A stair may technically be designed, but the framing doesn’t work once all the interfaces are considered. A precast wall nib may exist on a drawing but be too small to practically construct. A connection may satisfy the design requirements but require an unnecessarily large plate because the geometry wasn’t considered early enough.
These are design issues, but they are also construction issues. Engineers should ask not only whether it works structurally, but also whether it makes sense to build.
That requires consideration of sequencing, access, tolerances, fabrication, erection and the contractors who will ultimately construct what we have designed.
This consideration comes with experience. Great detailing is a thing of beauty. The best engineering solution is not necessarily the most sophisticated one; often, it is the simplest solution that achieves the required outcome.
Complexity has a cost
Complexity tends to accumulate quietly during design. A structural system may begin with a reasonable concept, but as architectural requirements, fire engineering, precast, services and other constraints are incorporated, the final arrangement can become unnecessarily complicated. Interfaces are particularly vulnerable.
Combining different structural systems can create coordination requirements around movement, tolerances, connections and fire or façade interfaces. Individually, each component may be reasonable, but the combined solution can become difficult to detail and construct.
The same applies at a smaller scale. Bespoke details, congested reinforcement, inconsistent connection arrangements and unnecessary changes in geometry can all create problems later.
There is value in periodically stepping back during design and asking: Can we simplify this? Is this working? Is there a better way? Is it consistent?
Simplification isn’t about reducing engineering rigour. It is often the result of applying more engineering judgement.
Documentation is part of the design
A technically correct model and calculation package aren’t enough if the construction team cannot clearly understand what is required.
Missing dimensions, incomplete typical details, unclear set-out information, inconsistent connection details or poorly coordinated drawings all transfer uncertainty into construction.
The more uncertainty there is in the documentation, the more likely the project is to generate RFIs, rework and delay. This is particularly important at interfaces between disciplines. Structural drawings need to work with architectural drawings and the requirements of services, façade, fire engineering and other specialist consultants. A structural detail that works in isolation may not work once every discipline’s requirements are overlaid.
Documentation therefore needs to be viewed as part of the engineering solution, not simply the method by which the solution is communicated. A good drawing should allow someone who wasn’t involved in the design process to understand what needs to be built.
Verification needs to be more than a compliance exercise
Another lesson is the importance of genuinely stepping back and reviewing a design before it is issued. A verification process can confirm that calculations have been completed and design requirements have been met, but there is another level of review that asks: If I were building this, what would I question?
Does the framing make sense? Are the most appropriate materials and structural systems being used? Are the details consistent? Are the interfaces resolved? Have the unusual conditions been properly considered? Is the sequence of construction realistic? Are there obvious clashes or missing information?
This type of review requires time and, importantly, fresh eyes. It can be difficult when projects are moving quickly and everything feels urgent, but time spent identifying a problem before issue is usually far less expensive than resolving it through an RFI, redesign, re-documentation and rework during construction.
The construction phase is an opportunity, not an interruption
Once construction begins, engineers gain access to information that wasn’t always available during design. Equipment loads, refined services layouts, fabrication constraints and actual site conditions can all reveal things that weren’t apparent earlier.
RFIs reveal where drawings are unclear. Shop drawing reviews reveal where details are difficult to fabricate. Site observations reveal where sequencing or access hasn’t been adequately considered.
These shouldn’t simply be treated as individual problems to close out. They are feedback about the design process. If the same type of RFI is appearing repeatedly across different areas or projects, there is probably a systemic lesson sitting underneath it.
Likewise, if shop drawing reviews repeatedly identify the same documentation issues, the answer isn’t necessarily to process the next RFI faster.
The better question is: Why are we creating the RFI in the first place?
Engineers need to help solve the problem, not just answer the question
Construction-stage engineering can become a chain of correspondence: RFI, response, clarification, another RFI, another discipline’s input, revised drawing or sketch and eventually another question. The back and forth can feel like a tennis match.
This becomes particularly inefficient when an issue crosses multiple disciplines or when responses are fragmented across different people.
The engineer’s role at this point is not simply to provide a technically correct answer. It is to help drive the issue to resolution in a coordinated manner. That might mean coordinating with the architect, fire engineer, services consultant, contractor or specialist subcontractor and consolidating the information into a practical solution.
It also means recognising when something is outside your immediate scope but still represents a project problem that needs to be resolved.
There is an important distinction between responding to an RFI and taking ownership of the problem behind the RFI. The second creates considerably more value.
The project is the system
One of the biggest challenges on complex projects is that responsibilities are divided between teams, disciplines and organisations. Structural engineers have their scope, architects have theirs and specialist consultants have theirs. Contractors and subcontractors have their own responsibilities.
But the building itself doesn’t recognise those boundaries. A steel connection doesn’t know where the structural scope ends and the façade scope begins. A precast element doesn’t know which consultant designed the adjacent steel. A service penetration doesn’t care which discipline owns the model.
The project succeeds when those interfaces work together. That means engineers need to develop an understanding of the project beyond their own drawings.
What is the contractor trying to achieve? What is driving the program? What does the client care about? Where are the major risks? What decisions made during design will create consequences during construction?
These questions allow engineers to contribute at a much higher level.
From design engineer to project adviser
None of this means that structural engineers should become project managers or take responsibility for everyone else’s scope. It means understanding that our professional value is not limited to producing calculations and drawings.
The engineers who create the most value are often those who can see the connection between the technical solution and the project’s ultimate outcome. They anticipate and consider rather than simply react. They simplify rather than unnecessarily complicate. They collaborate rather than pass problems between disciplines. They seek solutions rather than simply identify issues. They stay engaged when the drawings are issued because that is when the design begins its most important test: being built.
On large, complex projects, this can be challenging. It can also be one of the most rewarding parts of engineering. For me, that is the shift from design engineer to project adviser.
The drawing issue should not be the end of the engineer’s involvement. It should be the point at which we remain close enough to the project to see whether the design is achieving what it was intended to achieve – and to learn from what happens when it doesn’t.
That knowledge strengthens the team for the next project, because ultimately, our job isn’t just to design a structure. Our job is to help deliver one.
The post The engineer’s role doesn’t end when the drawings are issued appeared first on Inside Construction.
View Source
Comments
Post a Comment