プロジェクトの変更を管理する方法
コンテンツ
- 変化が起こることを受け入れる
- 変更管理プロセス
- プロジェクトのプロセス変更の要求/要求を受け取る
- 変更評価を実施する
- 推奨事項を準備して提示する
- 決定
- 変更管理ツール
- プロジェクト変更リクエストフォームの開発
- 変更とプロジェクト範囲管理
- 変更プロセスを通じてチームをリードする
プロジェクトマネージャーは多くの時間を費やして計画を作成し、チームの目標を確立します。その後、スポンサー、利害関係者、およびチームは、作業の範囲とロールアウトプロセスに変更を加えるのに多くの時間を費やします。明確で簡単な変更管理プロセスを実施し、全体像に着実に目を向けることは、たとえ詳細の一部が変わっても、プロジェクトを前進させ、冷静さを保つことを可能にするのに大いに役立ちます。
変化が起こることを受け入れる
変更は、プロジェクト管理ライフサイクルのほぼすべてのポイントで発生します。プロセスの一部は変更が避けられない-実際、多くの場合有益である-ことを認識することで、最高のプロジェクトマネージャーは、計画と実行に対してより機敏なアプローチを採用できます。変化が発生したときに効果的に対処するための戦略を立てることは、方向が常に変化しているように見える場合があっても、賞品に誰もが注目する最も早い方法です。
定義され、構造化された変更管理プロセスは、実行プレイブックです。あなたの戦略「聖書」。これは、開発プロセス内の変更に対する提案（さらには要求）に対してリーダーとしてどのように対応するのが最善かを定義します。それは、すべての関係者の最終的な目標の達成に向けて、優雅に、そして確実に、時には論争を巻き起こす協力的な状況をナビゲートするのに役立ちます。
変更管理プロセス
変更管理プロセスは次のようになります。
- プロジェクトのプロセス変更の要求/要求を受け取る
- 以下に関するプロジェクトの予算に重点を置いて、変更要求/要求を評価します。
- 材料
- 関連する許可要件
- 工数
- 失われた/獲得した時間
- プロジェクトの株主に準備/提示し、リクエストに応じてどのように進めるかに関する推奨事項を連絡します
- 続行するには、株主決定の承認または拒否を受け取ります
これらの各ステップを順に見ていきましょう。
プロジェクトのプロセス変更の要求/要求を受け取る
プロジェクトを変更するためのリクエストを、何百もの異なる方法で受け取ります。たとえば、会議で、電子メールで、電話で、廊下で、夕方にオフィスを急いでいるときです。理想的には、変更リクエストフォームで情報を取得しますが、実際には、多くの重要な利害関係者がこの種の事務処理を完了することがプロジェクトマネージャーの仕事であり、会社ではそうであると考えていることを知っておく必要があります。
プロジェクト変更リクエストテンプレート（詳細は1分以内）は、リクエストのすべての詳細を正確かつ簡潔にキャプチャする必要がありますが、非公式に届きます。すべての詳細が正確に記録されていると感じたら、すべてのポイントが完全に対処されていることを確認するために、開始者を通過してフォームを実行します。
変化はまた、運動をすることに関するものかもしれないことを覚えておいてください。変更が作業の投入に関連していると必ずしも想定しないでください。プロジェクトのスコープを拡大するか縮小するかに関係なく、プロセスは同じです。
変更評価を実施する
変更リクエストを詳しく見てください。以下に対する影響を評価します。
- スケジュール
- ドキュメンテーション
- これまでに行われた作業とまだ行うべき作業
- 予算
- 品質対策
- 範囲
- リソースの可用性
たとえば、ソフトウェアの変更が5日と推定される場合があります。これにより、スケジュールに5日が追加されるだけではなく、別のタスクが実行されて、主要なリソースが休日である時間枠内に移動されます。そのタスクも移動する必要があるため、全体的にこの変更により、スケジュールに8日が追加されます。それを行うには$ 5kかかり、追加の8日間はサプライヤとの契約で別の月に追いやられるので、そこでも検討する費用があります。品質は変わりませんが、スコープが変更され、新しい変更が組み込まれます。既に開始されているプロジェクト計画やトレーニングマニュアルを含むすべての関連ドキュメントを更新する必要があります。
つまり、全体像を見ると、5日間の単純な変更が大きな影響を与えています。全体像を把握することで結果が変わる可能性があるため、実装を決定する前に、関連するすべての要素を検討することが重要です。
推奨事項を準備して提示する
要求された1つまたは複数の変更の完全な影響を理解した上で、シフトの実行可能性に関する推奨事項を提示します。
場合によっては、認識されたメリットがコストよりも少ないため、変更は実装されません。他の場合では、追加の作業を行うコストを相殺するのに十分な利点が見つかる場合があります。他の場合でも、規制やコンプライアンスの問題、または組織の再構築などの内部の問題に起因するマイナスの影響に関係なく、変更が不可避であり、制御不能であることを証明します。
決定
許可の制限内にある小さな変更の場合、変更を受け入れるか拒否するかは（チームからの正しい入力により）決定します。それより大きいものは、プロジェクトスポンサーまたはプロジェクトボードによって承認される必要があります。どのカテゴリに該当するかについての用語は、通常、プロジェクトの最初に明確に記述されています。
結果に関係なく、プロセスに関与するすべての人に知らせておくことが重要です。開発の任意の時点でチームメンバーを疎外すると、プロジェクト全体の整合性が失われ、将来のコラボレーションにもコストがかかる可能性があります。
変更管理ツール
このプロセスをより簡単かつ合理的にするために、多くの変更管理ツールが開発されています。すべての変更管理ツールボックスの中心は次のとおりです。
- チェックリストまたはプロセスマップで、プロジェクトの範囲の変更を提起するための適切な手順をステークホルダーに説明
- テンプレート変更リクエストフォーム（注意：プロジェクトが自動化されたワークフローからオンラインで作業する場合は、このフォームをドキュメントリストに含めることをお勧めします）
プロジェクト変更リクエストフォームの開発
プロジェクト変更リクエストフォームには次のものが含まれている必要があります。
- 変更をリクエストする人（「リクエスタ」）の名前。
- 変更番号などの一意の識別子（リクエストを提起してフォームを使用する人がここに入力する内容を知っている可能性は低いため、後でこれを自分で追加できます）。
- 提案された変更の説明。可能な限り詳細に。
- 変更のカテゴリ。理想的には、リクエスタはこのセクションの事前入力されたカテゴリから選択できるようにして、ボックスをチェックするだけで済みます。これは、変更要求が規制または内部コンプライアンスに関連しているかどうかを確認するのに適した場所です。これが（通常）関連している場合は、計画と評価の多くのステップをバイパスして、そのまま続行できます。
- 変更の「理由」。それを実装する理由は何ですか？なぜ要求者はそれを望んでいるのですか？
- 時間、コスト、品質、範囲など、プロジェクトのさまざまな要素に対する提案された変更の潜在的な影響。依頼者はすべての詳細情報を持っていない可能性があるため、変更評価ステップを通じてこれらの空白を埋める支援を必要とする場合があります。この時点で探している最小値は、既存のプロジェクトパラメータを増加、減少、または変更する可能性があるかどうかの明確化です。
変更の詳細については、変更の詳細を記入するため、変更リクエストフォームにスペースを入れて丸める必要があります。テンプレートには、次のスペースも含める必要があります。
- 変更の決定：承認、拒否、延期
- 決定（またはグループ）を行う人の名前、および決定が行われた日付と追加のコメント。
変更とプロジェクト範囲管理
プロジェクトスコープの管理は、プロジェクトを正常に実行するために必要なものとそうでないものの違いをフィルタリングして調整するプロセスです。プロジェクトの変更リクエストを受け取ったら、それらの変更がプロジェクト全体にどのように影響するかを検討する必要があります。変更管理プロセスは、変更が実用的または必要でない理由をコンテキスト内で洗練および定義するのに役立ちます。
プロジェクト管理の知識体系（PMBOKガイド）のガイド–第6版のカバレッジプロジェクトの変更管理は、思っているほど直感的ではないため、言及する価値があります。 「PMBOKガイド」 プロジェクトスコープ管理セクションの「コントロールスコープ」と呼ばれるプロセスの形で優れたスターターガイドラインが含まれています。ただし、プロジェクトの変更管理プロセスは、より統合された方法で処理する必要があり、それはテキストに反映されています。 「PMBOKガイド」のユーザーは、より大きなランドスケープですべてがどのようにリンクするかを明確に説明しているため、統合変更管理の実行プロセスも参照する必要があります。
PMPになるためには、「PMBOKガイド」が試験の一部となるため、変更管理がどのようにカバーされているかを理解することが重要です。ただし、プロジェクトで実際に使用する変更管理プロセスは、統合され、理解しやすく、実用的である必要があることに注意してください。
変更プロセスを通じてチームをリードする
プロジェクトチームはどのプロジェクトの成功にも不可欠です。そのため、プロセスの変更を管理するときに積極的に関与してもらうことが役立ちます。
チームがプロジェクトの変更管理プロセスを迅速に理解できるようにするための5つの方法を次に示します。
1.変更についてオープンであること。 プロジェクトの変更が予想されることをチームに知らせてください。
2.プロセスについてオープンであること。 ここで説明する変更管理プロセスは、すべての人に自然に伝わるものではありません。ほとんどのチームメンバーは、アドバイスを受けるまで、何が期待されているかを知りません。ブリーフィングを設定して、彼らと一緒にプロセスを進め、その実行における彼らの役割をそれぞれに知らせます。
3.簡単にする。 プロジェクトの変更は、多くの場合、せいぜい、制御された混乱です。それをうまくナビゲートするために実行する手順は、プロジェクト管理者としての意欲を定義します。あなたのチームは、不安定な変更を見つけることができます。特に、大きな変更や、長い間解決されると考えられていた決定を覆し、ハードルが長い間解消されたと考える変更を見つけるものです。スケジュールが間違っている、予算が異なる、要件が確かに異なる場合があります。
チームはガイダンスと安定化を求めます。プロセスをできるだけ簡単にします。
4.助けに行く。 新しい作業方法を正常に統合するには時間がかかります。以前に非公式な方法でプロジェクトの変更を管理していた（またはまったくしていない）場合、正式なプロセスへの変更が「ここでのやり方」になるまでに時間がかかることがあります。彼らがあなたを越えて何かを実行する必要がある場合、彼らが彼らを助けるためにそこにいることをチームに知らせてください。
5.ノーと言うことを恐れないでください。 すべての変更が賢明な提案であるとは限りません。現時点でプロジェクトに適切ではない変更について強く感じた場合は、変更リクエスタとの会話の中で待機することをチームに知らせてください。
変更を効果的に管理できないと、プロジェクトが完全に脱線する可能性があるため、注意が必要です。適切な情報とプロセスを備えたプロジェクトの変更は、関係者全員に対して、制御されたスマートで有益な方法で対処できます。
