0. Introduction

The draft version of MFCF's RT — Alternatives and Improvements was published on 22 December 2006. The initial review by MFCF staff resulted in some minor changes, and the document was closed on 25 January 2007.

Since then, very little feedback has been received, but over the ensuing year and a half a few more problems with the existing system became more obvious, and the possible solutions more solidified.

1.1 Due-Dates versus Expected Completion Dates

The existing RT system has a Due-date field, intended to indicate when an item must be completed by. Item Owners can use this as a reminder to schedule their time appropriately, and Managers as an overall guide to how well work is progressing and to which items might need more urgent attention. Reminders are automatically mailed to Owners and Managers when items approach their due date, and overdue items are flagged in red in the MFCF RT Activity web pages.

MFCF Management also needs to have an overview of when open items without due-dates are likely to be completed. The Due-date field was usurped for this purpose, with owners encouraged to set expected completion dates in the Due-date field of their items.

If we normally completed all items on time, this misuse would cause only a small annoyance. But unfortunately, we have not proven good at managing our queues, with many items being allowed to go past their Due-date. Currently there are over 30 such items, and it's not at all obvious which ones have exceeded the Requester's due date (bad) and which are simply a case of the owner's completion estimate not having worked out (not necessarily bad, and certainly not unusual).

Obviously it's not a good idea to have a single date field with two different meanings, one applying to those small number of items where the Requester really does have a critical due date, and the other for Management to track overall progress.

1.2 Stalled Items

The current RT system has a stalled queue status. Unfortunately, this word has multiple meanings in English, and people have been using it for different purposes.

The original intent uses the less obvious meaning of stalled to indicate that no further work can be done on the item, often because an item it depends on has not been completed. But it has also been used, typically for longer-term less urgent items, with its more common meaning to indicate that the owner has become bogged down or is busy with more important duties and has put this item aside for a while.

Again, it's obviously not a good idea to have a single status name to indicate the two different reasons for lack of progress.

1.3 Queues

Management has suggested that our RT system might eventually be used by other units within the Math Faculty.

The original RT software defined queues precisely for this purpose, suggesting that a queue be set up for each organizational unit. Unfortunately, when we adopted the system we used queues for a completely different purpose. And even more unfortunately, what we did do doesn't even provide an adequate mechanism for that purpose.

Even if they weren't in such a mess, there would be no justification for preserving the current meanings or structures of queues.

2. Solutions

Generally, these observed problems are not with web pages reports, or other user interfaces, but with the process of organizing items and attaching meaningful attributes to them.

As mentioned in the original document, the whole concept of priorities, queues, and statuses is not well structured. These should be orthogonal properties, with some representing the intrinsic state of the item (e.g. which department requested it and for what purpose), while others should represent the changing state of the work being done on the item (e.g. is it currently being worked).

These attributes should allow emergency and urgent items to be selected by calculation, without their having to be manually marked explicitly as such (something required by the current system).

2.1 Queue

The simplest work queue structure is one per department, according to which organization is responsible for completing the work. Initially we would have only one queue, for MFCF.

Once the new system is working, we could add additional queues for other departments (e.g. Dean of Math). And perhaps we might decide it would be more convenient to have separate queues for units within MFCF (e.g. Windows, Unix, Operations, Networks, Consulting).

2.2 Due-Date

An optional due date may be set by the Requester, with the approval of the owner (or Management).

2.3 Importance

An item's importance should be set by the Requester, with the approval of the owner (or Management). For items with due-dates, the importance would reflect how disasterous it would be for the item not to be completed on time.

3. Attributes

...

3.1 Static Attributes

While it's possible they will change as work on the item progresses, some attributes will generally retain the same values as when the item was created.

Queue

The organizational unit responsible for the completion of the task.

Owner

Who, within the organizational unit, will do the work.

Requester, Department, etc.

Who is sponsoring the work.

Activity

Overall purpose of the work (e.g. Teaching, Research, Administration, Infrastructure).

Importance

How important completion of the work is.

Due-date (optional)

When the Requester expects the work to be completed.

3.2 Dynamic Attributes

Other attributes will generally change as work on the item progresses.

Status

How the owner is treating the item.

• Done — item is closed (with optional subcategories)
• Active — item is currently being worked on
• Stalled — work has started, but not currently being worked on
• Blocked — item is blocked by another item
• Pending — no work has started yet

Priority

Relative position of item within the queue. (Ideally, this is monitored and frequently changed by the Manager.) Currently this value has an effectively infinite number of values between 0 and 1, something that we may or may not wish to continue. Either way, there should be a specific lowest priority corresponding to the current wish-list queue to tag items that are not likely ever to receive further attention. (If that proves impractical, we could use a wish-list status.)

Estimated Completion Date (optional)

When the owner expects to finish the task.

4. Summary

Note that what appears above is only my opinion, which is subject to change, and which can be overridden by Management (and frequently by common sense).

I believe that the suggested changes will greatly improve the potential of our RT system, but as mentioned in the original document to be effective it will require stricter policies, more cooperation on the part of Staff, and more attention by Management.