Michael Bannach
The ninety percent plan set is due to the township at two o’clock. The project engineer is in the site trailer forty miles from the office, and the model she needs is on the server back at headquarters. She connects to the VPN, opens the file, and watches the progress bar. Eleven minutes later the application gives up. She tries again. The second attempt gets further and then locks the workstation hard enough that she has to hold the power button.
Back at the office, the managing partner is on the phone with the same provider he has been calling for three years, explaining, again, that the field people cannot open large files. The answer he gets is that the VPN is working fine and the problem is probably the cell signal at the site.
The plan set goes in at 1:55, exported from a copy the engineer had put on her laptop the night before, which is two revisions behind. Nobody bills a minute of that morning to a client.
The leak is on the timesheet, not the server
Engineering firms tend to describe their IT trouble in technical terms: the VPN is slow, the workstation crashes, the server is old. Those descriptions are accurate and they are the wrong frame, because they make the problem sound like a cost of doing business rather than a leak.
An engineering firm sells hours. Every hour an engineer spends waiting on a file, re-doing work from an older copy, or walking over to the partner’s desk because the printer will not print is an hour the firm paid for and could not invoice. The firm does not see it on any report, because nobody logs “waited for the model to open” on a timesheet. It shows up only as a vague sense that projects take longer than they should and that the utilization number never quite reaches the target.
A civil engineering firm we work with, twenty-two people with growing municipal contracts and a lot of remote site work, had the same pattern. Their managing partner was personally handling password resets, VPN errors and printer complaints. Engineers could not reliably open CAD files from the field. The network crawled at peak hours. Nobody owned IT, so requests went to the operations manager, a local freelancer, or whoever was willing to search online. Their files sat on one on-premises server with no backup anyone had verified. One of them put it plainly: “We had antivirus and crossed our fingers.”
None of that is unusual for a firm their size. What is unusual is a firm that stops to count what it is costing.
Why the VPN is the wrong tool for the job
Most engineering firms that struggle with remote file access are trying to open very large files across a VPN. The VPN is fine for email and small documents, but opening a file from the office share drags the whole thing across a cellular or consumer connection every time, and an application built for design work expects the file to be on a local disk. The result is the eleven-minute progress bar, followed by a crash, followed by an engineer who starts keeping private copies on her laptop so she can get work done. Now the firm has three versions of the model, nobody knows which is current, and the next coordination meeting starts with an argument about whose drawing is right.
The fix is not a faster VPN. It is to stop pulling the file across the wire every time. For the civil firm above, that meant moving project files to SharePoint with synced libraries, so each engineer’s workstation keeps a local copy of the projects they are assigned to and quietly syncs changes in the background. Drawings and project files open from the local disk, at local speed, in the trailer or at the kitchen table, and version history lives in one place. A model that several engineers edit at the same time needs a different setup, which is one reason the answer starts with an audit rather than a product.
There are other ways to get the same outcome, and the right one depends on the size of the models, how many offices you run, and whether you work with outside consultants who need access. The point is that “the VPN is slow” has an answer, and the answer is not to tell your engineers to try again after lunch.
The server in the closet is a single point of failure for the whole firm
The other half of the civil firm’s problem was quieter. The firm’s project files lived on one physical server, and the backup had never been restored to prove it worked. A dead server would not have cost them an afternoon. It would have cost them years of project records.
That is the question to put to whoever runs your systems, this week: if the server in the closet died this afternoon, where would the firm be working from tomorrow morning, and when was the last time anyone proved it? Until someone has restored from it, a backup is a theory, and for an engineering firm it is a theory about whether the last ten years of work exist.
What changed, and what it was worth
The civil firm’s fix was not exotic. A full audit of where the bottlenecks and exposures actually were. Files moved to SharePoint with synced libraries so the field could open large drawings quickly. A single place to send every request, with a ticketing system and response times the firm could hold us to, so the managing partner stopped being the help desk. Multi-factor authentication, patch management and monitored protection on every device. Communications consolidated in Microsoft 365 and Teams. Backups automated and disaster recovery put in place. A quarterly sit-down with leadership so the technology plan followed the growth plan instead of trailing it.
By our count, their downtime has dropped sixty percent since. The number we care more about is the one an engineer said out loud: “It’s the first time I haven’t had to think about our network all month. I just log in and work.” That is the sound of billable hours going back on the invoice.
Three questions for whoever runs your IT
- How long does it take an engineer in the field to open our largest active model, and what would it take to make that the same as opening it at a desk?
- If the office server failed today, where would we work from tomorrow, and when did you last restore our files from backup to prove it?
- Who is the one person every engineer calls when something breaks, and is that person a partner of this firm?
If the third answer is a partner’s name, the firm is paying partner rates for password resets.
How we handle it for engineering firms
Our work with engineering firms starts with the assumption that your time is the product. We tune the workstations, network and file systems for AutoCAD, Revit and the rest, in the office and from the field, put secure access between job sites, remote staff and headquarters, monitor everything around the clock, and give the firm one number to call. The partner gets a documented onboarding plan with dates before signing, agreed service levels that we report on, and an executive reporting cadence with a named owner, so the roadmap stays ahead of the project pipeline.
If you want a plain read on where your firm stands before you talk to anyone, the three-minute IT and security scorecard turns your answers into a written roadmap, and the conversation after it is free. You can also read more about how we work with engineering firms.
