First of all, I only realized when sitting down to this post-conference workshop that it was being led by Jennifer Vinopal of the wonderful article on project and portfolio management that I’d shared within my organization this past year. So I was very energized, which was good since I was otherwise totally exhausted coming off the end of the conference as a whole.
Vinopal did not disappoint. She is an excellent teacher and clearly knows her subject and how to present it to librarians. The context, outline, timing/pace, and the activities (a mix of alone work, pair and share, and open discussion) were very helpful for building a greater understanding of project management in libraries.
The session outline basically followed a “talk, do, discuss approach” around the following:
- project manag(er/ment) – what is it?
- project charter – documentation of the scope agreement (i.e. collaborative), which includes scope,goals,deliverables,
- project plan
- project execution
- [if time…portfolio management]
An important distinction about project management in libraries is to remember that library services are not the same as projects that never end. That is both an ill-defined project and an ill-defined understanding of service
Vinopal’s overview of the reasons projects fail (there were 8) is a good way to reveal why project management is valuable, and offers an approach for gaining organizational buy in. She observed that, as librarians, we all likely got where we are because were good doers, who are able to plan quickly. Project management, however, requires slowing down and building consensus, which are two different skills. There is an emphasis on facilitating both the work and workers involved in the project. This requires knowing your workers and what they need in all areas of project management, including (lightbulb moment for me) — communication. Her advice: Don’t force tools that don’t work. Use communication and project tracking tools that will enable you workers to work.
One of the great skills Vinopal had in her presentation was helping to translate the project manag-ese into terms that would be meaningful for libraries. We started by going around the room introducing ourselves and our planned project examples, which allowed us to identify commonalities and possible partners for our upcoming activities. Some of the project examples included:
- understanding the transition from project to process
- e-books and various related implementation projects
- a cancellation project
- a communication audit (evaluation)
- transitioning an ERMS
- a digitization project
Then, we got started on creating the project charter, aka project one-pager, project home page. Project charters need:
- a name =this may not be as simple as it seems, esp when dealing with multiple products
- description (goal)
- success criteria (assessment)
- the requirements (deliverables, optionals, and out of scope)
- who is on the project team (including roles and contact info)*
- milestones/schedule (high-level proposed dates)
*note especially the role difference b/w sponsor (finance, support, giving you authority) and stakeholder (advocate, ally)
After describing the requirements of the charter, Vinopal challenged us to think about where this information would come from. Seems like a no-brainer, but this is often when people get stuck and activate their doer over their planner. Some information resources for the charter may include:
- the sponsor and stakeholder (without promising at this stage)
- past projects
- surveys or environmental scans
- any and all correspondence and documentation (email, grant documents)
As we worked through and discussed our activities, I jotted down the some additional highlights (below).
Writing the charter. Consider the audience in the language of the charter. Your charter may include a communication plan, depending on the audience or project. Other considerations are a risk management plan which will vary as well depending on the audience
“Running Meeting Notes” are an easy way to keep notes and action by build from the bottom up. Create a home page linking to this additional documentation.
Communication plan can be an avoidance-of-risk plan and can be as simple as identifying how you communicate within the roles section of your charter.
All that matters is that you do and use what works for your organization. Microsoft Project is often overkill both for you as the planner and the audience who must follow it.
Creating tasks and setting timelines always take longer than estimate. “Make your best estimate and adjust up”. You have to talk with others in this step to determine how long certain things take. Planning Poker can be a fun (facilitation technique) way of invovling your team in estimating time.
Workflow design and redesign may be necessary within project planning.
Handoffs and triggers need to be part of the workflows. At the very least, add as a meeting agenda items to address handoffs and what’s in the pipeline.
ORGANIZATIONAL CULTURE QUESTIONS:
Responsibility without authority is ugly. View project manager as facilitator vs. task master. Organizational buy-in needed especially to the language and approach. It is helpful if someone can “be-knight you” as the project manager.
Project and Service portfolio management (PPM). Can be portfolios within organization as a whole or within just a small subset. Can be as basic as a list (inventory) of the project and services ongoing or on tap in the organization. PPM originated in business and IT; libraries may be doing it but they aren’t writing about it. Requires a good amount of buy in from the top and a governance structure for it beneath. Recommend having Project Portfolio Manager for the whole organization.
PPM can also track just who is doing things, rather than how long it is estimated to take. This may be less scary for individuals but while still giving the manager the ability to see realities.
Vinopal emailed us her complete presentation with her notes and encouraged us to contribute our projects and ideas about project management to the Crowdsources PM Toolkit.