ERP for Engineering Firms: Track Phases, Not Just Projects
A 35-person structural engineering firm billed a client for a completed bridge inspection project and, six weeks later, discovered the job had actually run 30% over its internal hour budget. Nobody caught it during the project because the firm tracked hours in a generic timesheet tool that showed total hours logged per project, but not hours logged against specific budgeted phases, design, analysis, documentation, review. The overrun had been hiding inside a total that looked roughly on track right up until the final invoice reconciliation exposed it.
That's the recurring failure mode for engineering firms running ERP or project software built for a different kind of business. Engineering firms are project-based like construction or consulting, but the work breaks down differently: a project isn't one continuous job, it's a sequence of distinct phases (conceptual design, detailed design, analysis, documentation, permitting support, construction administration), each with its own budget, deliverable, and often its own billing milestone. Generic job tracking treats a project as a single bucket. Engineering firms need it broken down by phase, because that's the level where cost overruns actually start and where they're still fixable if caught early enough.
Phase-level budgets, not project-level totals
A $180,000 bridge inspection and rehabilitation design contract might break down as $28,000 for site assessment, $65,000 for detailed structural analysis, $52,000 for design documentation, and $35,000 for permitting and construction support. Tracking only the $180,000 total against hours logged tells a PM the project is "on track" for weeks after the analysis phase alone has quietly burned through 140% of its allocated budget, because the documentation phase hasn't started yet and its unspent budget is masking the overrun in the total. Phase-level tracking would have flagged the analysis phase as over-budget in week four instead of at final invoicing, while there was still time to have a scope conversation with the client or reallocate a more senior engineer to get the remaining analysis work done faster.
Change orders and scope creep: the gradual version, not the dramatic one
Engineering scope creep rarely arrives as one obvious change order. It arrives as a client asking for "one more analysis run to check a different load case," or "just a quick review of an alternate design," each individually reasonable, none of them formally logged as a change to scope or budget. A firm that doesn't track time against specific scope items has no way to see that a project has absorbed six of these small, unbilled additions over two months, collectively representing 40 hours of senior engineering time that was never actually paid for. ERP built for engineering firms should make it easy to log a scope addition as a mini change order, even an informal internal one, the moment it happens, specifically so the pattern is visible before it's absorbed entirely into unbilled overhead.
Resource utilization by discipline, not just by person
A structural engineering firm typically has staff split across disciplines (structural, geotechnical, civil), and utilization needs to be tracked by discipline because that's where the actual bottleneck usually is. A firm might show healthy overall utilization at 74% while its geotechnical group, only three people, is running at 95% utilization and turning down work, while structural sits at 55% and is underbooked. A project-level or firm-level utilization number completely hides that imbalance, which is exactly the kind of gap that determines whether the firm should be hiring a geotechnical engineer or has a sales problem in structural, two very different business decisions that look identical from an aggregate utilization number.
Deliverables tied to milestones, not just dates on a calendar
Engineering deliverables (a stamped drawing set, a calculation package, a permit submission) are the actual unit of progress, more meaningful than a generic percentage-complete estimate. Software built for engineering firms should tie billing milestones directly to deliverable completion and, ideally, to a specific quality review and sign-off step, since a deliverable that goes out without the firm's internal QA review is a liability risk distinct from a simple scheduling delay. A generic project tool that only tracks task completion dates misses this distinction entirely; a task marked "complete" and a deliverable that's actually been reviewed, stamped, and is ready to send a client are not the same thing, and treating them as equivalent is how firms end up rushing an unreviewed package out the door to hit a date.
Subconsultants and multi-firm project teams
Larger engineering projects routinely involve subconsultants, a geotechnical firm brought in for a soils report, a specialty MEP consultant for a building system, and the prime firm's ERP needs to track their costs and deliverables against the overall project budget the same way it tracks internal phases, not as a separate accounts-payable line disconnected from the project's phase structure. A firm that treats subconsultant invoices purely as vendor bills, without tying them to the specific phase and deliverable they support, loses the ability to see whether a subconsultant's work is itself running over budget until the invoice arrives, often well after the associated phase should have flagged a problem.
This matters more in engineering than in many other project-based industries because subconsultant fees frequently represent 15-30% of total project cost on complex multidisciplinary work, and a cost overrun hiding in a subconsultant's scope is just as damaging to the project's overall margin as one hiding in the prime firm's own staff hours, but far easier to miss if the tracking systems for internal and external cost aren't unified.
What phase-level tracking actually looks like in practice
| Phase | Budgeted hours | Hours logged (week 6) | % of phase budget used |
|---|---|---|---|
| Site assessment | 160 | 158 | 99% (phase complete) |
| Structural analysis | 420 | 540 | 129% (over budget, still in progress) |
| Design documentation | 340 | 0 | Not started |
| Permitting support | 220 | 0 | Not started |
A project-level view of this same job at week six would show roughly 63% of total budgeted hours consumed against a project that's realistically 25-30% complete by deliverable, which looks alarming but doesn't tell anyone which phase is actually the problem. The phase-level view isolates it immediately: structural analysis specifically is 29% over its own budget while everything else hasn't started, which is a conversation about that phase's scope or staffing, not a vague, project-wide budget concern.
The licensing question that comes with a project-heavy staffing model
Engineering firms often run a mix of senior licensed engineers, junior staff, and CAD technicians, and per-seat ERP pricing that charges the same rate regardless of role can get expensive fast for a firm where most staff need at least time-tracking and project visibility, but not everyone needs full financial or procurement access. Comparing tiered licensing options through a license cost calculator before committing to a single license type across the whole firm is worth doing before signing, since a firm defaulting all 35 staff to the same full-access license tier is often paying for capability most of the team never uses.
The structural firm from the opening example rebuilt its project tracking around phase-level budgets after the bridge inspection overrun, and caught the same pattern starting on a different project just five weeks later, an analysis phase running hot while documentation sat unstarted, this time with enough runway left to add a second engineer to the analysis phase and bring it back in line before it affected the final invoice.