Measuring Staff Time — Is it Costing Us in Innovation?

I was basically going to put up another top-ten list, and then decided that I really only have one thing to say.

I have, on occassion, heard people use this logic:

When you have the choice of between outsourcing a piece of technology or building it in-house. You ask a tech-savy staff person how long the project would take him/her to develop. Two weeks? That’s over a thousand dollars if you count the person’s salary! We can outsource for [marginally] cheaper than that.

This, in a word, is a poor way to manage staff resources.

Taking a dollar-for-dollar match for staff time is not really good managerial accounting. See, you have to consider relevant costing. You already spent the money on the staff member, and probably can’t ask for it back. So the only relevant costs are the total value of what that staff member would be doing instead of doing the project. That number may be a thousand, it may be something more or it may be something less.

If you’d be taking that staff person away from a really valuable project, then I’d say you are justified in outsourcing. If that staff is just twiddling his or her thumbs then you are losing lots. Consider:

1. The loss of dollars spent on the outsourced product.
2. The lost productivity caused by putting your developer to less valuable or “make work” projects.
3. The lost knowledge and skills that could result from your staff doing the project.

Other things come into play here, of course. For example, will the in-house developed project be as secure, usable and/or maintainable as the proprietary one? One way or another you have to do better than a dollar-for-dollar costing of your project. If your staff member has a spare week to build something quality without getting in the way of other projects & activities, then the benefit is the same and the cost is pretty much zero.

I think people began to think this way because of an emphasis on private sector thinking. I have nothing against private sector thinking, actually. The problem is that, sometimes when people are told to think out of their element, they basically learn just enough to be dangerous.

The relevant costing scenario is a good one. Libraries want to put their decisions up to solid cost-benefit analysis. This is responsible decision making. But then people start measuring in present-day dollars, or adding sunk costs to their analysis. “Oh no! We spent all this money on a now ineffective system. I guess we are stuck with it. . .” This is just wrong! The fact that you spent money on something in the past means nothing in deciding whether to use a new system. You can’t get the money back, so losing the system is not a cost. You can only measure the benefits of the current system against the benefits of the new system minus the costs of purchasing it. If the benefit is still greater, then you should change despite the fact that you made a bad decision in the past.

Anyway, I was thinking that this sort of analysis has cost libraries even more than just bad purchasing decisions. In automatically thinking that purchased products are cheaper than staff time, we may have caused a serious de-skilling of the profession. We say that we will outsource different things to leave time for staff to do more important things. Then the more important things never materialize.

What results is a library staff that spends time doing minor updates on a web site that someone else designed for them. And I expect that, soon, we will begin to see the results of this. Libraries using CMSs with designs that don’t hide the product. Joomla sites will look like Joomla. Drupal sites will look like Drupal. And because we don’t know how to code a little bit of php, we put up with it — even when we know that the site will get really tired fast.

Part of library 2.0 and/or slow library may mean finding the meaningful “more important” work for librarians to do. We need to consider developing some things on our own — things that make sense for librarians to do, like architecting information, informing the design process and by gonnit, imagining a better OPAC!