Save Money on Your Issues

Randy Loomis, PMP Andover, Connecticut, USA

Our company was using training software that was five upgrades behind. We reached the point where it was so out of date the vendor would no longer support it. Our project consisted of working with the vendor to upgrade our training software to the latest release, and then to train our users to use the newest version.

We developed two statements of work, one that outlined the user training agreement and one that delineated a “not-to-exceed cost” for applying the upgrades to our old training software. After obtaining a copy of our data, the vendor began the process of remotely developing and testing scripts* necessary to begin converting the data and applying the first of the upgrades.

Once the scripts passed vendor testing, they were migrated to our development environment where we performed user tests. This process was repeated as we added each of the five, subsequent upgrades. While doing testing, we would document any issues that we encountered, then we retested those issues once the vendor had rewritten and re-tested their original scripts.

While working through each of the upgrades, the vendor's hours, multiplied by the billing rate established in the statement of work, were tracked against the “not-to-exceed budget”. As we progressed through the upgrades, we discovered bugs in the application upgrades, themselves, that were not related to the custom scripts written to install the upgrades. We thoroughly documented each issue; printing screens and providing step-by-step details of what we discovered, and how and where we encountered each issue.

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 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 completely 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 apparent that had we been tracking vendor time specifically against each bug issue located, we might have avoided paying the entire "not-to-exceed" contract total cost.

When negotiating a contract with a vendor, specify that both vendor and your project team's time be tracked against each separate issue that is encountered. 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 implement it.