From Site Visit to Report: My Retrofit Assessment Workflow

Over enough retrofit assessments, a workflow tends to settle into a fairly consistent shape — not identical every time, since every building is different, but consistent enough that it's worth describing in general terms. What follows is that general workflow, not an account of any one specific, dated site visit; the steps and sequence are typical of how this kind of assessment actually proceeds, from the first phone call through the finished report.

Before I Arrive: Pre-Visit Preparation

Reviewing whatever documentation exists — original drawings, prior reports, permit history — before the site visit, not during it. This shapes what to specifically look for on site rather than starting the visit with a blank slate, and it's usually where the first inconsistencies, like a described addition with no corresponding permit, surface as questions worth flagging before arriving.

Confirming access and safety logistics in advance. Basement access, roof access, occupied-unit access for interior columns — arranged ahead of time rather than discovered as a bottleneck on site, where a missed access point can mean an entire second visit.

Setting expectations with the client about what the visit will and won't determine. A single site visit rarely concludes an evaluation on its own; being explicit about that upfront prevents a client from expecting a final answer on the spot.

On Site: What I'm Actually Looking For

Comparing the as-built condition against the drawings, systematically, not just wherever something looks obviously wrong. Deviations aren't always visually dramatic, and a structured comparison — walking each documented element and confirming it matches — catches changes that a purely visual scan would miss.

Documenting anything that doesn't match expectations, even when it doesn't look urgent. A minor-looking inconsistency is sometimes the thread that, once followed, reveals a larger undocumented change — as our diagnostics case-study article on this site illustrates.

Checking the specific deficiency types relevant to the building's structural system and era — non-ductile detailing signs for older concrete, wall-to-diaphragm anchorage for masonry, connection conditions for steel framing — rather than a generic checklist that doesn't account for what's actually likely on this particular building type.

Talking to whoever knows the building best, whether that's a maintenance staff member, a longtime tenant, or the owner — informal knowledge about past leaks, past repairs, or areas that have "always looked like that" is a genuinely useful data source that a purely technical walkthrough would miss entirely.

Documentation and Field Notes

Photographing systematically, not opportunistically. A consistent numbering and location system for photos — tied to a floor plan or elevation sketch — saves significant time when writing the report later and avoids the all-too-common problem of a great photo with no clear record of exactly where it was taken.

Recording measurements immediately, not from memory afterward. Crack widths, tie spacing, member dimensions — anything numeric goes into field notes on the spot; memory reliably fills gaps with plausible-sounding numbers that aren't actually accurate.

Noting open questions as they arise, not just confirmed findings. A visit generates almost as many follow-up questions as answers — what a particular connection looks like above a finished ceiling, whether a discoloration is active or historical — and these need their own explicit list, not to get lost in a stream of general notes.

From Field Notes to Analysis

Reconciling field notes against the pre-visit documentation review before starting analysis. This is where the actual list of confirmed deviations gets finalized — differences between drawings and reality that the analysis needs to account for, rather than analyzing the building as originally designed and hoping it still matches.

Deciding what needs further investigation versus what's sufficiently confirmed. Not every open question from the site visit needs a follow-up probe or test; part of the workflow is judging which uncertainties actually affect the conclusion and which don't move the needle enough to justify additional cost.

Drafting the report's finding before its full technical justification, not the other way around. Starting from "what do I actually need to tell this client" and working backward to the supporting analysis keeps the eventual report client-focused rather than analysis-focused — the writing-craft habit covered in more depth in our reports article on this site.

Practical Application: What a Typical Visit Looks Like

In a fairly representative, generalized case — not a specific dated visit — a first site visit to a mid-rise structure runs three to five hours depending on building size and access complexity: roughly an hour reviewing documentation with whoever's available on site, two to three hours of systematic as-built comparison and photography, and remaining time following up on whatever specific concerns the documentation review flagged in advance.

A second visit is common, not a sign the first was inadequate — usually to confirm a specific finding that needs a closer look, or to gain access to an area that wasn't available the first time. Clients unfamiliar with this process sometimes expect a single decisive visit; setting the expectation of a possible follow-up early, as covered above, avoids that visit being read as a bad sign.

Common Mistakes

Skipping the documentation review and going in cold. This makes the site visit less efficient and more likely to miss a deviation that a prepared reviewer would have specifically checked for.

Treating photography as an afterthought rather than a system. Disorganized photos cost real time during report writing and can force an unplanned return visit just to recapture something that wasn't documented clearly enough the first time.

Writing the technical analysis before deciding what the client actually needs to know. This produces a report structured around the engineer's process rather than the client's decision — the opposite of what a good report needs to do.