At Internet Librarian in Monterey, Calfornia, I attended some sessions about failure. I’m a fan of sharing failures, as difficult as they are to share, so I looked forward to these. What I learned from attending them is that librarians in certain industries (academic and public, I suspect) aren’t really equipped with methods and processes to address and manage failure (or success, really). I know this particularly well because I didn’t have those methods and processes in my first couple of years either, but I was lucky enough to get a supervisor who does. She has been coaching me on project management principles ever since. I’m not exactly an expert, especially since my brain doesn’t naturally work for extended planning and organization, but I’ve worked very hard to grasp these ideas and make sense of them in my context, so I’m at least comfortable speaking about them at length.

Last night I joined the Libpunk collective’s podcast to chat about failure, and was reminded once again how desperately librarians need this process. Honestly, I sleep so much better working this way. So I’ve decided to share what I know.

To do this, I’m going to share a series of documents, along with some explanations of how to use them.

You may be wondering why the whole of my obsession with project management appears to focus on documents. I found this odd at first too. But think of it this way: the documents are a concrete version of verbal communication. Once these ideas and warnings are in paper, they are visible to everyone involved in your project and are much harder to forget or ignore. I’ve have argued that all (or at least most) failures in libraries are in fact communication failures. Documents like these are a way of taking your communication and putting it in paper form. It’s an externalized form of communication that you can refer back to and get agreement on.

The documents are also a great way to force your brain to think about your project in very concrete terms (probably the hardest part for me). They ask you to fit elements of your project in boxes that will help you keep the whole project in line, and will help you understand when and if your project is heading toward failure. They also provide the language that you need to get agreement on critical issues and deadlines, which really helps when you need to call the whole thing off or sing a victory hymn. I find it also makes the whole process official and solid, so even if a project doesn’t make it out of the early planning stages, it’s still an awesome thing that you did that ought to fit on your activity report and demonstrates great learning.

So while I’m going to talk a lot about documents as part of communicating this process, I’m really just talking about effective, consistent and constant communication.

And I say this as a person who is not naturally a planner or organizer. Working this way, with a very specific framework, has allowed me to be way more creative, oddly enough. It roots my process and lets me go off on wild tangents without burning up any of the key goal posts around me. Having a place where my creativity and crazy ideas fit and make sense (and are totally useful!) is extremely freeing.

First I will share and describe each of the documents. Then I will explain the stages you go through with them to move your project from glimmer of an idea to completion.

Documents

• Charter
• Scope
• Risk Assessment
• Stakeholder Analysis