Early in February 2004, Tom DeMarco and I conducted an outsiders' risk assessment on a large project. It is a service we often do together for our clients around the world. This particular project, now in its early stages, expects to conduct many rollouts into production over the next three years, to a final, complete, integrated system.

Tim Lister

We interviewed project managers, stakeholders, team leads, system consultants, and business area experts. We also looked at existing project documents, such as the project charter, budget, methodology, plan, and schedule. The plan and schedule we reviewed on this project are typical of such documents that we see on large efforts. Together, they show clusters of high-level tasks delivering functionality to different parts of the organization at expected delivery dates. These rollouts are not sequential, they overlap; so, as called for by the schedule, when Rollout 2 will be in final test for Business Area A, Rollouts 3 and 4 will be underway, delivering functionality to Business Areas some time after the delivery date of Rollout 2. Often the rollouts are dependent on previous rollouts. Business Area A is assumed to get certain functionality from Rollout 2,and then Rollout 5, based on the assumed success of Rollout 2, will complete the sum of new functionality for Area A.

As it usually goes, the plan is "aggressive." There is little slack time to recover if anything goes wrong. The plan is a combination of estimated effort and desired duration. Some rollouts have deadlines that have recognized business benefit. For example, certain financial features need to be in place in some business areas before the end of the organization's fiscal year, or the cost of closing the books will jump up.

The project, like most large efforts, is full of risks. There is new technology being deployed by a staff with very little in-depth experience in that technology. Some functionality is being delivered by a package which will go through a significant upgrade after the rollouts start, but before they are all done. Control and decisions will shift within the organization, so some groups will be net losers, will be less powerful, once this implementation is complete. The people we talked to are well aware of these particular risks, and also aware of many more.

What they haven't considered is the management part of risk management. They can identify risks, but they have taken no action; they have not planned what to do when some of those risks turn into actual problems.

In our discussions with these groups, we asked what will happen if the project strays from the plan. Tom often asked, "What are the plans for a smooth degradation of the original plan?"

This is a wonderful question from the perspective of risk management, because it cuts to the issue of whether all the people who care about the success of the project can agree on what is most important about that project. Art Gemmerer, a leader in Risk Management at Rockwell Collins, and in the U.S. for that matter, says that, "Risk Management is a conversation." Risk identification is observation; and Art is absolutely right, risk management is a conversation.

By asking the question, what do we do if the project is a month behind schedule, two months late, six months late, a year late, two years late, we can hear where the different constituents of the project believe there is flexibility, and where the line must be held. We have all been educated that the degrees of freedom on a project are duration, functionality, and funding. Asking what we should do when we are behind schedule is always informative because the single project plan, showing in detail how we'll make the milestones, the delivery dates, and the rollouts, has a hidden message built inside it. It says: If we are late we just press on with what we originally planned to do, and we will slide the schedule to the right.

You and I know that that is rarely the preferred answer. How many times have you been in an 11th hour, save-the-date, jettison-functionality release re-planning meeting?

Asking what we should do if we fall behind is hard to do if you have never asked everyone before. It sounds like you have no faith in the original plan. No, you just have some faith, just not complete faith in that plan. We all know the plan has an element of "most preferred outcome," rather than "most likely outcome" in it.

I want you to consider building a continuum of project plans. At the planning stage, you have the most options, and the lowest worry. It is the most appropriate time to find out what matters most as we venture out into the unknowns of complex projects. Wouldn't it be nice to know that when it is apparent that Plan A can not succeed, that you truly have an agreed upon Plan B, and if necessary Plan C, all set to go?

A single plan is harmful; people may believe it is the inevitable truth, not just one of many plans. Remember the adage: When people plan, God laughs.

— Tim Lister, New York, March 2004.

说得好呀...When people plan, God laughs.....