The Cost of Vendor Delays

If the client causes delays, a system implementation can legitimately seek a change order to recover costs associated with the delay. Why are vendors shocked when a client seeks compensation for vendor delays?

Last year, one of my clients procured a new data system and professional services to configure and install it. The vendor proposed the project would take about 12 months. The client immediately pushed back that the vendor’s schedule did not seem realistic, but the vendor assured the client that they had experience implementing this system and besides, the vendor was so busy that the project couldn’t slip because the vendor wouldn’t be able to staff it. I think my client’s first mistake was buying that argument.

This exchange was enough to raise my suspicions, so I started monitoring the project closely. Things didn’t get better from there. The vendor had frequent and excessive staff turnover, including several project managers, leading to significant schedule delays.

The vendor business unit providing services to the client was sold/spun off and the separation was a comedy of errors—staff unsure whether they were going or staying, resignations, delays getting contract amendments, needing to establish contracts with other parts of the organization that were involved in the project. When the transition to the new company finally happened, staff couldn’t access their systems and couldn’t access project documents stored in a repository for the former company for several days.

Midway through the project, when it became apparent that the initial schedule was untenable, the vendor was arrogant and dismissive. A six-month slip was agreed to, but the vendor made clear that if the new six-month target wasn’t met, they expected to be compensated and the go live date was likely going to be pushed to the next calendar year because of vendor staff availability.

Vendor delays continued.

I’ve been on the vendor side of things for 35 years. I understand that vendor costs escalate if a client fails to do their part and it results in schedule slippage. What surprised me is that this vendor appears oblivious to the costs my client is incurring because of vendor delays.

• The system being procured is replacing an existing system. Delays mean that maintenance on the legacy system must be paid for an additional year.
• Client staff have had to attend duplicate meetings because vendor staff who interviewed them for requirements and configuration information have left the project. The new vendor staff needed to repeat information gathering. This resulted in hundreds of hours of redundant work.
• The client project team was scheduled to move on to other projects when this one was complete. Those projects are being delayed for lack of available staff, resulting in opportunity costs and customer satisfaction issues with the users of those systems affected by the delay.

No one wants to play the “blame game”, and schedules sometimes slip through no fault of either party (or though minor faults of both). What surprises me is that the vendor appears oblivious, or at least is acting that way, when there is clearly a majority of fault on their side.

The lesson learned from this is to make sure that your change management process is clearly outlined at the beginning of a project and use it when there are unforced errors to get concessions - monetary or otherwise - from a vendor when the fault is clearly on their side. Vendors will certainly do the same when you are responsible for delays.