librarycampwest

 

Project Management in Libraries

Page history last edited by William Tietjen 1 yr ago

Project Management in Libraries

 

Discussion Leader: William.Tietjen@ucdenver.edu

Flip-Chart Author: Thank you,  Rachel            

Notes to Be Added: Thank you!  Maura McGrath  mamcgrat@du.edu

Laptop Notes to Add: Thank you, Jim CO State Library

Level of Interest: 25 attendees

 

 

Documentation: Web site: http://home.comcast.net/~projectmgmt/pmbasics.htm

 

Other Documentation: Agenda partial list for the discussion]

 

What Projects Are About [An outline and incomplete list: See: http://www.hyperthot.com/pm_fazes.htm ]

 

  1. Initiating
  2. Planning
  3. Executing and Controlling
  4. Closure

 

 

AGENDA AD HOC [ Based on Rachel's Chart Notes ] FOR TODAY'S MEETING October 10, 2008

 

 

 

  • Definition of a Project - "Every Project Has or should have a definite Beginning and an End" -
    • Projects are temporary endeavors undertaken to create a unique product or service
    • Projects use resources

 

    • Projects cause change
    • Projects should meet pre-established goals for cost, schedule, quality

 

 

Project Management is about....

 

  • Documentation
  • Accountability
  • Communication

 

  • Sponsorship
  • Stakeholder Management
  • Project Scope
  • Unexpected Events
  • After Close-Out
  • Conversion to Maintenance Mode
  • Tools, Techniques, Best Practices

 

 

 

Discussion Notes from the Agenda including enhancements and addt'l resources

 

 

How Projects Are Often Sourced In Libraries

 

  • Based on the Library's Strategic Plan [n....1] List or Priorities
  • Director May Bring Ideas
  • Stakeholders or Executive Committees
  • Customers or Clients - Based on Needs Assessments
  • Based on a Feasibility Study

 

 

Sponsorship is Fundamental - Every Project Needs One

 

  • Gives the Project Legitimacy or "A Charter" to Act
  • A sponsor acts as "champion or advocate" for resources
  • May help Project Manager overcome conflicts
  • May help with Issue Escalation
  • Coaches Project Manager as Needed
  • Provides Guidance for Key Decisions
  • May Influence Stakeholder Groups

 

 

Feasibility Study Components some examples

 

  • Staffing levels
  • $$$ - Budget
  • Community Needs
  • Cost / Benefit Impact
  • Sponsor Role - For Deliverables
  • Risk Assessment [Reasonabel vs. Crazy]
  • Change Control Methods
  • Training and Education Components
  • Goal Alignment - Between the Project and the Organization
  • Value Analysis

 

 

Scope and its close relative, Scope Creep      http://www.prosci.com/tutorial-project-plan-mod2.htm

 

Scope Is....          

 

 

  • What We Are Going to Do
  • What We Are Not Going to Do
  • Measure of Success MOS

 

The project scope is the boundary that tells where the project begins and ends. Throughout the charter of the project and discussions about the business problems and opportunities, you may feel that everyone is viewing the project the same. However, many times there is confusion about what falls inside the boundary of this specific project and what does not.

 

....A common mistake made by project teams is to define their project scope only in general terms. This lack of definition causes managers and key stakeholders throughout the organization to make assumptions related to their own processes or systems falling inside or outside of the scope of the project. Then later, after significant work has been completed by the project team, some managers are surprised to learn that their assumptions were not correct, resulting in problems for the project team. Other project teams report problems with "scope creep" as their project gradually takes on more and more work....

 

 

Scope Includes and is impacted by the use of Public Service and Business Models   

 

 

  • Documentation that Supports
  • Budget Outlays
  • Accountability
  • Keeping track of responsibilities
  • Transfer of Information - to End Users, Staff, Stakeholders, Sponsors
  • Modeling for Business Systems or Work Processes Workflow
  • Resources Needed
  • Training
  • Customer Satisfaction Objectives
  • Establish Project Milestones
  • Selection of Project Team

 

 

 

Requirements - High Level          http://www.philosophe.com/design/requirements.html

 

 

Planners cast most requirements in functional terms, leaving design and implementation details to the developers. They may specify price, performance, and reliability objectives in fine detail, along with some aspects of the user interface. Sometimes, they describe their objectives more precisely than realistically

 

The term requirements may be overused. At a high level it refers to a general set of documents that describe what a project is supposed to accomplish and how the project is supposed to be created and implemented. Such a general set of requirements would include documents spelling out the various requirements for the project -- the "what" -- as well as specifications documents spelling out the rules for creating and developing the project -- the "how".

 

A Specification is a requirement that defines an objective and may include:

 

Requirements - Detailed sample list

 

  • Specifications to Design or Build
  • Customer Service Interface or Impact
  • Human Resources
  • Tools or Software Needed
  • Compatibility with Other Library Systems
  • Time to Complete and Train Staff or End Users
  • Prototyping
    • How does this look to customer or patron? Human Factors
    • How do we test it?

 

Project Kickoff

 

  • Identify Leaders, Stakeholders, Sponsors
  • Create the Vision [e.g. 30 second elevator speech re the project for use by Project Team Members]
  • Identify Measure of Success - SEE SCOPE above]
  • Introduce Project Team

 

 

Implementation and Project Execution sample list of possible components http://home.comcast.net/~projectmgmt/duties.htm 

 

 

 

Gate Review Process - Example of Phase Gate Review    http://www.npd-solutions.com/phasereview.html

 

A Management Oriented Review - Key Focus    http://www.npd-solutions.com/reviews.html

 

 

The first mechanism is a management-oriented review occurring at the end of a logical project phase. This type of review is referred to as a gate review, phase-gate review, phase review or phase approval. This review assesses that the project is worthy of continuation and that risks are manageable. It approves the expenditure of resources to continue with the project. The term "gate" implies that the project must go through this step in order to continue on. The typical timing of phase-gate reviews is shown in the project phase diagram

 

Gate Review Elements                      

 

  • Milestones
  • Go / No Go Points
  • Program Approval
  • Design Approval
  • Pilot Approval
  • Gap Analysis and Report During Project
    • BCWP - Budgeted Cost of Work Performed
    • ACWP - Actual Cost of Work Performed
  • Formal, Standardized and Uniform Process
  • Testing or Prototyping

 

 

Project Delivery or Deployment

 

  • Punchlist or Close Out Form
  • Method of Procedure MOP for
  • Rollout Plan
  • Rollback Plan
  • Recovery Plan
  • Client or Sponsor Acceptance and Signoff IMPORTANT

 

 

Project Closeout

 

  • Reward and Recognition for Project Team Members
  • Closeout and Review Meeting
  • Lessons Learned Meeting
  • Completion of Billing and Administration
  • Delivery of Project Documentation Archiving
  • CELEBRATE !

 

 

 Is There A Need to Share.   Yes !

 

  • Introducing the Discipline of Project Management
  • Who Is the Champion in Organization for PM ?
  • Demonstration of Value of PM in Libraries
  • Need for a Project Management "Lite" Version for Libraries
  • Education and Training: http://www.pmi.org Project Management Institute International

 

 

 

Bringing Project Managment to Library Organizations

 

INTERESTED IN LEARNING MORE ABOUT HOW PROJECT MANAGEMENT CAN WORK FOR YOUR LIBRARY ?

 

CONTACT THE CONFERENCE PARTICIPANTS LISTED ON THIS PAGE !

 

EXPRESS YOUR INTEREST IN FORMING A PROJECT MANAGEMENT IN LIBRARIES USER GROUP PMUG HERE !**

 

 

 

 

 

 

Additional Notes from the session:

Project Management

 

William was the moderator for this session and he attempted to run the meeting like a project meeting by setting an agenda and keeping track of time. The purpose of the agenda was to keep the discussion on track. William also passed out three handouts

 

Project Management is about “documentation” and “accountability”

 

The basics of project management:

- bound in time

- have a beginning and an end

- has sponsorship

 

Sponsorship is buy-in by the administration, everyone on the team and not on the team

 

We did not discuss construction project management because it is a whole different animal

 

We asked:

 

How did the project get started?

- looking for that that fit in their strategic plan

- N through 1 – I have so many things to do

- A forward thinking director, the director has an idea and other work through it

- Needs assessment of the library community

- Everyone does it, but the process is not formalized

 

Who is the facilitator?

- The director sometimes, but not always

 

In the beginning a feasibility study (seeing if the project would work or not) is a good idea

- Do you have the staff?

- Do you have the money?

- What is the cost/benefit?

 

Always make sure that the sponsor says exactly what the objectives, deliverables are and that the sponsors have a role in the project, deliverables are very important

 

Conduct risk assessment—is this a project that has a reasonable level of risk? We need to have a check list in our minds

 

Address change management, training/education

- need to address how to get people along with you

- if change occurs in the middle of the project, make sure that everyone agrees with the change

- rework

 

- Budget

 

Under feasibility

- that goals are aligned under original goals

- value analysis

- takes time, energy and people wanting to do it

 

Value concepts may change along the way

 

Scope and its companion scope creep

 

A few areas to address

- How many do projects w/out documentation?

- Documentation is done but not made official

- Documentation does give accountability

- Documentation for knowledge transfer

- Transfer of responsibility and information

 

Scope- how big is this project? What will we do? What do we want to do?

Scope feeds into budgeting

At some point the end users need to know

Need some way to determine how resources are assigned to the project

- Does the project manager decide?

- The volunteer method

- The volunt-told method

Resources are not assigned until the rest is figured out

 

Reverse engineering- go back into it

 

Project in an informal environment no one takes time to go through

 

In libraries get a “double whammy” b/c many people make intuitive decisions

Is this due to people w/o understanding budget?

People tend to be public servants not used to quantifying w/ cost and time

 

People in power are librarians—

Our decision makers do not have training of management

Need business model in place

 

When doing projects

The requirements of the project on the deliverables and on the project

 

Requirements for PM

- HR

- Tools

- Resources

- Time

Compatibility how to work w/ a certain system (hardware & software)

Detailed requirements have to be agreed to by the stakeholders

- Prototyping

o If this is a public service how do we test it w/ the users

o How does this look?

o How do we test

- Communication

- Make sure you have communicated so that someone doesn’t come along and ant to change

o Stakeholder management

 

Along the lines of scope-

How do we know when we’ve succeeded? A measure of success is the deliverables, the blue print for getting there

 

Once everything is set to do the project—

How do you kick off the project?

- Identify who are the decision makers

- Create the vision and the 30 sec elevator speech that becomes your mantra, what we are doing and why we are doing it

- Schedule milestones

 

Can you have a project team w/out a project manager? No manager makes it a committee

Can the model be less hierarchal? Of it will start that way then someone begins to run the show, you do need to have someone leading, co project managers might work in a cross-team setting

 

Often we fall into projects

 

Implementing

- as we go along and managing the project how do we know that we’re succeeding

- Project meetings

- Assigning tasks

- PM keeps track of budget, time

 

BCWP

ACWP (actual)

 

Choosing milestones is a type of Gates Review Process

- stop and take the pulse of the project

- can be both formal and informal

- you might have one or more gate reviews

- if your organization is doing a gates review different from other department will have problems

- need to have a standardize the approach

 

The first review is before kick off – make sure that everyone agrees

Decide what elements need to go into it

 

Possibility to kill the project

Maybe the project needs to die, some need to be killed before they use up more resources

 

Does it have to be a cultural change?

 

Libraries are unwilling to kill projects, staff gets the burden (goes back to prioritization)

 

The process of publishing shows what is going on

Need buy-in with the process

 

Closing—

Close-out, prototyping, test how it works

Documentation comes back to haunt us here

- Test

- Prototype

- Instructions for users

- Go/No go

o Can we correct or do we need to stop it

o Do we know how to recover, roll it back?

- Following up in the next few weeks/months

- Have to have a meeting about lessons learned

- Recognize people for their contributions

 

Is there a need to share?

How to share?

Value of the project management

Is there an abbreviated method?

 

Project Management of Denver (pmi.org)

 

Comments (0)

You don't have permission to comment on this page.