The Capacity Crisis: Why Small Integrators Don't Have a Hiring Problem
Every small integrator I know has lived through this exact week: the one where everything lands at once. A project gets awarded the same week a startup runs long. Documentation piles up while three proposals hit deadline in the same afternoon.
None of it is a crisis on its own. Together, it's a capacity crisis.
This is a look at the situations that quietly eat capacity for small system integrators: project awards, field pulls, documentation gaps, scope creep, backlog, and proposal crunches. None of these show up as a single dramatic failure. They show up as a phone call, a missed internal deadline, or a project that starts sliding for reasons that have nothing to do with the engineering itself.
If you've run or worked inside a small integration firm, you've lived at least one of these.
Winning Work Creates Capacity Problems
Growth doesn't break small integrators. Growth without capacity does.
Winning a project should feel like a victory. So why does it sometimes feel like a crisis?
One of the realities of running a small system integration business is that work rarely arrives on a perfectly predictable schedule. For many owner-operated firms, the cycle looks something like this: spend a few months networking, quoting projects, and chasing opportunities; land a project; shift into execution mode; focus entirely on delivery. Then, right in the middle of project execution, the purchase orders from all those earlier sales efforts start arriving. Suddenly, what looked like a healthy pipeline becomes a capacity problem.
I've heard versions of the same story countless times: "We just won a $400K project and my best guy is stuck on-site in Tennessee for the next six weeks."
For larger organizations, the answer might be hiring. For small integrators, hiring a full-time senior controls engineer for a temporary workload spike rarely makes financial sense.
The real issue isn't a lack of opportunity. It's that project awards, commissioning support, customer requests, and proposal deadlines all tend to collide at the same time. The most successful small integrators I've worked with recognize that capacity has to be managed just as intentionally as cash flow. They build relationships with trusted resources before they need them, so when the workload spikes, they have options.
Because sometimes the challenge isn't winning the work. It's having enough bandwidth to deliver it without burning out yourself or your team.
The Field Pull
Every commissioning trip is a tax on future project schedules.
"Our lead programmer is only going to be gone for a week." Famous last words.
If you've spent any time in system integration, you already know how this story ends. The startup gets scheduled. Travel gets booked. The project team adjusts around it. Then reality shows up: the equipment isn't ready, the customer pushes the schedule, the mechanical contractor falls behind, production can't release the line. A three-day startup becomes two weeks. A one-week trip becomes a month.
Meanwhile, the programmer who was supposed to be developing the next project, reviewing drawings, supporting proposals, and answering customer questions is now living out of a hotel room.
The real cost isn't the travel. The real cost is everything that stops moving while they're gone. For small integrators, one startup can quietly impact multiple projects at the same time: programming milestones slip, documentation gets pushed to "later," proposal deadlines get compressed, customer response times increase. Projects that were on schedule start falling behind for reasons that have nothing to do with technical execution.
Most project schedules assume commissioning happens exactly when planned and takes exactly as long as expected. Anyone who's been around long enough knows that's rarely how it works. The most successful small integrators build flexibility into their delivery model because they know field support can consume far more time than anyone expected.
Documentation Is Always Tomorrow's Problem
Documentation isn't administrative work. It's part of the deliverable. And if it's treated as optional, there's a good chance the project is already headed for trouble.
Most projects don't fail because of bad code. They fail because nobody took the time to clearly define what success looked like before the programming started.
A surprising number of projects begin with a rough scope, a few conversations, and a deadline. Then everyone jumps straight into development. The PLC gets programmed. The HMI screens get built. The startup gets scheduled. And somewhere along the way, somebody says: "We'll get the documentation cleaned up later." Later rarely comes.
Good documentation isn't simply paperwork — it's the roadmap everyone else works from: a Functional Specification (what the system is supposed to do), a Control Narrative (how it should behave), a FAT Procedure (how it will be tested), and Acceptance Criteria (how everyone agrees the project is complete).
Without them, projects often end up being driven by assumptions, tribal knowledge, and conversations that nobody documented. That's when scope disputes start. That's when customers say, "That's not what we expected." That's when project teams spend hours arguing over what the system was supposed to do in the first place.
Any controls contractor can write PLC code. Far fewer can produce documentation that is detailed enough to engineer from, program from, test from, and ultimately define customer acceptance from. That's a different skill set entirely.
The most successful integrators don't treat documentation as an afterthought at the end of a project. They treat it as one of the first deliverables created. Documentation isn't what you produce after you've figured out the project — documentation is how you figure out the project.
Scope Creep Isn't Free
Scope creep isn't a project problem. It's a staffing problem.
"The customer only added a few changes." Then the project doubled.
Most scope creep doesn't arrive as a major change order. It arrives one request at a time: an extra screen, a few more alarms, another operating mode, additional reporting, one more review cycle. None of it seems significant on its own — until someone realizes the project team is performing substantially more work than originally planned.
At that point, most discussions focus on profitability, and that's certainly part of the problem. But for small system integrators, the bigger issue is usually capacity. The customer doesn't typically extend the schedule by 50%. The startup date doesn't move. The FAT date stays the same. The proposal deadline for the next project is still approaching. The same team is simply expected to absorb the additional workload.
That's why scope creep becomes a staffing problem. Every additional engineering hour spent on one project is an hour that can't be spent on another. The impact spreads far beyond the project where the scope changed: other schedules start slipping, documentation gets pushed aside, proposal work gets delayed, customer response times increase.
The best integrators understand that scope management starts long before the first line of code is written. Scope must be defined. Deliverables must be defined. Acceptance criteria must be defined. Because success means different things to different people unless everyone agrees on what "done" actually looks like. When expectations are documented clearly, scope changes become easier to identify, discuss, and manage.
The Backlog Doesn't Announce Itself
The backlog doesn't show up all at once. It shows up one deferred task at a time until it's the biggest project in the building.
"We'll circle back to that once things calm down." Things never calm down.
Every small integrator carries some amount of backlog: a screen that needs rework, a control narrative that never got updated after a field change, a program review that's been "on the list" for two months. None of it is urgent enough to stop what's active. All of it is real work that still has to get done.
The problem is that backlog doesn't compete for attention the way a live project does. There's no customer calling about it, no startup date attached to it, no purchase order riding on it this week. So it waits — and while it waits, it quietly accumulates.
Then one of two things happens. Either it surfaces at the worst possible time — a customer asks for as-built documentation on a project everyone thought was closed out, or an old panel needs modification and nobody remembers exactly how the logic works anymore — or it simply keeps growing until addressing it requires blocking out real time from people already fully committed to active projects. Either way, the backlog eventually stops being a list and starts being a resourcing problem.
The most successful small integrators treat backlog the same way they treat any other capacity signal: not as a to-do list to feel guilty about, but as a workload that has to be planned for like any other project. They also recognize that backlog work is often a poor use of their best field and sales people, since it rarely requires their unique skills — it just requires someone who can pick it up cleanly and finish it.
The Proposal Crunch
The projects you haven't won yet can be just as disruptive as the ones you have.
"We've got three quotes due this week, and all of them need real technical content."
Proposal work has a way of never showing up alone. One request for quote is manageable. Three at once, all with real deadlines, competing against active project delivery, is where things start to break down.
The tension is almost never about capability. It's about who has the bandwidth to write it. A strong technical proposal takes real time — architecture descriptions, control philosophy narratives, scope assumptions, exclusions, a defensible basis for the number attached to it. That's senior-level work, and it's usually the same senior people who are already carrying active projects.
So something gives. Sometimes the proposal gets rushed and the scope gets underdeveloped along with it, which plants the seeds of the next scope creep problem before the project is even awarded. Sometimes the proposal gets deprioritized entirely, and a viable opportunity goes to a competitor who simply had the hours available to respond. Either way, the cost isn't limited to the proposal itself — it's the next project, quoted thin because nobody had time to think it through properly.
The most successful integrators treat proposal development as its own category of capacity, not something senior staff squeezes in between real project work. They protect the time it takes to scope and price a job correctly, because a rushed proposal has a way of turning into a difficult project six months later.
The Pre-FAT Reality Check
If the FAT is the first real test of the code, your project is already failing.
The worst time to find a programming mistake is during the FAT. The second worst time is after it. Yet many projects still treat the Factory Acceptance Test as the moment when the engineering team finally discovers whether the system actually works.
That's not what a FAT is supposed to be. A FAT should be a formality — not because the customer doesn't have questions or issues can't be discovered, but because the engineering team should already know the system satisfies the requirements before the customer ever walks through the door. The FAT is for customer discovery. It should not be for engineering discovery.
Unfortunately, many project teams fall into a dangerous mindset: "I don't need to spend too much time checking this. Someone else will catch it." The programmer assumes commissioning will find it. Commissioning assumes the FAT will find it. The FAT team assumes the customer will find it. Eventually, somebody does. The only question is how expensive that discovery becomes.
The most successful project teams start with ownership: programmers test their own logic, engineers review their own designs, documentation gets checked against actual system behavior before anyone else sees it. That ownership is necessary but not sufficient on its own, because every person, no matter how experienced, has blind spots in their own work. That's why the most successful teams add a second layer — an independent review from someone who wasn't part of building it in the first place. A fresh set of experienced eyes catches assumptions, inconsistencies, and edge cases that the original team stopped seeing weeks ago.
The goal isn't to prove someone wrong. The goal is to find problems before the customer does.
The Hidden Cost of Hiring
Rather than having a hiring problem, most automation firms have a workload volatility problem.
This series has looked at where the hours actually go: project awards that collide with existing work, commissioning trips that quietly stall everything else, documentation that keeps getting pushed to "later," scope creep that turns into a staffing problem, backlog that piles up in silence, and proposals competing for the same senior time as active delivery.
Different triggers. Same root cause.
Most small integrators don't need another employee. They need another 200 hours.
When a major project lands, schedules start slipping, documentation begins piling up, and commissioning pulls key people into the field, the natural reaction is often: "Maybe it's time to hire someone." But by the time you've decided you need another engineer, you're already behind. Finding, vetting, and hiring the right person takes time. Getting them up to speed on your standards, customers, and projects takes even longer. By the time they're fully productive, the workload spike that triggered the hiring discussion may already be over.
Workload rarely grows in a smooth, predictable line. It arrives in waves. A major project gets awarded. A startup runs long. A customer adds scope. A programmer leaves. Three proposals hit at the same time. Suddenly the team needs more capacity — not permanently, right now. Then six months later, everything looks different: the project's done, the startup's finished, the backlog's cleared. The feast is over. And now the business has another full-time salary that still needs to be fed.
That's why many capacity problems aren't actually hiring problems. They're workload volatility problems.
The most successful small integrators I've worked with recognize this reality early. They build relationships with trusted resources before they need them. The vetting is already done. The communication rhythm is already established. The expectations are already understood. When the workload spikes, they aren't starting from scratch — they simply pick up the phone.
How BAC Fits In
Bunn Automation Consulting provides senior-level automation project capacity when the workload outruns the available hours — without the delays and overhead of a full-time hire:
Field coverage: keeping programming, documentation, and project deliverables moving while key resources are tied up in the field.
Documentation: functional specifications, control narratives, FAT procedures, and program review reports that hold up as real project deliverables.
Scope absorption: taking on engineering capacity when scope grows past the original plan, and helping define the scope and acceptance criteria that keep the next project from repeating the cycle.
Backlog clearance: picking up stalled programming, documentation, and review work so your best people stay focused on what's active and customer-facing.
Proposal support: developing the technical content for a proposal under deadline — architecture descriptions, control philosophy, scope narratives — so senior staff isn't choosing between winning the next project and delivering the current one.
Independent review: a second layer of review before FAT, while issues are still inexpensive to fix.
Capacity problems are inevitable. Being unprepared for them doesn't have to be.
Comments