Save Money on Your Issues
Randy Loomis, PMP Andover, Connecticut, U.S.
oUR 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* nec- essary to begin converting the data and applying the first of the upgrades.
Once the scripts passed vendor testing, they were migrated to our develop- ment 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 dis- covered 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 dis- covered, and how and where we encountered each issue.
* Script: In computer programming, a program or sequence of instructions that is carried out by a program rather than by the computer processor. Scripts can be used to control a software applica- tion without altering the core code of the application.
?
???????????????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.