Explaining some university staff peculiarities

August 8, 2007

I think that universities not having a return on investment as such may go at least part of the way to explain some weird university behaviors around staff. The core issue is that without an ROI it becomes difficult to see the cost of how staff spend their time.

(With a ROI for projects it is easy to see how having staff spend their time on a lower-ROI activity more or less directly costs you money.)

Not only does this effectively make staff into a constant sunk cost regardless of what you have them do, it means that it is very hard to cost-justify spending more money on a problem when you could just throw staff time at it. Until something gives way explosively, one side has at most fuzzy costs while the other side has very firm numbers; unless the firm numbers are small, you can guess which side is likely to win.

(One degenerate case is that if you just use staff time, you don't have to persuade someone to give you more money.)

Without being able to clearly assign costs or benefits to staff activities, a university lacks good signals on what is a sensible allocation of staff time. As a result, it is easy to slip into what an outsider would consider very peculiar decisions about what (expensive) staff spend their time doing, because staff time is as likely to be decided by what people can do as by what people should do.

(This is not just an issue of management; even if the staff themselves are making the decisions and want to make smart ones, they can be at least as lost in the forest as everyone else.)


Comments on this page:

From 72.143.180.234 at 2007-08-10 21:23:14:

Not necessarily, although that's the traditional way - it depends on how you approach it.

There's how we do it, and our sister department MFCF have a slightly different way of charging back time.

That's only for research support though, and there's only 3 of us + a manager in a department of ~20. Everybody else operates more or less along 'traditional' university lines.

MikeP @ UW

By cks at 2007-08-11 15:09:49:

Fundamentally, I don't think that charging for things internally is at all equivalent to making a profit for the institution; it doesn't generate any new money, it just moves money around.

As a result, I'm not convinced that it fundamentally changes the issues. Instead I think that it at most pushes them back one level; while staff will spend their time on 'profitable' things, this just means that the decisions about staff time are moved to the people who decide what the charges are.

From 72.143.180.234 at 2007-08-11 23:20:01:

It places a throttle on the silly requests from faculty members and grad students, at the very least. It also removes the excuse / rationalization that something is not interesting enough to pursue: the faculty members get to drive the time of the staff members, so unless the faculty member likes wasting their research dollars, what gets done is what is important to them. That is, in my eyes, a step up from the traditional "I don't want to work on that, it's not very interesting, so I'll blackhole it" approach that (some) university IT types take.

It eliminates the degenerate case you mention altogether, and does assign a cost to staff time; at a certain point, it does become more efficient to put money on the problem rather than just throwing more staff at it. We now have enough data from our group that we've started being able to use staff time as a hammer, since our group at least tracks pretty much everything it does.

MikeP There's still usually not calculations of RoI like you would see in business, but it gives us sort of a middle shadow ground between corporate world "but how does this help the company" and "nah, don't feel like doing that".

Written on 08 August 2007.
« A surprise with the Provides header in RPM
A gotcha with the format of dump archives »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Aug 8 23:56:16 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.