Monitoring and Controlling Risky Projects

Overview

"Adding manpower to a late software project makes it later."

—FRED BROOKS, author of The Mythical Man-Month

Apart from phrasing (the very 1970s manpower would be replaced by the more politically correct people or staff), it's hard to quibble with Fred Brooks's statement. In fact, the effect described by Brooks applies to projects of almost any type, not just software projects. Adding contributors to a late project never seems to help very much, because the first thing that new people on a project need is information, so they ask blizzards of questions. These questions are directed, of course, to the overworked people already on the project, which slows them down further. There are other reasons adding staff late in a project can be counterproductive, such as the need to build trust and to move through the team-building stages of "forming, storming, and norming." It is not the additional staff that is the real problem, though. It is additional staff too late. Monitoring and control of the work is essential to detecting problems such as insufficient staffing early enough to avoid the need for chaotic, and seldom successful, heroic measures. Disciplined monitoring and control finds and fixes problems while they are still small, so the project avoids serious trouble in the first place.

Risk management cannot end with the initial planning. Your project starts with its plan, just as a lengthy automobile trip begins with an itinerary based on maps and other information. But what trip ever goes exactly as planned? As the driver continues on the trip, small adjustments based on events and conditions are necessary. More serious issues such as vehicle problems or automobile accidents may result in major modifications to the itinerary. Throughout the trip, the driver must remain alert and reasonably flexible. Managing risk in projects is about detecting things that are not proceeding as planned in your project. Like the driver who must remain alert and responsive to things that happen on the road, the project leader uses tracking, reviews, and reapplication of the planning concepts discussed in the preceding chapters to adjust to the prevailing project conditions, seeking to bring it to successful closure.

Effective management of project risk relies on frequent and disciplined reassessment of new information and status as the project proceeds. Particularly on longer projects, you cannot know everything about the work at the beginning, so periodic project reviews are necessary to keep the project moving and productive.

Most of the content of this chapter falls into the "Risk Management and Control" portion of the Controlling Processes in the PMBOK Guide, but it also draws from "Performance Reporting," "Integrated Change Control," and from other Controlling and Planning Processes. The principal ideas in this chapter include:

Applying the Plan

Once a project baseline is established, the project plan is no longer a work in progress. The plan becomes a road map for the work, and you can begin tracking status and updating your project database with actual results. This information is useful primarily in assessing progress, but it also allows you to improve your processes and efficiency through periodic project reviews, as well as through postproject retrospective analysis.

Risk management relies on systematic project tracking to provide the information necessary for proactive detection of project problems while they are still small and easily solved. Project tracking helps you anticipate potential problems, allowing the project to avoid at least some of them. Disciplined tracking makes it difficult to ignore early warning signals and provides the data you need for effective response. Without accurate, timely information, project problems remain hidden, so they will occur without warning, inflicting serious damage to your plans.

Credible status data also can reduce the project worries and team stress that arises from a lack of good information. Even when the project status reveals bad news, the true situation viewed with credible information is nearly always less dire than the alternatives that people dream up when they lack data. In addition, detailed status often provides the information you need for recovery. Factual information also helps minimize both excessive optimism and pessimism, neither of which is helpful to a project.

Dogmatic collection of project status and routine comparison to the plan guards against a common project risk—"safe so far" project reporting. As long as the project deadline is still way out in the future, the project is not officially late. Even without any data, project reporting continues to say that the project is doing fine. Only at the deadline, or perhaps a little before it, does the project leader publicly admit that the project will not meet its schedule commitment. This is analogous to a man who falls off a ten-story building and reports, as he passes by each row of windows, "Safe so far!"

Projects become late one day at a time. Failure to detect this lag as soon as possible allows schedule and other risks to remain undetected, grow, and ultimately overwhelm the project.

In addition to frequent status collection, longer projects also need project reviews, performed every three to six months, to manage the work that extends beyond a reasonable planning horizon. A project review provides the opportunity to detect new risks, fine-tune the project plan, and make necessary corrections and shifts in the overall project.

Project Monitoring

Project monitoring can begin as soon as there is a clear, validated baseline plan that has been approved by the project sponsor and accepted by the project leader and team. Other prerequisites for effective project tracking are a functioning communications infrastructure, functioning tracking methods, and thorough project planning data available to all team members and stakeholders.

Decisions Related to Monitoring

You need to make decisions about project status collection and storage as part of the initial project infrastructure for your project.

You need to commit to an appropriate frequency and method for status collection. Tracking on technical projects is usually done weekly, with status collected from all project contributors via electronic mail, but many other options are possible for this. For very short or very urgent projects, more frequent data collection may be warranted. For long projects, less frequent data collection may be appropriate, but a cycle longer than two weeks is inconsistent with good risk management. In addition to electronic mail, data collection methods include printed forms, discussion during project team meetings, reporting by telephone, and one-on-one meetings between the project leader and project team members. Some projects also do this informally, but any choice that does not generate a written record increases project risk arising from garbled or incomplete information.

On large, complex, multiteam programs, consistent data collection is essential, and the volume of status information can become quite a burden. One way to respond to this is to set up a project office that is responsible for assembling, summarizing, and analyzing the data consistently for all the project teams. This ensures that you will have current, consistent data and also permits use of more complex scheduling tools without the cost of so many copies and the considerable effort that would be required for all the project leaders to master the tool.

Project reports and meetings are generally synchronized with status collection, so reporting is generally done on a weekly basis and distributed via electronic mail. Project status meetings, also usually weekly, should be face-to-face when possible; for distributed project teams, use the best available telecommunications methods. The frequency and methods used vary from project to project, but risks rise steeply when reports, meetings, and other communication are more than two weeks apart.

Decisions on how and where to store the project status information are also important. Whether the data are hard copy or on-line, all project team members should have access to them. Determine the tools and systems to be used for collecting and storing the data and provide appropriate security so that team members who need to update project information, but not others, are able to modify the data.

The precise details for these decisions related to project monitoring will affect your ability to manage risk, so commit to methods and frequencies that will best serve your project.

Project Status

Project status information is of two types: hard data (facts and figures) and soft data (anecdotal information, rumors, and less specific information). Both types of data are useful for risk management. Hard data include the project metrics discussed in Chapter 9, and most of them are diagnostic—telling you how the project is proceeding. Some of the hard data collected will relate to, or may even be, a risk event trigger, and other data may reveal dangerous trends. Soft data can tell you the causes for your project status; they may also provide early warnings of future problems and risk situations.

Hard Data

Hard schedule data include metrics that assess information on activities and milestones, including revised start and completion estimates for future work. Other hard data track resource information related to effort and expenses, results of scope testing and investigation, and other information on project deliverables. Hard data collection needs to be routine, easy, and not too timeconsuming. On most technical projects, people are so busy that if collecting hard status information is not simple, it will not get done. At a minimum, collect:

Soft Data

Additional information of a less tangible nature also permeates your project. Information about the project contributors may alert you to potential threats to needed resources, individual productivity, and other potential sources of project risk. Changes in the work environment, a rumored reorganization, or personal problems among individual team members may also adversely affect up-coming project work. Soft project data issues include:

You should collect metrics for hard data systematically, on the frequency you set for your project, and make the results available to the project team. Use hard data to detect any issues or shifts in project assumptions. Collect soft data continuously, but share them only as appropriate. Do not spread or add to the project archive any unsubstantiated rumors or confidential information specific to individuals.

The Status Cycle

Project monitoring depends on a four-stage cycle that repeats periodically (generally weekly) throughout the project. The first stage is inbound communication, collecting of project status information. The second stage of the cycle compares the status to the plan, evaluates the metrics, and analyzes any variances. The third stage responds to any issues or problems detected. The fourth and final stage is outbound communication, keeping people aware of what has happened in the project.

The monitoring cycle provides for analysis and planning after collecting project status information but before project reporting. This lets you include your responses to any issues or problems in your project status report. Any bad news you report will be received better if it is accompanied by credible plans for recovery.

Collecting Project Status

Collecting project status is primarily your responsibility as the project leader. Confine status collection to the data that you need, keep the process simple, and make your use of the data visible. Basic status for the scheduled project activities is an effective minimum. One easy way to obtain it is to provide a list of current open activities to each activity owner via electronic mail with a request for two responses—an indicator and a date. Possible indicators are "Not started," "Continuing," and "Done." The date provided with the indicator is the expected start date for activities not yet begun and the finish date (expected or actual) for the other two. Additional data, such as effort or cost information, are also useful, but for routine periodic status collection, simplicity improves both the quality of the data and the willing cooperation of the team. A detailed, five-page form that collects every possible project metric is of no use if no one fills it out or everyone treats it as a joke. Risk management requires data, so do what you can to keep them flowing.

There are a number of factors that can impede status collection. One pitfall is to collect project status only "when there is time." As typical technical projects proceed, the work intensifies, and problems, distractions, and chaos build. It becomes tempting to skip a status collection cycle. Especially during times of high stress and significant problems, it is risky to lose information. You may even find it necessary to intensify data collection during problems or near project completion.

Another thing to guard against is collecting data and then not using the information. After you collect status, at least incorporate a summary of it into your overall project status report. When you fail to use what is available, or when it looks like you are not using it, your team members will either stop sending it or will put no effort into supplying meaningful data. At least once in a while, recognize the work required to submit status, and thank people for it.

Perhaps the most common problem in status collection is handling bad news. When someone reports that his or her work is not going well, your first temptation is to find a chair and break it over his or her head, or at least to yell a lot. One of the hardest things a project leader has to learn is not to shoot the messenger. You need to respond positively, even to bad news. Thanking people for bad news is never easy, but if you routinely punish team members for providing honest data, you will quickly stop hearing what you need to know, and project risks will escalate. It is much better to mentally count to ten and then offer a response such as, "Well, I wish you had better news, but I appreciate your raising this issue promptly. What will help get you back on schedule?" It is never too soon to begin thinking about how to respond to the problem or issue.

Particularly when the status is coming from distant team members, or from people you do not know very well, screen the information carefully to ensure that it is realistic and meaningful. It takes a lot more effort to get regular, high-quality information from remote contributors, so be persistent, make multiple requests when necessary, stay up late or get up early to speak with team members on a regular basis, and verify the status data submitted as thoroughly as you can. For work done at a distance, probe for evidence of progress that supports the reported status, such as the results of evaluations, interim tests, walkthroughs, and investigations or samples of prototypes, mock-ups, or partial systems.

Risk management requires current, factual project information, so be persistent and diligent in obtaining it.

Metrics and Trend Analysis

After collecting status, look for project problems by analyzing variances. Variance analysis involves comparing the status information you collected with the project baseline plan to identify any differences. Variances, both positive and negative, need to be analyzed for impact; positive variances may provide clues for improved execution that might be applied to future work, and negative variances need attention so that they do not send the project spiraling out of control. Trend analysis on the metrics can also identify aspects of the project that may cause future disruptions.

Diagnostic Metrics

After contrasting the status data with the plan, the first thing to do is to validate the differences, particularly large ones. Before spending time on impact analysis, check with the people who provided the data to make certain that the problems (or, for positive variances, the apparent benefits) are real. For each difference, determine the root cause of the variance, not just the symptoms. Work with both hard and soft project data to understand why each variance occurred. Metrics seldom slip out of expected ranges in isolation; the project schedule, resources, and scope are all interrelated, so problems with one of these parameters tend to affect the others. Variances may also display patterns and trends over time that can be used to anticipate future problems and emerging risks.

Once you have determined the underlying cause of each variance, you can decide how to respond. Dealing with the root cause of a problem also prepares you to deal better with future situations that may cause similar problems later in the project. In variance analysis, focus on understanding the data; never just look for someone to blame.

Schedule Metrics

Schedule variances are generally examined first, whether positive or negative. If there are positive variances—work completed early—there may be an opportunity to pull in the start date of other work. It is also worthwhile to discuss the early finish with the activity owner to see whether it is the result of an approach or method that could be applied to similar work scheduled later in the project or whether you could shorten any duration estimates.

The more common situation is an adverse variance, which for critical activities will impact the start of at least one scheduled project activity. Unless an activity that comes after the slip can be shortened, it will affect all of the activities and milestones later in the project, including the final deadline. Even for noncritical activities, adverse variances are worth investigating; the slip may exceed the flexibility in the schedule, causing the same impact as a critical path activity that slips. For any adverse variance that impacts a schedule dependency, promptly notify the affected team members (and, if necessary, other projects) that their work will be delayed.

Whether or not the slipped activity is critical to the schedule, seek the root cause of the slip. If the delay is due to faulty analysis or inappropriate assumptions, any duration estimates for similar work later in the project could also be too short. On technical projects, there may be many essentially repetitive activities, so if the estimate for one proves to be too short, there is a good chance that they all may be too optimistic. Another consideration is the possibility of a similar problem within any of your contingency plans; it is a good idea to repair any defects in your recovery plans whenever they become apparent.

Finally, schedule variances may be due to root causes that were not detected during risk analysis. If the root cause of a slip suggests new risks and project failure modes, note the risks and set a time for additional risk analysis and response planning.

Resource Metrics

Resource variances are also significant, but dealing with them may not be as urgent. Metrics related to the concept of earned value are particularly useful in examining resource use throughout the project. Earned value metrics, such as the cost performance index (CPI), measure the effort or money consumed by the project in relation to the plan. If the consumption is low (CPI greater than one) but the schedule progress is adequate, there may be a possibility of completing the project under budget. If it is too low and the schedule is also slipping, the root cause is likely to be inadequate staffing or too little of some other resource available. Whenever project progress is too slow because of insufficient resources, escalate the situation to higher management promptly, especially if your project is being denied access to committed resources.

Whenever resources are being used in excess of what is expected—that is, when the CPI metric is less than one—the variance is almost certainly a serious problem. The likelihood is strong that the project will ultimately require more resources to complete than the plan indicates, because it is very difficult to reverse resource overconsumption. Even as early as 20 percent through the project schedule, a project with a "burn rate" that is too high has essentially no chance of finishing within budget. Using more resources than planned may cause your project to hit a limit on staff, money, or some other hard constraint, and halt the project well before it is complete. Publicly admitting to this sort of problem is never easy, but if you delay in delivering the news, it will make the inevitable discussions even harder. The longer problems like this persist, the larger they tend to become. There are also fewer options later in the project for resolving the problem, and the project sponsors and other managers will have much less sympathy for you near the scheduled end of the project.

Some resource issues are acute, having impact on only a short portion of the project, while others are chronic and recur throughout the work. Chronic situations not only create project budget problems; they also may lead to frequent overtime and constant pressure on project staff. Risks associated with late project activities grow with lowered motivation and other staffing issues. Chronic resource problems may also have an impact on existing contingency plans, and their root causes may reveal the need for additional risk response planning.

Scope Metrics

While schedule and resource variances are the most common results of status collection, some of the status data collected relates to the project deliverables. The results of tests, integration attempts, feasibility studies, and other work will either support the expectations set out in the project requirements, or they will not. Significant variances related to scope may indicate a need to propose project changes. Major variances may well foreshadow project failure.

If a scope-related metric exceeds the result expected, you should explore whether the project might be able to deliver a superior result using the same time frame and budget. It may also be possible to deliver the stated result sooner or less expensively. While this situation is relatively rare, it does happen, and making the best choice may not be obvious. Discussion with the project sponsors, customers, and other stakeholders is prudent before adding something to the project scope "just because you can." Assess the value and utility of any additional product feature before incorporating it into the project.

When scope data indicate a problem that can be resolved with additional work, the impact may be to the project schedule, resources, or both. These possibilities, along with an analysis of what realistically could be delivered consistent with the project budget and deadline, all need consideration in light of the data, so the most palatable option (or options) can be proposed as a change request to modify the project objective.

If you cannot resolve a scope problem with extra work, your only options are to propose a change that would result in a different, but possible, deliverable or to abandon the project. As with recognition of a resource overconsumption problem, scope under-delivery issues are always difficult to deal with. Some projects choose to hide the problems, hoping that someone comes up with a brilliant idea to close the gap between what is desired and what can credibly be delivered. This is a very high-risk strategy and seldom works out. The best course is to surface the issues as soon as you have validated the data. If you do this early, project options are more numerous, the total investment in the project is still relatively small, and expectations are less "locked in." While still painful and unpleasant, this is a lot easier than dealing with it later. When a project proves to be demonstrably impossible, the optimal time to change (or kill) it is early, not late.

In addition to the impact on the current project, scope problems may also affect other projects. Project teams that depend on aspects of your deliverable that are unrealistic or who are working with similar flawed assumptions also need to be informed so that they can develop alternate strategies or work-arounds.

Once you have completed the variance analysis, document the impact. List the consequences of each variance in terms of:

Once you have determined the source and magnitude of the problem, you have a basis for response.

Trend Analysis

Trend analysis does not necessarily need to be part of each monitoring cycle, but periodically it is a good idea to examine the trends in the status data. When the resource consumption rates or cumulative slip for the project moves in a dangerous direction, the trend data will make it clear. The earlier you are able to detect and analyze an adverse trend, the easier it will be to deal with it. Trend data may reveal a need to adjust the project end date, raise the budget, negotiate for more resources, renegotiate contracts, or modify the project deliverables. If so, the earlier you start, the better your chances for success.

Trend analysis performed early in the project identifies the things that need to shift at a point where there is much more tolerance for change, even significant change; the concept of the project is still flexible in the minds of the project sponsors, stakeholders, and contributors. Ignoring or failing to detect adverse trends in the status data is very risky. If trend information indicates a problem and no action is taken, the trend is likely to continue and grow. Ultimately, something will have to be done. As it gets later in the project, the options diminish and the changes required to reverse the trend become more extreme and less likely to do much good. These actions may create additional problems and even lead to project failure.

Detecting and dealing with adverse project trends early enough avoids the late project changes and cancellations that are so demotivating for technical project teams. After having worked for months, or even years, on a project, the team may find even small changes to the deliverable devastating. Allowing everyone to identify with a very aggressive, high-tech, bleeding-edge objective for the bulk of the project and then having to chop the heart out of it at the last minute so that you can ship something on time is demoralizing and embarrassing. People identify with the work they do, so they take late project changes very personally. Team building and motivation on subsequent projects become very difficult. If this happens often, project staff members are trained not to care about the projects and not to trust the people who lead and sponsor them. Technical projects are successful not because they are easy; they succeed because people care about them. Anything that interferes with this raises project risk to insurmountable levels.

Detecting and responding to adverse trends so that you can shift project expectations early into better alignment with reality is an important tactic for delivering on failure-prone projects.

Responding to Issues

At this point in the status cycle, any significant differences between the plan and actual project performance are visible. Treating plan variances as issues and resolving them soon after they occur, when they are still small, allows project recovery with minimum disruption. Responding to project issues resembles risk response planning, discussed in Chapter 8. In fact, for issues that you anticipated as risks, the response could be as simple as implementing a contingency plan. Other possible responses range from very minor staffing shifts or resequencing of project activities to major changes to the project objective, or even to project cancellation. The process for issue response closely resembles the "Plan-Do-Check-Act" cycle from quality management.

Base your response plan on the specifics of the problem. If the variance is small or there is a well-established contingency plan, it may be sufficient to delegate the response to the team members responsible for the work affected. If the situation is more complicated, many of the ideas from project planning and risk response come into play.

For significant problems, involve the right people. As with any project planning, everyone on the team brings his or her own expertise, ideas, and perspective. Larger project problems often require major project changes, so review, if necessary, the processes and requirements for change management.

Plan for Response

Prepare to brainstorm ideas to respond to the issue by checking the contingency plans already available and reviewing any responses that were used to recover from similar situations on earlier projects. Clearly state the problem and its root cause or causes, and focus your planning on solving the real problem, not just dealing with the symptoms. Be creative and let ideas flow; even ideas that seem impractical may trigger someone to think of a workable response. Don't simply accept the first idea someone comes up with. Develop a number of ideas, especially for larger issues.

Select a Plan

Once ideas for responding have been generated and captured, analyze and rank them. Consider the consequences of each potential response on project schedule, resources, and scope. Probe for possible unintended consequences, both in your project and for other related work. Even ideas that seem very good can sometimes lead to consequences that make things worse overall.

The best of the options developed may not present any obvious problems or require any significant project changes (sometimes the "brute force" option of just working some additional overtime is the path of least resistance). However, if the recovery plans that seem to make the most sense do require changes, the next step is to submit each option you are considering to the change management process for review.

For even more significant response plans, those that modify the basic project objectives, the analysis process could also involve fundamental replanning. If so, get buy-in from the project team and stakeholders for the revised plan, validate the new objective and baseline with the project sponsor, and update the affected documents.

Implement and Monitor the Changes

Once a response plan is accepted, implement it. Communicate the plan and the information on required project changes to the project team and any other people involved.

After taking the actions in the response plan, monitor to see whether you have solved the problem. If the actions are ineffective, plan for additional responses, looking for a better solution. The situation is similar to the way a fire department treats a fire. Initially a new fire is "one alarm," and one fire crew is sent out. When the fire is too large, or it spreads, the fire alarm escalates to two alarms, and then, if needed, to three or more. The escalation continues until the fire is brought under control. Ongoing project risk management requires the same diligence and persistence.

Significant project changes often lead to unintended consequences. During the status cycles that follow big changes, be particularly thorough in your data analysis and look for unexpected results.

Communication

The final step in the status cycle is to let people know how the project is doing. This includes the use of project status reports and status meetings, as well as less formal communication. Successful projects depend on a solid foundation of clear, frequent communication. Without effective communication, project risks may not be detected, let alone managed.

Communication Challenges

Communication on projects presents a number of growing challenges, many of which relate directly to observed risks on technical projects. These include distance, time differences, languages and culture, and the need to work cross-functionally with many diverse disciplines. Each of these makes effective communication, which is never easy anyway, more and more difficult.

Distance is a well-known barrier to communication. It restricts both the type and amount of communication possible and reduces informal interaction to almost none. On global or distributed projects teams with people who work at a distance, no one can just "stop by" to share information. Even with project teams that are local to each other, increasingly people are working from their homes or other locations apart from other team members.

As projects become increasingly global, time differences also interfere with communication. Even phoning people on global projects can be difficult; whenever you need to talk, it is the middle of the night for them, and they are probably asleep. Communication tends to be mostly written, with rare exceptions when one part of the project team can make itself available outside its normal work hours. Again, this challenge is not unique to global teams. "Flextime" and other policies that allow people to set their own work schedules erect a barrier even for teams that work in the same time zone.

Different languages and cultures are another growing communication challenge for technical projects. Global work involves people who speak different languages and who have different ways of working and communicating. Sharing complicated technical project information in this sort of environment is never easy, and omissions and misunderstandings may be frequent. In many locations, such as California, Singapore, India, and much of Europe, even projects with co-located teams face this challenge. Technical project teams are made up of individuals with different first languages and cultural backgrounds. Cultural and linguistic diversity in technical work is becoming the norm, not the exception, for many types of technical projects.

Finally, few technical projects are only technical. Communication between people from different disciplines can be even more difficult than communication between people with different native languages. Cross-functional project teams involve people from very different educational and work backgrounds. Development, manufacturing, sales, marketing, support, and other functions all need to cooperate on projects, and their vocabularies, jargon, and perspectives are radically different. In addition, technical projects increasingly depend on consultants, partners, and suppliers from other companies, and these contributors bring their own communication idiosyncrasies.

As the project leader, you are the person primarily responsible for project communication, and you must rise to these challenges to minimize project risks. In today's projects, this requires discipline and effort.

Project Status Reports

The most visible communication for most projects is the written status report. Ongoing risk management depends on clear, credible project information that is understood by everyone on the project. Status reporting that is too cursory increases risk because no one has enough information about the project to know what is happening, leading to chaos. This may occur because the project leader is busy or distracted and provides too little data. It also may be the result of "need to know" project reporting, where the project leader sends out very brief notes to each team member containing data only on the portion of the project that he or she is involved with. It can even happen because the project leader dislikes writing reports. Whatever the source, projects with too little information become very prone to risks, particularly risks related to dependencies and interfaces.

On the other hand, status reporting that rambles on and on is no better. No one has time to read it all, and, although the information everyone needs is probably there, somewhere, finding it becomes vanishingly unlikely. One common reason for long reports is a project leader who solicits individual reports from the whole team, concatenates them into a compendium running to dozens of pages, and ships it all out once a week. It can also happen with project leaders who like to write and are not good at summarizing. Time can be a factor in this; there is much truth in the old saying "I didn't have time to write a short report, so I wrote a long one." Whatever the reason for verbosity, the result is increased project risk, because no one has the patience or time to digest the entire report.

The best reports start with a short, clear summary and include only current, relevant data. Reporting formats may be standardized in your organization or created for the project specifically, but a consistent format for the weekly report makes it easier to write, easier to read, and more useful for postproject analysis. Select a format that works for your project, and stick with it.

In written reports, strive to be concise, honest, and clear. If you commit to reporting project status every Friday (or some other frequency), do it. Work to summarize, interpret, and clarify information. Avoid stringing together random bits of project data in a stream of consciousness. Include the information needed by your project team, your management, and other stakeholders such as the customer, other project leaders, or others to whom you will distribute the report. Periodically discuss the project reporting with stakeholders, and note their key interests so that you can provide the information that they require. Any important data that people notice are missing will probably result in unnecessary and time-consuming telephone calls or other interruptions. Missing information that goes unnoticed can lead to serious project risks and problems.

Regardless of the recipient, begin every status report with a brief (twenty lines or fewer) executive summary. Include the most important information in the summary, such as key accomplishments, current issues, and planned next steps. Be aware that sometimes the summary is all that will actually be read and that some of the people who receive your report will not need or want any more detail than this.

Follow the summary with any additional information organized by declining relative importance and increasing detail. If different people in your distribution list need varying levels of detail, the hierarchical structure allows you to create additional reports by truncation, rather than by rewriting. Always reread your report for errors, omissions (a missing "not" here and there can cause no end of trouble), and language that is clear and easily understood by all report recipients. Avoid technical jargon, acronyms, and idioms that may be confusing or misunderstood. Attaching graphs, figures, and charts can simplify complex project information and statistics (but be sure to use a format for this that all recipients will be able to read).

In addition to the executive summary, a typical project status report may include:

In written reports, include only status information that is substantiated, and use soft status data sparingly, if at all.

Other Reporting

In addition to the project status report, other reporting may be required. Some reports may be periodic, similar to the status report, while others may be issued only occasionally.

Periodic reports common on technical projects include change control summaries, quality reports, testing and defect reports (particularly late in the project), personnel reports, contract status reports, and budget reports. Some of these reports may be written for the project by others, and some are created by the project leader or team. Regardless of the source of the report, effective risk management requires that you, as the project leader, check the information for accuracy and consistency and diligently correct any inaccurate information.

Other, less frequent reporting and presentation of project data may be required for management reviews, phase transitions, or other reasons. These reports and presentations generally include much of the same sort of information found in your project status reports, but they take a longer view of the project, both backward and forward. Again, one of your chief responsibilities as the project leader is to ensure scrupulous consistency with other project information.

These higher-level reports and presentations are a good opportunity to reinforce your project goals and objectives, to be positive about what the team has done, and to share your plans for the future. Presentations are a particularly effective way to renew strong project sponsorship, motivate the team, and renew enthusiasm for the project. On longer projects, all of these factors are significant sources of risk.

Project Status Meetings

Project status meetings for technical projects are viewed by many as a necessary evil, and by everyone else even less positively. Technical people, for the most part, hate meetings, especially long ones. Considering the increase in project risk that results from inadequate communication, this is unfortunate. The discussions and exchanges that occur during project status meetings are essential for avoiding risks, and many potential problems never occur because of things that are discussed during status meetings. Regular status meetings, even via teleconferencing, are a potent tool for keeping difficult projects on track and risks under control.

Brevity

One key to improving attendance and participation in status meetings is to keep them short. Meetings are more interesting and energized if they focus only on project status—what has been accomplished and what issues are pending. Status meetings for some projects are lengthy, rambling affairs that cover a lot more than project status. In addition to discussions of general issues and business information unrelated to the project, there are frequent side trips into issue resolution and problem solving. While all of this may be necessary, none of it needs to be part of a project status meeting. General "staff meeting" issues may be of no value or interest to some of the project team, such as external consultants, and consume both time and money unnecessarily. Problem solving and issue resolution are unquestionably important, but they rarely require the entire project staff to be involved. While a few people are fascinated and engaged in the discussions, the rest of the people in the meeting will be falling asleep. Take problem solving and extended discussions off-line with smaller groups in follow-up meetings.

Agenda

Effective meetings are well structured, and they work from an established meeting agenda that they stick to. Useful goals for status meetings include always starting on time, setting time limits for the agenda items and enforcing them, and ending the meeting early as often as possible. An effective method for keeping meetings short is to schedule them just before lunch or near the end of the workday. Hunger and the desire to go home are excellent ways to focus people on the important issues and manage meandering discussions.

A typical project status meeting agenda might include:

Method

Meeting methods vary a great deal, and almost any method for periodic project discussion that the project team cooperates with can be effective. Face-to-face communication is generally best. When people can be in the same place at the same time, it minimizes misunderstandings and reinforces teamwork. Meetings in person also provide the best direct and immediate feedback to what is said; when you are face-to-face, you can ask questions and get answers immediately. Even when people work in the same location but at different times, meeting once per week should not be too difficult to arrange.

When people work in different places, frequent face-to-face meetings are not possible. Technology provides several other methods, but, without adequate planning and preparation, you will not get the most out of them.

Teleconferencing, like any meeting, requires advance planning so that any materials to be discussed will be available to all. Prepare any support materials the meeting will require, and send them via computer networking, electronic mail, fax, expedited shipping, or other means to all locations involved with the meeting so that all the information is available in time. Also, distribute the agenda for the meeting to all attendees, and get a commitment to participate from each person who needs to take part. Since, even with videoconferencing, it may not always be obvious who is speaking, start the meeting with introductions of all involved whenever there are new participants, and remind everyone to state his or her name before speaking during the meeting. When teleconferencing with people who don't know one another, it can be helpful to exchange pictures so that you have some idea of who is speaking.

For "real-time" work that involves visual images or applications—presentation slides, graphics, reports, or demonstrations of software—use videoconferencing or Web-facilitated meeting capabilities, and allow sufficient time for transmissions, explanations, and an occasional operational problem. When dealing with significant time differences, schedule meetings at a time that is as mutually convenient as possible. If there is no convenient time, as when dealing with a half-day difference between India and the western United States, do not schedule every meeting for the same time. Schedule the meetings so that all participants will be able to meet during their daytime at least once in a while. Spread the pain around; don't make the same team members lose sleep for every meeting.

For technology-assisted meetings, here are key considerations:

However the meeting is conducted, record what is discussed for any absent team members and for the project information archive. Capture new issues and action items, with assigned owners and expected due dates. Distribute meeting minutes promptly to all project contributors, and to others as appropriate.

Informal Project Communications

Never limit project communications to scheduled meetings. Some of the most important communication on technical projects takes place at coffee machines, in hallways, and during casual conversations. Project risks may surface far earlier in these discussions than in formal analysis.

Some of this communication involves the project leader, and successful project leaders create opportunities for frequent, unstructured conversations. The idea of "management by wandering around," popularized by Dave Packard and Bill Hewlett, is a particularly effective way to reinforce trust and build relationships within a project team. Even when teams are distributed and you are unable to talk frequently with people in person, there will be opportunities to do it once in a while, and you can rely on the telephone for the periods in between. A great deal of "soft data" and valuable project information surfaces during casual exchanges. Informal communications are also an important benefit of project celebrations. When one project team in California discovered a mutual interest in local wines, the members assigned letters to all their milestones. They had a great time working their way through the alphabet, sharing a bottle of wine (after work) from a winery with a name that started with the same letter as the completed milestone. Particularly on longer projects, you can schedule periodic "extra-curricular" activities chosen by the team and have some fun. Eating together works well, and, depending on the team, so might a sporting event, the new big-budget science fiction movie, or some other recreation. Effective project leaders work to encourage interactions among project team members. Team cohesion, which correlates strongly with the amount of informal communication, is one of your best defenses against project risk.

Project Archives

In addition to distributing project documents and reports to your stakeholders and contributors, you also need to retain copies as part of your project management information system (PMIS). This archive not only serves as an ongoing reference during the project but also is essential for capturing the lessons learned during postproject analysis; it contains data that can improve risk management on future projects. For most technical projects, the archive will probably be stored on-line, but it is also prudent to keep a hard copy of key data because a great deal of useful information may be lost whenever older software applications are replaced, making the original source files useless.

A typical project archive contains:

There may also be a great deal of additional archived information specific to the project. This archive tells the history of the project from beginning to end. When the project is over, the final addition will be the postproject retrospective analysis and lessons learned.

The archive serves many purposes, not the least of which is helping to mitigate a very significant project risk—the loss of the project leader. If for any reason the project needs to continue without the original project leader, the information in a well-maintained PMIS is invaluable. The new project leader who takes on a project where a thorough PMIS exists still faces a daunting task but is light-years ahead of where he or she would otherwise be.

Project Reviews and Risk Reassessment

When you operate a complex piece of machinery such as an automobile, you frequently need to add fuel, check the oil and the air pressure in the tires, and make other minor adjustments. This is sufficient in the short run, but if you never do anything more, the car will soon break down. Periodically, you also must perform scheduled maintenance to change the oil, replace worn-out or poorly functioning components, check the brakes and other systems, and generally bring the vehicle back into good operational condition.

A project is also a complex system. The activities in the status cycle are necessary, like adding fuel to a car, but, unless the project is very short, they are not sufficient. Most projects also require periodic maintenance, in the form of a project review. The planning horizon for some technical projects may be as short as two to three months, or it may stretch to most of a year, but no project can plan with adequate detail beyond its planning limit, whatever it may be. Project reviews allow you to take a longer view, beyond the next status cycle, in order to revalidate the project objectives, plans, and assumptions. Successful project and risk management require cycles of review and regular reassessment to keep the project on track.

Another reason for periodic review relates to the dynamics of a distributed team. If you begin a project with a face-to-face startup workshop, technological methods and long-distance meetings are very effective for coordinating work on separated teams—up to a limit. After about six months, established trust and relationships begin to break down, resulting in conflicts, errors, and loss of productivity. Desired behavior, such as collaborative problem solving, deteriorates into unproductive finger pointing and arguing. Periodic project reviews, which at least some of the distributed team members attend in person, are an excellent way to reestablish project team cohesion.

Even for co-located teams, the project review is an opportunity to reinforce the value of the project, recognize and reward significant accomplishments, and motivate the project team. Loss of interest on very long projects is one of the reasons that these projects are higher-risk. Reminding the team why the project matters and formally saying "thank you" is an effective way to reduce this risk.

The limited planning horizon and technical complexity also contribute to the greater project risk of lengthy projects, and project reviews are an effective way to better manage these factors. During the review, as you reassess the project, one of three scenarios will arise. Some reviews find few issues, requiring minimal attention, and the project continues as planned. Other reviews reveal changes or additional planning that is necessary, and the project continues, but only after the changes are made. The third possible outcome of a project review is a recommendation to cancel future project work. While this is not pleasant, it is better ultimately for everyone than continuing with a project that would eventually fail after spending even more time and money.

Schedule the Review

Project reviews are generally most productive when they are scheduled to coincide with major project milestones or events. Some examples include life-cycle phase checkpoints and stage-gate transitions that follow a major change in project direction or occur when key project contributors leave or join the project or after a major business reorganization or change in management. Even in the absence of one of these events, however, you should schedule a project review at least every six months; for particularly risky projects, quarterly (or even more frequent) reviews may be prudent.

Allow sufficient time for a project review. A thorough review usually requires about the same amount of time as the project start-up workshop did. At minimum the review will take half a day, but most technical projects need a day or more. The most effective way to review a project is to get away from the usual workplace and assemble all key project team members face-to-face. Choose a time for the review by checking the calendars of the people you need to participate, and get their commitment to attend. If there are more than about twelve essential people, consider breaking the review into several smaller meetings with fewer participants that will focus on specific aspects of the project. These partial project reviews can be either conducted in sequence or held simultaneously and then followed by a larger general session where you summarize results, integrate the findings, and bring the review to closure.

Preparing for a review relies on information in the project archive, but it also may require new information, necessitating revision or new versions of the data used for scope planning. The universe does not remain static month after month as your project work proceeds, so for long projects you should update your market research, customer needs data, and competitive analysis information. Basic project assumptions and business strategies may also shift during the project, requiring adjustments, and more work may be necessary to assess new or evolving technological alternatives currently available to the project. Before your review, determine the information you need, and assign an owner to prepare it. Thorough preparation for a project review may entail significant effort, so scheduling reviews too frequently can create a lot of project overhead.

Objectives for the Review

The overall objective of the review is "scheduled maintenance" for the project. During the review, the principal focus is the course of the project moving forward. Major objectives should include:

Develop an agenda for the review, and assign specific expected outcomes and time allotments for each item on the agenda.

Conduct the Review

Begin the project review by clarifying the roles of the participants and setting the agenda. During the review, assign participants responsibility for capturing decisions and action items in writing, and maintain a separate list of any project issues that require later attention but are beyond the scope of the review meeting.

Focus initially on positive aspects of the project. Review accomplishments and project work completed, recognizing the people who have made noteworthy contributions. Identify the things on the project that have gone well, and consider how you could expand the use of these processes as the project continues.

Then, focus on any needed project changes. Reconsider the scope definition assumptions, and, when necessary, develop recommendations for changes necessitated by newly available market research, competitive analysis, or user interview data. Review all unanticipated activities you have added to the project to date and all the activities that were underestimated or were planned based on faulty assumptions. Review the future project plans using these data, and identify any additional project activities or other plan defects that are now apparent. Test the assumptions, estimates, and other data for future scheduled work in light of what you now know. Make note of any changes that are proposed for later analysis. Reexamine project decisions that you have made, the project environment, and the processes that you are using. The risk survey in Chapter 9, edited down, is an effective way to determine aspects of your overall project that could use improvement.

Discuss the problems and risks you have encountered in the project so far, and brainstorm methods for avoiding similar trouble in the remainder of the project. Also, review your existing risk list, and identify additional scope, schedule, resource, or other risks that are now visible in the project. Add the new risks to the list, and assess all of them, rank-ordering the risks on the basis of current information. Develop appropriate risk responses for any significant risks that have none.

Capture all suggestions, recommendations, and decisions made during the review, and close the review by summarizing the results. Assign owners and due dates for all added project activities and action items. For any change recommendations that are beyond your authority, delegate responsibility for preparing a change proposal. For recommendations that would change any of the overall project objectives, assign yourself the task of updating any affected project documents, and prepare to revalidate the project with your sponsor.

Follow up after the Review

After the review, document what you discussed and learned. Summarize the findings and distribute them appropriately, generally to the same people who receive your project status reports. Submit all recommendations requiring changes to your change control process, and support their analysis with your data. When changes are approved, implement them as soon as practical. If a change you recommended is rejected, meet with the project team to investigate other ways to deal with the situation that the proposed change would have corrected.

If changes to the project objective are necessary, discuss your recommendations with your project sponsor. Support your proposal with compelling data, and seek approval, revalidating the project plan. You will need to replace any project plans and documents to reflect all recommendations that were approved and provide updated project plans to the project team. Archive all older versions of the project documents, marking them as obsolete.

After the review, use what you learned to get some attention for your project. Prepare a presentation to summarize the project's progress to date and your plans going forward. Invite stakeholders and people from related projects to attend. Use the presentation to report significant accomplishments and to publicly recognize the contributions by specific people and teams. In presenting information about the remaining project work, accentuate the positive, emphasizing the value and importance of the project. Use the presentation to renew enthusiasm for the project and motivate the project team.

Finally, personally thank your team members for their contributions. If team members work for other managers, acknowledge the contributions to them, too. When appropriate, suitably reward contributors for their efforts. Do not wait until the end of a very long project to recommend contributors for available recognition programs. Project reviews are also a good time to celebrate your accomplishments. Long projects, especially, need more parties.

Key Ideas for Risk Monitoring and Control

Panama Canal Risk Based Replanning (1908)

Project monitoring and prompt responses when necessary were among the main differences between the first effort to construct the Panama Canal and the second one. No project proceeds exactly as planned, and the U.S. canal project was no exception. It was ultimately successful because the managers and workers revised their plans to effectively deal with problems as they emerged.

As the work at Panama continued, for example, it seemed that the more they dug, the more there was to dig. Mud slides were frequent, and between 1906 and 1913 the total estimates for excavation more than doubled. The response to this problem was not terribly elegant, but it was effective. Following the report of a particularly enormous mud slide in the Culebra Cut, George Goethals remarked, "Hell, dig it out again." They had to, many times. Some risks are managed primarily through persistence and perseverance.

As time passed, a number of factors not known at the start of the project came into focus. By 1908, it became clear that new materials, including the steels to be used on the canal, were making possible the construction of much larger ships. Goethals made two significant design changes as a result of this. The first was to commit to a wider excavation of the Culebra Cut, increasing it to nearly one hundred meters (from 200 feet to 300 feet) to accommodate ships wider than thirty meters sailing in each direction. Although this represented much additional digging, it also made the tasks of ongoing maintenance and dredging a little easier.

The second change was to the size of the locks. Relying on Goethal's estimates of the size of future ocean-going ships, the locks were enlarged to be 110 feet wide and 1,000 feet long. Although conversion to metric units of these dimensions is trivial, few do it, as this somewhat arbitrary choice became the single most important factor in twentieth-century ship building. These dimensions are the exact size of the rectangular-hulled PANAMAX ships, the largest ships that can transit the canal. Apart from oil supertankers (which are generally designed for use on a single-ocean, point-to-point route), very few ships are built any bigger than a Panama Canal lock.

In addition to making the locks larger, Goethals made another change to them. All the water used to operate the canal flows by gravity. Locks are filled from the manmade lakes above them and then emptied into the ocean. During the rainy season, this works well. In the drier parts of the year, the depth of the lakes falls, and the water level in the cut that connects them could fall to too low a level to permit ocean-going ships to pass. To save water, Goethals redesigned each of the twelve locks with multiple sets of doors, enabling smaller ships to lock through using a much smaller volume of water.

One additional significant change was adopted midproject, primarily for security reasons. At the start of the twentieth century, the global political situation, particularly in Europe, was increasingly unstable. The geography of Panama has a long, gradual slope from the central ridge north on the Atlantic side and a much shorter, steeper slope on the south, facing the Pacific. On the steeper Pacific slopes, the locks in the original plan were visible from the water, and Goethals, a military man, feared that the canal might be closed down by projectiles fired from an offshore warship. To avoid this, he moved the Pacific locks further inland. The change actually made the engineering somewhat easier, as the new plan took better advantage of the more level land farther up the slope.

George Goethals managed risk through scrupulous management of all changes, insisting throughout his tenure that "everything must be written down." Once the plan was set, the debating stopped, and all the effort went to execution.

Related

Категории