変更管理

提案された変更の主要な詳細と付随的な詳細を検討してください。これには、変更の特定、所有者、変更の伝達と実行方法、^{[ 8 ]}成功の検証方法、変更の重要性の推定、その付加価値、ビジネスおよび業界標準への適合性、完了の目標日などの側面が含まれる必要があります。^{[ 3 ] [ 9 ] [ 10 ]}

影響とリスクの評価は、次の重要なステップです。実行時に、提案された計画によって何か問題が発生するでしょうか？関連システムは、提案された変更によって影響を受けるでしょうか？この段階では、些細な詳細も考慮する必要があります。その後、提案された変更には、高リスク、中リスク、低リスクのいずれかのリスクカテゴリを割り当てるのが理想的です。高リスクの変更には、経営陣の承認や利害関係者への通知など、多くの追加ステップが必要ですが、低リスクの変更には、プロジェクトマネージャーの承認と最小限の文書化のみで済む場合があります。^{[ 3 ] [ 9 ] [ 10 ]}計画/スコープで対処されていない場合は、特に重大な最悪のシナリオがある高リスクの変更については、ロールバック計画の要望を表明する必要があります。^{[ 3 ]}

変更管理者、変更管理委員会、運営委員会、プロジェクトマネージャーのいずれであっても、通常はレビューと承認のプロセスが必要です。^{[ 11 ]}計画/範囲と影響/リスク評価は、ビジネス目標、要件、およびリソースのコンテキストで検討されます。たとえば、変更要求が、修正にかなりのリソースを必要とする低深刻度、低影響の問題に対処するものとみなされる場合、要求の優先度を低くするか、完全に棚上げされる可能性があります。影響の大きい変更が要求されたが、しっかりとした計画がない場合、レビュー/承認主体は、さらなる分析のために完全なビジネスケースを要求する可能性があります。^{[ 1 ] [ 3 ] [ 9 ] [ 10 ]}

変更管理要求が承認され、先に進む場合、デリバリーチームはテスト環境または開発環境で小規模な開発プロセスを通じてソリューションを実行します。これにより、デリバリーチームはユニットテストや回帰テストを実施しながら、段階的な変更を設計および実行する機会を得られます。^{[ 1 ] [ 3 ] [ 9 ]}リスクの低い変更については、テストや検証はほとんど行われない場合もありますが、大きな変更の場合は、実装前に十分なテストが必要になります。^{[ 9 ]}その後、承認を求め、実装フェーズを実行する日時を要求します。まれにソリューションをテストできない場合は、変更/実装期間について特別な考慮が必要です。^{[ 3 ]}

ほとんどの場合、変更を迅速に進めるための技術的専門知識を持つ特別な実装チームが変更の実装に使用されます。チームは、承認された計画に従って変更を実装するだけでなく、組織標準、業界標準、および品質管理標準にも従って変更を実装する必要があります。^{[ 9 ]}実装プロセスでは、トラブルシューティングの支援を求められる可能性のある利害関係者^{[ 11 ]}など、実装チーム以外の追加のスタッフの責任も必要になる場合があります。 ^{[ 3 ]}実装後、チームは実装後のレビューも実施する場合があります。これは、別の利害関係者会議またはプロジェクトの終了手順中に行われます。^{[ 1 ] [ 9 ]}

終了プロセスは、変更管理において最も困難かつ重要なフェーズの 1 つとなる可能性があります。^{[ 12 ]}この終了フェーズにおける 3 つの主要なタスクには、プロジェクトが実際に完了したことを確認すること、「プロジェクト完了の文脈でプロジェクト計画を評価する」こと、およびプロジェクトの成功の具体的な証拠を提供することが含まれます。^{[ 12 ]}最善の努力にもかかわらず、変更管理プロセス中に何か問題が発生した場合は、将来の変更に教訓を適用することを目的として、何が起こったかについての事後検証を実施する必要があります。^{[ 3 ]}