Time Tracking for Engineers:
What Actually Needs to Be Tracked
Engineering work generates a steady stream of small, individually reasonable demands — a calculation revision here, an RFI response there, a submittal review, a coordination request from another discipline. Generic time tracking captures the hours. It doesn't capture what drove them — which means it can't show when those demands have added up to more than the fee assumed. Here's what time tracking actually needs to look like for an engineering firm.
Engineering Work Accumulates in Increments That Don't Look Like Anything on Their Own
Ask an engineer what they worked on this week and the list often sounds routine: revised a load calculation after the mechanical layout changed, responded to two RFIs about a detail, reviewed a submittal package, updated a drawing after a coordination call, recalculated a beam size after the architect moved a wall.
Each of those items, on its own, looks like normal engineering work. None of them individually looks like a scope problem.
But all of them are real time, driven by something — a design change in another discipline, a contractor question, a submittal that didn't meet the spec the first time. And whether that time gets logged as generic "project work" or as something specific enough to show what drove it determines whether the firm can ever see the pattern: that this project, or this client, or this project type, consistently generates more of this kind of work than the fee accounted for.
For engineers, the gap between what time tracking captures and what's actually happening is less about iteration — as it is for architects — and more about volume. A single calculation revision is nothing. Forty of them across a project is a fee problem that nobody can see unless the time tracking shows it.
→ Read: Why QuickBooks Fails Architecture and Engineering Firms
Engineering time tracking fails when forty small, individually reasonable tasks all get logged as "project work."
A timesheet that shows 40 hours of generic engineering time tells the firm nothing. A timesheet that shows 12 hours of original design, 14 hours of calculation revisions driven by other disciplines, 8 hours of RFI responses, and 6 hours of submittal review tells the firm exactly where the fee is going — and why.
The Three Categories of Engineering Time That Generic Tracking Misses
Generic time tracking tools assume billable hours map cleanly to client work. Engineering generates three categories of time that don't fit that assumption — and all three are where firms lose the ability to see scope expansion before it's too late to do anything about it.
Calculation and design revision time
Engineering deliverables — structural calculations, load calculations, system sizing, circuit design — are not produced once and finalized. They get revised whenever the conditions they depend on change: an architectural layout shifts, a mechanical equipment selection changes, a civil grading plan is updated, a structural system is value-engineered.
The engineer doing the revision logs time. What gets lost is why the revision happened. A revision driven by the engineer's own design development is included scope. A revision driven by another discipline's late change, or by a client-directed program change after the engineering was substantially complete, is a different category — one that may represent additional services, and one that the firm needs to be able to point to when that conversation happens.
When all revision time gets logged as "design" or "calculations," the firm cannot separate normal iteration from revision driven by external changes — which means it cannot identify when a project has generated an unusual volume of externally-driven rework.
RFI response time
RFIs are a constant during construction administration, and engineers answer a significant share of them — especially on projects with complex structural, mechanical, or electrical systems where the contractor's questions require engineering judgment rather than a simple clarification.
A 20-minute RFI response and a half-day RFI response that requires coordination with another discipline and a calculation check are very different things — but if both get logged as "CA — RFI," the firm sees identical entries for fundamentally different amounts of work. Over a project with 150 RFIs, that difference is the entire gap between a CA phase that holds its fee and one that doesn't.
Submittal and resubmittal review time
Submittal review volume is driven by the contractor's procurement process and fabricator relationships — not by the engineer's scope. A structural steel package that's complete and coordinated takes one review cycle. The same package from a fabricator unfamiliar with the specified connections might take three.
When submittal review time is logged without distinguishing first reviews from resubmittals, the firm can't see that a particular submittal has already consumed three review cycles — information that matters both for managing the current project (is this submittal now an additional service?) and for understanding, across projects, whether certain contractors or certain submittal categories consistently require more review than the fee assumes.
→ Read: How RFI and Submittal Volume Erodes A/E Fees — and How to Track It
None of these three categories are unusual. Calculation revisions, RFI responses, and submittal reviews are normal parts of engineering delivery.
The problem is volume — and volume is invisible unless time tracking captures what each entry was actually responding to, not just that engineering work happened.
What Engineering Phases Actually Need From Time Tracking
The standard phase structure — schematic design, design development, construction documents, bidding, construction administration — applies to engineering disciplines, but each phase has a failure mode specific to how engineering work depends on other disciplines.
Schematic and design development — where the engineering follows someone else's decisions
In early phases, engineering work is often responsive — the structural system follows the architectural massing, the mechanical system follows the program and the architectural floor plan, the electrical system follows both. When those upstream decisions change — and they do, repeatedly, during SD and DD — the engineering has to be revised to follow.
Tracking this time as "design development" without distinguishing original engineering development from revision-driven-by-upstream-change means the firm cannot see how much of its DD effort on a given project was responsive rework versus original engineering — information that's directly relevant to whether DD was underpriced for a project where the architectural design was unusually unsettled.
Construction documents — where engineering gets finalized around a design that may not be final
CDs assume the design is substantially resolved. When it isn't — a late owner decision, a value engineering exercise, a permitting comment that requires a system change — engineering disciplines absorb the consequences, often more than the architecture does, because engineering systems are more interdependent and a single change can cascade through structural, mechanical, and electrical simultaneously.
CD-phase engineering time should distinguish document production from CD-phase revisions driven by late design changes. On projects where this distinction is tracked, it's common to find that a meaningful share of "CD work" was actually re-engineering triggered by changes that happened after CDs were supposed to be underway.
Construction administration — where RFI and submittal volume determines the outcome
For engineering disciplines, CA is dominated by RFI response and submittal review — and the volume of both is determined by the contractor's documentation quality and the complexity of the systems involved, not by the engineer's scope estimate.
A mechanical engineer's CA fee assumed 60 RFIs and 80 submittal reviews. The project generates 110 RFIs and 140 submittal reviews because the contractor's fabricators are unfamiliar with the specified equipment and the documentation requires multiple resubmittal cycles. Without time tracking that captures RFI and submittal volume against the original assumption, the engineer is 50 RFIs and 60 submittal reviews into additional service territory with no record of it — and no easy way to have that conversation at project closeout.
→ Read: Construction Administration for A/E Firms: The Complete Guide
The phase structure tells you where engineering time went.
The activity type — original design, revision driven by another discipline, RFI response, submittal review, resubmittal — tells you why it took as long as it did, and whether the volume has exceeded what the fee assumed.
Building Time Tracking That Matches How Engineers Actually Work
The fix is the same principle as for architects — categories that match how engineers already think about their work, structured so accurate tracking takes no more effort than vague tracking.
Activity types within phases.
tructure time entries around categories that map to engineering reality: original design, revision driven by another discipline, RFI response, submittal review, resubmittal review, change order evaluation, site observation. An engineer logging time against "revision — driven by mechanical layout change" instead of just "design development" is providing information that's immediately useful for additional services and for future pricing — without extra cognitive effort, because they already know what triggered the work.
RFI and submittal counters that compare to the original assumption
The single most useful piece of CA tracking for engineering disciplines is a running count of RFIs answered and submittals reviewed, visible against the number the CA fee assumed. When that count crosses the assumption with months of construction remaining, the project manager has a documented, specific basis for the additional services conversation — while the project is still active.
A visible home for additional services
When an engineer recognizes that a revision was driven by another discipline's late change, or that a change order required real evaluation time, there needs to be a low-friction way to flag that time for project manager review — without a separate process or a conversation that has to happen before the time gets logged.
Weekly review connected to the fee structure
A project manager reviewing time weekly — rather than at billing — can see if revision-driven time is running unusually high on a project where another discipline's design has been unstable, or if RFI volume on a CA phase is tracking ahead of the original assumption with significant construction remaining. Both are signals that are actionable in week 20 of a 50-week project and far less actionable in week 48.
The most immediate change when this works is in additional services capture — revision time driven by other disciplines, and RFI/submittal volume beyond the original assumption, become visible while the project is active rather than discovered at closeout. The second is in future pricing — a firm that can see, across projects, that its mechanical CA fees consistently assume fewer RFIs than projects actually generate has real data to adjust the next proposal, rather than repeating the same underestimate.
→ Read: Proposals & Fees for A/E Firms
→ Read: Financial Metrics for A/E Firms
→ Read: Subconsultant Liability: The Cash Flow Risk Most A/E Firms Don't See Coming
Related Articles
Time Tracking Software for Architecture and Engineering FirmsCut Your Billing Time by 60% Within 90 Days — Or We Refund Every Penny
We're so confident BaseBuilders will transform your billing process that we're putting our money where our mouth is.
BaseBuilders’ easy-to-use software is specifically designed to help small to mid-sized firms track time, manage projects, stay on top of expenses, and more. We’ll handle the invoicing for you so you can focus on growing your firm and designing wonderful spaces.