“Client leadership has very low confidence that this system is even going to get there at this point.” The FAT timeline expanded from one week to four weeks. Nobody could explain why. Client leadership was asking for itemized breakdowns and getting vague answers. Were we on the verge of letting poor vendor management kill our project?
This isn’t a hypothetical. Our team literally watched this unfold on a project we manage. I would love to sit here and tell you it was all the vendor’s fault, but the vendor wasn’t even – incompetent. They just weren’t attacking the problem from the right angles. The breakdown was in the structure – the framework that should have existed before a single PO was ever signed. This was a collective miss.
Remember when we discussed the boneyards, massive deployments, and installations gone wrong? The $4.3B Lie addresses a lot of these issues and then some. Vendor management is a critical component that is often overlooked as a core reason why projects fail and why equipment ends up in the boneyard.
The Vendor Isn’t the Villain (Usually)
Here’s the uncomfortable truth nobody wants to say out loud: most vendor management failures aren’t caused by bad vendors. They’re caused by manufacturers who didn’t know what they were actually buying and the processes they are actually supporting.
I’ve been on both sides. I’ve been the guy who bought the wrong equipment, standing in front of my Director or VP trying to explain why the system I promised would change everything is not delivering. I’ve also been the guy brought in to clean up after someone else did the same thing. The difference between those two experiences is roughly $4.3 billion in wasted annual manufacturing spend across this country – and almost none of it starts with a vendor lying to you.
In our blog on the $4.3 Billion Manufacturing Automation Lie, we broke down the captivity trap: the sunk cost fallacy that keeps you locked into systems you can’t afford to replace, the knowledge dependency that makes switching nearly impossible, and the vendor entrenchment that suffocates innovation. What we didn’t spend enough time talking about was how you avoid walking into that trap in the first place.
It starts with vendor selection. And I don’t mean the procurement checklist version – “evaluate technical expertise, financial stability, industry experience.” That’s table stakes. Almost everyone does that. I’m talking about the harder questions. Does this vendor actually understand what you’re trying to achieve, or are they just selling you what they have? Can they adapt when things change – because things will change. Are they going to tell you the truth when the timeline slips, or are they going to string you along with estimates disguised as commitments? And mind you, I am not even going to broach site readiness assessments and unified project procurement documents.
But hey, I think it’s safe to say we’ve all been in that room. I hate using extreme language like this, but we’ve heard that the vendor thinks the date they provided is achievable (with a buffer). You relay that to your client. Then the date moves. Then it moves again. Then your project lead is on a call saying: “I just have to be very clear about this – their leadership has very low confidence that this system is even going to get there at this point. There’s no more room for any shifts.” And the vendor responds: “Every date we’re giving you is what we think at this point in time.”
At what point in the history of project management did “I think” become a project commitment?
The Onboarding Illusion
Most onboarding failures aren’t about missing documentation. They’re about the fact that nobody agreed on what success looked like before the work began.
We wrote about this in Breaking Down Silos: consider the scenario where $20 million is spent on automation equipment, only to discover during the Site Acceptance Test that the machines are not the right type. Twenty million dollars. Wrong machines. Discovered at SAT.
How does that happen? It happens because onboarding was treated as a checkbox exercise. Scope documents were signed. Communication channels were established. RACI was assembled and yet nobody – not the manufacturer, not the vendor, not the project team – actually verified that everyone was looking at the same picture.
In Why Manufacturing Transformations Fail, we laid this out: a manufacturing director sees automation potential. A plant manager sees operational disruption. Finance sees an 18-month cash flow impact. Procurement sees a 16-week equipment lead time. Quality sees new validation requirements. Everyone is looking at the project from their lens. If those perspectives don’t get integrated into a coherent plan before vendor onboarding, you end up with decisions that make sense in isolation but conflict in execution.
The vendor gets onboarded to a project that doesn’t actually have alignment behind it. And then six months post-site acceptance, everyone’s surprised when the system doesn’t deliver what “everyone agreed on” – except nobody agreed on the same thing.
Cadence Without Accountability Is Just Meetings
Structured communication is one of those things that sounds good in theory and collapses in practice. Weekly project reviews. Engineering syncs. Design and timeline risk updates. Cross-functional check-ins. All good. All useless if there’s no accountability baked into the cadence.
On one of our recent projects, we ran biweekly equipment readiness syncs with the vendor. Equipment modifications tracked with 24-hour turnaround commitments. Scope aligned, technician schedules confirmed. Shipment timelines locked. That cadence worked because every meeting ended with clear ownership: who’s doing what, by when, and what happens if it doesn’t get done.
On the same project, we also had meetings where the vendor couldn’t explain why a testing timeline expanded from one week to four. When pressed for an itemized breakdown, the response was: “It’s an estimate. I could easily just take four weeks out of the schedule and we’re right back to where we were before.”
If we were to compare that response against the definition of ‘cadence’ we start to see the real disconnect develop.
Our project lead’s response was the right one: “You can’t just arbitrarily set numbers. You have to know why you think it’s going to take that long. When setting a schedule, you have to be like, okay, well, we need this much time because we need to do this much work. So, what is that work?”
If your vendor can’t answer that question, your cadence isn’t working. You’re just having meetings about meetings.
The Timeline Lie
In Why Manufacturing Transformations Fail, we shared data that should make every manufacturer pause: projects that compress planning to 15-20% of total timeline have a 70% chance of schedule overrun and a 60% chance of budget overrun. Projects that invest 35-40% of timeline in planning and design typically deliver on schedule and on budget.
We’ve led projects where companies lose four to six months to solve problems that could have been prevented with better upfront design. That’s what we call a timeline catastrophe not even inching toward progress.
When a FAT date moves from January to April – a three-month slip – and nobody can produce an itemized explanation, it’s clear that there was no attention paid to project definitions to help avoid continual planning. Another time sink. The timeline was never realistic. It was aspirational. The last time I checked, aspiration is not a project management methodology. But I digress…
If the plan is unrealistic, the project will be too. So what do we do? We need to validate vendor schedules, identify dependencies, assign accountability via ownership RACI charts, and build buffers. And when something moves, document why. Things like “it just took longer than we thought” isn’t an answer that leadership will accept – and frankly, they shouldn’t. And project leaders should never go into a conversation with that kind of rhetoric conveyed to the client.
Visibility Is Not Optional
On many of our projects, we introduce tracking dashboards at the very early onset. These dashboards improve task updates, align stakeholder teams, and aim to avoid delays we have experienced in the past. These are lessons learned and solutions applied. They help tremendously. But the first time we introduced something like this, it was after leadership had already lost confidence. It was a last-ditch effort, but it definitely saved us.
Visibility is like a smoke detector. It only works if you install it before the fire.
If you wait until your client is asking “what exactly is happening in those four weeks?” to build transparency into your project, you’ve already lost the room. Tracking dashboards, issue logs, change order tracking, risk registers – these aren’t nice-to-haves. They’re the instruments that keep you from walking into a status meeting with nothing but vague percentages and good intentions. And a lot of these should come from the client if good processes exist. Though if you’re reading this and you’re scratching your head, you’re not alone.
The Mystery Cases and the Incorrectly Glued Flaps
During testing on one of our projects, the vendor discovered that 80-90% of the cases the client supplier shipped were bad stock. Half of them had flaps glued shut over the minor flap seam. Dividers were too long. Case erectors were inverting the stock. Robots were crashing when trying to place dunnage. The supplier had rushed the order and not checked before shipping. The project lacked accountability on the supplier side and as a result, we let them derail our timeline.
And because we caught this during testing – paid 3-4x the cost because discovery during testing is always exponentially higher than the cost of prevention.
Part development and raw stock strategy isn’t about “proactive planning reduces downtime.” It means making sure the materials that feed into your automation are actually compatible with your automation – before you’re standing in front of a robot that’s crashing because someone manufactured the wrong cases.
We’ve also learned that being present and on-site matters. Not to just waste time or strengthen relationships – but to catch the things that will kill you in production while you still have time to fix them. We’ve lost that “in person” touch post-COVID and I think that’s what is really sabotaging real progress. There’s nothing like human interaction – when it makes sense. A few days at the vendor’s facility can surface material compatibility issues, design integration gaps, and operational realities that a Teams review call will uncover.
FAT: The Crucible
Here’s where I stop being polite.
The Factory Acceptance Test is the single most critical phase in any equipment project. It’s where promises meet reality. It’s where the system either proves itself or falls apart. And on most projects, it’s the phase that gets the least structured preparation.
We use custom-developed FAT documentation – not templates, not vendor guidelines or checklists, not suggestions, but structured test protocols with pass/fail criteria for every operational requirement.
Static checks: machine matches order confirmation, safety switches operational, conveyor integration verified, electrical cabinet cabling conforms to drawings.
Dynamic checks: bottle separation, positioning, label application, wiping components, packaging quality at outfeed. Speed requirements: nominal 60 units per minute for 30 minutes without faults, surge at 80 for five minutes.
Induced failure tests: photo eye function, star wheel jams, label station alarms, door alarms, emergency stops.
Documentation requirements: user manuals, technical documentation, electrical schematics, format tables, spare parts lists, warranty certificates.
Like I said, not a checklist. This process helps mitigate future disputes because success was defined before testing began – not argued or questioned after the fact.
But we have seen FAT processes get derailed. That’s normally driven by things like vague scheduling with no underlying logic as to why. A seemingly recurring theme. When the timeline expands from one week to four and nobody can produce an itemized breakdown of what’s actually happening in those four weeks, you’ve created an accountability vacuum. The client fills that vacuum with doubt. And doubt, once it takes root in leadership, is almost impossible to remove. Clients seem to think that more time testing equates to more value. This is seldom reality.
On the project I opened with, the conversation went like this:
Our team: “What exactly is happening in this four weeks? And why wasn’t it accounted for?”
Vendor: “It’s an estimate.”
Our team: “You can’t just arbitrarily set numbers. You have to know why you think it’s going to take that long.”
Client: “I think it might not be a bad idea to take four weeks to test. We can better understand the system before it ships.”
Our team: “Well what would you want to test that would take four weeks?”
Client: “…..”
In one case we had a vendor commit to providing a detailed breakdown to help with the client request. It took two more weeks to produce because key resources were on PTO and at another install.
Two more weeks to explain a schedule. Let that sink in.
SAT: The Moment Nobody Plans For
In Breaking Down Silos, we referenced the $20M SAT disaster where machines turned out to not be the right type. That’s not an edge case. That’s what happens when SAT is treated as a formality rather than a critical validation milestone.
A carefully orchestrated SAT is the difference between the equipment either delivering on its promise or becoming the next entry in the boneyard. It’s not an easy process because of the shear complexity of being in a live environment. It requires installation oversight, integration testing, operator training, and structured issue resolution. And it needs to mirror FAT – not in complexity, but in rigor. If your SAT plan is “we’ll figure it out when it gets here,” you’re already behind. We’ve seen this mentality sink project sentiment and momentum many times.
On one of our projects, SAT remained undefined even as FAT was being scheduled. Full testing for all product variants was emphasized as critical – but the plan didn’t exist. That’s become the new normal in many company boardroom decision slates.
The Long Game
Here’s where most vendor management frameworks stop – at go-live. As if the project ends when the equipment is installed. This is where we push to change the paradigm. This is truly when the real work begins.
On one of our recent engagements, we started with a maintenance assessment. That led to training for 13-16 users. That led to on-site support twice a week. That led to developing more processes and systems to help unlock additional potential. That led to recruitment assistance and technical support. Each phase built on the last because we proved value before asking for more.
If we are being transactional, that’s “post-implementation support.” But to me, it’s a relationship that we’ve invested in that compounds. And it only happens when the vendor management framework extends beyond commissioning into the operational lifecycle.
Warranty management, critical spares, material management, performance monitoring, vendor response expectations, continuous improvement opportunities. These mechanisms protect ROI. Skip them, and you’re guaranteeing that the lessons you paid for as part of the total project cost will be relearned – at full cost – on the next one.
The Boneyard Awaits
Let’s revisit the final point before we wrap up.
Almost every factory I have worked on, worked in, visited, or discussed with a colleague has a boneyard full of forgotten equipment. Frustration in the form of heaps of lost hope.
Vendor management isn’t glamorous or even discussed enough.
It’s not the stuff that wins awards or makes for compelling trade show demos, but it is the difference between equipment that performs and equipment that becomes a history lesson. It’s the difference between a project that builds trust and one that erodes it.
In Technology Without Foundation, we said it plainly: when you standardize processes first, automation amplifies efficiency. When you automate chaos, you amplify and multiply it. Cost, complexity, emotions…everything.
The same principle applies to vendor management. When you build structure or strategy first, vendors amplify your capability. When you manage vendors through chaos, you amplify the chaos.
The framework isn’t complicated, but it does require attention and sometimes the hardest part isn’t knowing what to do. It’s doing it before the fire starts, not after.
And if that’s too much, well – there’s always room in your boneyard.
