Engineering Firm Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the resource model get scoped as a timesheet report?

Because that is what the source data looks like. A developer opens your accounting system, finds hours by person by project, builds a dashboard on it, and delivers utilization by discipline. It is competent work and it is the biggest scope failure in this category, because utilization computed from posted timesheets is an accounting output, not a management instrument. On Wednesday you are looking at last week, and last week has already been paid for.

The model that helps runs the other way. Every phase carries a remaining hours estimate by discipline and by grade, meaning principal, senior, engineer in training and drafting, and that estimate moves on two live inputs: hours burned, pulled nightly from accounting, and deliverable state pulled from wherever your sheets live. What you present is a twelve week forward capacity curve per discipline, not a backward percentage. When mechanical is projected past 100 percent in week six, you see it in week two, which is the only window in which a staffing decision is still cheap.

The tell is whether a developer asks what happens when a geotechnical report comes back and creates sixty hours of unplanned structural work that exists in nobody's plan. A team that has built this asks unprompted. Ask them to model your domain on a whiteboard before you sign: whether phases are fee bearing, how a job that shifts from lump sum to time and materials mid stream is handled, and whether percent complete rolls up from sheets or from hours.

What goes wrong when you migrate project numbering and job history out of Deltek or Ajera?

The data moves fine. The meaning does not. Firms that grew by acquisition carry two or three numbering conventions, phase codes that do not map, and contract types that compute earned value differently. Somewhere there is a mapping tab in a workbook one person understands, and the proposal will quietly assume it is correct. It usually is not, because it was built for a quarterly report rather than a system of record.

Do not solve this by renumbering. Telling an acquired office that fifteen years of history is wrong is a political project, not a data project, and it will stall the build. Build a canonical project spine instead: an underlying record carrying a stable identifier, discipline, phase, contract type and office, with each legacy convention preserved as a display alias. Reporting queries the canonical layer, users keep their own numbering, and the mapping becomes maintained data rather than folklore.

The second layer is closed job history, and here you should be selective. Two to three years of completed projects is what makes forecasting specific to your firm, letting the model learn that your electrical discipline runs well over estimate after the 60 percent review on water treatment work. Beyond three years the data usually predates a change in how you scope or bill, and importing it adds noise dressed as depth. Migration typically takes three to five weeks in parallel with the build, and you keep the old system authoritative until the new one has reconciled against it for a full billing cycle.

Why do accounting and CAD integrations break after launch?

Accounting integrations break on retroactive edits. An engineer files a timesheet late, a principal reallocates hours between phases at month end, an invoice is credited and reissued. Your forecast already consumed the earlier version, and a naive integration that pulls yesterday's changes will never see the correction. Two weeks later the forecast and the ledger disagree by an amount nobody can explain, and the moment a project manager catches that, the tool is dead. Ask any developer what they do when a timesheet is edited after your forecast consumed it.

The fix is boring and it works: reconcile on a period rather than on a delta. Pull the full open period every night, recompute, and store what changed with a reason so a variance can be traced rather than argued about. Start read only. Firms that insist on day one write back into Deltek Vantagepoint regret the cost and the added weeks, because the interface is narrow and every write needs reconciliation logic behind it.

Computer aided design integration breaks for a different reason. Pulling live sheet state out of Revit or Civil 3D means dealing with model files rather than an interface, and those files move, get renamed, get worked on locally, and get upgraded with the software version. A sheet register that silently stops updating produces a computed percent complete that quietly freezes, which is worse than no number at all. Make staleness visible: show when each register was last read, and alert when one has not refreshed in a working day.

What happens when audit trail and timekeeping controls are not covered?

If you bill federal, transport department or defence work, the timekeeping and audit requirements attach to whatever system holds the record: immutable edit history, documented approval chains and segregation of duties, all designed in rather than added. Retrofitting an audit trail into a system not built for one is close to a rewrite, and the firms who paid for it twice all thought at kickoff that they would handle compliance later.

The cleanest architecture is to leave the audited record where it already is. If timesheets stay in Deltek, Ajera or Unanet and your custom layer only reads, your compliance surface has not moved. The moment your system becomes where people enter time, you inherit the whole obligation. Decide deliberately and put it in the statement of work.

The other gap is access segregation. Utility, critical infrastructure and defence drawings often carry restrictions on who may see them, and a system giving every project manager visibility across all projects is a finding waiting to happen. Model project level access from the start, including a principal who needs firm wide financial visibility but not drawing access. Adding that later means touching every query in the application.

Should you build custom or configure what you already own?

If you are single discipline, under roughly $8M in fees, and your work is mostly hourly with a repeatable deliverable set, stay. BQE Core will run that firm well, and the budget is better spent on business development. Stay also if the honest diagnosis is that nobody files timesheets on time. Software does not fix a management problem, it gives it a dashboard, and you will have paid six figures to be told the same thing on a nicer screen.

Before you commission anything, have a competent person spend two weeks inside the system you own. A large share of what gets reported as a product limitation is unmaintained configuration: a work breakdown structure set at implementation and never revisited, planning modules nobody was trained on, and reports that broke when their author left. Deltek and Unanet are good at financial reporting and timesheet discipline. If your complaint sits there, configure rather than build.

Build when the complaint sits outside it. Forward resource forecasting and interdiscipline coordination are not configuration problems, because these products model a person as a labour rate on a cost line rather than as capacity with forward commitments, and no settings page changes that. The strongest signal is a spreadsheet the business depends on, maintained by one person who is a single point of failure. The second is being told three times that the system does not work that way about the same workflow. Their product serves the median firm and you have stopped being it.

How do hidden costs get into the quote?

Discipline count is the first. A quote priced against three disciplines and delivered against five is not a small overrun, because each discipline brings its own deliverable vocabulary, its own review states and its own handoff rules. Name them in scope with their deliverable types beside each one.

Write back is the second, and it is usually presented as a small extension of a read integration. It is not. It typically adds a meaningful share of the first release budget and several weeks, because every write needs reconciliation logic for the retroactive edit case. Get it priced as its own phase so you can defer it honestly.

Contract type variety is the third. Lump sum, time and materials, and cost plus fixed fee compute earned value differently, so a firm running all three has three models rather than one with a switch. Fourth is computer aided design integration, where the effort is in file handling rather than interfaces and the estimate is routinely optimistic. Fifth is the migration mapping, because reconciling numbering and phase codes across offices is people work with meetings attached, and it lands on your staff rather than the developer's, which is precisely why it never appears in a proposal.

What separates a build that works from one that fails here?

The projects that work pick one measurable outcome for the first release and refuse everything else. In this category that is nearly always the forward capacity curve plus a deliverable register that computes percent complete, reading from accounting and writing nothing back. Twelve to sixteen weeks, one number the Monday meeting can trust. The ones that fail try to replace the accounting system, the document register and the client portal together, and spend a year in discovery while the resource meeting still runs on an export.

Make the gap the metric. The most useful figure this build produces is the difference between the typed percent complete and the computed one, per job. A fifteen point gap is a scope conversation that should happen this week rather than at the 90 percent review, and framing it as a gap rather than an accusation is what gets project managers to use the system instead of routing around it.

Use models where they operate on your data and nowhere else. Extraction from client requests for proposal and addenda saves senior hours, provided the model proposes and a person confirms. Forecasting trained on your own closed jobs works for the same reason. Generating engineering content does not, and we do not build it.

Finally, settle ownership before kickoff, in the contract rather than a later addendum: the repository under your organisation from the first commit, the schema, the cloud accounts and the right to bring in another firm. At Digital Heroes the client owns all of it from day one. What you are encoding is how your firm actually operates, and that model is your asset rather than your developer's.