Save Money on Your Issues
July 17, 2019OUR COMPANY WAS USING TRAINING SOFTWARE that was five upgrades behind. We reached the point where it was so out of date that 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 the 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 retested 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 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 completely focused on getting the software installed. Our concern about 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 “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 to be tracked against each separate issue that is encountered. This will allow the software project manager 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.
This article first appeared in the book – 97 Things Every Project Manager Should Know and has been reproduced here under the Creative Commons – Attribution 3.0 license.