The problem with problem tracking

Putting a system in place to follow up on software management issues is harder than you think


You Can't Detect What You Can't See: Illuminating the Entire Kill Chain

On-Demand Webinar

(Page 1 of 2)

Just when you think you have a handle on your development and testing processes, you realize you really don't. Now, you find out you need a robust means of managing the issues that arise from building and supporting your own software. Sometimes these issues are outright bugs, sometimes design flaws, and sometimes enhancement requests. But whatever their nature, you need an orderly way of tracking their existence, status, and disposition.

What starts out as an innocent problem-tracking product acquisition often turns into yet another development and administration commitment.

You probably already have a tracking system of some kind in place: usually a homegrown database or customized groupware. And you may even have several of these systems sprinkled throughout different departments. The odds of keeping these homegrown systems maintained and supported--not to mention enhanced--is a full-time job with only part-time resources. You discover that it's not as simple as maintaining a database of reported or requested items. In addition, you must incorporate company policy about who is notified and when, what the workflow and the service levels are at each phase, who participates in prioritization, and who decides when an item can be closed. Whether this is done centrally through IT or at the individual project level, it requires ongoing support for new platforms, technologies, and features.

To tackle these and other issues, you decide to acquire one of the growing number of commercially available problem-tracking solutions. But what starts out as an innocent product acquisition often turns into a politically charged process, and yet another development and administration commitment. How does this happen, and what can you do about it? At least one experienced survivor has some observations and advice.

The search

Take the case of Tyler Barnett, the staff engineer at Lexmark International Inc., who's been responsible for the company's IT problem-tracking system over the past 10 years. Lexmark, based in Lexington, Ky., started out as IBM's printer division and now develops and manufactures printers, supplies, and supporting software. "Our system originally ran on an IBM VM mainframe, then it was ported to an X-Windows client/server application in the early '90s," he says. "The needs of the business have changed, and workarounds we used to keep the old application going couldn't be extended any longer, especially since [the app] was not Y2K compliant."

Barnett originally planned to develop a custom, Web-deployed system, but he realized that the requirements would keep growing and, with the Year 2000 looming as a nonnegotiable deadline, it was unlikely he would be able to complete the development and conversion to a customized system in time. Instead, Barnett assembled a shopping list of requirements and went out to buy a packaged, but flexible, solution.

His list included security, accountability, file attachments, and improved performance, as well as additional fields and more flexible workflow management. External vendor access to problem tracking was important to Lexmark. At the same time, the system had to be able to restrict access within certain groups such as some vendors or developers. Web access would be a major advantage, with the ability to broadcast information among the responsible parties instead of requiring them to drill down in search of it.

According to Barnett, "Whatever I did, I wanted to deploy a single system that could be used by everyone. I didn't want to glue disparate tracking systems together or maintain them. Yet, management also wanted to see everything from one viewpoint." Obviously, this was quite a challenge.

The solution

Eventually Barnett chose TeamTrack by TeamShare Inc. of Colorado Springs, Colo. But while making the product selection might seem like the conclusion of the process, it was actually only the beginning.

Page 1 of 2

1 2
Next Page

Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.