プロジェクト・マネジメント-課題 | 项目管理

課題

課題プラクティスの目的は、課題を収集して評価し、プロジェクトのベースラインに対する変更をコントロールする。

プロジェクトは、組織的および環境的変更が絶え間なく続く状況で発生します。プロジェクトのスコープが広く、期間が長いほど、課題や潜在的な変更に対応する必要の発生確率が高くなります。課題マネジメントはプロジェクトのモニタリング機能の中心であり、プロジェクト・マネジメント・チームのメンバーが課題をフィルタリングまたは検閲する場合、プロジェクトは組織および環境の状況変更に対応できません。

定義: 課題: プロジェクト・マネジメントの検討を必要とするプロジェクトに関連するイベント。課題はプロジェクト中にチーム・メンバーまたは利害関係者によっていつでも提起され、プロジェクト・ログに記録される可能性があります。

定義: 変更: 変更は、プロジェクトのベースラインを構成する承認済みの成果物に対する修正として定義される。変更は適切な権限を委任された個人または役割によって承認されるまで、プロジェクトのベースラインに組み込まれません。

定義: プロジェクトのベースイン: 変更コントロールの対象となるマネジメント成果物とプロジェクト成果物の現在の承認済みバージョン。評価される前に課題を判断しないことが重要です。変更は回避すべきものではありません。変更はすべてのプロジェクトで生じます。無視するのではなく、対処する必要があります。重要なのは、対応力のある、コント口ールされた方法で変更に対処する。

ガイダンス

課題マネジメント・アプローチは、次によって構成されます。・ベースライン: 変更コントロールの対象となるものについて説明するもの・課題解決: 課題を特定、把握、評価し、解決策を提案する方法・変更コントロール: プロジェクトのベースラインに対する変更のコントロール方法について説明するもの・変更に関して委任された権限: プロジェクト委員会から権限を割り当てることで、対応力のあるコントロールされた方法で変更に対処する・変更予算: 変更に備えるための計画において確保された金額

1. ベースライン

変更はプロジェクト委員会によって理解および承認されたプロジェクトへのインパクトの観点からのみ評価できます。効果的な課題マネジメントと変更コントロールにおける必須条件は、変更の分析とコントロールを可能にする成果物のべースラインを作成する。変更が承認および実施されるたびに、成果物の新しいバージョンが作成されます。変更コントロールにより、関係者は変更がいつ行われたかを特定し、適切な権限によって行われた決定まで追跡できます。課題マネジメント・アプローチは、提供される成果物の性質(「何」)と計画立案されたデリバリー活動(「どのように」)によって決ります。したがって、通常、このアプロ一チの準備は成果物記述書とワーク・パッケージ記述書の準備に従います。

サイズ、規模、複雑性に関係なく、プロジェクト・マネジメント・チームは次の内容を判断する必要があります。・成果物をベースライン化する必要がある適切なレベル・一般的にコンポーネントを単独でリリース、導入、置換、修正できるレベルに達するまでプロジェクト成果物を分解して、レベルを判断する。・実施するコントロールのレベルは、プロジェクトの重要性と成果物間の関係の複雑性を反映する。・成果物とそのバージョンの特定方法・一般的に何らかの種類のシステムを確立し、各成果物に固有の識別子を付ける必要がある。・成果物に関するどのような情報を把握してプロジェクト・ログに保持する必要があるか(バージョン、ステータス、他の成果物との関係など)。・ベースラインの承認に必要な特定の権限と認可。・課題と変更を把握して管理するための手順。成果物の実際のステータスが成果物の認可された状態を反映していることを定期的に検証し、相違がないことを確認することがグッド・プラクティスです。通常、これはレビューまたは監査を通じて行われ、一般的には各ステージの終了時とプロジェクト終了時に実施されます。ほとんどの場合、プロジェクトのベースラインはさまざまなシステムで管理されます。マネジメント成果物は、各バージョンとその承認日を示す簡単な方法で文書として維持される場合があります。スペシャリスト成果物には専用のシステムが必要な場合があります。プロジェクト・ログの成果物登録簿の要素には、プロジェクトのベースラインに対するすベての変更の承認と実施を記録します。

2. 課題解決

すべての課題を次のいすれかに分類する・問題または懸念事項・プロジェクト外部のイベント・ビジネス機会・変更要求・仕様外項目これは評価を支援し、繰り返し提起されている課題タイプで、プロジェクト・マネジメントの別の側面が機能していないことを示唆するものに関する貴重なデータも提供します。課題の分類を評価するときは、課題が実際にリスクであるかどうかを確認することがグッド・プラクティスです。区別するべき点は、リスクが不確実であるかどうかです。(この場合、課題をリスク登録簿に移転し、リスク・マネジメント・アプローチの手順に従います。同様に、リスク登録簿に不確実ではないエントリが含まれているかどうか、それゆえ課題として管理するかどうかをレビューして確認することもグッド・プラクティスです。)

定義: 問題または懸念事項: 問題はすぐにマイナスのインパクトを受ける課題。懸念事項は適時性とインパクトを評価する必要がある課題。多くの場合、課題はプロジェクト・チームのメンバー間の会話やコミュニケーションで最初に非公式に提示されます。ほとんどの場合、問題や懸念事項への対処方法は判断の問題です。(あまりにも多くの問題や懸念事項を課題として捉えると、プロジェクト・マネジメント・チームは些細な決定で溢れかえり、最も重要な決定から注意がそれてしまう可能性があります。一方、プロジェクト・マネージャーは問題や懸念事項をフィルタリングしたり、事前に判断したりしないようにします。)課題を早期に特定することは、承認された許容度の範囲内で一般的に解決できる場合に、最も効果的です。場合によっては、課題はプロジェクト外部のイベントであり、プロジェクトに何らかのインパクトを与える可能性があります。プロジェクトの外部環境を定期的にモニタリングすることが常に推奨されます。

定義: ビジネス機会: プロジェクトまたはユーザ一組織にとって、予期していなかつたプラスの結果を示す課題。すべての課題が悪影響をもたらすわけではありません。場合によっては、プラスの結果を伴うビジネス機会を表す課題が発生します。インパクの評価と可能な解決策を準備する際にプロジェクト委員会の助言を求めることは有用です。課題は課題登録簿に記録します。(課題によっては、課題登録簿に記録された詳細で十分に課題の検討とアクションの合意を得られる場合があります。ただし、一部の課題ではより詳細な分析が必要となり、その場合は課題報告書が作成されます。課題報告書では課題の種類を特定し、プロジェクトのベースラインへのインパクトを評価し、課題の解決方法を推奨します。課題に関連する決定と処置は、課題登録簿に記録します。) 場合によっては、課題またはその解決がプロジェクトのベースラインへの変更を表すことがあります。その後、変更コントロール手順を通じてこれに対処する必要があります。

3. 変更コントロール

定義変更コントロール: プロジエクトのベースラインに影響を与える可能性のある変更が特定および評価されてから、承認、却下、延期されるプロセス。変更要求: ベースに対る変更の提案。仕様外項目: 品質仕様を満たさない成果物。条件付き承認: 仕様外項目のうち、プロジエクト委員会が是正処置を要求せすに受け入れるもの。すべてのプロジェクトには、プロジェクトのベースラインへの変更をコントロールするための適切なアプ一チが必要です。課題マネジメント・アプローチは、プロジェクトのベースラインを変更する提案を記録および決定する方法など、プロジェクトの変更コントロール手順を説明します。変更要求では変更が提案されているマネジメント成果物を特定し、変更を行う正当な理由を提供する必要があります。変更に関連するコストがある場合、その資金源は承認された変更予算または追加資金のいずれかとして特定する必要があります。仕様外項目は、サプライヤーが品質仕様に完全に準拠した成果物を提供できなかった場合に最もよく発生します。承認されたプロジェクトのベースラインと提供された成果物の間の相違を表しており、この相違は変更コントロール手順を通じて対処する必要があります。仕様外項目が受け入れられた場合は、影響を受ける成果物記述書を反映するようにプロジェクトのベースラインを変更する必要があります。受け入れられた仕様外項目は条件付き承認と呼ばれ、プロジェクト委員会の承認、または委任された変更許可委員による承認が必要です。仕様外項目が却下された場合、チーム・マネージャーはプロジェクト・マネージャーと相談して、変更予算の使用や例外報告書の提出など、状況を修正する方法を検討する必要があります。課題に変更または仕様外項目の要求が必要な場合、タイムリーな意思決定を可能にするために、課題報告書には提案された変更の詳細を含めます。

4. 変更に対する委任された権限

変更要求と仕様外項目のレビユーと承認に関しては、プロジェクト委員会が最終権限を持ちます。ただし、プロジェクト委員会は変更を承認する権限を委任できます。(効果的な変更コントロールのための権限の委任は、効率性とコントロールのバランスが重要です。委任が少なすぎると、プロジェクト委員会は進捗を遅らせたり、他の人が決定できる変更のレビュ一を依頼されたりする可能性があります。一方、委任が多すぎる場合、特に多くの異なる役割への委任が多すぎると、ビジネス正当性との整合性が希薄化するため、プロジェクトの全体的なベネフィットが低下するリスクが高まります。) 多くの変更が発生する可能性が高いプロジェクトでは、プロジェク卜委員会は一部の決定を委任することもできます。実際には、変更の大部分はワーク・パッケージ・レベルで発生します。ワーク・パッケージの変更を承認するために十分な委任された権限があることを確認することが重要です。(このようにして、承認のために決定をプロジェクト委員会にエスカレーションすることなく、変更を加えることができます。) プロジェクトの規模と複雑性によっては、プロジェクト・マネジメント・チーム内の複数のレベルで変更許可委員を委任すると便利な場合があります。これは、課題マネジメント・アプローチで指定されたパラメーターに基づいています。

5. 変更予算

定義: 変更予算: 変更に備えるための計画において確保された金額または認可された制約条件。認可された変更を提供するための委任された権限を持つ人によって割り当てられる。プロジェクト・マネージャーは、委任された権限に、承認された変更を提供できる適切な変更予算が付随していることを確認します。通常、変更予算は変更に資金を提供するために特別に取り置かれた金額です。ただし、トレードオフを行うことができる一連の認可された制約として定義することもできます。

技法

5ステップの課題マネジメント技法(課題の把握、課題の評価、変更の勧告、変更の決定、変更の実施)が含まれています。必要に応じて代替手順を使用できます。代替手順の使用は、テーラリングに関する決定のー部としてプロジェクト立ち上げ文書に記載します。

1. 課題を把握する

課題はプロジェクト中に利用可能な公式または非公式のコミュニケーション・チャネルのいずれかを介して把握できます。ただし、プロジェクト・マネージャーは、これらのチャネルから課題報告書へと課題を変換する手段が効率的であり、管理上の負担が最小限であることを確認します。(新規および未解決の課題のレビューは、定期的なステータス会議からステージ境界レビューまで、すベてのプロジェクト・レビューの一部です。)

2. 課題を評価する

課題をレビュ一するときは、次の質問に答えることを狙いとします。・課題の種類は何か(問題または懸念事項、プロジェクト外部のイベント、ビジネス機会、変更要求、仕様外項目)？・この課題はプロジェクトに影響するか？・もしそうなら、どのように？主要な課題やプロジェクトのベースラインに対する潜在的な変更には、プロジェクト計画書全体へのインパクトの状況でそれらを考慮する統合評価が必要です。評価では課題または変更が以下に与えるインパクトを考慮します。
・承認されたターゲットと許容度・プロジェクト・ビジネス・ケース・その他の成果物またはワーク・パッケージ可能であれば、プロジェクト・マネージャーは、課題や変更に対応するための複数の方法をプロジェクト委員会に提供することを狙いとします。多くの場合、デリバリ一の遅延を許容する見返りに成果物からより良いパフォーマンスを得るなど、要件または許容度の間でトレードオフまたは条件付き承認を行うことができます。課題にプロジェクト自体のスコープ外でのインパクトと対応オプションがある場合に、課題の評価と解決方法の開発には、さまざまなプロジェクト・チーム・メンバーや利害関係者からインプットやアイデアを収集することにより、協力的な方法でアプローチするのが最善です。評価を完了してオプションを提案する前に、プロジェクト委員会の助言を求めて、課題の優先度または重大度を理解しているかどうかを確認する。

3. 解決を勧告する

評価に基づいて、必要な権限を持つ適切な個人またはグループに勧告が行われます。勧告が変更要求を承認するか拒否するかにかかわらず、両方の選択の結果を明確にします。

4. 変更を決定する

変更勧告に対応する選択肢

種類	対応	検討内容
変更要求	承認	変更にかかるコストは、次の方法で調達できます。 • 変更予算を使用する • プロジェクトのその他の要素のスコープを縮小する • 追加の資金を要求する
変更要求	却下	ビジネス正当性が引き続き満たされ、変更が拒否された場合でも予想ベネフィットは実現されますか？
変更要求	例外計画書の要求	これは、問題が過度に厳しい品質仕様または受け入れ基準に起因し、承認された許容度の変更によって解決できる場合に適切な対応となります。
変更要求	詳細情報の要求	この選択は事実上決定を延期しますが、変更要求の承認または却下のインパクトが複雑な場合は適切な対応になる可能性があります。
仕様外項目	受け入れる	ビジネス正当性と予想ベネフィットにはどのようなインパクトがありますか？プロジェクトのベースラインが更新され、仕様外項目が条件付き承認として記録されます
仕様外項目	却下	どうすれば課題を解決できますか？ • 変更予算を用いて • 例外計画書を用いて • 契約上の救済手段を用いて(サプライヤーが実行責任を負う場合)

5. 変更を実施する

承認された変更要求および仕様外項目の要求は、プロジェクト・ログに記録し、影響を受けるマネジメント成果物に反映します。(それぞれのマネジメント成果物のベースラインは異なるシステムを使用して維持できますが、各システムは変更の記録と置き換えられたバージョンのアーカイブを提供することにより、構成コントロールを可能にしなければなりません。)

支援技法

さまざまな問題解決技法を使用して、課題の評価と解決を実現できます。 * 根本原因分析: 1 つ以上の主要な原因を他の二次的または派生的な原因と区別することを狙いとして、問題をその寄与原因に分解します。 * パレート分析: 考えられる原因を収集し、成果の 80% がすべての原因の 20% に起因すると主張するパレートの法則とも呼ばれる 80/20 ルールを使用して、最も可能性の高い原因を特定します。 * これは、複数の原因が存在し、1 つの原因が明白な原因ではない場合に便利です。 * 原因と結果の分析: 最も重要な要因を特定することを狙いとして、考えられる原因を元の問題とは異なるさまざまなカテゴリーに分類します。 * この分析は、フィッシュボーン図(石川ダイアグラム)を使用して実施されることがあります。 * 障害モード分析: 成果物またはプロセスで発生する可能性のあるすべての障害を特定し、それぞれの結果を評価するためのステップ・バイ・ステップのアプローチです。 * これには通常、中間形式(プロトタイプなど)または最終形式のいずれかの成果物が存在する必要があります。 * 5 つの WHY: 一連の質問(「なぜこのようなことになったのか」など)を使用して、問題の連続するレイヤーを調査します。 * 各質問に対する答えは、次の「なぜ？」の質問の基礎になります。これは、詳細な統計が必要ない場合や利用できない場合に役立つシンプルなツールです。

プラクティスの適用とコンテキスト

組織的な状況

プロジェクト・マネージャーは、適用する必要のある組織または外部の方針、標準、手順があるかどうかを判断し、それらをプロジェクト独自の課題マネジメント・アプローチに組み込みます。

商業的な状況

商業的な環境では、プロジェクトは契約で定義された変更コントロール手順を適用しなければならない場合があります。サプライヤーがプロジェクトの課題マネジメント・アプローチに参加する必要がある場合は、その課題登録簿または変更コントロール・ツールを使用します。これは、適用可能な契約または合意内で指定する必要があります。

デリバリー手法

直線的かつ連続的なプロジェクトプロジェクト・ライフサイクルが進歩するにつれて変更の数と規模は減少する反復的かつ段階的なプロジェクト課題マネジメントと変更コントロールは、反復的かつ段階的なアプローチに組み込まれています。進捗の頻繁なレビューとデリバリー作業の短いサイクル(アジャイル手法など)は、課題を迅速に提起して解決することを目的としています。これは、成果物の要件と開発された能力の間に緊密な整合性を持たせるよう、スコープのベースライン(プロダクト・バックログと呼ばれることもあります)を進化させるためです。

持続可能性

持続可能性は、特に規制要件やサプライヤーの能力の分野で、プロジェクトの外部からの重大な課題や変更の原因となる可能性があります。持続可能性と環境インパクトがプロジェクトの主要な側面である場合、課題マネジメント・アプローチは、プロジェクト・マネジメント・チームの誰かが潜在的な課題と変更の外部ソースをモニタリングする責任を負っていることを確認します。

規模

プロジェクト・マネージャーは、課題マネジメント・アプローチを開発する際に次のことを考慮します。 * プロジェクトの規模と利害関係者の数または多様性: 小規模なプロジェクトでは、プロジェクト・マネージャーは支援なしで課題や変更を管理できる場合がありますが、大規模なプロジェクトでは、課題マネジメントと変更コントロールで専用の支援が必要になる場合があります。 * 提供される成果物とその品質仕様の不確実性または変動性の程度: 成果物記述書とそれらの提供に関連する活動の理解が深まり、十分に理解されている場合、課題や変更が頻繁に多発する可能性は低くなります。プロジェクトの成果物とデリバリー手法が斬新であるか、提供される成果物一式が複雑な場合、課題マネジメントと変更コントロールにはかなりのレベルの作業が必要になる可能性があります。 * プロジェクト変更コントロール・ツールと関連データの特徴: ソフトウェア開発などの一部のプロジェクトは、課題マネジメントと変更コントロールが単一の統合環境でサポートできるツールによって支援される場合があります。 * 課題とプロジェクトのベースラインの機密性: 一部の利害関係者によってネガティブに認識されるおそれのあるディスベネフィット、または成果を含む可能性のあるスコープのあるプロジェクト・チームは、課題登録簿へのアクセスを厳しくコントロールすることをお勧めします。

マネジメント成果物

アウトプット

リスク・マネジメント・アプローチ(プロジェクト立ち上げ文書のー部)

目的: プロジェクトでのリスク・マネジメント方法を説明する。適用される特定の手順、技法、標準、責任が含まれる。
コンテンツ概要
- スコープ: 課題マネジメント・アプローチのスコープの説明
- プロジェクトベースライン要素: プロジェクトのベースラインを構成するマネジメント成果物のリスト
- 課題の報告と解決の手順: 課題の発生、報告、解決の説明(ビジネス標準からの逸脱は、逸脱の正当性とともにハイライトする)。
- 変更コントロール手順: プロジェクトのベースラインに対する変更の要求、決定、組み込み、検証方法の説明(ビジネス標準からの逸脱は、逸脱の正当性とともにハイライトする)。
- 変更予算: 認可された変更予算と、ステージまたはワーク・パッケージ・レベルでの割り当て
- 正式な課題マネジメント活動のタイミング: 課題をレビューおよび決定する時期と頻度
- 責任: 変更許可委員の委任など、課題マネジメント・アプローチに関連する役割の実行責任を担う人物を定義
- サポートするツールまたはシステ: バージョンコントロールシステムなど、課題マネジメント・アプローチを実施または支援するために使用されるツールまたはシステム
- 標準: 課題の優先度と重大度を評価するために使用される格付けシステムなど、課題マネジメントに適用される標準(標準では、課題登録簿およびその他の変更コントロール・レコードの構成と形式も指定する)

課題登録簿(プロジェクト・ログのー部)

目的: プロジェクト・ライフサイクル中に発生したすベての課題報告書、現在のステータス、終了日を記録する
コンテンツ概要
- 課題の識別子: 課題の一意の参照コード
- 課題の記述書: 課題の概要
- 課題の種類: 問題、懸念事項、外部イベント、ビジネス機会、変更要求、仕様外項目
- 格付け: 優先度と重大度の評価
- 課題のオーナー: 課題の担当者
- 決定: 課題に対応する決定のレコード。仕様外項目の場合、受け入れを記録し、決定した条件付き承認の概要を提供する
- ステータス: 課題の現在のステータス(記録済み、レビュー済み、処置済み、エスカレーション済み、解決済みなど)
- 課題に関連する日付: 提起日、最終レビュ一日、処置の期日、解決日など
- レコード: 課題とその場所に関連付けられている文書のリスト

課題報告書

目的: プロジェクトのベースラインに対する課題のインパクトを説明し、課題を解決する方法や仕様外項目に対処する方法を特定し、決定を推奨する
コンテンツ概要
- 一意の識別子: 課題の一意の参照コード
- 成果物識別子: 課題の影響を受ける成果物の識別子
- 提起日: 課題が最初にログに記録された日付
- 課題の種類: 問題または懸念事項、外部イベント、ビジネス機会、変更要求、仕様外項目
- 格付け: 重大度と優先度(使用する場合)
- 記述書: 課題の要因、原因、インパクトの概要
- インパクト分析: プロジェクトのベースラインへのインパクトの分析
- オプション: プロジェクト、ユーザー、サプライヤーが課題に対応する方法
- 勧告: プロジェクト・マネージャーまたはチーム・マネージャーが推奨する決定
- 決定: 課題に対応する決定のレコード。仕様外項目の場合、受け入れを記録し、決定した条件付き承認の概要を提供する

主要な役割

役割	責任
ビジネス・レイヤー	ビジネス・レイヤーの責任
プロジェクト・エグゼクティブ	プロジェクト・エグゼクティブの責任
シニア・ユーザー	シニア・ユーザーの責任
シニア・サプライヤー	シニア・サプライヤーの責任
プロジェクト・マネージャー	プロジェクト・マネージャーの責任
チーム・マネージャー	チーム・マネージャーの責任
プロジェクト保証	プロジェクト保証の責任
プロジェクト支援	プロジェクト支援の責任

ビジネス・レイヤーの責任

課題マネジメントと変更コントロールのためのビジネス・レイヤーの方針、標準、手順を提供する
プロジェクト・レベルの変更予算を承認する(使用している場合)
プロジェクト・エグゼクティブからの助言の要求やエスカレーションされた課題に対応する

プロジェクトエグゼクティブの責任

プロジェクト・レベルの変更予算が必要かどうか、および必要な金額を判断する
ステージ・レベル変更予算を設定する
変更を承認するための委任された権限が必要かどうか、および必要な場所を判断する
課題マネジメント・アプローチを承認し、それがプロジェクト目標に適していることを確保する(課題の重大度と優先度を評価するためのスケールを設定)
プロジェクト・マネージャーからの助言の要求に対応し、特にビジネス正当性の継続を重視して、エスカレーションされた課題に対する意思決定を行う

シニアユーザーの責任

プロジェクト・マネージャーからの助言の要求に対応し、特に予想ベネフィットを守ることを重視して、エスカレーションされた課題に対する意思決定を行う
課題マネジメント・アプローチに合意する

シニアサプライヤーの責任

プロジェクト・マネージャーからの助言の要求に対応し、特にソリューション全体の完全性を守ることを重視して、エスカレーションされた課題に対する意思決定を行う
課題マネジメント・アプローチに合意する

プロジェクトマネージャーの責任

利害関係者と協議して課題マネジメント・アプローチを準備および維持し、成果物がベースライン化されるレベルに合意する
可能な場合は、プロジェクト支援のサポートを受けて、課題および変更コントロール手順を管理する
チーム・マネージャーがワーク・パッケージ記述書で合意された課題と変更コントロール手順を実施するようにする
可能な場合は、プロジェクト支援のサポートを受けて、課題登録簿を管理する
是正処置を実施する

チームマネージャーの責任

ワーク・パッケージ記述書で合意された課題と変更コントロール手順を実施する
是正処置を実施する

プロジェクト保証の責任

課題マネジメント・アプローチについて、プロジェクト・マネージャーに助言する
課題マネジメント・アプローチがビジネスの方針に準拠していることをプロジェクト委員会に確認する
課題の評価および解決について助言する
プロジェクト委員会とプロジェクト・マネージャーを支援するために、依頼に応じて課題報告書と例外報告書を確認する
課題と変更コントロールのプラクティスをレビューして、課題が適切に管理されていることをプロジェクト委員会に保証し、課題がプロジェクトの課題マネジメント・アプローチに沿って実施されていることを確認する

プロジェクト支援の責任

次によって変更コントロールと課題手順を管理する
- 課題登録簿の維持
- プロジェクトのベースラインの維持
- プロジェクト・マネージャーによる課題報告書の作成支援
- プロジェクトのリスク・マネジメント手順の適用について、プロジェクト・マネジメント・チームを支援