Software for Engineering Firms: Fixing Utilization, Deliverables and Multi-Discipline Coordination

Why project management software makes or breaks an engineering firm

An engineering firm sells hours it cannot restock. Every hour a structural engineer spends on a job that was scoped at 40% design and is now sitting at 70% is an hour that never becomes revenue. The firms that stay profitable are not the ones with better engineers. They are the ones that know, on Wednesday afternoon, that the mechanical team is at 62% utilization while civil is at 118% and the drainage package is going to slip.

Most firms do not know that on Wednesday. They know it three weeks later when the invoice goes out short. The typical stack in a 60 to 300 person multi-discipline firm looks like this: Deltek Vantagepoint or Ajera holds the financials and the timesheets, BQE Core or Unanet holds them if the firm is smaller, Microsoft Project or Smartsheet holds a Gantt chart that stopped matching reality in week three, Procore or Newforma holds the RFIs and submittals on the construction-facing jobs, Bluebeam holds the markups, and a folder tree on SharePoint holds the actual deliverables. Then there is the spreadsheet. There is always a spreadsheet. It is called something like ResourcePlan_v14_FINAL_updated.xlsx and one person maintains it.

I have watched this same scene in four different firms. It is Monday, 8:00am, and the principals are in a resource meeting. The COO has exported hours from Deltek into Excel. The exported hours are through Friday, but three engineers have not filed timesheets, so two of the six discipline leads are arguing with the numbers on the screen. A project manager says the transmission line job is 55% complete. She means the drawings look 55% done. The system says 71% of budgeted hours are burned. Nobody in the room can tell whether that is a scope problem, a fee problem, or a junior engineer redrawing sheets. The meeting runs 90 minutes, produces a staffing decision based on a stale export, and reconvenes next week to correct it. Six principals at roughly $200 an hour of opportunity cost, 52 weeks a year: that is real money to argue about a spreadsheet.

Problem 1: Utilization is measured after the fact, so you steer by the rear-view mirror

The pain: your utilization number is a lagging accounting output. Deltek and Ajera compute utilization from posted timesheets, and timesheets post late. On a Wednesday you are looking at last week at best, and last week has already been paid for. Meanwhile your CAD techs are 40% overloaded and nobody flagged it until someone worked a Saturday.

Why the incumbent cannot fix it: Deltek and Unanet are built as accounting systems with a project layer bolted on. Their model of a person is a labor rate on a cost line, not a capacity with a forward commitment curve. Their resource planning modules ask you to enter planned hours per person per week by hand, which means the plan is only as good as the last time a busy PM updated it, which is never. The tool does not know that the geotech report just came back and the foundation redesign is now 60 hours of unplanned structural work.

What a custom build does: model capacity forward, not backward. You build a resource ledger where every phase of every project carries a remaining-hours estimate by discipline and grade (principal, senior, EIT, CAD tech), and that estimate is driven by two live inputs: actual hours burned, pulled nightly from your accounting system's API, and deliverable state pulled from your document system. The dashboard shows a 12 week forward capacity curve per discipline, not a backward utilization percentage. When mechanical is projected to go past 100% in week 6, it surfaces in week 2. This is where forecasting AI genuinely helps: train a model on your own closed jobs, so it learns that on your firm's water treatment projects, the electrical discipline historically consumes 1.4x its estimate after the 60% review. That is a pattern no off-the-shelf tool can know, because it lives in your history, not the vendor's.

Problem 2: Percent complete is a lie told by whoever is on the phone

The pain: earned value on engineering work is a judgment call, and the judgment is made by the person who least wants to report a problem. A PM says 55% and means it honestly. The reality is the client changed the site plan and 20% of what is done needs redoing. You find out at the 90% review.

Why the incumbent cannot fix it: Microsoft Project and Smartsheet accept whatever percentage you type. There is no evidence layer. Procore is better on the construction side but it is built for the contractor's world of RFIs and submittals, not for design production. Nothing connects the number in the schedule to the actual state of the sheets in the drawing set.

What a custom build does: make percent complete a computed value, not a typed one. You define the deliverable structure the way your firm actually works, a drawing register with sheets, each sheet having a discipline, a milestone level (30/60/90/IFC), and a review state. Percent complete rolls up from sheet states and review sign-offs, weighted by budgeted hours per sheet. A PM can override it, but the override is logged and shown next to the computed number. In the firms where we have shipped this, the gap between the typed number and the computed number becomes the single most useful metric in the Monday meeting: a 15 point gap on a job is a scope conversation waiting to happen.

Problem 3: Multi-discipline coordination lives in email and dies there

The pain: structural needs the mechanical equipment loads before it can size the roof framing. Mechanical is waiting on the client's equipment schedule. Nobody owns that dependency, so it is an email thread with eight people on it, and the structural team quietly works on something else for three weeks. Then everything compresses into the last two weeks before IFC and you pay overtime.

Why the incumbent cannot fix it: a Gantt chart in Microsoft Project can express task dependency, but it cannot express information dependency, which is what actually gates engineering work. The real dependency is "structural sheet S-201 cannot advance past 60% until mechanical issues equipment loads." That is a data handoff between disciplines, not a task predecessor. No generic PM tool has a concept for it, so firms manage it in someone's head.

What a custom build does: model interdiscipline data handoffs as first-class objects. A handoff has a producer discipline, a consumer discipline, a required-by date derived from the consumer's schedule, and a state. When mechanical marks the equipment loads issued, the structural sheets that were gated unblock automatically and the resource forecast updates. When a handoff is 5 days from blocking downstream work and still unissued, it escalates to the discipline lead before it becomes a schedule problem. This is the single highest-return feature in most multi-discipline builds and it does not exist in any product you can buy.

Problem 4: Client documents arrive as PDFs and become 6 hours of manual data entry

The pain: a client sends a 90 page RFP with a scope matrix, or an owner issues a 40 page addendum, or a utility sends a spec update. Someone senior reads it, extracts the scope items, and types them into a proposal or a change order. On a busy month that is 20 to 40 hours of principal-level time doing transcription.

Why the incumbent cannot fix it: Deltek and BQE are systems of record. They wait for you to type. Newforma indexes documents but does not understand them.

What a custom build does: this is where document-extraction AI pays for itself, and it is one of the few AI features I recommend without hedging. You pipe incoming client documents through an extraction pass that pulls scope items, deliverable lists, submittal dates, and referenced standards into structured records, then puts a human on review rather than on transcription. The rule that makes it work: the AI never writes to the record directly. It proposes, a person confirms, and the confirmation is what commits. The same pipeline reads inbound RFIs and drafts a routing suggestion to the right discipline based on content, which typically cuts RFI triage from a day to under an hour. Extraction on structured-ish engineering documents is reliable enough to be a real time saver; generation of engineering content is not, and I would not build it.

Problem 5: Every office and discipline invented its own numbering, so firm-wide reporting is fiction

The pain: you acquired a firm in 2021. Their project numbers are alphanumeric, yours are sequential. Their phase codes do not map to yours. Your CFO's firm-wide backlog report requires a manual mapping tab that one person understands. Multi-location firms all have this and all pretend they do not.

Why the incumbent cannot fix it: Vantagepoint will let you configure a WBS, but you get one structure, and the migration to make everyone conform is the exact project that keeps getting deferred because it means telling the acquired office their 15 years of history is wrong.

What a custom build does: build a canonical project spine with per-office alias mapping underneath it. Each legacy office keeps its own numbering as a display alias while the underlying record carries a canonical ID, discipline, phase and contract type. Reporting queries the canonical layer, users see their own conventions. This is unglamorous data modeling and it is usually the thing that makes the entire build worth it, because it is what finally lets a CFO see accurate backlog by discipline across five offices without a mapping tab.

What this actually costs and how long it takes

These bands are Digital Heroes delivery experience across 2,000+ projects, not a market survey. A focused first release, meaning the forward resource forecast, the deliverable register with computed percent complete, and a read integration into your accounting system, typically lands at $60k to $130k and ships in 12 to 16 weeks. A full platform with interdiscipline handoffs, document extraction, QA/QC review workflow, client portal and write-back to accounting runs $150k to $400k phased over 6 to 12 months.

What drives price up in this category specifically: writing back into Deltek Vantagepoint rather than just reading from it, because the API surface is narrow and every write needs reconciliation logic. Number of disciplines, because each one has its own deliverable vocabulary and each adds review states. Federal or DOT work, because you inherit FAR-compliant timekeeping and audit trail requirements that turn a simple timesheet into a controlled record with immutable history. Multi-office with different contract types (lump sum, T&M, cost plus fixed fee) each computing earned value differently. And CAD integration, because pulling live sheet state out of Revit or Civil 3D means dealing with model files, not APIs, and adds real weeks.

What keeps it down: starting read-only against your existing accounting system. Every firm we have seen insist on day-one write-back regretted the extra $40k it costs and the six weeks it adds. Ship the forecast, prove it, then earn the right to write.

Where buying is the right call

Buy is genuinely right if you are single-discipline, under about $8M in fees, and your work is mostly hourly with a repeatable deliverable set. BQE Core will run that firm well, and the money you would spend on a build is better spent on business development. Buy is also right if your problem is that nobody files timesheets. Software does not fix a management problem; it just gives it a dashboard.

Build when these signals show up together, and they usually do. First: you have three or more disciplines and the coordination between them is where your schedule slips, not within them. Second: someone in your firm has a spreadsheet that the business genuinely depends on, and that person is a single point of failure. Third: you have grown by acquisition and your reporting requires a translation layer. Fourth, and this is the sharpest one: you can name the annual dollar figure you lose to jobs discovered late. If that number is above $300k, the build pays back inside 18 months and the conversation is over. If you cannot name the number, that is itself the finding, and it is why the tool you bought is not helping.

How to choose a developer for engineering firm project management software

Ask them to model your domain on a whiteboard before you sign anything. A developer who has built this before will ask, unprompted, whether your phases are fee-bearing, how you handle a job that shifts from lump sum to T&M mid-stream, and whether percent complete rolls up from sheets or from hours. A developer who has not will draw a task list with a status field. That difference is worth more than any portfolio.

Make them show you a Deltek, Ajera, Unanet or BQE integration they actually shipped, in production, with the reconciliation logic. Ask what they do when a timesheet is edited retroactively after your forecast already consumed it. Every firm has retroactive edits and every naive integration breaks on them. If they have not hit that wall, they will hit it on your budget.

Get compliance scoped explicitly, in writing, before the estimate. If you touch federal, DOT or defense work, ask specifically how they handle audit trail and timekeeping controls, and whether the log is immutable. If you handle utility or critical infrastructure drawings, ask about access segregation by project. Retrofitting an audit trail into a system that was not designed for one is close to a rewrite, and I have watched a firm pay for it twice.

Require that you own the code, the schema and the deployment on day one, in the contract, with the repository under your organization from the first commit. In this category you are encoding how your firm actually operates, and that model is your asset, not the vendor's. Any developer who hesitates on this is telling you their business model depends on you not being able to leave.