Conclusion

Overview

"Whether you think you can do a thing, or not, you are probably right."

—HENRY FORD

Risk management processes provide a way to learn whether your project is feasible—whether you should think you can do it. A feeling of confidence, based on credible information, is a powerful determinant of success, and project risk information is a key source of the data that people need. When the verdict of the risk assessment is poor, it leads you to better alternatives.

This book contains a wide range of ideas and techniques for project risk management. It is fair to ask whether all of these are always necessary, and the answer to that is simple: No. Each is essential to some projects at some times, but it is hard to imagine any project that would benefit sufficiently from everything discussed in this book to justify your doing all of it. Besides, some of the concepts covered represent alternative approaches to similar ends and would be redundant.

So, how much is appropriate? The answer to this, like the answer to every other good question relating to project management, is also simple: It depends. Technical projects vary so widely that there can be no "one size fits all" answer. The trade-off between the value of risk information developed and the effort and cost associated with obtaining it always makes deciding how much project risk management to do a judgment call.

That said, there is at least one useful guideline. Do enough planning and risk management to convince yourself that the project is, in fact, possible. The quotation from Henry Ford is applicable to projects of all kinds. People successfully deliver on ridiculously difficult objectives with amazing regularity when they believe that they can. When people are confident that they will be successful, they persist until they find a way to get things done. Conversely, even the most trivial projects fail when the staff working on them lacks confidence. The staff's belief in failure becomes self-fulfilling; no one puts in much effort—why bother?

Demonstrating to all concerned that your project is at least plausible defines the minimum investment in project planning and risk assessment that is prudent. If you can do this with informal discussions and capture the necessary information on index cards or yellow sticky notes, do it that way and get to work. If your project warrants more formality, and most technical projects probably do, determine what you need to do to provide confidence to the project team, and establish a baseline for status tracking and change management. But remain practical. Getting more involved than necessary in computer tools and complex assessment techniques is just as inappropriate to project and risk management as doing too little.

The most successful strategy for making permanent process improvements is to define your objective clearly, in measurable terms, and then to make small process additions and adjustments over time, assessing whether they are effective and helpful. Continuing this strategy over a sequence of projects will result in good control of risk at an acceptably modest cost in time and effort. Adding a lot of new overhead to a project environment all at once is not only expensive but also distracts at least the project leader from other project issues, often creating more problems than it solves.

Think about all the ideas and techniques in this book in the same way that a craftsman views his tools. In the tool set there are tools that are used every day, tools that are used only once in a while, and even a few tools that have never been used, at least so far. The entire set of tools is important because even the unused tools have applications, and the craftsman knows that when the need arises, the right tool will be available.

If you are currently doing very little to manage risk, consider the suggestions that follow. If the situation improves, this may be enough. If problems persist, add a few more ideas, and keep trying. While risk can never be eliminated from projects completely, it can always be reduced, often with relatively minor incremental effort.

Scope Risks. Minimize risk by thorough definition of project scope. Every aspect of the project deliverable that remains fuzzy, ill-defined, or "flexible" represents a very real failure mode. If you do not know enough to define everything, convert the project into a sequence of smaller efforts that you can define, one after the other, and perform reviews and testing as the interim subprojects complete. As you proceed, refine the scope definition and the next steps. If actually breaking the project into incremental pieces is not feasible, use a straw-man specification to document as much specific detail as you can, and invite criticism. Always validate the scope definition with project sponsors, customers, and key stakeholders, and set the expectation that every scope change will require significant justification.

Schedule Risks. Project planning is the foundation for managing schedule risk, and planning for the immediate short-term activities (at minimum) is never optional. Starting from the profile for the work, identify all the project activities that are similar to past work that has caused trouble. For every project estimate, set a range based on your confidence, or, better yet, probe for the worst cases and document their consequences. For projects that carry significant risk, negotiate some schedule reserve, but establish a credible plan that could complete at a date prior to the committed deadline.

Resource Risks. Most resource risks relate to bottlenecks and constraints. Past project resource problems are likely to recur unless you develop plans to avoid similar situations. Perform sufficient resource analysis to reconcile your requirements and skill needs with the project budget and available staff. For particularly risky projects, negotiate a budget reserve.

General Risks. Examine your plan, and brainstorm probable risks with the project team. List known risks, and determine probability and impact for each risk, using at least "high/moderate/low" assessments. Prioritize and distribute a list of significant risks, even if you use the list only to make the project exposures visible. Develop prevention or recovery strategies, as necessary, for substantial risks.

The remaining minimum requirements for risk management relate to tracking and change control. Dwight Eisenhower said, "In preparing for battle I have always found that plans are useless, but planning is indispensable." Eisenhower recognized the fact that few things ever go exactly as planned, which is especially true for projects. The exercise of planning never predicts the future precisely, but it does provide what you need to measure progress and quickly detect problems. For risk management, tracking progress at least once a week for all current project activities is prudent. Failure to do this periodic monitoring allows project slippage and other problems to quickly expand and cascade, and they can soon become insurmountable. Dogmatic, frequent tracking of project work is crucial to ongoing risk management. Through disciplined tracking, you can detect many risk situations while they are small. Small problems can be resolved quickly, preserving the project plans and objectives; large problems can easily take a project down.

Project control is also central to risk management. During a running project, there are many things going on that a project leader cannot control. Use the controls you do have to your best advantage. One of the most important controls the leader does have is the process for managing project changes. Projects with no ability to control specification changes are almost certainly doomed. Another thing leaders control is the flow of information. Use project reports, meetings, and discussions to communicate risks and to keep project issues and progress visible.

Long-term improvement of project risk management relies on postproject analysis. Through this, you can assess project results and make recommendations for more (or different) processes devoted to risk management and project planning, execution, and control.

Failure-proofing difficult projects requires three things. The first, thorough planning based on stable specifications, is the primary subject of this book. The second is diligent tracking and control of changes, the topics of Chapter 11. The third requirement, which is project-specific and beyond the scope of this (or any single) book, is technical expertise.

Risk management is much easier when you are lucky, and this third element of success represents the most obvious way to boost your luck. To the best of your ability, staff the project with a range of skills, including specialists in each field that the project is likely to need. Projects with experienced practitioners are much better equipped to deal with the twists and turns in a typical project trajectory. Recovery from risks is quick and effective when there are a few battle-scarred veterans who know what needs to be done and what has worked in the past. It also never hurts to recruit at least some people for the project who have reputations as generalists known for their problem-solving talents. Once your team is together, you can boost your luck further by rehearsing contingency plans for significant potential problems, so that if you need to use them, you will be competent and efficient.

Through all of this, never lose sight of the main objective: to manage your project to successful completion. The project management ideas presented here are components of the means to this end. Treat the ideas and concepts of this book as your risk management toolbox. When it makes sense, use the processes just as they are described. You may need to tailor other ideas to make them work in your environment. If a risk management idea promises you little current value, hold it in reserve. Above all, persevere. Inside every project that seems destined to fail lies a perfectly credible one, waiting for you to break it free. Also remember that a little risk is not a bad thing; to quote Ferengi Rule of Acquisition 62, "The riskier the road, the greater the profit."


Panama Canal The Next Project

Projects have a beginning and an end, but they are generally part of a continuum of activities stretching back into the past and forward into the future. For the remainder of the twentieth century, the basic operation of the Panama Canal was largely unchanged, except for ongoing maintenance, widening of the cut, and a new dam built upstream in the 1930s to ensure continuous operation through the drier seasons. A plan in the 1950s to replace the canal with Ferdinand de Lesseps's imagined sea-level canal using thermonuclear bombs for the excavation was taken seriously for a time, but (fortunately) it was shelved.

As the twenty-first century begins, so does a new era for the canal. Following the 1999 turnover by the United States, the canal is now operated by Panama. It remains a vital link in world shipping, but, to ensure its viability in the future, the first major operational change in the nearly ninety-year life of the canal—the addition of a third transit through the isthmus—is now in the planning stages. A new set of locks, parallel to the existing locks on the Atlantic and the Pacific sides of the canal, are proposed that will be nearly twice as wide, 40 percent longer, and 25 percent deeper. This new route will permit transit of larger ships in addition to quicker transit for the PANAMAX freighters that currently use the canal. The new locks will hold nearly four times the volume of water required to operate the current locks, and their use will require massive dredging to allow the existing lakes to supply enough water. The magnitude of this overall effort is comparable to the original project, so it will be interesting to see which of the earlier projects the new endeavor will most resemble.




Identifying and Managing Project Risk
Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project
ISBN: 0814413404
EAN: 2147483647
Year: 2005
Pages: 130

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