プロジェクトのリスク管理には、リスクを特定し、定量的に評価し、管理することが含まれる。すべてのプロジェクトには、一定のリスクがある。新しい技術を使うプロジェクトでは、その技術が期待通りの働きをしない恐れがあり、高度に複雑なプロジェクトは、必要な時間と費用を正確に見積もることが難しい。また、小さく、単純なプロジェクトでさえ、リスクの要素はある。
すべてのリスクを取り除くことは不可能であり、だからこそ、プロジェクトの失敗を防ぐために、リスクを特定して管理しようとするわけだ。プロジェクトの承認を得るためには、リスクをきちんと定義し、コントロールするためのリスク管理計画が必要となる。
しかし、不意に襲ってきて、プロジェクトを完全に脱線させてしまう未知のリスクについてはどうだろうか？リスク管理はプロジェクト管理の重要な部分であると考えられているが、そういった事態にも役に立つだろうか？もし役に立たないとすれば、予測不可能なものを予想し、コントロールするために、時間とエネルギーを投資すべきだろうか？
リスク管理計画を持てば、プロジェクトマネージャーが不測の事態（経済的な問題であれ、ほかの問題であれ）を計算に入れ、プロジェクトの最中におこる可能性がある出来事を把握して、それに備えることは可能だという議論には説得力がある。しかし、もしリスクが既知のもので、予想できるのであれば、その事態が起こる可能性は高いわけで、単にそのリスクに対処するための追加タスクをプロジェクトのスケジュールに組み込めばいいだけだという議論もあり得る。例えば、仕様の不完全性や不正確さの問題を避けるために、プロジェクトの途中で仕様のレビューを行う時間を取るべきだし、定期的に顧客とのコミュニケーションを改善するための時間も割り当てておくべきだ。
多くのリスク管理計画は、あらゆるプロジェクトに当てはまる同じようなリスクを列挙した、標準的なテンプレートにすぎない。例えば、文書にない仮定や、タスク見積もりの正確性の欠如、チームの中心メンバーの異動などだ。確かに今では、どのプロジェクトにもこういった不確定要素が存在することはよく知られている。
潜在的なリスクについてよく知っているのであれば、そもそもなぜそれを「リスク」と呼ぶのだろうか。それらは単に、新しいことをやろうとする際には常に存在する不確実性ではないだろうか。実際、Stephen Ward氏とChris Chapman氏は、「Transforming project risk management into project uncertainty management」（プロジェクトリスク管理をプロジェクト不確実性管理に変える）という論文で、現在の「リスク」という言葉の使い方に異議を唱えている。
では、リスクの計画と管理は実際的な目的に役立っているのだろうか、それとも単に問題が発生した時の責任回避のためにあるのだろうか。あるいは、予算が超過した理由を説明するためにあるのだろうか。プロジェクトを承認プロセスで認めてもらうために、必ず起こるであろう「リスク」があるにもかかわらず、それらへの対処費用を計上しない予算を立てようとしてそう呼んだのかもしれない。あるいは、費用の問題ではない場合もあるだろう。失敗のリスクがあまりにも高く、リスクをすべて表に出せば承認されない可能性が強いが、それでもそのプロジェクトを推進したい上級役員がいるということも考えらえられる。現実のプロジェクトは、数多くの相反する要素の影響を受けており、あるプロジェクトが承認されない理由さえ分からないこともある。
