![]() |
|||||||||
| |
|||||||||
| you are: contents > Article 2 | Volume II, Issue 2, May 7, 2003 | ||||||||
| |
|||||||||
Advice for the First-Time Project ManagerRuth Ann Jones, Digital Projects Manager and Assistant Head, Digital & Multimedia Center, Michigan State University Libraries, jonesr@msu.edu Four years ago I found myself newly transferred to a position as project manager in the MSU Libraries' Digital Sources Center. The new position involved managing digital production for grant-funded digitization projects and developing prototypes for new project proposals. I had spent the previous eight years as a reference librarian (though with responsibility for some significant special projects), so the difference between my old and new jobs was striking. Project management as a distinct set of skills is given regular attention in the business press, and special project assignments seem to be more common among my colleagues as well, including those early in their careers. For new library professionals facing project management for the first time, these informal observations on the nature of project work might be helpful. What is Project Work?What is the different between projects and other work? Definitions in the business literature agree that the most fundamental characteristic of a project is that it has a definite ending point. This is in contrast to operational activities, which continue indefinitely into the future. References services are an easy example. They are a normal part of library operations: there may be changes in the scope of the service, the hours service is offered, or the specific staff providing the service, but the activity itself continues. Naturally, projects may be very closely entwined with operational activities. A recent project in my library has been to develop a real-time e-reference service. Once this service was established, it became an ongoing task for the reference staff -- therefore, an operational activity. Before that could happen, however, significant tasks of policy making, technical planning, and staff training had to be accomplished. These tasks had an ending date: they had to be completed before the service was scheduled to be available to the MSU community. The work of implementing a new operational activity is itself a special project. In fact, special projects affect every unit of the library. In addition to establishing a new service, typical projects may include:
Recurring but non-continuous events may have similarities with special projects as well as with normal operations. Closing acquisitions accounts at the end of the fiscal year, annual evaluation processes, or preparing budget requests are all examples of recurring events. One common thread among the examples listed above is that many of them are associated with change. Advances in technology, economic pressures, and evolution of a library's mission are all forces for change, and these conditions clearly exist in our environment. When I first became a librarian, workshops and staff development sessions on "dealing with accelerating change" were commonplace. A decade later, we seem to have adjusted to the stress somewhat! Attention has shifted, therefore -- in libraries and in the workplace generally -- toward developing skills to manage the special projects that respond to and facilitate change. How does project work compare to operations work in other ways? As one might guess, there is a good deal of common ground between the two areas: for example, giving clear directions is an important management technique in either case. And, in libraries and nonprofit settings in general, it is likely that both operational activities and special projects will be carried out on tight budgets and with limited resources. However, there are some points of divergence. These can be described as scheduling issues, "first time" issues, and the issues related to coordinating the work of multiple partners. Scheduling IssuesThe scheduling considerations for a project may be on a different scale than many librarians are accustomed to. Paradoxically, the temporary nature of projects doesn't necessarily mean the timelines are shorter, but can be the opposite. Although operations tasks continue indefinitely into the future, their actual scheduling might be done on a very short-term basis. Reference desk shifts may be scheduled a few weeks or months in advance, but never decades; a cataloger responsible for creating a certain number of records each year most likely has productivity goals in mind for the current week and month. Because the nature of the tasks changes relatively slowly, it's likely that nothing in particular needs to be done this month for the reference desk shifts you'll work in 2005. The life cycle of a project, however, often involves tasks that are diverse enough to be performed by different groups of specialists and which might have to be performed sequentially rather than concurrently. Architectural plans must be completed before building permits can be obtained; permits must be in hand before construction can begin; concrete has to be poured for a basement before the ground level walls can be built. However, interior design of a building might be done at any time between completion of the architectural plans and the point when decoration can begin, and probably will not take as long as the various stages of construction. The length of time it will take to perform all the activities that must be performed sequentially is known in project management as the critical path.
Figure 1: Schedule for moving a collection to a new location. The critical path for this project is eight weeks: the time required for weeding, loading, transporting and reshelving, tasks that must be done sequentially. The two-week task of building new shelves can be delayed up to four weeks from the start of the project before affecting the completion date. The sequential or cumulative nature of the tasks in special project may mean that the project manager has to plan the end stages of the project in a fair amount of detail many months ahead. This is an issue not only of scheduling specialized tasks, but of understanding how the early stages of work relate to the later stages. I began my very first digitization project with only a hastily acquired knowledge of XML encoding and no real understanding of how the encoded texts would be rendered for a web browser with an XSL stylesheet. The first completed texts in the project had to be redone once I understood the functionality of XSL. The situation was manageable, but could have been much worse! "First Time" IssuesAs noted above, projects are often, though not always, initiated in response to change or to prepare for change. This means they often involve unfamiliar territory for the project manager. This may be new technology, a new organizational structure, or other activities not covered in library school, like planning a building addition or producing a video. The new territory may be a first-time experience for the institution as well as the project manager. Feeling unprepared, at least initially, for the new task has been a common element among nearly all the significant projects I've been involved in. It's fortunate that librarians tend to embrace the concepts of self-education and lifelong learning, because it is often necessary for the project manager to get up to speed quickly on new areas of expertise. While the experience of sudden immersion into a new set of tasks can be quite exciting, it can also divert the project manager's attention from one of the essentials of planning a project, which is to ensure that the outcome of the project is clearly defined. A central concept of project management (indeed, all management) is the idea that achievements, not activities, are the desired outcome; another way of saying this is to emphasize results, not effort; or to define a project's outcome in terms of the benefits and deliverables it produces. A simple example is a line that appears in the annual goals-and-objectives statement of many of my colleagues (and sometimes in mine as well) -- "Keep up with professional literature." This is an activity, not an achievement. Though it might be worthwhile to invest time in professional reading, it would probably be more useful if done with a specific achievement in mind. Merely performing an activity does not constitute success. If a committee is charged to examine a certain library policy and recommend changes, their outcome has only been defined in terms of an activity. If the recommendations prove to be unacceptable to the library administration, the committee may have "done its job" but no progress has been made toward solving the situation that caused the committee to be formed in the first place. By contrast, if the committee's charge is to develop recommendations that are acceptable to all stakeholder groups, the work might be approached in a different way: perhaps with more attention to consultation or compromise. If in doubt, how can you tell if your project goals are expressed as activities or achievements? Here's where the business-speak about deliverables and benefits is helpful. The deliverables for a project are what will be accomplished or produced. The benefits are the effect of the deliverables on a situation or on groups of people such as staff or patrons. In a digitization project, the deliverable might be defined as making available on the web 50 historic cookbooks with supplementary material for students. The associated benefit would be the usefulness of this resource in K-12 classrooms, which would have to be proven or demonstrated in some way. One concern I have heard expressed several times is that concentrating on results rather than effort creates an atmosphere where risk-taking is unsafe: staff will be penalized more for failure than for lack of results. Certainly this is a possibility. But, the opposite situation can also be risky. If project sponsors do not clearly define the desired results of a project, a likely result is that work will have be repeated when the result is not what the sponsor had in mind. Another reason to focus on results rather than effort is that outcome-based evaluation is becoming the norm in, at least, the world of grant-funded projects with which I am familiar. "Libraries change lives" has to be more than a slogan; it must be something we can demonstrate. Coordinating the Work of Multiple PartnersCoordinating the work of other people can sometimes be the most challenging aspect of project management, especially for relatively new librarians who may not have significant management responsibilities as part of their normal duties. Why is this the case? The administrative structure of most libraries (and other institutions) is based on functional divisions. In a library, the staff whose work is related to technical services usually form one administrative division. The staff who perform acquisitions, cataloging, and processing likely represent administrative units under the tech services umbrella. Managers of operational units, for the most part, direct the work of people whose duties are well known to them and over whom they have some authority. By contrast, special projects often involve staff from different functional areas of the library. One of the projects mentioned above was establishing a real-time e-reference service. The tasks of policy-making, technical development and training involved staff from the reference department, the systems office, and the outreach unit responsible for serving remote patrons, among others. In this type of situation, the project manager must coordinate the work of staff whose duties are less familiar and over whom he or she does not have direct authority. This can be intimidating. In an ideal world, our colleagues would all be easy to work with and we would all have plenty of time to do the work we are assigned. In the real world, we may sometimes encounter a lack of collegiality or coworkers who have, like us, too many duties claiming their attention. There are no magic solutions to this issue. Negotiation skills are useful, and a talent for networking can be particularly valuable since building contacts outside one's own department is likely to be useful in projects involving staff from different units. Most important, though, is to remember that special projects generally do not originate with the project manager, but are initiated higher up in the organization. The project "sponsor" is the person who wants the project to happen and has the organizational influence to direct money and resources to its completion. If networking and negotiation fail, the project manager is well advised to let the project sponsor know about obstacles rather than risk an unsuccessful outcome. Go Forth and ManageThe most stimulating and rewarding experiences of my library career have all been related to work on special projects. The benefits of this type of work include the challenge of exploring new territory, the chance to work with staff from diverse specialties, and the opportunity of greatly broadening one's range of experience... not to mention the excitement of working in the spotlight under short deadlines! Every project is a learning experience and offers prospects for professional growth. |
|||||||||