Author: Yogi Schulz

A gap will always exist between customer expectation and vendor delivery. That gap is product of the rosy vendor sales pitch coupled with the unrealistic imagination of the customer. Occasionally, the gap becomes wider than the Grand Canyon.

When the gap becomes too wide, vendors will engage in what I call the bob and weave tactic. Watch out for these telltale signs of vendor bob and weave because they can scuttle an IT project. Here’s what to watch out for and what to do about it.

Let me Get Back to You on That Topic

Often the functionality expected exceeds the functionality delivered. When the vendor wants to weave around this annoying fact, the representative will say that he’ll get back to you with a resolution. In fact, he’s fervently hoping the topic will become lost in the growing pile of outstanding issues and action items, never to be heard from again. In some cases, the issues drag on for so long that a reorganization absolves the vendor of ever needing to take any action.

You can reduce the weave and improve performance by logging all the items and holding a monthly review meeting with the representative. If vendor staff start to become too busy to attend the review meeting, you’ll have to escalate the issues within the vendor management team.

I know I promised a Response but other Issues Arose

When it’s painfully obvious that the vendor has failed to respond within the initially promised time frame, it’s time for the bob as a diversion tactic. Now the vendor representative says: “Yes, we promised but you created a newer, more important action item that we’re responding to.”

I believe it’s reasonable to expect that a vendor can address more than one issue at a time. You can protect yourself from this bob by ensuring that the vendor team is adequately resourced to meet your expectations about responsiveness. You can assure adequate resourcing by planning to pay for vendor professional services effort as part of your project budget.

{For those of you who believe: “It’s outrageous that I should have to pay the vendor to address what I view as vendor deficiencies.”, let me suggest that some compensation is better than watching your project momentum fade to the point of project failure. There is no free lunch.}

I don’t believe we committed to deliver that Function

When a debate about in-scope functionality breaks out, the vendor representative can weave by saying: “I can see where that functionality could be useful, but I don’t believe we committed to deliver it as part of our RFP response.”  This response pushes the onus back on the customer to assess the voluminous pages of the RFP response to see what’s factual and what isn’t.

As a project manager, you can avoid this weave by simply insisting that the vendor produce a summary of the related documents and that your position is that the expected functionality remains in-scope until the vendor demonstrates otherwise.

{This approach can be enforced with commercial terms that set a series of milestones where the vendor is paid significant sums of money during the course of the project. Commercial terms where the vendor receives most of the money up-front are less effective for the customer.}

That’s not what the Words Mean

If the customer or the vendor miraculously finds some wording in the RFP response that indicate indeed, the delivery is deficient, then the vendor can always bob by saying: “I don’t believe your interpretation is what the words we wrote actually mean. However, just to be sure let me check with Angela, now part of our San Diego team, who contributed to our RFP response to you. Let me get back to you on that.”

Now it’s d¹jù vu all over again. Be careful how much time you invest in these interpretation issues. There’s lots of gray in every RFP document and in every RFP response. Aim for a compromise.

{Often government projects drag out and cost way too much because the grind-the-vendor procurement staff injects itself into the situation. Your best strategy is usually to negotiate a settlement where the vendor gives you a deal but you have to pay something as well. Neither party will be ecstatic about such outcomes but at least your project doesn’t stall and your vendor relationship doesn’t turn frigid.}

It’s in the Next Release

When the temperature in the relationship between the customer and the vendor rises to an uncomfortable level, the vendor can weave by saying: “The feature you’re looking for is in the next release.”

Now you as the customer face a difficult choice. The vendor promised this feature in the current release, so clearly the vendor is in violation of their contract. However, what is the benefit in making a big issue of the violation?  Introducing lawyers and the possibility of a lawsuit into the project will be a huge distraction that will delay completing the project.

{If you have experienced a series of flagrant violations, then a settlement under threat of lawsuit is probably your only answer. If however, this case is the first major violation you are better off to negotiate a financial settlement around non-delivery, push the missing piece of functionality into the next release and move on.}


Whenever the vendor starts to bob and weave, that’s a clear indication of inability to deliver. In most cases your best strategies are thorough follow-up and pragmatic negotiation to avoid project failure.