Get Your "Ticket" to the Show

I was comparing notes with a colleague at a local PMI meeting last week and we agreed there seems to be an evolutionary step many companies go through as they emerge from chaos and move toward an environment supportive of Project Management. For lack of a better name, I'll call it a "ticket" system. They use products such as Bugzilla, TeamTrack, Remedy, SharePoint Lists, and so on, to "organize" their work. This might range from recording service requests, issues, mini projects, and other discrete work tasks they need to complete.

Now there is nothing fundamentally wrong with this type of tool or organization. The problem seems to lie within why it is adopted and the expectations around its performance. A colleague at a major San Diego telecommunications company related this story [I'm paraphrasing] to me a few years ago ...

Our IT Department installed a ticket system to handle their growing volume of work. Within 6 months, at least two new layers of management were installed to "manage" the system. Everyone was going crazy. The project team members were unable to get anything done, because every time they turned around, there was a manager on the phone asking about the status of ticket "x". They needed more managers since the number of unsatisfied tickets just kept growing exponentially.

Now the real issue here is usually a failure to address the "root cause". If these are problems with bugs, defects, or quality issues, sure a ticket system can help in organizing and prioritizing the work, but if the underlying quality issue isn't identified and fixed, the ticket system keeps feeding itself.

Or maybe the underlying issue is planning and resources. In that case, some hard decisions may have to be made about what will and will not be done, or what resources may need to be added to accomplish goals, but throwing in more tickets to develop new features is not going to solve the underlying issues.

There WILL be a breaking point. After a near internal melt down, the telecommunications company realized the situation was not improving and hired consultants to a) improve product requirements so quality and other issues were addressed and b) started to adopt basic project management practices to prioritize work and review resources and schedules. Over time they de-emphasized the significance of the ticket system in favor of creating well run projects.

When I took over my current position, I had 6 pages of Excel spreadsheet of work (around 300 tasks taking anywhere from 8 hours to a week to complete) needed for customers. During my first six months, we triaged and prioritized work, identified roadblocks and planned their removal, and steadily reduced the list. During the second six months, we analyzed resources, looked at some trade-offs, and continued to build tools. Today, there is little or no chance this list will become unmanageable again unless something goes horribly wrong. Why? Some of our clients are now trained and would rather take on the work themselves than wait in a larger request pool, we have trained more people to perform these tasks so we shouldn't easily run out of resources, and we've dramatically improved the tools and techniques we use to carry out the work. The root causes were successfully identified and addressed.

So if you are at the point that a "ticket" system is called for, step back and take a hard look at the root cause. The ticket system itself will often disappoint if you believe the organization it offers is the only thing that needs to change. Be sure you are planning to address the real root cause and not just institute a tool where tons of tickets will accumulate without resolution. The meltdowns may be entertaining for some, but they rarely lead to productive situations.