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.