By Meredith Farkas | January 16, 2008
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.