All too often, we in IT suffer paralysis from analysis—we spend more energy entering our to-do lists in a project management system than we do working on the tasks themselves. And once we do begin work on the tasks, there’s one key ingredient that is often overlooked but can determine whether a project management system succeeds or fails miserably: due dates.

Just get it done
Recently I started a new consulting job for a small software company. My job is to watch, listen, and provide feedback about what is working and what needs improvement in this company’s shop. Here’s what I learned.

This company produces a nice vertical market application that’s been successful enough to generate its sixth version. The players are:

  • The Product Development Department. This team consists of the developers and the test managers who make sure the final product performs according to the specification. This team is also in charge of making fixes and enhancements to the program.
  • The Customer Service Department. The people in this group use the product daily and support customers who use the product. They also generate “change requests,” which are requests for changes or additions to the program.
  • The Marketing Folks. These people sell the product and provide feedback from existing and new customers about what new features should be added.

Each week, representatives from the departments meet to discuss the “open” change requests. The goal of that weekly meeting is to prioritize the change requests so that the most important changes get made as soon as possible.

The problem is, of course, that the groups rarely agree on which items should be ramped up to the top of the list.

  • Marketingsays, “We’ve got to have these new features right away.”
  • Customer servicesays: “We’ve got to have these bugs fixed right away.”
  • Product developmentsays, “We’re strapped for resources, and we’ll try to do what we can.”

When the people in customer service become frustrated and complain about how long it takes for a change to be made, the product development folks go on the defensive. “It takes time,” they say, “to get these things done.”

The problem may be in the project management system
I listened to people from all of the teams, and I was struck by the lack of company-wide unity. Too many sentences started out “Well our team this, and their team that…” The individuals had drawn boundaries in the cybersand. However, my goal was not to advise management on how to foster a single-team company spirit, but to find something in the process that could be improved—and I did.

The “change request” database contained more than 600 open items. That’s six-zero-zero open items. Those items ranged from “fix this misspelled word” to “this feature doesn’t work according to spec” to “please add this new feature.” Some of those items had been languishing in the project management system for months.

Add a new field
Although the project management system did a pretty fair job of tracking the change requests, it contained no mechanism for flagging items that were overdue. Change requests simply fell through the cracks, and the people in customer service and marketing were frustrated, feeling that their change requests weren’t being given the respect and consideration their suggestions deserved.

Each record in the change request database tracks the name of the person who requested the change, the date of the request, the severity and priority ranking, the category of the change, and the name of the person to whom the item was assigned. But conspicuously absent was a field for date due—and by that I mean “date by which this change will be made (or discarded and not made).”

My suggestion was that, by default, a change request should come due 30 days after it’s entered into the change request database. If it isn’t flagged as completed within 30 days, it should hit an “overdue change request” report and go straight to the top of the list. The minimum length of time depends on your circumstances; if 30 days is too soon, maybe the default should be 60 days.

At that point, the product development team should either schedule the change or justify to the change request committee why the change cannot or should not be made. The goal is to whittle down the majority of those 600 open items and prevent change requests from getting stuck for months in the database without being resolved.
If your IT department maintains a database of action items, how do you prioritize those items to make sure they’re accomplished in a timely fashion? If you’ve devised a particularly clever solution, please post a comment below or send me a note .