The way in which we allocate time is determined by our understanding of what our clients want and will accept. All that follows is intended to be derivable from that basic goal of client satisfaction and acceptance.
Our clients are the Cheriton School of Computer Science, as well as any others that CS deems to be clients. An example of that is ICR, which wouldn't normally be a client.
Our client's needs are both presented to us by our clients (reactive work), and expected of us (proactive work). Thus we must balance our time between several forms of work, as described in the following. Our challenge is to be sure that we spend sufficient time on each. In practice, that means not allowing special cases to dominate at the expense of other forms of work.
What is yet to be understood is what constitutes "sufficient time", other than to say that it's more than none, and over which period of time we should expect to be able to spend that time on work of each category.
It's quite likely that the appropriate balance depends upon the nature of the work being done. E.g. research support tends to be more reactive than infrastructure support.
Reactive work is the work explicitly requested by our clients.
It is human nature to want to be treated fairly; nobody likes a queue-jumper. So by default, this work is FIFO (First In, First Out).
In ST terms, First In is the oldest of the "Upcoming Requests" list.
There are exceptions to FIFO considered to be acceptable to most if not all of our clients. We assume that there is a limit to how long clients are willing to have their work delayed in favour of the special cases. How long is a judgement call.
The following exceptions are common examples that clients will accept (to a point). We may discover more.
The most obvious are "emergencies", which by definition cause other work to stop.
Senior administration have been known to impose specific priorities.
Telling a client that their two minute job will be done in three weeks is no more acceptable than the "queue jumping" referred to above. Visit any large consumer store, and you'll find an express lane to address the problem. We too need an express lane.
In ST terms, this is the most recent of the "Upcoming Requests" that appear to be doable quickly. That implies that the time likely to be required to complete incoming requests must be assessed as the work arrives.
A due date with the characteristic that missing it will result in the work not being useful is likely an example of a special case (acceptable to other clients). A due date imposed just to "get things done" is likely not one that our clients would accept. It does require judgement.
Research support provides a commitment of time based upon the current subscription level of a client/group. Thus a request for research support from one client (group) may be done ahead of that for others to honour the time commitments. I.e. the FIFO principle applies independently to each group.
If a large number of clients want the same work done, then we take it to be likely that other clients will consider that an acceptable reason to alter the priority of the work.
Merriam Webster: acting in anticipation of future problems, needs and changes.
There are several reasons for work which has yet to be associated with a specific client request, but that nevertheless should be done to aid clients.
Unlike reactive work, we're free to prioritize this, in whatever way we think will best minimize and/or improve our reactive work.
In ST terms, this is the "Upcoming Projects" list.
Like reactive work, we expect this work to be resolved.
In an ideal world, clients wouldn't have to ask for anything, all of their needs would be met in advance. So work that can reasonably be predicted to become reactive work if not done, should be done before someone requests it.
Work that will likely be applicable to multiple client requests and that can't be fairly attributed to a single client (e.g. because of a requirement that it be done far sooner than it would otherwise be) has to be done. It's considered separately from the reactive work from which it might have been derived when billing for time, as it wouldn't be fair to assign the cost to the first of many who make the same request. An example would be preparation for an upcoming release of a system (software or hardware) that is popular enough with our clients that we can reasonably predict many demands for expertise with it.
Work that improves the efficiency of reducing reactive work wait time is considered worthy of time.
Work that improves the quality of the computing environment used by our clients is presumed to be acceptable to them.
Overhead can be regarded as work that our clients don't feel they should have to ask for, but nevertheless should be done. E.g. keeping basic services running, or administrative tasks needed to facilitate our work.