Planning the Project

Planning the Project

The dictum that "failing to plan is planning to fail" is better poetry than advice. While nobody plans to fail, simply creating a plan is no guarantee of success. Planning divorced from the reality of the project is worse than no planning because it gives the illusion of control. A less lyrical, but more accurate statement is, "Poor planning guarantees failure."

Planning a project consists of the following activities:

1. Defining project risks and identifying actions to mitigate them
2. Listing the project assumptions and constraints
3. Organizing the project structure
4. Identifying how quality will be managed
5. Constructing a list of activities and cost components
6. Establishing dependencies between activities
7. Estimating effort and costs
8. Preparing a schedule and milestones
9. Assigning and leveling project resources
10. Aligning the budget and schedule to client requirements
11. Preparing the project budget
12. Managing project paperwork
13. Writing the project plan

This chapter deals with each of these separately.

The culmination of the planning process is the project plan, a document that describes the project and how you intend to execute it. The final section in this chapter presents a sample table of contents for the project plan.

Project Management Software

As project management has evolved, new planning techniques have been developed to help make planning more accurate and simpier.

For example, techniques for breaking down a project into hundreds of small tasks simplify the planning of large projects. However, these techniques create problems of their own; when changes are made, redrawing a complex plan would be so timeconsuming that it is rarely done.

To help plan and manage projects, several companies have developed project management software packages, all of which allow some form of project planning and automation of the tools to help track progress. While some are better than others, all have their advocates, and the popular ones all provide similar features.

Why use such software? After all, the builders of the pyramids, the Panama Canal, the transcontinental railroads, and the great cathedrals of Europe did all right without it. Why bother with it for a little six-month project for two or three people? Because it improves the chances for success. With it, those of us who are not brilliant builders destined to change the face of the Earth can successfully manage the complexities inherent in even a small project.

If your organization uses project management software, master it. If it does not, master a package that seems comfortable to you. You and your projects will benefit.

Defining And Managing Risk

A risk is a potential problem, a situation that, if it materializes, will adversely affect the project. Risks that materialize are no longer risks, they are problems.

All projects have risks, and all risks are ultimately handled. Some disappear, some develop into problems that demand attention, and a few escalate into crises that destroy projects. The goal of risk management is to ensure that risks never fall into the third category.

There are four steps to managing risks: identify them, categorize them, mitigate them, and manage them.

Identifying Project Risks

Although all projects are different, the same risksthose listed in Exhibit 4.1tend to recur. The list in Exhibit 4.1 is not exhaustive, and in identifying the risks for a project, you must continually ask, "What can possibly go wrong?"

If there is one risk that is universally the most dangerous for all projects, it is the following:

Corporate management views the project manager's risk analysis as alarmist and will not take the risks seriously until they materialize.

The only way to mitigate this risk is to document all other risks, identify the actions you take, and keep management informed, especially as the risk becomes more probable. It is only by stressing your risk analysis, by making explicit recommendations, and by insisting that management understand the risks that you can avoid having to say, "See, I told you so."

Common Project Risks

Exhibit 4.1 lists common risks that most projects will encounter. They form a starting point for developing a catalog of risks. However, the list is not exhaustive; most project managers will find several more risks that they can add, and project experience will tend to increase this number. When you are assessing the risks for your projects, always refer to a list such as this. Otherwise, you run the project management risk that not all project risks are identified.

Staff Risks

Key staff will not be available when needed.
Key skill sets will not be available when needed.
Staff will be lost during the project.

Equipment Risks

Required equipment will not be delivered on time.
Access to hardware will be restricted.
Equipment will fail.

(continues)

Exhibit 4.1 (continued)

Client Risks

Client resources will not be made available as required.
Client staff will not reach decisions in a timely manner.
Deliverables will not be reviewed according to the schedule.
Knowledgeable client staff will be replaced by those less qualified.

Scope Risks

Requirements for additional effort will surface.
Changes of scope will be deemed to be included in the project.
Scope changes will be introduced without the knowledge of project management.

Technology Risks

The technology will have technical or performance limitations that endanger the project.
Technology components will not be easily integrated.
The technology is new and poorly understood.

Delivery Risks

System response time will not be adequate.
System capacity requirements will exceed available capacity.
The system will fail to meet functional requirements.

Physical Risks

The office will be damaged by fire, flood, or other catastrophe.
A computer virus will infect the development system.
A team member will steal confidential material and make it available to competitors of the client.

Categorizing Risks

There are numerous statistical methods for defining degree of risk, but the simplest categorization, and therefore the most effective, is to describe risks as extreme, high, medium, low, or minimal.

The degree of risk depends upon two characteristics: the probability that the risk will occur, and the impact on the project if it does.

Probability and impact are both categorized as high, medium, or low, and their relationship, as illustrated in Exhibit 4.2, indicates the degree of risk.

Consider two risks: that a team member will resign during the project and that a fire will consume the office, destroying the installation and all the work that has been done. Both risks are of medium degree. In the first case, although the probability is high, the impact is low: You assume that the team member will give adequate notice and can be easily replaced. The second risk has a highin fact, potentially devastatingimpact, but the probability is low and the risk is easily mitigated by ensuring proper off-site backup.

You categorize risks so that you can identify those that are the most dangerous and therefore require the most attention. It is the extreme and high risks that need your attention first.

Mitigating Risks

You mitigate a risk by reducing its probability, its impact, or both. Since every project is unique, so are the mitigating actions. However, some principles apply across projects and risks.

1. Remove excuses. When the project depends on someone (such as a supplier, client, or line manager) to provide something (such as staff, equipment, or material) in accordance with a schedule, ensure that the provider knows the schedule, knows what is expected, and understands the consequences of a slippage. For major providers, such as the client, make up a schedule giving the exact dates when the project will require client resources. If you are not able to give an exact date now, give a date by which you will be able to.

You remove excuses by providing visibility into the project, an active process in which providers are forced to understand what is expected of them. For example, if you have ordered a piece of equipment with a two-month lead time to be delivered by a specified date, just putting a required date on the purchase order is not enough. Four weeks before delivery, call the sales representative to verify the schedule. Three weeks prior, call to clarify, for example, the power requirements. At two weeks, call to clear up a technical question. One week ahead of time, call to establish shipping procedures. With each call, of course, you will ask if there are any problems that could delay delivery, and you will emphasize how critical timely delivery is. After this series of calls, the supplier has no excuses to fall back on. There is no guarantee, of course, that the equipment will actually be delivered on time, but by actively reminding the supplier of the schedule, you have reduced the probability of a late delivery.

2. Demand visibility. When the project depends on someone delivering something and there is a process that the provider must follow before delivery, you must understand at least the milestones of the process. For example, if a piece of equipment must be manufactured, identify the checkpoints in the manufacturing process, have the sales representative attach dates to each checkpoint, and call on those dates to ensure that the milestones have been met and there are no delays.

If the process is repetitive, such as client review and approval of project documents, understand the process. What happens to a document when it is received? Who reviews it? How are individual reviews reconciled? Is there a final authority for approval? Who? What is the priority of the project for the reviewers? With this understanding, you will be able to suggest changes in the process that will speed things up if there are delays.

3. Help people communicate. When there is a surprise, the project manager is frequently the last to know, even though the informal communications network (or "rumor mill") among team members and users contains various tidbits and snippets of information that provide inklings of problems to come. Helping people to communicate increases the probability that useful information will find its way to you. See ''Building the Team" in Chapter 5 for more about communication.

The communications network can provide advance warning that an employee is dissatisfied and looking elsewhere, that the performance of a system may be slower than required, that software components may not integrate smoothly, or that covert scope changes are being smuggled into the system. In other words, the rumor mill is a prime source of information about emerging risks.

The key rule to using the rumor mill is, "Don't shoot the messenger." No matter how painful the information, thank the deliverer; otherwise, like the jilted spouse, you will be the last to know.

4. Plan fallbacks. If the technology does not perform adequately, what can be done to improve it? If a critical team member is lost to the project, how will those skills be replaced? If the building bums down, how does the project recover? Fallbacks are your plans for when the worst happens.

Fallbacks must be capable of being put into action, either now or when they are needed, and they must be capable of being handled within the budget, schedule, and functionality of the project. If this is not the case, they are not fallbacks, they are wishes with nothing to anchor them but the fervent hope that they will never have to be exercised.

Managing Risks

Risk management is both a planning and a managing activity. It is not enough to set down some risks at the start of the project and then ignore them. You must manage them.

Managing risks means continually reevaluating the risks that have been defined and identifying new ones. There are three main mechanisms for managing risks: project team meetings, project status reports, and project manager reflection.

The biggest problem with risks is that they tend to get lost in the day-to-day hubbub of a project; since they are only potential problems, they are lower in priority than real ones. Therefore, to manage risks, you must ensure that they are an overt part of the project team's, and your, consciousness.

All team members must be aware of the risks that have been identified and awake to situations that affect them. To keep risks visible, devote part of each team meeting to a "risk review" (see "Team Meetings" in Chapter 5) in which the risks are addressed one by one, and team members are instructed to comment on anything that affects each risk. The purpose of the risk review is not to take action, it is to identify what risks, if any, have changed. The risk review also uncovers new risks as team members become attuned to dangerous situations.

Your project status report (see "Reporting Status" in Chapter 5) should include a section entitled "Risk Review" in which you report on risks that have become more, or less, probable or serious. By regularly reporting risks, you are also able to prepare management for unpleasant news so that it does not come as a surprise.

Project manager reflection (see "Reflection" in Chapter 5) is thinking time apart from the daily activities of the project. Devote part of that thinking time to reviewing existing risks and identifying new ones.

Prepare a risk management work sheet, similar to the one in Exhibit 4.3. The sample work sheet contains a short name of the risk to be used in status reports or risk reviews, a longer description, and a table to track how the risk has changed. When a risk has been eliminated, enter "Resolved" under "Comments." The risk management work sheet keeps the risks visible.

What If?

Others Claim That You Have Overstated The Risks.

You may be faced with complacency on the part of the client or an unwillingness to plan for problems. This becomes serious when the client refuses to expend resources to mitigate a risk that you see as high or extreme.

Actions

Seek other, less expensive mitigation procedures that you can use to reduce the risk to some extent.

Document your reasons for categorizing the risks as you did. State the probability and describe the impact in graphic terms. Present your Others Claim That You Have Understated The Risks.

You could be faced with a large number of high or extreme risks, all of which require effort and action. You could also be led into mitigation procedures that are excessive, expensive, and time-consuming.

Actions

If the risk assessments of others leads to a large number of high or extreme risks, ask the complainants whether they really believe the project is this risky and, if so, whether it should be undertaken. Most people will back down and acknowledge that things are not as risky as they have made out.

Honor the risk assessment from others who are knowledgeable, but do not be intimidated into abandoning your own view of the risk. You will encounter people who will claim, usually loudly, that a risk is "unacceptable" and cannot be mitigated except by the most extreme safeguards. If your experience and that of others on your team tells you that this opinion is alarmist, respect the risk, but prepare your plans based on a more reasonable assessment.