プロジェクトを引き続き進めていく
また、使用できる変更管理ツールのいくつか、およびプロジェクトスコープ管理がどのように機能するかについても見ていきます。
私たちがプロセスやツールについて話す前に、私はあなたの見通しを変えて議論したいと思います。
変更を受け入れる
変更はプロジェクト管理ライフサイクルのどの時点でも発生する可能性があります 。
頭痛の少ないプロジェクトの変更を管理する最も簡単な方法は、それが起こることを知り、それを計画することです。
彼らが起こる前に変化に対処するための戦略を持っていることは、誰もが違うものを乗り越えるための最速の方法です。
定義され、構造化された変更管理プロセスが最善の出発点です。 誰かがプロジェクトが現在計画されているものとは異なる何かをしているべきであり、プロジェクトの失敗を避けるために良い方法を提案しているなら、何が起こるかについてのあなたのプレイブッです。
変更管理プロセス
変更管理プロセスは次のようになります。
- 変更に関する情報を受け取る
- どのくらいの仕事が計画されているかを含め、変化を評価する
- 先に進む価値があるかどうかについての勧告を準備する。
- 次に、あなたは変更を組み込むべきかどうかについて、プロジェクトのスポンサーから決定を受け取ります。
これらのステップのそれぞれを順番に見てみましょう。
変更に関する情報を受け取る
プロジェクトの変更依頼が届きます。 あなたは、夜間にオフィスから出てくるように、ミーティング、電子メール、電話、廊下で何百もの異なる方法で情報を受け取ることができます。 理想的には、変更依頼フォームに関する情報を得ることができますが、現実の生活の中で、多くの重要な利害関係者が、この種の書類を完成させることがプロジェクトマネージャーの仕事であると考えるべきです。 あなたの会社では、そうかもしれません。
プロジェクトの変更依頼テンプレート（詳細は1分以内）を使用してリクエストの詳細をすべて把握しますが、非公式にリクエストが届きます。 次に、イニシエータを過ぎてフォームを実行し、必要なものが正確に反映されていることを確認します。
変更はまた、取り組むことにもなることを忘れないでください。 変更が作業を入れることに常に関係しているとは限りません。プロジェクトのスコープを増減しているかどうかにかかわらず、プロセスは同じです。
変更評価を実施する
変更要求を詳細に見てください。 あなたはその影響を評価するでしょう：
- スケジュール
- ドキュメンテーション
- これまでの仕事とまだやるべきこと
- 予算
- 品質尺度
- 範囲
- リソースの可用性。
たとえば、5日間でソフトウェアの変更を見積もることができます。
これは、スケジュールに5日を追加するだけではなく、別のタスクを押し出し、キーリソースが休暇中である時間枠内で移動させるためです。 そのタスクも移動する必要があるため、全体的にこの変更はスケジュールに8日を追加します。 それには5kドルの費用がかかり、余分な8日間はサプライヤー契約を締結してさらに1ヶ月になりますので、そこでも考慮する必要があります。 品質は同じですが、範囲の変更は新しい変更を組み込むために変わりません。 すでに開始されているプロジェクト計画や訓練マニュアルを含め、すべての関連文書を更新する必要があります。
ご覧のように、5日間の簡単な変更で幅広い効果が得られます。 完全な画像が結果を変えることができるように、変更を行うかどうかを決定する前に、これらについてすべてを知ることが重要です。
勧告の作成と提示
変更の完全な影響を知ったので、それを先に進める価値があるかどうかを推薦することができます。
知覚される利益がコストよりも小さくなるため、場合によってはそうではありません。 他の場合には、追加作業を行うコストを相殺するのに十分な利益がそこにあるかもしれません。 それ以外の場合は、変更がコストに悪影響を及ぼしますが、規制やコンプライアンスの問題であるか、組織の再編のような他の内部的な理由から、あなたができることは何もありません。
意思決定を得る
あなたの認可限度内にある小さな変更については、変更を受け入れるかどうかを決定することができます（チームからの正しい入力で）。 より大きなものは、プロジェクトのスポンサーまたはプロジェクトボードの承認を受ける必要があります。
彼らの変更が拒否された場合、戻って誰かに告げることを忘れないでください。 可能であれば、プロジェクトのステークホルダーに迷惑をかけないようにしたい！
変更管理ツール
このプロセスを簡単かつ合理化するために使用できるさまざまな変更管理ツールがあります。 私はお勧めしたい：
- プロジェクトスコープの変更を行うために必要な作業を正確に実行するチェックリストまたはプロセスマップ。
- テンプレート変更要求フォーム。 これは自動化されたワークフローを介してオンラインになる可能性があります
次はプロジェクト変更依頼の内容を見てみましょう。
プロジェクト変更依頼に入るもの
プロジェクト変更依頼書には以下が含まれている必要があります。
- 変更依頼者の名前（「依頼者」）。
- 変更番号のような一意の識別子（後で自分自身でこれを追加することができます。なぜなら、要求を出してフォームを使用する人は、そのボックスに何を入れるべきかを知ることはありません）。
- 提案された変更の説明で、管理できる範囲で詳細を記述します。
- 変更のカテゴリ。 理想的には、このセクションをあらかじめ入力しておき、ボックスにチェックマークを付けるだけです。 これは、変更が規制または社内のコンプライアンスと関係するかどうかをメモするのに適しています。まるでそれが（純粋な）ものであるかのように、多くの計画と評価のステップを迂回して簡単に進めることができます。
- 変化の「理由」。 それを行う正当な理由は何ですか？ なぜリクエスタはそれを望んでいますか？
- 時間、コスト、品質、範囲などのプロジェクトのさまざまな要素に対する変更の影響。 彼らはすべての詳細を持っていない可能性がありますので、ブランクを記入するために変更の評価ステップ中に作業しなければならないかもしれません。 彼らはできるだけ多くを完了する必要があります。 現時点で探している最小値は、既存のプロジェクトパラメータを増減するかどうかを確認することです。
変更依頼フォームの一番下には、変更がさらに議論されるために記入するための詳細が表示されます。 あなたのテンプレートには、
- 変更の決定：承諾、拒否または延期
- 決定を行った人の名前（またはグループ）に、決定が行われた日と追加のコメントを加えたもの。
要求を行った人はまだ結果を知らないでしょう - だれも誰もしません - そうすれば、適切なグループがあなたの推薦を話し合って決定を下すまで、これらのボックスは空白になります。
変更とプロジェクトスコープ管理
プロジェクトスコープ管理は、 プロジェクト内のものとそうでないものを制御する主な方法です。 プロジェクトスコープの変更を受け取ったら、それがプロジェクト全体にどのように影響するかを考える必要があります。 変更管理プロセスは、これを行うのに役立ち、コンテキストで設定するために、変更管理はスコープ管理の小さな部分です。
プロジェクトマネジメント知識体系（PMBOK®ガイド） - 第5版では、プロジェクトの変更管理について、どのように直感的に考えるべきではないので、ここで話す価値はあります。 PMBOK®ガイドには、「プロジェクトスコープ管理」セクションに「コントロールスコープ」と呼ばれるプロセスが含まれています。これは始めるのに最適な場所です。 しかし、プロジェクトの変更管理プロセスは、より統合的な方法で処理する必要があり、それはテキストに反映されています。 PMBOK®ガイドユーザーは、すべてのリンク方法を説明しているため、統合変更管理の実行プロセスも参照する必要があります。
PMPになるためには、 PMBOK®ガイドがどのように変更管理を対象としているかを理解する必要があります。 ただし、プロジェクトで実際に使用する変更管理プロセスは、統合され、従いやすく、実用的である必要があることに留意する必要があります。
変更プロセスを通じてチームを支援する5つの方法
プロジェクトチームは、プロジェクトの成功に不可欠であるため、プロジェクトの変更を管理しているときにそのチームをオンサイドにすることができます。
ここでは、5つの方法で、プロジェクトの変更管理プロセスを迅速に理解できるようになります。
1.変更について話す。 プロジェクトの変更が正常であり、期待するべきことを知らせます。
2.プロセスを共有します。 上記では変更管理プロセスについて説明しましたが、これはすべての人に自然には当てはまりません。 あなたのチームメンバーは、あなたが指示しない限り、何をすべきか、何が期待されるのかを知らないでしょう。 ブリーフィングを設定して、彼らと一緒にプロセスを進め、彼らの役割が何であるかを知らせてください。
3.簡単にしてください。 プロジェクトがスコープの変更を経ると、それは非常に混乱することがあります。 スケジュールが間違っている、予算が異なるかもしれない、要件は確かに異なっています。 チームは変化の不安定さを見つけることができます。特に、これまでに考えられていた決定を元に戻してしまうような大きなものや、そういうものがあります。 プロセスを可能な限り簡単にします。
4.助けてください。 新しい仕事の仕方では就寝するまでに時間がかかります。以前に非公式にプロジェクトの変更を管理していた場合（またはまったくそうでない場合）は、正式なプロセスの変更には「ここでのやり方' あなたが過去の何かを動かすことを望むなら、彼らを助けるためにそこにいることをチームに伝えます。
5.いいえを言うのを恐れないでください。 すべての変更が合理的な提案ではありません。 あなたのチームに、今回のプロジェクトで正しいことではない変更が強く感じられた場合、変更依頼者との会話に立ち会うことを知らせてください。
効果的に変更を管理しないことは、プロジェクトを脱線させる方法の 1つなので注意してください。 この情報を活用することで、プロジェクトの変更を制御された方法で処理できるようになりました。