Chapter 11
Monitoring and Controlling Risky Projects
“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 to the overworked people already on the project, which further slows their progress. 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 to 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. Periodic project reviews are necessary to keep the project moving and productive.
Don’t Panic
The main focus of this chapter is ongoing execution of a project with as few detours and aggravation as possible. Risk planning helps to reveal what might go wrong, and responds to much of it. However, project work is unpredictable, so things will happen. Effective project leaders strive to remain calm when problems arise. Risk management depends on level-headed analysis and prompt action, so work to remain composed. Recovery from problems not only depends on a prompt and appropriate response, it also depends on competent execution. You will stay on track more successfully by heeding Rudyard Kipling: “If you can keep your head when all about you/Are losing theirs and blaming it on you. . . .”
This is much easier to say than to do, but minimizing emotions and chaos in a crisis is the fastest route to problem recovery. Stress causes inefficiency and mistakes, and raises the likelihood of future risks, so do your best to keep things running smoothly throughout your project—even when things seem to be falling apart. Panic will only make things worse.
Applying the Plan
Predictable project progress depends on your baseline project plan. The plan is now the road map for your work, and you can begin tracking status and updating your project database with actual results. Status information is primarily useful in assessing progress, but it also provides early warnings for risks. Status data also supports longer-term risk management through process improvement during periodic project reviews and 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 it 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 as soon as possible allows schedule and other risks to remain undetected, grow, and ultimately overwhelm the 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
Specifics concerning project status collection and storage are basic decisions that you need to make 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, but 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. Online or e-mail status collection is most common, but any method that is effective and in writing can work.
On large, complex, multiteam programs, consistent data collection is essential, and the volume of status information can become quite a burden. One way to manage this is through a centralized project office, responsible for assembling, summarizing, and analyzing the data consistently for all the project teams. This ensures 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 status meetings are also usually weekly. When face-to-face meetings are not possible, 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. Online storage of project data is best, because it provides the project team access at any time. Determine the tools and systems to be used for collecting and storing the data, and set up appropriate security so that only team members who should be updating project information will be able to modify it.
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 includes the project metrics discussed in Chapter 9, and most of them are diagnostic metrics—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; it may also provide early warnings of future problems and risk situations.
Hard data Hard project data includes metrics that assess progress, including revised start and completion estimates for future work. Hard data collection should be routine, easy, and not too time consuming. 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:
• Schedule data, such as activities completed and activities scheduled but not completed, milestones completed or missed, actual activity start and finish dates, and duration remaining for incomplete activities
• Resource data, including actual effort consumed, cost data, remaining effort for incomplete work, and missing resources
• Data regarding issues, problems, and specification changes
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 individual team members having personal problems may also adversely affect upcoming project work. Soft data may also provide information on opportunities to help the project. Soft project data includes issues such as:
• Conflicts arising from expected new projects or other work
• Falling productivity of individual team members
• Suspected changes to the project environment
• Changes needed by your project that seem threatened
• Potential problem situations with a common, persistent root cause
• Frequent situations requiring more authority than you have
• Long delays getting resolution of escalated issues and decisions
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. Status data is your “dashboard” for the overall health of your project. Whatever data you decide to collect, be dogmatic in collecting it. Project risk management requires data, so do what you must to keep it 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 may be tempting in times of stress to skip a status collection cycle. Especially during significant problems, it is very risky to lose information. You may even find it necessary to intensify data collection during problems or near project completion.
Other things to guard against are collecting data and then not using the information, or misusing it. After you collect status, at least incorporate a summary of it into your overall project status report. When you fail to use what you collect, your team members will either stop sending it or will put no effort into supplying meaningful data. Misuse of status information can also be a major problem. When the status you receive is bad news, your first temptation may be to grab a chair and break it over the head of the person who sent it, 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 you raising this issue promptly. What will help get you back on schedule?” The sooner everyone begins to focus on recovery, the earlier things can get back on track.
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 opportunities for improved execution of future work, and negative variances need attention so that they do not send the project spiraling out of control. Trend analysis on the metrics may also reveal potential future risks and 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, any apparent opportunities) are real. For each difference, determine the root cause of the variance, not just the symptoms. (Root-cause analysis is explored in Chapter 8.) 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 will probably affect the others.
Armed with the underlying cause of each variance, you can best decide how to respond. Dealing with the root cause of a problem also prepares you for 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 following the slip can be compressed, 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, or it might reveal an analysis error that could invalidate duration estimates for later project activities.
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. Metrics related to the concept earned value management (EVM) are particularly useful in examining resource use throughout the project. EVM 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 less than one) but the schedule progress is adequate, there may be an opportunity to complete 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 CPI is higher than one or another metric shows your “burn rate” is too high—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 an adverse CPI variance 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 completed. Publicly admitting to this sort of problem is never easy, but if you wait it will be worse. Problems like this increase with time, and the options for recovery diminish later in the project. Sympathy from your project sponsors and stakeholders will drop from little to none at all if you wait too late to deliver bad news.
Some resource issues are acute, having impact on only a short portion of the project; others are chronic and will recur throughout the work. Chronic situations not only create project budget problems, they also may lead to frequent overtime and constant stress on project staff. Risk probabilities rise with increased stress and lowered motivation. Chronic resource problems may also have an impact on your ability to execute existing contingency plans.
Scope metrics Although schedule and resource data provide the most common status variances, at least some of the data 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 even foreshadow ultimate project failure.
If a scope-related metric exceeds the result expected, you should explore whether there might be an opportunity for the project to deliver a superior result within the same time frame and budget. It may even be possible to deliver the stated result sooner or less expensively. Although this situation is relatively rare, it does happen, and how best to exploit such opportunities may not be obvious. Discuss them with your project sponsors, customers, and other stakeholders before adding something to the project scope “just because you can.” Use your change management process to assess the value and utility of any additional product feature before incorporating it into the project.
When scope-related data indicates a problem that can be resolved with additional work, the impact may be to the project schedule, resources, or both. Consider various alternatives by analyzing what realistically can be delivered consistent with the project budget and deadline. Determine the most palatable option (or options) based on relative project priorities, and propose required changes to the project objective.
If you cannot resolve a scope problem with extra work, your only options are to modify the deliverable or to abandon the project. As with recognition of a resource overconsumption problem, scope underdelivery 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 that seldom works. The best course is to raise 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.” Although still painful and unpleasant, this is a lot easier than dealing with it later. When a project deliverable proves to be demonstrably impossible, the best time to change (or kill) it is early, not late.
In addition to the impact on the current project, scope problems may affect other projects. Inform the leaders of projects depending on your deliverable (or who may be using similar flawed assumptions), 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:
• Predicted schedule slip
• Budget or other resource requirements
• The effect on the project deliverable
• Impact on other projects
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.
Unfavorable trends detected early in the project can show the need for change when there is much more tolerance for it. Near the start of a project the objectives remain somewhat 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 help. 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, even small changes to the deliverable can be devastating to the team. 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 you can ship something on time is demoralizing and embarrassing. People identify with the work they do, so late project changes are taken 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.
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. Base your response plan on the specifics of the problem. If the variance is small, it may be sufficient to delegate the response to the team members responsible for the work affected. 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. In planning problem responses, work quickly, but seek good solutions.
When you have captured ideas for response, analyze how each will affect project schedule, resources, and scope. Probe for possible unintended consequences, both in your project and for other related work. 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).
Larger problems may require major changes. If so, submit each option you are considering to the change management process for review. For even more significant changes, analysis process could also involve fundamental replanning. If so, get buy-in from the project team and stakeholders for the revised plan. When necessary, revalidate the objective and baseline with the project sponsor, and update all affected documents.
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 department 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, escalation, 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 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 on projects presents a number of growing challenges. 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. As project teams 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. 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 are common. Cultural and linguistic diversity in technical work is becoming the norm, not the exception, for all types of projects. Finally, few technical projects are only technical. Cross-functional project teams involve people from very different educational and work backgrounds. It may be easier for an engineer in Ohio to communicate with an engineer in Japan than it is for them to communicate with the marketing manager down the corridor.
As the project leader, you are the person primarily responsible for project communication. You need to rise to these challenges and minimize project communication risk. 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 only data 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 is impossible. One common reason for long reports is a project leader who solicits individual reports from the whole team and concatenates them into a compendium running to dozens of pages. Time pressure 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, the result of rambling reports is increased project risk, because no one will have the patience or time to digest the entire report.
The best reports start with a short, clear summary, including current risks. Regardless of who you are sending a status report to, begin with a brief (twenty lines or fewer) summary. 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 additional needed information that is concise, honest, and clear. If you commit to weekly reporting on a specific day, do it. Understand what your stakeholders need to know and provide it in your reports, in a consistent place and format. Any important data that people notice is missing will probably result in unnecessary and time-consuming telephone calls or other interruptions.
Following your high-level summary, your project status report may include:
• A short description of each major accomplishment since the last report. This portion of the report is an excellent place to “name names” and to recognize individual and team accomplishments.
• Activities planned during the next status period.
• Significant risks, issues, and problems with your planned responses.
• A schedule summary, with planned, actual, and expected future dates.
• A resource summary, with planned, actual, and expected future resource requirements.
• Project analysis, including an explanation of any variances, issues, and plans for resolution.
• Risk analysis, including the known risks in the near project future and the status of any ongoing risk recovery efforts.
• Additional detail, charts, and other information as needed.
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, including various other periodic reports to support organizational needs. Other reporting also provides occasional opportunities for higher-level reporting and presentations. Such cases are an excellent opportunity to reinforce the importance of your project, 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 your team, and renew enthusiasm for the project. On longer projects, all of these factors can assist in avoiding future problems and risks.
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 they are discussed during status meetings. Holding regular status meetings, even via teleconferencing, is a potent tool for keeping difficult projects on track and risks under control.
One key to improving attendance at and participation in status meetings is to keep them short. Meetings are more interesting and energized if they focus only on important project information—what has been accomplished and what issues are pending. Problem solving and issue resolution are unquestionably important, but they rarely require the entire project staff to be involved, so delegate problem solving and extended discussions to smaller groups, and keep your meetings brief.
Effective meetings are well structured, sticking to an established meeting agenda. They also start on time, set time limits for the agenda items, and end early whenever possible. Face-to-face communication minimizes misunderstandings and reinforces teamwork, but may not always be possible. For teleconference meetings, minimize communication risks by:
• Using the best meeting technologies available
• Ensuring that the technologies used are familiar to all participants
• Verifying that the technologies to be used are compatible and functioning, and retesting them following any changes or upgrades
However you conduct your meetings, record what was discussed and distribute meeting minutes promptly to all project contributors (and to others as appropriate). File meeting minutes in your project archives.
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.
Successful project leaders create opportunities for these 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 in between. A great deal of “soft data” and valuable project information on project risks surfaces during casual exchanges. Effective project leaders also 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 Archive
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, it is essential for capturing the lessons learned during postproject analysis, and it contains data that can improve risk management on future projects.
A typical project archive contains:
• Project definition documents
• All project planning documents
• Each project status report
• Other periodic project reports and communications
• A change control history
When the project is completed, the final addition will be the post-project retrospective analysis and lessons learned.
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, 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.
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 a project review, one of three scenarios will arise. Some reviews find few issues and the project will proceed as planned. Other reviews will reveal changes or additional planning that is necessary, and the project will continue, but only after modifications. The third possible outcome of a project review is a recommendation to cancel future project work. Although this is not pleasant, it is ultimately better for everyone to cancel a project that will eventually fail before spending even more time and money.
Whatever other agenda items you set for your project review, plan to explicitly reassess your risks and analyze your reserves. Discuss the problems and risks you have encountered in the project so far, and brainstorm methods for avoiding similar trouble as the project proceeds. 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 your risk register and reassess all of them, rank-ordering the risks based on current information. Develop appropriate risk responses for any significant risks that have none.
As you review your risks, also reassess the overall risk profile for the project. As projects proceed, things change and overall risk changes with them—either increasing or decreasing. As the work proceeds and more is known, project-level risk should decrease, but every project is different and it is prudent to reassess. In particular, review the usage of any reserves established for the project. If contingency funds have been depleted faster than anticipated, determine what might be done to replenish them. If you have used most (or all) of your schedule reserve, consider options for increased staffing, revision of the deadline, or other alternatives.
After your review, document what you discussed and learned. If changes to the project objective or reserves are necessary, discuss your recommendations with your project sponsor and use your change processes to implement them.
A project review is also a good opportunity for recognition and celebration. Prepare a presentation to summarize the project’s progress to date, and your plans going forward. Use the presentation to report significant accomplishments and to publicly thank specific people and teams. 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. Project reviews are also a good time to celebrate your accomplishments. Long projects, especially, need more parties.
Taking Over a Troubled Project
This chapter ends by exploring one additional project execution risk. As the PERIL database shows, staff turnover is a significant problem. It can be an especially personal one if the turnover results in your being asked to lead a failing project. This unfortunate situation is one of a project leader’s worst nightmares. Even if you inherit a project that appears to be in pretty good shape, it’s best to respond to such a request with, “I’ll take a look at it and let you know as quickly as possible if any changes or adjustments might be needed.”
Your first order of business is to find out whatever you can about the project and get to know the team. Although it may be interesting to dig into why the prior project leader is no longer in the picture, this can probably be left for later unless the information will contribute to project recovery.
Learning about the project can begin with a review of project documents and other information in the project archive and elsewhere. If there is a well-maintained archive of project information in a PMIS, it will be invaluable. A new project leader who has access to such data still faces a daunting task but will be light-years ahead of where he or she would otherwise be. On a troubled project, though, there may be little useful information. You may need to do the best you can to quickly fill in the gaps.
For current information, spend time reviewing recent status reports. Be skeptical and verify any information in them that is inconsistent with what you see. Discuss the project with each project contributor, and use these conversations to solicit suggestions for change, to build your understanding of where things are, and to start establishing relationships and trust. Avoid making predictions or firm commitments while you investigate, but do communicate openly and let people know when you expect to have better answers.
If there is little concrete (or credible) information, you will need to initiate a very fast planning effort to develop some. Even if there is data, at least do a quick project planning review to validate it. Someone else’s plan can be a good starting point, but it won’t serve as a credible foundation for project execution until it’s yours. An “express” planning exercise should include, at minimum, detailed examination of all current and pending activities, verification of the project’s committed scope, timing, staffing and funding, and documentation of all currently identified issues and problems.
There are a number of reasons that projects may be viewed as failing, so determine what the main problem (or problems) are. Some typical issues include:
• Schedule delays
• Excessive resource consumption
• Insufficient staff or other resources
• Scope not achievable using available technologies and capabilities
• Low priority
• Conflicts with other projects
• Weak sponsorship
Recovery requires prompt action, and the best strategy for this comes from the medical field: triage. Once you have determined what is not going well and listed all the project activities and issues needing attention, sort them into three categories. Some things need immediate attention and will result in permanent damage to the project if not addressed immediately. Identify and staff this work, stopping other activities with lower urgency where necessary. Other matters on your list need attention but not right now, so put them aside for the present and plan to address them soon. Other matters listed may be hopeless. Note these and move on.
This last category is potentially very revealing, because these legitimate project problems may provide evidence that the project cannot be completed. Even the issues that you are able to manage and resolve may require more resources, time, or both than can be justified. Schedule time with the project sponsor to review your response actions and the overall project. Plan to discuss modifications to the project or even cancellation. Not all troubled projects can be fixed, and it’s better to pull the plug on a doomed project sooner rather than later.
If the project is recoverable, your next steps after resolving the short-term problems will be to schedule an in-depth project review, as described above. Your goals for this are to understand the project and engage the project team in developing current and realistic project planning information, including updated risk data. Once you have the truck back on the highway, invest the time it takes to ensure that you can keep it there and out of the ditch. Tools for this are found throughout this book.
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 100 meters (from 200 feet to 300 feet) to accommodate ships wider than 30 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. Based on Goethals’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 simple, few do it, as this somewhat arbitrary choice of dimensions 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 man-made 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 connecting them could fall too low 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 minimized 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.