Internet Librarian 2008

Pre-conference workshop: practical project management

Posted in project management by bbstafford on October 18, 2008

Practical Project Management October 18th
Sadie Honey, Internet Strategy and Project Management Consultant CivicActions, UCSF Health Sciences Library
Kathleen Cameron, Digital Content Development Manager, UCSF Library & Center for KM
Leslie Wolf, Project Manager, California Digital Library

Participants for this workshop were an interesting group of library and IT people, including medical libraries, special libraries, government libraries, a person from Web Junction, plus myself, the one person from a public library. There were many good ideas in this workshop, and you can read them yourself in the wiki they created. The first part of this presentation was about how to organize and manage projects; how to anticipate and solve problems. They told us about specific projects that they had worked on that were spectacular failures and others that were totally successful. Overall, they said to learn from the ones that fail, and move on. In the last section, the presenters taught us how to teach the workshop to others in 4 sessions, to use this system of project management where we work. Very good, yes?

Here are my summary notes from today’s workshop, from the powerpoint presentation of the speakers. But the full version is in the wiki linked above.

A project is:
An assignment that has a beginning and an end, a temporary and one-time effort to create something unique. At the end, you may be handing off the project to others if it is an ongoing process.

Steps:

1. Find a sponsor: “If you don’t have a sponsor, you don’t have a project.” -or- if you have a project, find a sponsor as the first step. Next, create a project description template and meet with the sponsor(s) to revise the template until it is a good, workable plan. At this point, get the agreement of your sponsor, so that the project description is like a contract to accomplish the work that you plan to do. You can revise the project description as you go; write it up initially and change as needed by discussion with the stakeholders.
Comment from the presenters: “if you don’t have the details for the template, you are not ready to get started. ”

2. Write up a project description (the speakers gave us a template for project descriptions)
Review the completed document with your sponsor. To develop a project description: use of wireframes for project descriptions and whiteboards, sticky notes on the wall to gather ideas from the participants or stakeholders. Use the project template for all projects in the library, and keep track of these for historical documentation. Project documentation can be used to reference other projects, to revisit the project if changes need to be made, or for personnel evaluations.

Set up the team of stakeholders to decide how the team will be organized in terms of meetings to make sure that everyone has the current version of the plan, and process for accomplishing the goal. Hold a stakeholder’s meeting, and then meet with the stakeholders individually, as well as your sponsor individually, to organize the project. Cast your net widely for stakeholders. Start with what you can actually accomplish, divide large projects into smaller ones to accomplish work. Example: transition reference work change by deciding the end result of you would like to accomplish. Divide larger project into smaller, more manageable ones that can be accomplished most easily, and complete these first as steps to the larger set of goals. “Some projects need a detailed communication plan to accomplish the work.”

Project description template: include each of these aspects below in your project description:

  • Description: some will read no further than this 1st paragraph.
  • Scope:
    1. Stakeholders will have expectations that they don’t mention – your job is to collect these unspoken goals/assumptions of the project.
    2. Who owns the project? Include the project manager’s name.
    3. Starting and ending dates for project – anticipated.
    4. Groups or sections that will help define the project.
    5. Tools/technologies.
    6. Deliverables – perhaps people have new skills, perhaps it is a tangible project or new system.
    7. Expected outcomes
    8. Define: what is the definition of success for this project?
    9. Key milestones if known
  • What is out of scope for the project? uncover hidden expectations and state what is included
  • Stakeholders: who is needed for expertise, approval, or implementation.
  • Sponsor: who has the authority to make decisions.
  • Costs:
  • Approvals needed:
  • Opportunities and risks: – what could possibly go wrong, and how situations might change the project.

3. The Project Plan – all the steps involved to complete project:
When you have agreement for the project description, write up a “project plan” in excel with all the steps involved. The project plan includes these fields: Area (grouping of tasks), Task (manageable task), responsibility (person responsible for completion), target start date, target end date, Actual date – completed on time?, Done Y/N, Status notes (details about the project)

Your responsibility as you manage the project: -keep everyone informed of changes that effect outcomes. For example, if sections of the project are not finished as planned, note these changes in the excel chart. Often, deciding the date for starting and completion is the most difficult part, but expect that there will be changes. Think about the best-case scenario and add a little time for tasks, especially if any of the dates for sections of the project appear overly optimistic.

Be sure to add: meeting and administrative time.
Be sure to add: lag time for approvals.

Tools to keep track of projects:
– excel (best since everyone has it)
– ms project (good but more of a learning curve and people may not have it; therefore everything has to be saved as pdf to share)
– wikipedia has a good list of open-source project planning systems.

Tip: make visual forms of the project schedule – a visual timeline using excel charts.

Issues that effect projects:
Communication: send out weekly or regular updates (a brief narrative, next steps, revised plan)
Describe what is going well and not going well. Don’t just cheerlead – it’s your job to flag problems and resolve them. Ways to do this: use colors in excel for coding what is working well etc.

Issues: Slackers
– raise the flag on slackers. Talk to the person first, it that doesn’t work, then enlist the sponsor to help. Then figure out how to get the work done another way if you have to.
– meet consistently with your sponsor and enlist their help. Don’t try to be a superman or superwoman!

Issues: Lack of Participation
– weak sponsorship. It means that there isn’t general support for your project: A way to resolve: ask them why they are not participating and get advice from them directly. Comment from participant: if your stakeholder has your project on their list of “measurable outcomes” this will help insure success. Ask: “when is it reasonable for you do do this in terms of time and materials” ask a direct question. Ask people who are key persons “how can you help me accomplish this or get it completed?

Issues: Working with IT
– many of your projects will be with IT staff
– don’t be intimidated!
– functional requirements: describe what the product does. ex.: describe what you want the product to do: instead of “we want a blog” say “we want a forum, etc. that does….xyz”
– for applications, describe user roles and case scenarios. Set administrative levels for creating content and what each role does. Describe what the administrative roles are.

After the Project Completion:
market your success and make sure that your sponsor knows the successful outcomes
– hold a meeting at the conclusion to discuss what went right, what went wrong etc.
– as you do more projects, you will have more skill. Accept the projects that didn’t work, and move on.

Documentation: keep track of projects by creating a consistent process for retaining the projects the library works on. This creates a history of work that has been completed that can be shared.
Creating a consistent process prevents ‘re-inventing the wheel’ syndrome. Eases the fear of writing an reading. Creates a common language for peer to peer support.

Historical documentation should include locations of files, all the project plans, deliverables such as powerpoint presentations, handouts, etc.

For the participants in your project:
– acknowledging adult learning theory when working with groups.
– recognize that everyone has a contribution to make.
– be sure that everyone has a chance to actively participate.
– acknowledge that people may have fears about new technologies. Try to use tools that everyone is familiar with, such as excel.

Advertisements
Tagged with:

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s