| Martin had started his own tracking system. Every issue that came in on the daily reports was listed and tracked. With the increasing size of the project, and the complexity of some of the bugs, Martin could not accurately track them manually. To resolve this issue, he worked with the vendor to get access to its bug system so he could examine in real time, at his pace, the current status of the open bugs . Jumping time zones was tough enough, but not even staying in place long enough to be contacted was worse . With the lightning-like pace Jason needed to keep up, it was not surprising that it was taking him upwards of 24 hours to respond to an issue. To address this issue, Jason created an internal discussion group . It was his hope that the pilot community could post and share issues and resolutions . Problem tracking was done in the evenings on the rare nights when the group returned early enough. |
The Methodology Beyond the reporting and tracking described, additional attention needs to be paid to problem and resolution tracking. As the pilot is deployed, issues will arise that must be addressed. It is important to record when a problem was first seen, on what desktop build, on what biometric system configuration, the severity of the problem, and lastly, the resolution. This type of information should be shared as quickly as possible and will form the basis of a support database. The better the data in the support database, the more efficient the support infrastructure. Thus, when a problem is seen again by a different support resource, he/she can consult the support database and see the resolution to the problem. Beyond providing a support reference, tracking the problems shows that both issues and resolutions are being found. Documenting this will allow claims of outstanding issues to be refuted at the end of the pilot. The issue log also shows that the pilot is doing what it was intended to do, that is, to find, document, and correct the issues of the biometric system before full-scale deployment. |
