Engineering firms are unusually well equipped to evaluate a technical supplier. It’s essentially the job — assessing whether something meets specification, holds under load, and performs as claimed.
Yet most practices apply almost none of that rigour to their own IT arrangement. There’s no specification, no acceptance criteria, no performance data. Just a provider who has been there for years and a general sense that things are mostly fine.
That gap is worth closing, and it doesn’t require technical knowledge to close it. What follows is a standard — what a competent provider should be delivering to a firm like yours, and how to establish whether yours is.
Start with the right question
Most firms evaluate their provider on how quickly problems get fixed. That’s a reasonable measure of responsiveness and a poor measure of value.
The better question is: who notices when something is wrong?
Not who fixes it. Who notices. Who would know that a backup started failing in April, that patch compliance has been sliding since January, that a drive is logging errors, or that someone logged into a mailbox from an unfamiliar location three weeks ago?
For a great many firms, the honest answer is nobody — problems surface when staff complain. Which means every issue reaches the people doing billable work before it reaches anyone technical, and problems producing no visible symptom never surface at all.
That’s the difference worth understanding. Everything below follows from it.
What a provider should deliver: performance
They should be measuring, not guessing
If you asked how long a large model takes to open, and whether that’s better or worse than six months ago, could your provider answer?
Without a baseline, nobody can say whether performance has degraded or by how much. More importantly, nobody can say where the delay originates — and that’s the question that determines whether money gets spent usefully.
This is the most expensive error in the category. Firms replace workstations, spend heavily, and see modest improvement, because the constraint was storage all along. The new machines wait in exactly the same queue.
They should distinguish storage speed from storage capacity
These get conflated constantly and the difference costs real money.
Capacity is how much fits. Speed is how quickly storage responds when several people access it at once — which is precisely what happens with shared project files and CAD work.
A drive that’s half empty and slow under concurrent load throttles everyone. Adding space achieves nothing. If your provider’s answer to slowness has been “we’ll add another drive,” that’s worth examining.
They should understand what your software actually does
Engineering applications behave differently from office software over a network. They make thousands of small requests against files rather than transferring them in one piece, which means latency affects them far more than raw bandwidth does.
A provider who doesn’t grasp this will recommend a faster internet connection to solve a problem that faster internet won’t touch.
A quick test you can run yourself: time a large file opening early in the morning when nobody else is working, then time the identical operation at 11:45. If the second is dramatically slower, the bottleneck is shared. If they’re similar, look at workstations or the model itself.
What a provider should deliver: protection
Multi-Factor Authentication, enforced with no exceptions
Not available. Not enabled for most people. Enforced, everywhere, including principals.
Stolen credentials remain the most common way anyone gets into a firm, and MFA stops the overwhelming majority of those attempts. The usual failure isn’t absence — it’s partial coverage, with two or three senior people exempted during a busy period that nobody revisited.
Ask whether a coverage report can be produced. “I believe so” is not the answer you want.
Behaviour-based detection, not just antivirus
These are different products and the distinction matters.
Antivirus recognises threats it has catalogued. That’s useful against known malware and blind to everything new — including attacks that arrive through legitimate stolen credentials with no malware involved at all.
Endpoint detection and response watches for suspicious behaviour instead. That’s what identifies an intrusion during the weeks an attacker spends mapping a network before triggering anything, which is the only window where it can be stopped cleanly.
Backups that have been restored, not just run
A completed backup job confirms the job ran. Corrupted data backs up perfectly well.
Two questions establish your position. When was the last actual restore test? You want a date. And could ransomware on our network reach the backup? If the answer involves the server room, that’s the finding — modern ransomware hunts connected backup storage as standard practice.
For an engineering firm this is more consequential than for most businesses. Ransomware reaching your project storage doesn’t delay one job. It stops every active project on the same morning, with every client and consultant affected simultaneously.
Our backup and disaster recovery approach covers daily verification, off-site replication, and scheduled testing with written results.
What a provider should deliver: responsiveness
Response measured in minutes
When an engineer can’t open a model at three in the afternoon on a submission day, the technical problem might take ten minutes to resolve. If reaching those ten minutes means leaving a message and waiting, your cost isn’t ten minutes — it’s however long it sat.
Ask for last quarter’s average first-response time. A provider who measures will have it. One who doesn’t will explain why measuring is complicated.
Most issues resolved without a visit
A high remote resolution rate tells you the provider has the tooling and access to work effectively without travelling. It also removes distance from the equation entirely, which matters for a firm in Cameron Park comparing providers across the region.
Above 90% is achievable. Below 70% suggests limited remote capability, which will show up as slower response regardless of intentions.
What a provider should deliver: documentation
This category didn’t exist meaningfully a few years ago and now appears in nearly every conversation.
Public sector clients and larger private organisations increasingly send security questionnaires to their engineering consultants — sometimes during procurement rather than afterward. Insurers require evidence of specific controls at application and renewal, and the application is a legal document.
A provider running things properly generates this documentation as a by-product. Monitoring produces logs. Scheduled testing produces reports. Automated patching produces compliance percentages.
If a questionnaire arrived tomorrow, could your provider supply the evidence within a day? If the answer is uncertain, that’s worth resolving before the questionnaire rather than during it.
The specification, summarised
If you want a single reference for what to hold a provider to:
- Monitoring across all devices, continuously, with defined escalation
- Patch compliance above 98%, measured and reported
- MFA enforced on 100% of accounts, no exemptions, with a coverage report available
- Endpoint detection and response, not antivirus alone
- Backups verified daily, replicated off-site, tested quarterly with written results
- Recovery points spanning at least 30 days
- First response under 15 minutes with published actual figures
- Remote resolution above 90%
- Performance baselines established and trended
- Documentation available on request without a scramble
That’s not an aspirational list. It’s a reasonable standard for a firm holding what yours holds.
When it’s the provider and when it isn’t
Worth being fair here, because not every frustration is a supplier problem.
Model hygiene affects performance considerably, and no infrastructure compensates for a project file that has grown unwieldy — linked files nobody purged, imported geometry left in place, unused elements accumulating over a project’s life.
If your infrastructure tests clean and one particular model is still slow, that’s a model management issue rather than an IT one. A good provider will tell you that plainly rather than selling you hardware.
Equally, some things genuinely are limits. A provider can’t make a five-year-old workstation perform like a new one, and can’t make a domestic internet connection behave like a commercial link.
The distinction to watch for is whether they measure and explain, or guess and sell. Firms that measure will tell you when the problem isn’t theirs. Firms that guess recommend hardware.
Making the assessment
If you want to establish where you stand, here’s a sequence that takes about a week of low effort.
Days one to five: ask three or four people to note roughly how many minutes they lose daily to waiting. Rough figures are fine. This gives you a cost.
Day two: run the morning-versus-midday timing comparison yourself. Five minutes, and it tells you whether the constraint is shared or individual.
Day three: send your provider four questions — current patch compliance percentage, date of last restore test, MFA coverage report, and last quarter’s average response time.
Day four: read what comes back. Specific figures suggest an environment being managed. Reassurances without numbers suggest one that isn’t being measured, which usually means it isn’t being managed either.
That’s the whole assessment. No technical knowledge required, and the answers will tell you more than any proposal.
A closing thought for engineers
You wouldn’t accept “it seems fine” as a structural assessment. You’d want the calculation, the assumptions, and the margin.
The technology your practice runs on deserves the same standard — and the reason it usually hasn’t received it is simply that nobody framed it as a specification with acceptance criteria. Framed that way, it becomes a straightforward exercise in the kind of evaluation your firm does routinely.
Whether that assessment leads you to change providers or confirms you’re well served, you’ll know rather than assume. That’s the useful outcome either way.
Call our team on 209-920-4077 and we’ll benchmark your current environment against the specification above — measured figures, written results, and a plain assessment of where you sit. If your existing provider is meeting the standard, we’ll tell you that too. Get in touch here if you’d rather start by email.
