|
|
プロジェクトのリストは、次の 2 点によって判断されます。
またはリスク = 影響 x 可能性 たとえば、プロジェクトの最終レポートを印刷することには、印刷前に停電になるリスクが含まれているとプロジェクト マネージャーが考えたとします。 しかし、停電は起こりそうもないので、このリスクは問題なく無視できると考えられます。 計画するのにふさわしいリスクとしては、株主向けの複雑な高品質のレポートを印刷する印刷業者に空きがないことがあります。 このリスクに対処するには、プロジェクト マネージャーはレポートの印刷のための十分な期間をスケジュールに見込む必要があります。 プロジェクト管理ガイドの他の記事については、「プロジェクト管理のロード マップ」を参照してください。 |
開始前のプロジェクト管理のヒント . . .
リスクが高い活動の例
次に、プロジェクトのリスクを高める可能性がある典型的な活動の例を挙げます。
|
リスクの高い活動 |
説明 |
|
|
クリティカル タスク |
クリティカル パスにあるタスクに特に注意します。 このようなタスクは、プロジェクトの終了日に最も大きい影響を与えるためリスクが高くなります。 |
|
|
ベンダー タスク |
ベンダーと契約している場合、社内のチーム メンバーからよりも、短い間隔で詳しい進捗レポートの提出を依頼するようにします。 プロジェクトの最後に発生するベンダー タスクは、その他の時期のベンダー タスクよりもリスクが高まります。 「ベンダー」には社外の契約者と社内の他の分野の社員の両方が含まれます。 この理由は、自分のチーム内の人々よりも管理しにくく、プロジェクトの成果に対するリスクの点では同様に扱う必要があるためです。 |
|
|
経験不足のチーム メンバー |
経験不足のメンバーをプロジェクトの終盤の業務に割り当てると、これらのメンバーは成果を出すまでに時間がかかる場合があるため、プロジェクトの終了日が危うくなります。 このリスクを抑えるため、新人には十分な時間を設けたスケジュールを設定します。 |
|
|
1 年を超える長期プロジェクト |
1 年を超える長期プロジェクトは見込みが立ちにくいため、リソースの可用性、テクノロジーの変化、市場の変化などの要因によるリスクをより多く含んでいます。 |
|
|
同時に発生するタスクが多すぎる |
同時期に予定されているタスク数が多すぎないかどうかを確認します。 タスクを実施するのが別の人であっても、多数のタスクが同時に行われると、特にプロジェクト終盤の場合はプロジェクトのリスクが高まります。 |
|
|
スケジュールを適切な順序で設計する |
開始時点で、プロジェクト マネージャーはタスクの概要を把握する前にタスクを関連付ける誤りを犯すことがあります。 これは、混乱とやり直しを招く原因になる可能性があります。 新しいプロジェクトを開始するときは、まずタスクを列挙してグループにまとめ、プロジェクトの全体像と成果物を把握できるようにします。 その後でタスクを関連付け、タスクの終了時点をスケジュールの理想的なタイミングに合わせます。 |
|
|
過去の軽視 |
プロジェクトの誤りを記録していないと、将来のプロジェクトでも問題が繰り返されます。 プロジェクトの最後には、今後のプロジェクトでリスクを繰り返すことを最小限に抑える目的で結約書を作成するとよいでしょう。 |
リスクの管理方法
次に挙げる要領は、プロジェクト マネージャーがリスクを管理するときに役立ちます。
|
リスクを回避する |
プロジェクトの活動が重大な結果になる場合、回避するのが得策です。 たとえば、2 つの成果物に対して同時に製造工程を実施すると、プロジェクトの時間調整がかち合う可能性があります。 そうするのでなく、プロジェクト マネージャーは製造工程を順番に実施することで、リスクを回避できます。 |
|
リスクを緩和する |
リスクの可能性を軽減する方法を探します。 たとえば、革新的でコストが高い製造工程があり、導入に時間がかかりすぎるのであれば、簡単でよく知られた製造工程を採用するのがよい場合があります。 |
|
リスクを転化する |
外部ベンダーにリスクを移転することで、リスクを管理します。 たとえば、コンピューター サブシステムのドキュメントの範囲が、内部リソースが時間に間に合わせられないほど広くなりすぎた場合、部分的に外部ベンダーに委託します。 |
|
リスクから学ぶ |
リスクは悪い一方ではありません。 リスクからチャンスが拓けることもあります。 たとえば、プロジェクトのリスクを調べたことで、大規模製造工程の一環として開発予定のソフトウェア サブシステムが、単独の商品として売り物になる可能性があることに気付いたとしたら、今後のそのサブシステムの開発に最も優秀なエンジニアを割り当てると決めることができます。 経験あるエンジニアをプロジェクトから外すことで、プロジェクトに別のリスクが高まる可能性がありますが、代わりに得られるチャンスで相殺できるかもしれません。 |
リスクを管理する
|
リスクのあるタスクを明らかにするためにスケジュールの進行状況を追跡する場合は、プロジェクトのベースラインの設定について学習する必要があります。 |
|
|
リソースがプロジェクトでどの程度効率的に使用されているか、割り当て超過または割り当て不足のリソースを調整する必要があるかどうかを確認します。 |
|
|
チーム メンバーからのタスクの更新を確認し、リスクがどこにあるかを調べます。 ガント チャートを使って進捗状況をすばやくトラッキングするか、高度な達成額の分析を使うことができます。 |
|
|
プロジェクトの終了日に最も大きい影響を与えるタスクを表示します。 まず、これらのタスクを確認してスケジュールのリスクに対処します。 |
|
|
プロジェクトに潜むリスクは、1 つの観点からでは見つかりません。 さまざまな観点からプロジェクトのリスクを積極的に調査します。 |
|
|
獲得価値分析を使用すると、進行状況のリスクを特定するのに役立ちます。"このプロジェクトでこれまでに行った作業の量を見ると、どの程度のコストを費やしていたのか" のような質問を行うことができます。 または "時間に合って終了しますか? |
|
|
リスクに対処するためにプロジェクトを管理すると、スケジュールの中でタスクを動かすことになります。 プロジェクトを変更すると、時間、コスト、またはスコープが必ず犠牲になります。 |
|
|
リスクを計画し、スケジュールを調整すると、プロジェクトが予期せずタスクを移動する可能性があります。 大きな "理由" を理解する プロジェクトの強力なスケジューリング エンジンの背後にある。 |
|
|
プロジェクト コストの入力後、コストを調べ、予算を脅かすリスクが生じていないことを確かめます。 |
