プロジェクト変更要求を評価する方法

Jane Suchan、PMP

制御できない変更は、プロジェクト マネージャーの最大の敵の 1 つです。     そのため、堅実な変更管理プロセスがプロジェクト マネージャーの親友になる可能性があります。 この種のプロセスを実施すると、顧客が要求した内容を、必要なタイムラインで、合意された予算内で提供できます。 変更制御がないと、プロジェクト スコープが移動ターゲットになり、プロジェクトの成功要因が 1 つ以上見つからないリスクがあります。 特にプロジェクト スコープの変更を管理および制御する機能は、目標を達成するための鍵であり、プロジェクト マネージャーの一般的なパフォーマンス インジケーターです。 プロジェクトの変更は避けられないので、プロジェクトが発生した場合ではなく、それに対処する準備をする必要があります。

変更管理と官僚組織のバランスを取る

プロジェクト マネージャーにとっての課題の 1 つは、不当な官僚主義を回避しながら、プロジェクトの変更を制御する必要性のバランスをとることです。 問題は:チップポイントはどこにありますか? すべてのプロジェクトが一意であるため、変更コントロールが値の追加を停止し、赤いテープに変わるポイントは、プロジェクトごとに異なります。

一部の利害関係者やプロジェクト チーム メンバーは、変更管理を実施することが、恐ろしい範囲の不気味さを回避する方法であり、柔軟性を持ち、顧客とビジネスに最適な作業を行うことを望んでいないと感じる場合があります。 この認識を払拭することが重要です。 あなたがやっていることは正反対であることを伝えてください。要求された変更を一貫して評価するための効率的なプロセスを実装しています。 変更が適切なアイデアと見なされる場合は、必要に応じて対応するプロセスが整います。

ページの先頭へ

プロジェクト変更管理計画

迅速な対応を支援するために、プロジェクト変更管理計画では、逸脱が発生した場合の動作について説明します。 変更を防ぐためのものではありません。むしろ、その目的は、変更がどのように伝達されるか、決定がどのように行われるか、それに応じてプロジェクトがどのように適応するかを明確にするプロセスを概説することです。

ページの先頭へ

変更コントロールを配置する

ビジネス要件やスケジュールなど、重要な成果物のベースラインを作成したらすぐに、変更管理プロセスを有効にする必要があります。 プロジェクト チームと利害関係者 (およびプロジェクトの変更の影響を受ける他のユーザー) は、変更管理計画を実行する前に確認し、承認する必要があります。

プロジェクトの全体的な成功にほとんど影響を与えない小さな変更は、要件やクリティカル パス スケジュールマイルストーンに対して行われた変更と同じ厳格さを伴うべきではありません。 正式なプロジェクト変更要求 (PCR) が必要な場合、プロジェクト変更管理計画の状態を指定する必要があります。 次に例を示します。

• スケジュールと予算の変更のしきい値は何ですか?

• 常に変更要求を必要とする変更はありますか?

• 変更管理プロセスでスキップできる変更

ここでの注意:多くの場合、大きくて明らかなものではなく、損害を与える小さなスコープの変更がたくさんあります。 PCR 基準を定義する場合は、この点を考慮してください。 たとえば、変更管理計画では、メジャーやマイナーなど、変更要求カテゴリを定義する必要があります。

• 主な変更点    これらは次のようになります。 PCR として文書化されています。 プロジェクトの主な変更点:

  • クリティカル パスの要件または作業項目に影響を与え、重要なマイルストーンまたはプロジェクト全体の終了日を特定の時間の割合または期間で遅延させます。 プロジェクトごとに大きな変更基準を定義する必要があります。

  • 追加資金 (ドルまたは予算の割合) が必要です。 ここでも、プロジェクトごとに金額を定義する必要があります。

• 軽微な変更    これらの定期的な変更では、PCR は必要ありません。 軽微な変更:

  • プランに大きな影響を与えないでください。 マイルストーンやプロジェクトの依存関係を持つタスクの完了日は延長されません。

  • 経済的な影響はありません。 結果としてプロジェクト予算の差異は発生しません。

ページの先頭へ

変更要求を評価するためのヒント

プロジェクト変更管理計画には、変更要求の評価方法に関する情報も含める必要があります。 この評価の基準は、時間が無駄にならずに合意に達しないように、必要になる前に決定することが重要です。 これらのパラメーターを設定すると、変更と全体的なビジネス目標と利点のバランスを取るのに役立ちます。

変更要求を評価する際に考慮すべき一般的な質問を次に示します。

• この変更により、ビジネス要件が追加または変更されますか?

• 回避策はありますか、それともプロジェクトの全体的な成功のためにこの変更が必要ですか?

• この変更には資金調達の増加が必要ですか?

• これにより、プロジェクトの終了日が遅れるのですか?

• この変更は、このプロジェクトに悪影響を与える可能性がありますが、重要なビジネスのアップサイドを生み出して価値がありますか?

• この変更を適用する方が、遅延するよりも意味がありますか? 遅延は最終的に会社により多くのお金を費やすことになりますか?

• 影響を受けるすべての利害関係者が考慮され、変更を支持していますか?

• 考慮すべき契約上の影響はありますか? たとえば、この変更により、外部ベンダーとのコミットメントは満たされませんか。

ページの先頭へ

プロジェクト変更要求の承認

また、要求された変更を承認できるユーザー (承認できないユーザー) を定義することも重要です。 定期的な変更を効率的に処理できるように、さまざまな権限レベルを定義するのが一般的ですが、重要な変更は必要なレベルの管理上の注意を受けます。

提案された変更がプロジェクトの範囲に影響する場合は、プロジェクト スポンサーからの承認を必要とするビジネス上の決定と見なす必要があります。 スコープが影響を受けない場合、プロジェクト チームとスポンサーは、プロジェクト マネージャーが特定の制限内で変更を承認する権限を持っていることを決定できます。 一部のプロジェクトでは、変更管理委員会が定期的に作成および開催され、変更要求の検討と承認が行われます。 organizationには、さまざまな種類の変更要求を処理する異なる変更制御ボードが存在する場合があります。 たとえば、技術変更管理委員会では、テクノロジの問題を調べます。

変更要求を承認するためのガイドラインを要約する簡単な方法の 1 つは、サンプル プロジェクトに基づく次のようなテーブル内にあります。

ページの先頭へ

大きなペイオフ

プロジェクト チームは常に、効果的な計画を犠牲にして、プロジェクトの実行に到達することを切望しています。 ショートカットを取り、あなたが行くにつれて物事を理解すると仮定するのは魅力的です。 変更が発生する前に、適切に開発された変更管理プロセスを実施すると、大きな見返りが得られ、プロジェクト全体の結果が向上します。 主観を変更制御から外すと、プロジェクト チームは変動を効率的かつ効果的に処理できるようになります。 プロジェクト チームのメンバーや関係者が受け入れた、よく考えられた詳細な変更管理計画により、時間とコストを節約できます。プロジェクト マネージャーには十分な量がありません。

ページの先頭へ