2.2. Create the Project PlanThe project plan defines the work that will be done on the project and who will do it. A typical project plan consists of:
The project plan is used by many people in the organization. The project manager uses it to communicate the project's status to the stakeholders and senior managers, and to plan the team's activities. The team members use it to understand the context for the work they are doing. The senior managers use it to verify that the project's cost and schedule are reasonable and under control, and that the project is being done in an efficient and cost-effective manner. The stakeholders use it to make sure that the project is on track, and that their needs are being addressed. It is important that the organization reach consensus on the project plan. To accomplish this, the plan should be inspected by the representatives of the project team, senior management, and stakeholders. Many project plans are stored simply as a folder containing a set of word processor and spreadsheet files, or are printed and stored in a binder. It is important that the project plan is periodically reviewed, and that any deviations from the plan are tracked at the review sessions. Frequent reviews are what can keep the plan from going stale and becoming a work of fiction. It's difficult, if not impossible, to build a project plan without a vision and scope document. Without it, the actions that a project manager would have to take in order to create a project plan are almost identical to those required to create the vision and scope document. For this reason, the project manager should begin the planning process by first writing a vision and scope document; all other planning activities depend on it, and the time required for the project manager to create it will pay for itself when the project plan is created. 2.2.1. Statement of WorkThe first component of the project plan is a statement of work (SOW). This is a detailed description of all of the work products that will be created over the course of the project, including who is responsible for creating each work product. The description of each work product should contain a reference to any tasks in the project schedule (see Chapter 4) in which it is involved. The vision and scope document is a useful starting point for the SOW. But the SOW serves a different purposewhile the vision and scope document talks about the rationale for the project (the needs that must be met, the list of users and stakeholders who need it built, etc.) the SOW simply contains a detailed list of the work that must be done and all of the work products that will be produced. The SOW is included as part of the project plan, but it should be a separate document that can stand on its own. It should contain each of the following:
2.2.2. Resource ListThe project plan should contain a list of all resources that will be used on the project. This list should go beyond what's covered by the project schedule by including a description of each resource, as well as any limits on that resource's availability. Most project management software packages provide a feature to maintain a resource list . If this is not available, the resource list can either be a spreadsheet or a word processor document containing a simple list, with one line per resource. The list should give each resource a name, a brief one-line description, and the availability and cost (if applicable) of the resource. All resources should be handled in the same way, regardless of type. 2.2.3. Estimates and Project ScheduleOnce the statement of work and the resource list have been created, the project manager should build a project schedule. This is usually done in several steps:
The project plan should include the complete revision history of the WBSit should contain a list of any tasks that are added, changed, or removed, and when those changes occurred. It should also include estimates and a project schedule, including any revisions that were made during the review meetings. (Chapter 3 contains a repeatable process for generating a WBS and estimates. Chapter 4 describes how to create a project schedule.) 2.2.4. Risk PlanA risk plan is a list of all risks that threaten the project, along with a plan to mitigate some or all of those risks. Some people say that uncertainty is the enemy of planning. If there were no uncertainty, then every project plan would be accurate and every project would go off without a hitch. Unfortunately, real life intervenes, usually at the most inconvenient times. The risk plan is an insurance policy against uncertainty. Each of the risks in the plan must be assessed by the project manager and the team. Risk assessment is an important part of planning a software project because it allows the project manager to predict potential problems that will threaten the project and take steps to mitigate those problems. Adding a risk plan to a software project plan is an effective way to keep the project from being derailed by surprises or emergencies. Many people are thrown off by the word "assessment"it's a word that is usually associated with finances or accounting, not with project management. But in this case, it's appropriate. A good project manager will assess the risk of her projects in much the same way that a good stock trader will assess the risk of his portfolio. In both cases, potential problems should be identified, and the relative probability and impact of each risk should be estimated. Certain risks will be much more likely to occur and, if they do occur, they might cause much more damage than others. In those cases, steps should be taken to hedge the project (or portfolio) against the risk; this is usually referred to as "mitigation" when it is done in the context of project planning. Risk planning for most projects can be done in one meeting, usually in less than two hours. The meeting is led by the project manager, who should select a team similar (or identical) to that of the Wideband Delphi session (see Chapter 3), with the exception that there is no moderator. Table 2-2 contains a script for creating the risk plan.
2.2.4.1. Brainstorm potential risksRisks should be as specific as possible. It's true that "The project might be delayed" or "We will go out of business" are risks; however, they are far too vague to do anything about. When a vague risk comes up, the project manager should prod the team into making it more specific. What are the possible sources of the project delay? How have past projects been delayed? For example, if the last project was late because a major stakeholder quit and was replaced by someone who disagreed with his predecessor's vision, the team should write that down as a risk. The assumptions documented in the vision and scope document and identified in a Delphi session are another good source of potential risks. The team should go through them and evaluate each assumption for potential risks as part of the risk brainstorming session. 2.2.4.2. Estimate the impact of each riskOnce the team has generated a final set of risks, they have enough information to estimate two things: a rough estimate of the probability that the risk will occur, and the potential impact of that risk on the project if it does eventually materialize. The risks must then be prioritized in two ways: in order of probability, and in order of impact. Both the probability and impact are measured using a relative scale by assigning each a number between 1 and 5. These numbers are arbitrary; they simply are used to compare the probability or impact of one risk with another, and do not carry any specific meaning. The numbers for probability and impact are assigned to each risk; a priority can then be calculated by multiplying these numbers together. It is equally effective to assign a percentage as a probability (i.e., a risk is 80% likely to occur) and a real duration for impact (i.e., it will cost 32 man-hours if the risk occurs). However, many teams have trouble estimating these numbers, and find it easier to just assign an arbitrary value for comparison. Many people have difficulty prioritizing, but there is a simple technique that makes it much easier. While it's difficult to rank all of the risks in the list at once, it is usually not hard to pick out the one that's most likely to occur. Assign that one a probability of 5. Then select the one that's least likely to occur and assign that one a probability of 1. With those chosen, it's much easier to rank the others relative to them. It might help to find another 5 and another 1, or if those don't exist, find a 4 and a 2. The rest of the probabilities should start to fall in place. Once that's done, the same can be done for the impact. After the probability and impact of each risk have been estimated, the team can calculate the priority of each risk by multiplying its probability by its impact. This ensures that the highest priority is assigned to those risks that have both a high probability and impact, followed by either high-probability risks with a low impact or low-probability risks with a high impact. This is generally the order in which a good project manager will want to try to deal with them: it allows the most serious risks to rise to the top of the list. 2.2.4.3. Make a mitigation planAll of this risk brainstorming and estimation is only useful if it leads to the team taking actions to avoid the most pressing risks. The remainder of the risk planning meeting should be dedicated to identifying these actions. The project manager should start with the highest-priority risk, working with the team to decide on any actions that should be taken. After that, the team should move down the list of risks, until they decide that the priority of each of the remaining risks is low enough that no action would be required. The team can take any or all of these actions to mitigate a risk:
Once the mitigation steps are identified, all of these risks and actions should be documented in a risk plan. The easiest way to do that is to create a simple spreadsheet with five columns: Risk (one to three sentences that describe each risk), Probability (the estimated probability from 1 to 5), Impact (the estimated impact from 1 to 5), Priority (Probability x Impact), and Action (the specific actions that will be taken to mitigate the risk, or "None" if the risk is deemed a low enough priority to ignore). Figure 2-1 shows a sample risk plan. Note: A more detailed risk mitigation process is described in Making Process Improvement Work by Neil Potter and Mary Sakry (Addison Wesley, 2002). 2.2.5. Project Plan Inspection ChecklistThe project planincluding the project scheduleshould be reviewed (see Chapter 5) using this inspection checklist :
|