The problem with problem tracking

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

“We went into production after only two months,” Barnett says, “but that [timeframe] was driven by business requirements. I’d have stretched it a few months longer and put more research and thought into the rollout.” What he discovered was his company’s processes didn’t necessarily map to the ones contemplated by the product. The “one-issue, one-person” paradigm simply didn’t fit the Lexmark business model, and neither did the Web-page notification scheme. Barnett redesigned the e-mail interface to run as an outside process, and he’s still working on a group-based workflow approach.

Some degree of customization is inevitable, so plan for it. If you expect to “install and go” out of the box, you will be disappointed.

Barnett’s experience is more the rule than the exception. A packaged product cannot, as a practical matter, accommodate the wide variety of ways and means in which companies manage their development processes, not to mention the technical landscape in which it’s installed. Some degree of customization is inevitable, so plan for it. If you expect to “install and go” out of the box, you will be disappointed.

The results

For Barnett, the good news about buying TeamTrack and investing in the customization is that it was worth the effort. “We have enjoyed significant positive impacts from the new system,” he notes. “The file attachments capability fixed a time-lag problem by getting failing test cases into the hands of the developers. Previously, we had to describe where the test case lived and how to get to it, and we lost a lot of time because of this.”

Reporting and analysis have also been enhanced. Instead of exporting the data into spreadsheets and creating their own charts and graphs, the new system provides users with built-in reports as well as enhanced spreadsheet interfaces. Search times are dramatically reduced with a relational database, and Barnett expects to see a reduced client-support workload, since the new system uses HTML/Javascript instead of X-Windows, which is harder to support.

The light at the end of Barnett’s tunnel is when he completes the training for about 30 administrators in the weeks ahead so they can begin to determine their own area’s destiny. At that point, he can transfer daily administration of the system to administrators and concentrate on server support, maintenance, and policy.

The lessons

As Barnett’s experience proves, acquiring a packaged product for issue and problem management is a smart move, but not a free ride. You’ll probably save time by keeping the old system patched and glued together while you spend time gathering requirements and finding a product that meets your company’s needs. Then you will still have to incorporate the nuances that make your company’s internal processes unique.

So while the IT department may never be free of maintaining and supporting an issue- and problem-tracking system, daily administration can be given to the project groups, which accomplishes the ultimate goal: to put project groups in control of their own destiny. And, of course, you will also reap the benefits of improving your processes. //

Linda Hayes is CEO of WorkSoft Inc. She was one of the founders of AutoTester. She can be reached at linda@worksoft.com.