Browsed by
Category: Project Management Series

Project Management for Librarians: Stakeholder Analysis

Project Management for Librarians: Stakeholder Analysis

I have a Stakeholder Analysis spreadsheet, but it’s very very simple and I’m considering revamping it based on what I’ve recently discovered. Once I have something that works, I’ll share it. Currently, it looks something like this: (column 1) Name, (column 2) Role, (column 3) Interest in Project. You can probably make this yourself, use Google Docs to make it easier to share.

What’s a stakeholder? It’s anyone who has a stake in your project. Who are people who are going to be involved in your project? Who’s your project team? Who’s your project manager? Who are the people you will go to for sign off at various stages along the way? In my experience, these are the easiest questions to answer, but I’ve seen over and over how people fail to answer these basic questions. So let’s get that out of the way.

You need a project manager. The project manager is the one who usually creates and updates these documents I’m sharing (though not alone, and not necessarily, those are tasks that can be shared). The project manager schedules the meetings and keeps an eye on the timeline. Personally, I’m a hyper-creative type, and I love having a good project manager. It’s a huge weight off my shoulders to have someone else take care of the little details. Project management tasks are organizational, primarily, making sure the Is are dotted and the Ts are crossed, so to speak. But having a project management role doesn’t mean you can’t also be wildly creative; you just schedule the time to do it. Wild creativity has an important role in any project, and as the project manager you can build time for it into the schedule of the project. The crazy blue sky phase comes at the beginning, and once the project is set up, you’re welcome to engage in it. While the project manager has a leadership role, it’s not an authoritarian one. Just time- and goal-management.

You also have gatekeepers. These are the people who do have an authoritarian role in your project, the ones who will look at your proposed solutions and say yay or nay, the ones who authorize other people’s time and any budget you may have. You really can’t get started at all without knowing who your gatekeepers are. In my world, the chief librarian is always the primary gatekeeper, since we are all her resources, essentially. But I usually have other gatekeepers who are more deeply involved in the project, who make decisions in the chief librarian’s stead. That might be an associate chief librarian, or a unit manager. For me determining who this person is is pretty paramount. Without knowing who this person is, I don’t know who to ask about starting the project in the first place. My gatekeepers have so far never been on my project team, however. They don’t attend our checkin meetings. We bring our solutions to the gatekeeper when we’re good and ready.

Your project team are the people who have allotted time to do work on this project. That work might be intellectual, not code or otherwise. I have done projects entirely on my own, and to be honest with you I hate it. Sure, I have all the control over my time and commitments, but I find it deflating not to have a team to bounce ideas off. Your project team are the people you turn to, the people who share the work with, meet with regularly, and share ideas with. The team agrees to the solution before you bring it to a gatekeeper.

Some of the key things to think about with each of these stakeholders are: how do they see their role in the project? How do you see it? What kind of commitment are you expecting from them, and do they expect from you? What are the best ways to communicate with them? Usually (in an academic context, at least) these people are the ones you see every day. How often do you want to meet with the project team? I’ve been involved in projects where we checked in daily. (My favourite projects are like this, but I’m a pathological sharer.) You might have a quick checkin meeting weekly, or every other week: to me, the best checkins are short, informal, and serve to keep everyone engaged and on the same page. Personally I look forward to these meetings, but only if everyone understands them in the same spirit I do. So it’s good to have a conversation about that from the start. If you want to have a weekly checkin (good idea), book them upfront. Be honest about the time commitment you’re asking from your team. It doesn’t serve anyone to pretend a project is very simple and requires all most no time at all and then try to sneak meetings in where you can. That doesn’t serve the project, and it short-changes everyone involved. Book the meetings, keep them short and on topic, and make them useful.

You meet with your gatekeepers in a more formal way, but I’ll get to that further when I get through the documents and talk a bit more about the process of working with them.

So these are your local main players: your team, the ones who have cleared part of their schedule for the project. Your gatekeepers, who approved investigating the project, and to whom you bring updates at various stages (more on the stages and the gate meetings later). That’s all fine and good, and, in my experience, the easy part.

The harder part is determining the rest of your stakeholders, the nebulous others who may or may not be all that easy to meet with. I’m speaking now from the point of view of an academic librarian. We have tons of stakeholders for any project we undertake, and I’ve discovered recently that it would do me well to consider and then constantly reconsider exactly who all my stakeholders are, and whether they are being properly and effectively communicated to.

For example: one of my projects in the last 8 months has been managing a major courseware upgrade. We didn’t do the technical upgrade ourselves, but our job was to learn how to use all the new tools, create support documents, design a new training program for faculty, answer faculty questions, communicate the change to the campus (faculty, staff and students), and make sure the changes don’t come as a surprise to anyone. So who are the stakeholders?

First there was our team: me and two of my colleagues. Our gatekeepers: my supervisor, and my colleagues’ supervisor. But obviously that’s not it. The range of further stakeholders was huge. Our faculty (all of them). Our departmental staff. The departmental chairs. The dean. TAs. The entire entire student body. The registrar’s office. Student Life. Further: the librarians, who interact with faculty every day. Our circulation staff, who answer basic student courseware questions, they need to be in the know too. Our reference staff, who answer advanced student questions. The technical staff who actually do the work on the servers: they’re invested in our work as well.

The reason I can’t share any documents on this subject is that I have a single one, and as you can see, I clearly have two major kinds of stakeholders: the ones you talk to every day, who know about your project, agreed to participate, and are pretty easily kept in the know, and then this other group that includes all the people who will be affected by the decisions that we make, who are unlikely to be direct participants in the group. But I need to think about them as stakeholders. How am I going to communicate to them? How are they going to communicate back to me? What are their needs from my project, and how am I planning to address them?

What I’ve learned recently, the revelation I’ve had about stakeholder analysis, is that I need to revisit this list often, and revisit whether or not I am meeting their immediate communication needs. Certain of these groups tends to get little attention, when in reality they are some of my closest allies in getting my work done well. I fear at times that I have neglected the rest of the librarians to the point that they don’t feel involved in the project, while in reality they are a liaison to the faculty and an understanding of this project is kind of critical to both them and me. That’s a mistake, and one I don’t want to repeat again. We tend to live in silos, and a searching stakeholder analysis is a process you can use to break them down. Any of these groups, say, the departmental chairs, may not initially see themselves as a stakeholder in my project. (That’s not the case at my institution, however, but it could happen.) I don’t have to use this language, or tell them they have a specific commitment to me and my project, but what I can do is commit to keeping them informed and taking their feedback. In our case, that meant attending a chair’s meeting and detailing our plan, accepting feedback or questions at any time, and keeping them informed of our progress. It also meant offering specific services and materials to that group. I never said the world “stakeholder”. It’s more of a reminder to me, and the team, that these people are important and we should treat them that way.

I’ve never encountered a group to whom I have offered a formal information vehicle to that has been unhappy to receive it.

At first, I understood a stakeholder analysis as a list of project team members. But now, I understand that it’s far more than that, and I schedule in points in my projects to revisit my stakeholders and consider who I am leaving out, who I could better inform, what communication tools I could use to better inform them. It might be a phone call, or a group skype meeting, or a public blog tracking the progress of the project. And that is what I now consider to be a thorough stakeholder analysis.

To do this effectively, you might need to talk to third parties and explain your project, see if they think you’ve missed anyone. I’ve been involved in projects where people we didn’t think to include provided valuable insight we should have considered earlier.

All failures are at their heart communication failures; a stakeholder analysis is how you determine, and put in writing, exactly who you need to communicate to, how, and why.

Project Management for Librarians: Risk Assessment

Project Management for Librarians: Risk Assessment

[Download the risk assessment document template]

[youtube http://www.youtube.com/watch?v=jDEnh1hJKkQ&fs=1&hl=en_US]

Risk assessment is clearly an art I haven’t entirely mastered yet, but even at my novice stage it’s helpful, primarily because it gets you thinking about what you’ll do in the case of an imminent failure. It puts the possibility of failure on the table, and forces you to talk it over with your supervisor, your stakeholders, and your team. Even when you don’t anticipate the particular risk you end up facing, you’ve probably brainstormed enough mitigating and contingent actions that it won’t take you long to construct a new one on the fly. It also introduces the tools and language to kill your project when it’s limping toward failure, since you have built in all the parachute points at an early stage.

I had to shelve the project the model risk assessment in the video was written for in the face of a risk I did not anticipate. It’s still not a failure; it’s just shelved until the risk event is past. The team were grateful when I raised the issue and suggested shelving it, because it saved everyone the pain of a public flop. No hard feelings! These things happen! We will regroup at a later date!

Download this tool and use it; make a better video than I did!

Project Management for Librarians: Scope

Project Management for Librarians: Scope

[Download the Scope Document Template]

[youtube http://www.youtube.com/watch?v=QP6PF96m374&fs=1&hl=en_US]

In sum: a scope document can be your best friend. It’s a great touchstone for your first big meeting with your team and your stakeholders, because there is no document that helps clarify a project more than a scope doc does. I’ve had the experience a number of times now where a project really comes together in that first meeting poring over the scope doc and deciding what stays and what goes. It prompts a lot of conversation and encourages a lot of clarity. When you all agree on the content of your scope doc, you’ve got a good grounding to move forward with your project, and a good sense of what will define success and failure.

Of course, a scope doc changes along the way at first. More about that a bit later.

Project Management for Librarians: Charter

Project Management for Librarians: Charter

[Download the blank Charter document template]

[youtube http://www.youtube.com/watch?v=OcZA2rPQnPE&fs=1&hl=en_US]

In sum: you create a charter document when you first have the idea for something. It’s a very simple document that you fill out and hand to the person who authorizes the time/resources you need for your project. I never use these documents instead of talking to people though; I talk to everyone before I write the document, and also when I pass it off. The document is like a cheatsheet about the idea, the paper version of the conversation you’re having. But a charter document is open and simple enough that you aren’t locking yourself into any one solution yet. It’s just saying: hey, here’s a problem I want to address. If you’re me and incapable of keeping any bright ideas to yourself, you are probably saying way more about what you want to do with this project in person than you are in paper. But at least you’re all acknowledging that yes, you’re going to spend some time thinking about this thing, and we all agree that it’s a good idea.

If you’re concerned about being called on your use of your time, you can modify this document to include a signature area. You can get someone to physically sign off on you investigating a project. At the very very start, this is the document they would be signing off on.

A charter document is a one-off. It just gets you started on the project. The end project might look very very different than the charter, but that’s okay. We can address any changes in the project in future documents, like the scope and alternatives. But more on that later.

Project Management for Librarians Series

Project Management for Librarians Series

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