The Vendor Yes That Could Not Survive a Calendar

Filed by: D.B. Trench

Field line: A yes without dates, names, and assumptions is only weather with a purchase order.

The vendor’s first yes arrived in the proposal deck.

The second came during kickoff.

The third came in the workshop where the technical lead asked whether they had reviewed the current interface specification.

That third yes had a pause in it.

Not a long pause. Just enough air for the project to hear the floorboard shift.

The account lead smiled through it.

Yes, we are comfortable with this class of integration.

Comfortable with this class of integration is not the same as having reviewed this integration.

The project schedule, unfortunately, was being built by people who wanted those to be the same sentence.

The timeline showed design complete in two weeks, build in four, test in three. It looked disciplined. It also assumed the vendor had named resources, reviewed the source system, confirmed access, accepted the data mapping, and understood the business rules hiding behind the phrase standard workflow.

None of that was in writing.

So I asked for the yes to come down from altitude.

Please confirm the named delivery resource, documents reviewed, open assumptions, required client inputs, access date, and the condition that would change the target build completion date.

The answer did not arrive as quickly as the yes had.

That is one way to know you have moved from sales to delivery.

By Monday, the vendor had confirmed one resource, not two. The named resource was available at fifty percent for the first two weeks. The interface document reviewed was last year’s version. Access to the test environment was assumed, not confirmed. The data-mapping exception that everyone called “minor” required a configuration decision from the client team.

The original yes was not a lie.

It was a sales-level truth trying to carry a delivery-level schedule.

Leadership asked whether the vendor was backing away from its commitment.

No.

That was too easy a story.

The vendor was still willing. The project had simply never forced the willingness to stand on a calendar.

The schedule review became less cheerful after that. Design no longer closed in two weeks. Build no longer began on the fantasy Monday. The target date moved because the project had finally counted the assumptions it had been treating as evidence.

Nobody thanked the calendar.

The revised note said:

Vendor commitment confirmed subject to named resource availability, current interface review, access readiness, data-mapping decision, and client turnaround on configuration questions. Current launch path is under review pending confirmation of these conditions.

That sentence did not win applause.

It stopped the project from treating a sales yes as a delivery fact.

If a vendor says yes, do not ask whether they are confident. Confident people have caused some very expensive Mondays.

Ask what they reviewed, who is assigned, what they assumed, what they excluded, and what condition breaks the date.

If the answer gets less confident, good.

Now the project is finally talking to delivery.

---

Vendor commitment check: Use this when a vendor says yes in general language while the schedule depends on specific evidence.

Sales-level yes sounds like: “We are comfortable with this class of work.”

Delivery-level yes requires: Named resource, reviewed documents, assumptions, exclusions, access date, and break condition.

Record line: “Vendor commitment remains conditional pending [named conditions]. Date confidence cannot be confirmed until those conditions are closed.”

Field channel: Get The Dispatch — weekly field reports for PMs managing the work beneath the official update.