Train wreck at Montparnasse 1895, via Wikipedia
Library conferences can be great places to pick up new ideas, with roundtables, seminars, and sessions filled with stories of successful projects from peers, vendors, and professionals from other fields. Information from these sessions can help other libraries get started on new initiatives without having to reinvent the wheel.
But all projects involve some degree of risk, and some projects can fall apart as the result of preventable problems. At the recent Code4Lib 2013 event held at the UIC Forum at University of Illinois at Chicago, a group of librarians found during their Fail4Lib pre-conference workshop that discussing failed or problematic projects can be as constructive as discussing success.
“There’s starting to be a confluence of different types of activities along these lines,” notes Jason Casden, Lead Librarian, Digital Services Development at North Carolina State University (NCSU), who organized the pre-conference with his colleague Andreas Orphanides, NCSU’s Librarian for Digital Technologies and Learning. “Maybe attitudes are changing about how to talk about failure and its relationship to risk and its relationship to our work.”
The startup business world has even developed its own jaunty business-speak euphemism for failure, Casden noted.
“When business people say “‘pivot’ it’s basically a nicer way of talking about failure. You’re saying ‘the thing you were trying to do no longer makes sense. What do you do?’ And it’s being sold as a central part of idea development and product development process. I feel like the culture, at least around technical work, is shifting in a way that is more willing to accept failure as a part of innovative work.”
This hasn’t always been the case.
Failure “is something we don’t talk about very much. Especially in libraries, but also in IT in general,” said Fail4Lib participant Cynthia Ng, Innovative Technologies Librarian for Ryerson University Library & Archives (RULA). “I find that in public institutions, there can be this resistance to failure, I guess because they see it as having wasted resources and money. And, of course, public institutions are getting budget cuts every year.”
Ng’s personal example was an Issue Tracking System/support ticket system that RULA wanted library staff to use when they were experiencing technical problems. So far, the system has not caught on.
“We’ve had the issue tracker and the form up for more than half a year now, and I can probably count on my two hands the number of times we’ve had a staff member report an issue.”
In retrospect, she said, the pilot test of the ITS may have become too closely associated with a single project. Telling staff to use the system only for one specific project, while continuing to report all other problems in other ways, may have generated confusion and allowed old habits to become further ingrained as the system was rolled out.
“We’re trying to learn from that right now, and we’re coming out with a new approach and trying to push it again, especially now that we’ve updated to a new version and worked out how we will do it.”
The new approach will involve, in part, increased outreach efforts to explain to staff how the system works.
Getting the hang of it
“Mission-critical” projects, by definition, are not permitted to fail. But stress and confusion can be mitigated by successful planning when these types of projects arise.
Participant Becky Yoose, Discovery and Integrated Systems Librarian for Grinnell College Libraries (GCL) reviewed challenges that GCL faced when the timelines for two mission-critical projects collided during the summer of 2012. The library was working with Discovery Garden, and had planned to have an instance of digital repository Islandora ready for launch by the spring of 2012.
GCL had also signed up to be an early development partners with Innovative Interfaces Inc. for their Sierra Services Platform. When Islandora required more extensive testing prior to launch, and Sierra moved to its beta-test phase faster than GCL had anticipated, the staff suddenly found their hands full with two major projects that could not fail.
“We survived, mostly because we had planned a little bit for worst-case scenarios,” Yoose said. Contingency planning included having two project managers assigned to each project, for example. At one point, this allowed Yoose to drop out of the Islandora project and shift her focus to the Sierra project.
Overcommitting can also lead to other issues, noted Erin White, Web Systems Librarian for Virginia Commonwealth University (VCU).
While developing an instruction scheduler “as a young project manager, I didn’t know how to say ‘no,’” White said. People made lots of requests for tweaks and changes in the system, and White would take action without asking questions or standing her ground for the sake of the interface.
“It ultimately resulted in a bloated interface,” she said. “Two years after we built it, we’re still maintaining it, and I’m still cursing some of the decisions I made that allowed it to bloat. In some ways it wouldn’t be considered a failure, because it’s out there and being used heavily. But at the same time, it’s just a huge burden.”
At the pre-conference, White explained how that project had helped her learn “to look farther down the road than just getting the project complete and to look for opportunities to standardize whenever possible.”
Somewhat ironically, this inaugural Fail4Lib preconference workshop was such a success that a scheduling failure occurred. In three and a half hours, the group only made it through the first of several prepared discussion units. Casden said that the workshop may be worth revisiting next year as a result.
Yoose agreed that the workshop was productive, musing that presentations about failed or problematic projects can be useful l to others possibly because people tend to take different approaches when discussing success and failure.
Discussion of successful projects “tends to be more about the destination than the journey,” she said. “With failed projects, you focus more on the journey to that particular failure.”
Fail4Lib from Jason Casden
About Matt Enis