Workflow Time Management

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.

Implications of Prioritization

CSCF has to demonstrate that it can complete the priorities set for it. The implication of prioritization is that we maximize the resources spent on the priorities, and minimize the resources used for other work, all in the context of ongoing time commitments.

We must complete what we start, and then make a conscious decision about what will be done next.

Reactive Work - FIFO

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.

Reactive Work - Special Cases

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.

Emergencies

The most obvious are "emergencies", which by definition cause other work to stop.

Executive Prerogative

Senior administration have been known to impose specific priorities.

The Express Lane

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.

Due Dates

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.

Time Commitments

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.

Popularity

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.

Proactive 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.

Predictable

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.

Efficiency

Work that improves the efficiency of reducing reactive work wait time is considered worthy of time.

Quality

Work that improves the quality of the computing environment used by our clients is presumed to be acceptable to them.

Overhead

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.