Collective Wisdom from the Experts 23
We also brought the vendor proof showing what we had originally been
promised the software would do. The vendor insisted that the software was
functioning “as designed.” Later, we discovered that the small bugs we had
encountered were only the tip of the iceberg and had greater ramifications.
They illuminated significant problems with the software’s basic functionality,
even after the upgrades.
Over time, the vendor conceded that several of the issues we discovered were
admittedly not “as designed”; rather, they were actual bugs. Remaining true to
our “not-to-exceed” contract, our vendor did not charge us for the significant
amount of work they were required to do to correct their own product after
they reached the “not-to-exceed” total in our contract.
At this stage of the project, in order to meet critical deadlines, we were com-
pletely focused on getting the software installed. Our concern of whether an
issue was “as designed” or a bug was the least of our worries. It became appar-
ent that, had we been tracking vendor time specifically against each bug issue
located, we might have avoided paying the “not-to-exceed” contract total cost.
When negotiating a contract with a vendor, specify that both the vendor’s and
your project team’s time be tracked against each separate issue that is encoun-
tered. This will allow the software project manger to have an accurate record
and be able to lower charges when there are issues with the vendor’s original
product, as opposed to problems with the contractual project work to imple-
ment it.