CLA Weblog Submissions
To navigate our archives, please click on a category to the left. Do you have information that would be of interest to the library community? Please send your weblog submissions to the CLA office at info@cla-net.org.
Using Project Management to Relocate Your Library
Moving a Library is a daunting task. It can be even more daunting when you are the person who is responsible for moving all the technology from one location to another.
When the Anaheim Public Library secured capital improvement funding to do an ADA retrofit of the Central Library, it fell to me to create a plan for moving the technology for Adult and Teen Services to a temporary home while expanding the Children's services in an area that would remain in place and open during the renovation. Trying to implement some of the skills I learned from my various project management courses I started putting together my project plan. I created a template that I compiled from text book examples, course outlines and other webcasts. I start with a header that appears at the top of each page with the project title. The first line of the first page contains the project start and end dates. This is when the work is to be done. Then I write the project objectives. For some this is sufficient for the project charter which would then receive management approval. I already have been given direction to proceed so I go next into the work breakdown structure.
After that we get into the main body of the document and the fun really begins. I use a work breakdown structure in an outline format that shows all the tasks that need to get done. In this case I start with relocating a network switch from the Central Library to the temporary building and assign it to the City Networking team. I brought them into the planning process early so we make sure that everyone is aboard. Here is an example of the how this outline might look:
1. Install networking hardware in the building
a. Contractor to terminate fiber connecting the building to the city network.
b. City Networking Team to test cable runs to verify existing cables will carry data
c. City Networking Team to remove Central Library Network switch from the basement and move it to the Temporary Building.
d. Run patch cords from existing patch panel to the Network Switch
The next part of the document addressed relocation of public computers to the temporary building. Now we involved City's Facility Maintenance to ensure we had sufficient electrical capacity to meet our needs. After that the staff computers, and where they were going.
I also wanted to enlist as much help as I could in relocating equipment. The company that is responsible for maintaining the public copy machines was asked to help move that equipment. But moving the security detection system was a bigger hurdle. 3M technician time was a billable expense.
That brings me to the next section of the document: the issues list. Here is where I list out any and all potential problems and concerns that need to be addressed. Sometimes these were technical issues: i.e."Old security gate must be three feet from metal objects. Also, magnetic field will interfere with computers operations for computers within eight feet." Other items were notes to management regarding cost and needs for billing information. Then there were matters that affected the public: i.e. no wireless access planned for the temporary site. The point here is to get all potential problems and concerns on paper so everyone could have input on them.
This brings me to the list of responsibilities. The next part of the document is a table which outlines who is responsible for what and their contact information.
Now this can be as extensive or short as you need it to be. You can put in your entire list of stakeholders if you want to. However, the Project Management definition of a stakeholder is "anybody who perceives they might be affected by the project." That can be a lengthy list, so you might want to limit it to critical stakeholders: those who can actually kill or withhold funding from the project.
In my case I did not need to go that route. I just needed a list of contacts that were responsible for the work and funding the work. So I included my City Networking Team lead, library staff coordinating the move to the new building, the dispatchers for 3M and other third party agents who were responsible for moving their equipment, telephone people and the City Librarian.
The final section is a comments section. This is supposed to be an open space where anyone can say anything about the upcoming project. However, in the three projects I have used this template, nobody has ever written anything in. I have had several discussions with various stakeholders that resulted in alterations to the main body of the document, but not in the comments section.
So that was the planning part of the project and then the work got done. I am in the habit of marking completion dates on this document.
Finally, everything on the list gets done. But then new issues that had not been anticipated arise. To address these items for the future, I decided to add a new section to this document. I simply call it "Issues prior to project-closing" i.e. While we changed the hours of operation in the ILS system, we neglected to do so for the self-check machine receipts. Lessons learned and project closing are usually separate documents in project management, but for my purposes, they make a fine way of ending this project document. It keeps everything in one location for easy reference.
Submitted to California Libraries by:
Thomas Edelblute
Public Access Systems Coordinator
Anaheim Public Library
The Anaheim Public Library is an Institutional Member of CLA and directly supports our advocacy programs. Click here for more information on Institutional Membership.
Posted on November 25, 2009 9:05 AM | Permalink