By way of background, Delphine mentioned that her team has spent the last few years developing their Digital Library Architecture (DLA) in order to have a stable delivery mechanism for any and all content, across the entire library. Their goal was to get away from “one-off” solutions for each proposed digital collection that came along. They achieved this with the DLA, but the bright ideas didn’t stop there. In addition to avoiding individualized delivery platforms, they also realized that the workflows involved in moving a collection from the physical to the digital ran across the entire library, and they involved staff from virtually every library department.

This presented an opportunity to expose a wide variety of library staff to the process of digital projects development, and to start having digital library efforts perceived as a library-wide endeavor. It also offered a chance for individual staff members to pick up new skills and grow professionally.

Here’s how they took advantage of those opportunities.

They established 4 digital library project teams by format: image collections, page turning collections, catalog collections, and non-catalog collections. Each team has 4 permanent members: 1 from ITaDD, 1 web manager, 1 public services librarian, and 1 technical services librarian. Teams also have guest members, who are typically collection owners, rotating in as projects pass through the team’s workload. The public and technical services members of the teams focus primarily on tasks such as such as data mapping, gathering requirements, writing specifications and documentation, and leading meetings, and they also gain a familiarity with the ITaDD methodology of project management.

In this way, Delphine estimates that over 50 people from the library have had direct experience with the DLA and with digital library projects in the past 3 years. And some of these people have had extended and extensive experience. This is changing their effective skill set.

She has recently gotten approval for a pilot project to invite a few of the permanent members to enter into a mentoring relationship and learn the basic technical skills needed to do digital ingest. This takes things to the next level, as she says, and has the potential both for staff development and also for increasing the library’s capacity for handling new projects.

Could this model be adapted for use in your environment? What differences might it make?

When I’ve been asked this question, I’ve sometimes thought it was genuine, but just as often, I’ve sensed that the questionner is wondering when the other shoe is going to drop. In other words, he or she was actually wondering: how heavy will the burden of project management have to be? S/he sees someone calling themselves a “project manager” and s/he thinks the person is poised to impose a bunch of unnecessary and heavy-handed layers of red-tape.

I am sympathetic to this perspective. Maybe the reason is that I spent some formative years of my career studying how people actually do their work. Most of us don’t like busy work, and we don’t like having to submit reports or fill out forms just for someone else’s benefit.

The antidote to this situation is twofold. First, start from the ground up. That is to say, allow the project and program tracking artifacts and mechanisms to emerge from the team that is using them. This is the approach that Jennifer Vinopal described to me on my recent trip to New York University’s Bobst Library. Vinopal is the Librarian for Digital Scholarship Initiatives and Project Manager for NYU’s Digital Library Technology Services. She is gradually introducing a basic project management office capability a little bit at a time, as staff can see the benefit of putting in the time to submit the data. This shows a real understanding of how to introduce lasting change.

A second thought along these lines is my answer to the question with which I started this post: how long does the task list need to be? In my view, the task list, or even it’s big brother, the work breakdown schedule (WBS), needs to be only as long or as detailed as required to understand the status of the project. This is the main–and most important–purpose of the task list, and the WBS: progress monitoring.

This means that there is no one level that is right for every project, nor is the level necessarily going to be the same throughout the life of the project.  It helps to ask some questions: how are the team members finding out when and how work is getting done? Often, they are waiting for certain tasks to be completed before they can start or finish certain other tasks, so this is important information. How do they want to find this out? At what point in their workflow? Can you adjust meeting schedules and select project tools so that when you meet your information gathering needs you also meet their information gathering needs? It may not be completely possible, but it’s worth trying for, and you may be able to improve on practices that are not taking team workflows into account.