Part 2: Managing the Project
What Is Project Management?
Let us begin by asking, "What is a project?" A project's main characteristic is that it is intended to accomplish something unique; in other words, a project is always a special project, something that is done only once. Even if you choose a new CMS every five or ten years, it's not the same project each time, as the requirements and situation will differ greatly. Projects are thus distinguished from operations, which are by definition repetitive.
Because projects are unique, each one is a new situation for the project manager. Three important implications are:
Because there is so much new, the critical job for the project manager is to focus on the process enough for it to succeed, but not so much that the substantive goals of the project are neglected.
Now we can answer the question, "What is project management?" Clearly it is that branch of management that deals with unique, one-off situations. This uniqueness is the central problem for managing projects:
Project management (PM) is not primarily a body of theory, although theories abound in management literature. Instead, you need to know a few basic approaches and techniques and the discipline to apply them; plus you need quick perceptions of people and situations and you need the courage to change what is not working, whether it is the procedures or the people.
PM is down in the trenches. No project is perfect, either in its day-to-day methods or in its final results, but good project management will ensure that problems are caught and corrected while they are still small. In other words, you won't win all the battles; concentrate on winning the war.
What Is Success?
What does it mean for a project to succeed? Later we will see how to prepare a written statement of goals for the project; clearly one definition of success is that these goals are met. But we have all known cases where formal goals were met but the project was still perceived as a failure, as well as the contrary case where the project did not meet its stated goals but everyone was happy with it.
What is the project?
Let me guess that you may be confused at this point as to what "the project" is. If you are choosing a new CMS, which is the real project, the planning phase or the implementation phase? In fact there are two projects here. The planning for the system is one project, and the implementation of the system is another. Often we speak of these as one big project, and often the same people are involved in both, but it is impossible to consider them a single project for this reason: until you finish the planning phase you do not have the knowledge to develop goals, schedule, or budget for the implementation phase, so it cannot be a defined project until the planning phase is over.
This suggests a practical way to scope projects which may have more than one phase: the current project is that part for which you can develop written goals, schedules, and budgets, and one of the goals of the current project will be to gather the information to plan the next phase, which will be a new project.
Thus I want to give you this very simple definition of success: meeting expectations.
Each of the two words has powerful implications. "Expectations" implies that certain results have been conceived of in the minds of others, and "meeting" implies that these results are delivered. Thus as project manager you must ensure that the right expectations are planted in the minds of your colleagues, and then you must fulfill them.
Let's get a little more specific about expectations. A project is defined by three things: its technical goals, its schedule, and its cost. These three are components of every project, from planning a computer system to building an aircraft carrier.
Now that we have defined expectations in terms of goals, schedule, and cost, we can be more precise about what we mean by success:
A successful project:
What if these expectations are not met? Well, there's a problem, but it is not always obvious what the problem is. For example, if there is a cost overrun on a project, there MAY have been poor cost control (failure in execution). But it is just a possible that the original budget was infeasible (failure in planning). Or there may have been technical problems that impacted the schedule and thus the budget. Or external forces may have caused problems. The lesson is that a project can go wrong in many ways, so constant vigilance is required. We will return to this when we discuss the evaluation of projects.
Planning a Project
You may be wondering how project planning relates to the planning discussed in the previous article. The answer is that most planning proceeds in a top-down manner, from generalities to specifics. In the last article we discussed broad questions of stakeholders, project participants, and scaling the planning to the problem. We hope you acquired a general knowledge of what planning is and how to do it.
In this article, we will be more specific. We will outline the specific steps to plan any project. Although we do not believe in cookbook approaches for the substantive planning, here we are addressing the mechanical aspects of managing projects, which can be generalized to any project.
The following steps will be the initial work of the Planning Team. Whether this is done before or after the kickoff meeting with the Steering Committee depends on your situation. If done before, it provides an excellent agenda for the kickoff meeting, but it may be more politic to focus the kickoff meeting on team-building instead.
Steps In Planning a Project
Let's name our project to give it an identity. This gives the project visibility and credibility both for the participants and throughout the museum.
Now comes the hard part. You must describe in some detail the goals, schedule, and cost of the project. We suggest that you outline this now, and refine it several times as you perform the later steps.
There are three keywords to keep in mind as you do this: Realistic, Concrete, Written.
First, you must be realistic. Don't promise more than is feasible, or you will raise expectations which cannot be met (remember that success is meeting expectations). This applies to the goals, the schedule, and the budget.
It is easier to be realistic if you are concrete. Don't just say you will choose a new CMS. Instead, say you will evaluate the needs for a CMS, survey the market, perform comparative evaluations (or an RFP), meet with colleagues at other museums, etc. Stating the broad functions of the CMS you are planning will prevent unwarranted expectations that it will do things you are not planning for. Likewise be concrete in your schedule and budget.
Finally, the goals, schedule, and budget must be written. This is your main weapon in combating unrealistic expectations. And make sure the written document is circulated widely, at least to the Steering Committee but perhaps throughout the museum. Otherwise some people will believe you are going to solve every problem they have. A written document is also the best way to get management concurrence on the schedule and budget -- if not formally at least tacitly.
We discussed the reasons for stakeholder analysis in the previous article. Now you must sit down and do it.
To review, the purpose of stakeholder analysis is to make sure that all relevant needs are considered in the planning. Stakeholders are those persons or groups inside or outside the organization who will be affected by the new system. The previous article suggested some stakeholders you may not think of.
And don't forget perhaps the most important stakeholder: the future needs of the organization. You must think about what your colleagues 20 years in the future will need from your work. You know what you think about the systems that were implemented 20 years ago; you want to avoid similar comments by your future colleagues! This inevitably raises the issue of standards, which are a way to protect your investment into the future. (We will discuss standards in a later article.)
The Team needs to ask itself, Who are the persons and groups who will be affected by this system? For whom are you doing the project? Who are the users and how will they use the system? This analysis will later help you make specific decisions such as image resolution.
Finally, decide how the needs of each stakeholder will be represented. Some will be represented by members of the Project Team, some by the Steering Committee. Others can be brought in during testing or prototype evaluation, focus groups, etc. Some may need representation only at certain stages of project.
How will the project be done? Will you do a pilot project? Build a prototype? Use contractors? Develop an RFP? What tools and methodologies will you use? Formal or informal? What constraints apply? How will you test/implement? What documentation is required? What implications will the project have for the organization?
Obviously these questions depend on what kind of project you are planning. We do not imagine you will be able to answer them all in a single meeting, but they must be answered before you can develop a schedule and budget.
By now you have probably chosen a project manager. Usually this is based on the job title, so that a CMS project will be managed by the collections manager or registrar.
But we recommend you consider whether there are other roles that should be assigned. For example, if you are the sponsor or main customer of the new system, you are much too emotionally involved to manage the process as well as the content. You have to realize that your success will depend on having open, participatory meetings and encouraging a wide range of opinions. This is far easier if someone else does it. You can't be impartial and committed at the same time -- we're just not built that way.
Thus you may want to designate someone else as the facilitator. The facilitator has these responsibilities: to call meetings, to run meetings, to maintain records, and to arbitrate differences of opinion. His/her primary role is to focus on the process and methodology needed to achieve good planning and a good system.
Ideally, this should be someone not otherwise connected with the project, preferably someone outside the organization. Of course, few museums have the budget to hire such a person. Instead, choose a calm, fair, supportive person to manage the process, leaving the Team free to focus on the technical issues. Needless to say, the facilitator will not be able to participate in the technical discussion as well as managing the process, so it should be someone who is not a stakeholder. It need not even be a museum professional.
Another role to consider is a project librarian, to maintain the immense amount of paper you will soon be accumulating. Usually someone is a natural for this. This is best done by a member of the Project Team rather than a secretary, as knowledge of the Team's work is necessary.
A secretary is another role that can save the Team time. There will be endless meetings, documents to format and copy, travel to other museums, and visits by vendors. Although probably not a full-time job, this is a critical role.
Other good questions about roles concern the record-keeping functions. Who will be responsible for recording meetings? (Normally this should be the facilitator, if you have one.) What about preparing documents? Preparing the monthly monitoring of goals, schedule, and budget? Preparing the monthly presentation to the Steering Committee? We suggest assigning such roles to Team members rather than having the project manager do everything: participation fosters commitment.
Because each project is unique, it is not enough to organize it and hope for the best, Instead, the project must be monitored throughout its life. The Project Team must develop ways to monitor progress in all three areas: goals, schedule, and cost.
Schedule and cost monitoring are relatively easy. However, we must emphasize that in order to monitor a schedule, the tasks must be relatively small and discrete. A gigantic task like "evaluate systems" can take six months or more, so is useless in monitoring. Instead, break it down into tasks that take two weeks or less. (The schedule will be based on the Task Plan, discussed below.)
Monitoring goals is much harder, as it consists of making sure the deliverables of the project are of high quality. No simple system will ensure this, but our best advice is the "reality check" discussed in the previous article. You need to look at each deliverable and ask if it meets the goals for that deliverable. (Deliverables are also part of the Task Plan.)
We discuss monitoring in more detail below.
As you proceed with the project, you undoubtedly will face situations where new policy is needed or old policy must be modified. You need to think about how to handle these situations. The most logical way is to put policy issues on the agenda of the monthly meetings with the Steering Committee. This is one of the primary roles of the Steering Committee, and discussions of how the new system will affect policy not only benefit the project, but keep it everyone informed.
Before you proceed to the most detailed level of planning in the next step, you need to evaluate the feasibility of the project. By this time you know what you plan to accomplish, and have some idea of the schedule and budget requirements. Now you need to see if the project should be done as you have designed it, or whether it should be redesigned to increase the likelihood of success. This is a major topic that we discuss in the next section.
Depending on the outcome of the feasibility study, you may need to go back to step 2 and revise the goals, then proceed again through steps 3 through 8. Continue iterating until everyone agrees the project is feasible as designed.
Once you have successfully concluded step 8 (which may take several iterations), the final step in defining the project is to develop the Task Plan. This starts out as a list of tasks to be done in order to complete the project. Then each task acquires the following additional details: task descriptions, its dependencies on other tasks, start and end dates, deliverables, who is it assigned to, and budget. We recommend that every task have a written deliverable; even if the task is something like site visits, a document is often appropriate to serve as a summary of the results of the activity.
|Do you remember we said earlier that you really don't have to know what you're doing, as long as you follow a good methodology? This iterative technique is the methodology that will enable you to plan your project well. It will take far more time that you think it should, perhaps even weeks, but there is no shortcut. When you finish, you will be amazed at the degree of understanding you will have, and how little you knew before you did this.|
Clearly this is a job that software can help with, and any of the PM software packages will serve. Software is especially recommended to study task dependencies. Be prepared to devote several days on this process to do it right (yes days; the more you work on it the more you will learn about the project). You will definitely receive some surprises if it is done thoroughly. Some of these surprises may require the Team to revisit steps 2 through 8 all over again.
PM software includes ways to evaluate workload, so you can see whether anyone is being asked to work more hours than there are in a day. We have found this feature completely useless in planning professional workloads. It is just not possible to determine ahead of time how long professional tasks will take, and how much time professionals will have available. Instead, use your judgment in avoiding impossible deadlines.
Evaluating Costs, Benefits, and Risk
A central question for management is, "How do we know the project is worth doing?" This is somewhat different from the question we have been focused on up to now, "How can we make the project succeed?" In other words, we are shifting our attention from ensuring the project delivers good results to ensuring its results are worth delivering.
This evaluation is step 8 of the procedure outlined above.
Presumably if you have reached step 8, management has decided that the project is indeed worth doing. In museums these decisions are usually reached without any formal analysis of the type we are discussing. However, your job as project manager is to ensure that the project delivers maximum benefits with minimum costs and risks. Thus you can use this analysis to answer the question, "How can this project be as valuable as possible?" By analyzing the benefits, costs, and risks, you can redesign the project for maximum value.
In benefit-cost analysis (also called cost-benefit analysis), benefits are of three types:
When describing a project's benefits, I recommend you describe them in these categories, in this order. Thus you will develop a reputation for being both hard-headed and seeing the big picture.
As with benefits, costs can be monetary, measurable, or intangible. However, unlike benefits, only the dollar costs are normally of interest to museums.
Monetary costs can be direct or indirect. Direct costs are the salaries, equipment, and other costs that are specific to the project. Indirect costs are things like utilities, administrative costs, and others that cannot easily be calculated for a single project. Usually these are quantified by taking a percentage of the direct costs. In museums, direct costs are usually the only ones considered.
One of the most important aspects of PM is knowing how to configure a project to reduce its risk of failure. Over the past several years, Systems Planning has been developing a model for the evaluation of technology-based projects. The model consists of six factors that you must consider when determining the risk of a specific project.
An article on this technique is available on our website as "Risk Factors in Technology Projects". We recommend you read this before continuing this article.
The three-legged stool
We assume that you have by now outlined the benefits, costs, and risk of the project. What do you do with this?
Benefits, Costs, and Risk are three legs of a stool on which a project must balance. While the relationship between costs and benefits may be obvious, the effect of risk is less so. High risk must promise high rewards, in management as well as in investment.
This can be more formally stated as the following rule:
Thus reasonable efforts should be made to increase the benefits, lower the cost, and lower the risk. Consideration of the three together can help determine how to adjust a project to be more acceptable. For example:
Costs too much
Too little benefit
However, it is possible to go too far with this. By trying to increase the benefits more than reasonable, there is a risk of the scope of the project's getting out of hand. Reducing costs too far can lead to inefficiencies (such as not having clerical support). Reducing risk too far can compromise the goals of the project.
An example of reducing risk too far is this. Obviously it is less risky to use older technologies than newer ones. But reducing risk by using only old technology may lead to inefficiency. New tools are developed because they permit more benefits to be achieved per unit cost. To take an obvious example, the labor cost of entering data into a database is about the same as (or even less than) typing the data on slips of paper, but the database provides benefits the slips do not. So be aware that using old technology may mean you have tried to reduce risk too far. A good rule is to use "current" technology (neither old nor new) for your major systems.
As said before, the greatest benefit of all comes from doing the analysis, no matter what use you make of it. Further, we want to emphasize that management judgment is always required when using these kinds of numerical scores to make decisions.
There's no substitute for periodic formal review of the project, in which the project leader or Team spends some time reviewing the progress toward the goals, the schedule, and the budget. The focus should of course not be on assigning blame but on identifying problems and solving them. Look for root causes of problems and try to prevent them in future (for example, non-attendance at project meetings may be causing communications problems).
We suggest you use the risk factors to evaluate causes of problems and find solutions. For example, if decisions cannot be made, or communications problems are taking most of the Team's time, or meetings are impossible to set up, perhaps there are just too many people involved. By looking at the risk factors, possible solution may suggest themselves. Perhaps you have a long-linked activity and should redefine the project to be intensive? Perhaps your Team lacks sufficient experience and you need to hire a consultant or get a different one?
To monitor the deliverables, perform the "reality check" described earlier. (We hope you defined a deliverable for each task, as recommended in the Task Plan.) During the review, the Team should ask itself, Did this deliverable meet the needs? Again, the goal is not a simple yes/no answer, but a search for patterns of problems that can be prevented. One good warning sign is deliverables that are never quite complete. Certainly we have often recommended going back to redo steps in the planning where necessary, but on the other hand, incomplete products can hamper success. For example, if you never complete the analysis of users of the system, you will not be able to have confidence in your requirements statement.
Monitoring the schedule is rather hard also. It requires prediction of schedule implications based on the present state. The more you have broken tasks into small parts, the easier this is. Ongoing use of the project-management software is an excellent way to predict schedule problems, as it will recalculate the completion date based on actual progress to date.
Monitoring the budget is easier, because everyone understands money. We know a dollar is not flexible, but somehow we feel a week is!
Remember, the purpose of monitoring is not just to compare progress against expectations, but to identify and correct problems. We used the example above of a cost overrun, which could have resulted from poor cost control, poor planning, technical problems, or external forces. A similar list of reasons could be made for schedule problems or problems with deliverables. In each case, the Team should identify the root causes (not the symptoms) and brainstorm ways to prevent the problem in future.
The evaluation of the project, once complete, is not for the benefit of the project, but for you as a project manager. It is part of your education.
The final evaluation should be done in private: its purpose is to learn, not to assign blame. Write down what went right, what went wrong. Then find reasons for these. How could problems have been reduced? Could planning have been better? Could risk have been reduced? Could monitoring have been improved? Was the planning/monitoring scaled to the project correctly?