Sometimes we start a project or create a new service and it’s an instant success. Other times, we try something and it becomes obvious that it’s not meeting patron needs. Too often though, a project is neither an obvious success or failure. Even with statistics, it can be difficult to know what constitutes success and failure. You start a blog and it gets hits but no comments and gets a lukewarm reception from patrons. You expand your reference hours and find that you get a very small number of people asking questions at that time. Yes, you’re probably benefiting a few people, but not enough to consider it worthwhile. If we had unlimited time and money, we could just keep doing these projects, but our time is often stretched so thin that we have to choose carefully what we’re going to dedicate our work time to.
I’m currently considering whether or not to close a service that I’ve been providing for about a year. While it has benefited some people, it did not have nearly the sort of results we were hoping for. If it didn’t take up much of my time, I’d just keep doing it since it does help a few people. However, it takes up about 6-8 hours of my time per week, which means that it’s really keeping me from doing other things that could be more beneficial to patrons. I’m currently looking at alternative ways of providing the same service, but it got me thinking about situations where they return isn’t commensurate with the investment.
It was wonderful synchronicity that I came upon Char Booth’s recent post (her blog is fantastic by the way) about how she and her colleagues are working to reformulate their video reference kiosk project:
Although many of the interactions we had using this model were positive, we determined that the amount of system maintenance required with the open call model was not justifiable based on the level of user need (several other service points were available near the kiosk, making it less viable in terms of utility).
Upon deciding to go with another service model for the kiosk, my boss (the head of OU Libraries’ Reference and Instruction Department) had the excellent idea of transforming it into a touchscreen welcome terminal of sorts, which would allow us to build several layers of functionality into what had been limited to basic reference.
Char and Chad Boeninger built a cool browser-based interface (since touch screens aren’t cheap). Maybe the new approach will work, maybe it won’t. But I like what Char said about it: “it’s an excellent example of trying something new with a underwhelming program instead of writing it off.” I’m definitely thinking in that direction too. Before dumping a project, we should try to find a better way to provide the same type of service. But sometimes, there is no better way and it’s hard to know when to stop a service that just isn’t providing the enough benefits.
Have you ever developed a service that wasn’t a brilliant success and not known whether to write it off or keep on keeping on? How did you determine whether it was (or wasn’t) working? What did you consider when making your final decision about whether or not to continue? We talk a lot about successes and failures, but we rarely talk about how to deal with that big gray area in between.
It’s hard to stop a service! That’s what I’ve learned — it’s just as hard to stop as to start, often because you know you’re serving a FEW users, or because it’s “better than doing nothing”. But the problem with failing to stop when you should is that you end up doing whatever it is very badly — because you know it’s not worth the effort you’re giving it. So is it somehow better to provide a badly managed service than to kill it outright?
I struggle with this one, day to day, and I suspect (hope?) many others do, as well. I wish I knew how to gather the gumption to say “No. We’re stopping this.”
thanks for the mention, meredith – it’s a good day over at infomational.
Where it’s the sort of service amenable to it, we often do a pilot project first to see what kind of interest it gets. That’d solve the problem Jenica’s talking about, because there’s a set stopping date, so the ensuing decision is not “Should we stop?” but “Should we set this up permanently?” It doesn’t necessarily help to answer that question though…
Late last year a colleague and I trialed a “laptop librarian” project (though due to dodgy-minded colleagues we called it “library on location” 🙂 ) — taking a trolley out to student cafes with popular books, DVDs, etc and a laptop to issue them with and provide reference services. Results were definitely in the grey area; I need to get together with her some time to write them up and figure out if we want to push to develop the concept some more.
Thank you, Char, for the inspiration. I get so much out of your blog and am looking forward to meeting you at Computers in Libraries.
I agree it is hard to stop a service. Kudo’s again to Meredith for recognizing that it may need to stop and being willing to stop. Should catalogers look into this (are all those marc fields needed?) Sorry I can’t help with more specifics but it sounds like you know it is time to fold them and I would bet you are right. If not, you will hear about it! 🙂 Then that is good feedback. Good luck.
6-8 hours per week!! Wow… that’s a big percentage of your time, particularly if those are 6-8 hours where you can’t do anything else. If you can’t delegate it, and it’s only benefitting a small number of people, I think I’d have to kill it of.