Section 2.2. Create the Project Plan


2.2. Create the Project Plan

The project plan defines the work that will be done on the project and who will do it. A typical project plan consists of:

  • A statement of work that describes all work products (specifications, test plans, code, defect reports, and any other product of work performed over the course of the project) that will be produced and a list of people who will perform that work

  • A resource list that contains a list of all resources that will be needed for the product, and their availability

  • A work breakdown structure and a set of effort estimates (described in Chapter 3)

  • A project schedule (described in Chapter 4)

  • A risk plan that identifies any risks that might be encountered and indicates how those risks would be handled, should they occur

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 Work

The 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:

  • The list of features being developed. If the software is being released in phases, the features should be divided into those phases as well.

  • A description of the intermediate deliverable or work product that will be built. This is a list that covers (but is not limited to): software requirements specifications, design and architecture specifications, class or UML diagrams, code or software packages (divided into separate libraries or modules, if necessary), test plans and test cases, user acceptance plans, and any other document, source code or other work product that will be created. A brief descriptionno more than a paragraphis usually sufficient for each one. The SOW also should list any standards or templates that will be used to create the work product.

  • The estimated effort involved for each work product to be delivered (possibly based on the results of the Wideband Delphi estimation session), if known.

2.2.2. Resource List

The 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 Schedule

Once 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:

  • A work breakdown structure (WBS) is defined. This is a list of tasks that, if performed, will generate all of the work products needed to build the software.

  • An estimate of the effort required for each task in the WBS is generated.

  • A project schedule is created by assigning resources and determining the calendar time required for each task.

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 Plan

A 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.

Table 2-2. Risk planning script

Name

Risk planning script

Purpose

To assess risks and create a risk plan.

Summary

The risk planning meeting happens in three parts: a brainstorming session to identify risks; a discussion in which the probability and impact of each risk is estimated; and a discussion to identify actions that can mitigate risks. The end result is a risk management plan, which should be included verbatim in the final project plan.

Work Products


Input

Any project documentation that has been developed so far.


Output

Risk plan.

Assumptions generated by the Delphi process.

Assumptions in the vision and scope document.

Entry Criteria

The project manager has gathered the project team for a two-hour meeting to assess the project's risks.

Basic Course of Events

  1. Brainstorm potential risks. The project manager leads a brainstorming session to identify risks. Team members suggest every risk they can think of; the project manager writes the risks on a whiteboard as they come up. Brainstorming should be reminiscent of microwave popcorn: a few ideas should "pop" at first, followed by a large number being fired rapidly, slowing down to a final few "pops." The team will generally be able to judge when the risk identification is over.

  2. Estimate the impact of each risk. The team assigns a number from 1 (highly unlikely) to 5 (very likely to occur) to represent the estimated probability of each risk. Similarly, impact should be estimated by assigning a number from 1 (for a risk with low impact) to 5 (for a risk which, if it occurs, will require an enormous effort to clean up).

  3. Build the risk plan. The team identifies actions to be taken to mitigate high-priority risks and creates a risk plan that documents these actions.

Exit Criteria

The risk plan is finished.


2.2.4.1. Brainstorm potential risks

Risks 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 risk

Once 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 plan

All 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:

  • Alter the project plan . The project schedule can be adjusted to help reduce the risk. Riskier tasks can be moved earlier in the project, or given more time. This will give the team an early warning or a time cushion in case the risks materialize. The project manager can also hold an additional estimation session to break down the riskiest tasks into sub-tasks. More detailed planning will help reduce the risk.

  • Add additional tasks. There are certain actions that can be added to the schedule to help avoid risks. For example, if there is a high probability that a critical team member will leave the organization, cross-training tasks can be assigned to other people. This will increase total effort in the project, but it will be worth it if the team member leaves.

  • Plan for risks. For risks with a high impact that do not need specific tasks or project plan changes, the project manager should have the team spend a few minutes identifying the steps that should be taken in case the risk does occur. These do not need to be added to the project schedule, but they should be written down and added to the risk plan. This way, if the risk does occur, nobody will panic. Problems that have a large impact on the project can be demoralizing to the team and may throw the project into chaos. Simply having preplanned the steps needed to fix the problem is highly reassuring; it keeps the team feeling like they are on track.

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 Checklist

The project planincluding the project scheduleshould be reviewed (see Chapter 5) using this inspection checklist :


Statement of work

Does the project plan include a statement of work (SOW)?

Is the SOW completedoes it contain all of the features that will be developed?

Are all work products represented?

If estimates are known, have they been included?


Resources

Does the project plan include a resource list?

Does the resource list contain all resources available to the project?

Figure 2-1. Sample risk plan


Are there any resources known to be assigned to other projects at the same time that they are assigned to this one?

Have dates that the resources are unavailable (scheduled downtime for machines, vacations for people, times that facilities cannot be booked, etc.) been taken into account?


Project schedule

Does the project plan include a schedule?

Are there any tasks that are missing or incorrect?

If a WBS was generated by a Delphi session, does the project schedule reflect all of the tasks that were identified by the team?

Does each task have a predecessor?

Is a resource allocated to each task?

If multiple resources have been assigned to a single task, has the task's duration been updated properly to reflect that?

Is there a more efficient way to allocate resources?

Does the project schedule contain periodic reviews?


Risk plan

Does the project plan include a risk plan?

Are there any risks that are not in the plan?

Are there any assumptions (from the vision and scope document or a Delphi session) that represent risks that should be included in the plan?

Is each risk prioritized correctly?

Has the impact of each risk been estimated correctly?

Have the risks been sufficiently mitigated?



Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net