基本概念
統合とは、調整と調和のことです。プロジェクト統合マネジメントは、プロジェクトマネジメントの中核をなすものであり、プロジェクト要素間の相互調整を達成し、相反する目標や競合する目標の最適なバランスを見出すことを目的としています。統合マネジメントが必要とされるのは、最も問題が発生しやすいプロジェクトの結合だからです。
プロジェクト内の統合は間違いなくプロジェクトマネジャーの責任であり、プロジェクト外の統合は少なくともプロジェクトマネジャーのアシストの責任です。
絆があればどこでも統合が必要なのですから。
インテグレーターとしてのプロジェクトマネージャー
プロジェクトマネジメントにおけるプロジェクトマネジャーの役割は多面的ですが、最も重要な役割は「インテグレーター」です。
PMBOKガイドでは、プロジェクトマネージャーは、プロジェクトの統合を管理するタスクを引き受けなければならず、このタスクを他のチームメンバーに委任してはならないことを特に強調しています。
プロジェクトマネージャーの最も重要な役割は、コミュニケーションを通じて調整し、調整を通じて統合しなければならないインテグレーターです。
知識領域を超えたマネジメントの統合
プロジェクト・インテグレーション・マネジメントは、プロジェクト・マネジメントの経営哲学であり、プロジェクト・マネジメントと従来のマネジメントの最大の違いです。
プロジェクトマネジメントとは、統合と分業によるマネジメントです。
統合マネジメントは、10の知識エリアの相互関係という観点から、プロジェクトマネジメントの指針となる原則です。プロジェクトマネジメントチームは、統合マネジメントに導かれて、次の9つの知識エリアのマネジメントに取り組む必要があります。統合マネジメントはプロジェクトマネジメントの本場でもあります。後者の9つの知識エリアのマネジメントは、最終的にはプロジェクトの統合マネジメントを実現すること、つまり、最適なプロジェクトのどの側面だけでなく、全体最適のプロジェクト目標を達成することです。ある側面の最適化は、統合最適化の達成に寄与しないか、あるいは有害でさえあります。
統合マネジメントはプロジェクトマネジメントの哲学であり、プロジェクトマネジメントに最も必要な要素です。
プロセス間の関係
入出力の概要
統合プロジェクトマネジメントを実現するプロセスには、プロジェクト憲章の作成、プロジェクトマネジメント計画の作成、プロジェクト作業の指示と管理、プロジェクト知識の管理、プロジェクト作業の監視、全体的な変更管理の実施、プロジェクトまたはフェーズの終結が含まれます。これらのプロセスは、インプットとアウトプットを通じて相互に関連しています。
入力と出力の解釈
統合管理では、プロジェクト全体を俯瞰し、プロジェクト管理計画のあらゆる要素やあらゆる種類のプロジェクト文書が、実行、モニタリング、終結プロセスのインプットとなり得ます。
プロジェクト憲章の作成
プロジェクト憲章の作成は、プロジェクト開始フェーズの重要な部分です。これは、選定されたプロジェクトを正式に開始し、組織におけるプロジェクトの正当な位置を確立し、プロジェクトマネジャーに組織のリソースを使用してプロジェクトを遂行する権限を与えるためです。
プロジェクトの事前準備
プロジェクト・チャーターを指定する過程では、プロジェクト・スポンサーによるプロジェクトの初期構想の提示、プロジェクトのビジネス・ケースを実施するための専門家チームの雇用、関係機関によるプロジェクト開始に関する協力協定の締結など、プロジェクトの事前準備作業を完了する必要があります。
事前準備作業の主な目的は、プロジェクトの実現可能性を確認し、プロジェクトに必要な資金を確保することです。
厳密に言えば、事前準備はプロジェクトマネジメントの5つのプロセスグループにも、10の知識エリアにも含まれません。
プロジェクトの開始
事前準備の完了後、正式なプロジェクト開始フェーズに入り、プロジェクト憲章を作成・発行します。通常、プロジェクト憲章が発行されるまでの開始フェーズは、スポンサーが自ら指揮を執ります。プロジェクト憲章が発行されると、プロジェクトマネージャーがプロジェクトをリードします。
プロジェクト開始段階において、スポンサーはプロジェクトマネージャー指名者に以下の主なタスクの実行を許可します：
- プロジェクト評価の実施
- ハイレベルの成果物の特定
- ハイレベルなスケジュールとコスト要件の決定
- プロジェクト全体のリスクレベルとその主な原因の特定
- 主要な仮定と制約の特定
- プロジェクトの主な関係者の特定と分析
- プロジェクト憲章の作成、プロジェクト憲章に対するスポンサーの承認取得、プロジェクト憲章の配布
ビジネスケースはプロジェクトを選別するために実施され、プロジェクト査定は実行可能なプロジェクトが実行可能であり続けることを確認するために実施されます。プロジェクト憲章の策定プロセスに入ったプロジェクトは、一般的にカットされません。
プロジェクト憲章
プロジェクト憲章は、プロジェクトスポンサーまたは上級管理職が署名し、主要な利害関係者に発行する必要があります。これにより、彼らはプロジェクトが正式に開始されたことを認識し、プロジェクトの主な目的を理解し、プロジェクトにおけるそれぞれの役割と責任を理解します。プロジェクトスポンサーは、通常、キックオフミーティングを開催し、憲章を発行し、プロジェ クトマネージャーの指名を発表し、プロジェクトの正式な開始を宣言します。
プロジェクト憲章がなければプロジェクトはできません。
プロジェクト憲章は、原則的に要求事項を定めたものであり、プロジェクトに変更が生じても、通常はプロジェクト憲章に変更が生じることはありません。万が一、プロジェクト憲章を修正する場合、その権限があるのは、プロモーターまたは上級管理職だけです。プロジェクト憲章を発行した者が、それを修正する権利を有します。
「仮定と制約」は、もはやプロジェクト憲章には存在しません。現在では、プロジェクト憲章の作成中に特定された仮定と制約を記録するために、専用の「仮定ログ」が使用されています。
プロジェクト憲章には、少なくとも以下の内容を盛り込みます：
- プロジェクトの存在を正式に確認し、法的地位を与えること。
- プロジェクト開始の根拠を明確にし、業務目標や戦略目標と関連付けること。
- スコープ、スケジュール、コスト、品質要件など、プロジェクトのハイレベルな目標を定義します。
- プロジェクトマネジャーが組織のリソースを活用してプロジェクト業務を遂行できるようにします。
プロジェクト管理計画の策定
プロジェクトが正式に開始されると、プロジェクトマネジメント計画が作成されます。すなわち、すべてのサブマネジメント計画とサブベンチマークが包括的なプロジェクトマネジメント計画にまとめられます。PMPは、次の9つの知識エリアごとの計画XXマネジメントプロセスと計画ステークホルダー・エンゲージメントプロセスのアウトプットであり、ベースラインはWBS作成、スケジューリング、予算策定プロセスのアウトプットです。
プロジェクト管理計画の主な要素
プロジェクト・マネジメント計画は、他の計画プロセスの結果に基づいて作成されます。
プロジェクトプラン」という言葉を目にしたとき、その延長線上にあるものを文脈から判断しなければなりません。
プロジェクトマネジメントプランは、サブマネジメントプラン、3大ベンチマーク、プロジェクトライフサイクルの3つで構成されます。
スコープ、スケジュール、コストの3つのベンチマーク。プロジェクト管理計画の指定では、3つのベンチマークは「パフォーマンス測定ベンチマーク」に統合されます。
ベンチマークとは、プロジェクト実績と計画要求事項の乖離が許容範囲内かどうかを判断するために、プロジェクト実績を評価するための比較基準として使用する、承認されたハイレベルなプロジェクト計画です。ベンチマークは、プロジェクト計画の特別版とも言えます。
プロジェクトマネジメント計画書にも、他のセクションにも、「品質ベンチマーク」はありません。なぜなら、ハイレベルな品質基準は、通常、プロジェクトマネージャーやプロジェクト実施組織自身が設定するものではなく、法律、規制、業界標準などで定義されるものだからです。
プロジェクトのライフサイクルに関連するプロジェクトマネジメント計画の主な要素は、プロジェクトのライフサイクルの種類とフェーズ、計画された製品開発方法、プロジェクトのマネジメントレビューのタイミングと内容スケジュールです。
プロジェクトマネジメント計画は包括的な計画であり、個別の計画がプロジェクトマネジメント計画に相当することはありません。
プロジェクトマネジメント計画の役割
プロジェクト管理計画は、上級管理職だけでなく、場合によっては他の主要なプロジェクト利害関係者の承認を得なければなりません。
プロジェクトマネジメント計画が策定されると、その後の計画、実行、モニタリング、クローズアウトはすべて、その計画に従って実施されなければなりません。
プロジェクトの実行は、指導者に支配されるのではなく、計画に支配されるべきです。チームのメンバーは、指導者の指示に耳を傾けるのではなく、計画の配置を見て、彼らが毎日やっていることを行う必要があります。このようにして初めて、プロジェクトの様々な仕事の間のより良い協調が形成され、指導者のメンバーが本当に同じように出入りできるようになるのです。
プロジェクトマネジメントプランは、プロジェクトチャーターの割り当てとプロジェクトマネジメントプランの策定プロセスを除く、47のプロジェクトマネジメントプロセスのインプットとして使用されます。
プロジェクトマネジメント計画とプロジェクトマネジメント文書の違い
プロジェクト・マネジメント・プランが包括的な計画であるのに対して、プロジェクト・ドキュメントは、まとめられていないさまざまな個別文書の総称です。
プロジェクトマネジメント計画は上級管理職の承認が必要ですが、プロジェクト文書は一般的に上級管理職の承認は必要なく、プロジェクトチームが自主編集するのが普通です。
プロジェクトマネジメントプランのサブマネジメントプランは、手続き的なプランです。
プロジェクトマネジメントプランの更新は、変更プロセスを経て、上級管理職の承認を得なければなりませんが、プロジェクト文書の更新は、必ずしも変更プロセスを経る必要はありません。
プロジェクト計画の作成者
プロジェクト計画はボトムアップで。プロジェクトチームのメンバーは、自分に密接に関係する部分について適切な計画を作成し、それを一つ上の階層に報告し、まとめなければなりません。最後に、プロジェクトマネージャーは、総括詳細書を調整し、包括的なプロジェクトマネジメント計画をまとめる責任があります。
また、プロジェクトマネージャーやチームメンバーは、プロジェクト計画を作成する過程で、他の主要なステークホルダーの意見を十分に聞き、ステークホルダーのニーズを可能な限りプロジェクト計画に反映させる必要があります。
プロジェクト計画は、プロジェクト・マネジャーが総括的な責任と統合の役割を果たし、プロジェクト・メンバーによって作成されます。その他の重要なステークホルダーもプロジェクト計画の作成に関与します。
計画の実施者は、計画の作成に参加しなければなりません。そうすることで、計画の質が向上するだけでなく、計画に対する強い当事者意識が生まれ、計画通りに実施しようと努力するようになります。
プロジェクト計画の作成時期
プロジェクト実施当初は、可能な限り完全なプロジェクト計画を作成します。しかし、プロジェクト計画は、プロジェクトのライフサイクルのその後の段階においても、継続的に見直し、改善、改良、更新される必要があります。
プロジェクト・プランニングは、一朝一夕にできるものではなく、相当な期間にわたって、継続的な見直し、改良、改善、更新が必要です。
プロジェクトマネジメントでは、プロジェクトの状況が徐々に明らかになっていくので、プロジェクトの特性や計画を徐々に詳細にしていくことを重視します。最初から詳細な計画を押し付けると、非現実的なものになりがちです。
プロジェクト計画は通常、ローラープランニング方式で作成されます。つまり、近い将来に実施される作業については詳細な計画を作成し、遠い将来の作業については大まかな計画だけを作成し、後で時間をかけて洗練させていくというものです。
プロジェクト作業の指揮と管理
簡略化のため、PMBOKガイドでは、このプロセスを主にプロジェクト実施フェーズの作業について説明しています。
このプロセスでは、プロジェクトマネジメント計画の要求事項を達成するために、プロジェクトマネジメント計画の活動を実施し、成果物を完成させ、必要に応じてプロジェクトの変更を特定し、要求します。プロジェクト実行フェーズでは、通常「キックオフミーティング」が行われます。
PMBOK試験のシラバスでは、キックオフミーティングの開催は、計画プロセスチームの最後のタスクです。
プロジェクトの実施には、作業許可システムの使用が必要です。
プロジェクト実行中の重要な作業の多くは、スケジュールで指定された開始時刻に自動的に開始されるのではなく、正式な作業承認がなければ開始することができません。作業承認システムは、プロジェクトの作業がいつ、どのような順序で実行されるかを管理するために使用されます。
プロジェクト知識の管理
管理されていない知識はうまく機能しないだけでなく、増殖します。
ナレッジ・マネジメントは、既存の知識をよりよく活用するために整理・体系化すること、また、整理・体系化された知識に基づいて新たな知識を生み出し、その知識を実践することに重点を置いています。
PMBOKガイドでは、知識共有と知識統合という2つの重要なKM活動について特に言及しています。
プロジェクトのモニタリング
このプロセスは、プロジェクトマネジメント計画で定義されたプロジェクト目標が達成されるように、プロジェクト作業をモニタリングすることです。一方では、モニタリングはプロジェクト全体を通じて実施されます。すなわち、立ち上げ、計画、実行、クローズアウトがモニタリングされ、他方では、実行作業のモニタリングに焦点を当てて議論されます。
モニタリング・プロセス・グループにおける "モニタリング "とは、監督＋管理。モニタリングとは、実際のパフォーマンスと計画の要求事項を比較し、逸脱を特定すること。コントロールとは、逸脱を分析し、許容できないほど大きな逸脱を解決するために必要な変更の承認を要求することです。モニタリングとコントロールは表裏一体です。
プロジェクト作業プロセスのモニタリングは、プロジェクト全体のハイレベルなグローバルモニタリングです。作業実績報告書と必要な変更要求書を出力します。変更要求は幅広い。プロジェクト計画の変更だけでなく、是正措置、予防措置、欠陥是正の勧告も含まれます。
全体的な変更管理の実施
このプロセスは、プロジェクトの開始、計画、実行、監視の各段階で行われた変更要求を包括的にレビューするもので、変更要求の承認または却下、プロジェクトに対する変更の管理、プロジェクト・ベースラインの重大性と完全性の維持を目的としています。
このプロセスは、変更要求の承認に特化したものです。このプロセスは、変更要求のレビューにおいて、包括的、体系的、統合的でなければなりません。また、1つまたは2つの側面への影響に限定されるのではなく、変更がプロジェクトのすべての側面に及ぼす可能性のある影響に目を向けなければなりません。
変更要求のレビューは包括的でなければなりません。変更が承認されるのは、プロジェクト全体に利益をもたらす場合だけです。局所的な利益のために全体の利益が損なわれることを防がなければなりません。
変更が変更依頼を保留にすることは可能です。保留中の変更要求は、追加情報のために変更要求の発信者に返されることがよくあります。
誰でも許可申請をすることはできますが、許可申請を承認する権限は誰でも持っているわけではありません。
プロジェクトまたはフェーズの閉鎖
このプロセスは、調達契約、プロジェクト段階、またはプロジェクト全体を、正式なクローズアウト手続に従って正式に終了することです。
プロジェクトは、正式に終了する前に、正式な終了プロセスを経なければなりません。目的を達成することなく早期に終了したプロジェクトであっても、このプロセスを経て正式に終了しなければなりません。
プロジェクトは、終了するときはいつでも、プロジェクトまたはフェーズのプロセスを終了することによって、正式に終了しなければなりません。
プロジェクトやフェーズを終了するプロセスは、管理上の終了を実施し、プロジェクトを正式に終了することです。管理閉鎖の最後の作業は、チームを解散することです。チームが解散すると、何もできなくなります。
プロセスのためのツールとテクニック
専門家の判断
専門家判断とは、ある問題に対して、当該専門家がその知識と経験に基づいて判断することです。プロジェクトマネジメントには、科学的な要素と芸術的な要素があるため、芸術性を反映した専門家の判断は非常に重要な技術です。実際、ほとんどのマネジメントや技術的な仕事は、専門家の判断と切り離すことはできません。
専門家の判断は、プロジェクト実施組織の内外、プロジェクトチームの内外から得ることができます。
ミーティング
プロジェクト統合マネジメントの7つのプロセスのうち、「プロジェクト知識の管理」プロセスだけが、ツールとしてのミーティングを持っていません。
会議の目的としては、情報交換会議、プログラム作成・検討会議、意思決定会議に分けられます。この3つのタイプの会議は別々に行うのがベスト。どうしても一緒に開催しなければならない場合は、会議全体を3つの段階に分けることが望ましい。
会議は必要ですが、多すぎてもいけません。すべてを会議で解決しなければならないのであれば、それは仕事のシステムがうまくいっていない証拠です。
対人スキルとチームスキル
プロジェクト憲章の策定やプロジェクト管理計画の策定は、対人関係やチームスキルを活用し、プロジェクトの目的や計画に関する意見の相違を解決するためのプロセスであり、プロジェクト知識の管理は、知識の共有や知識の創造を可能にするためのプロセスです。
データ収集
ブレーンストーミングフォーカスグループインタビュー。チェックリスト。
データ分析
意味 決定
投票、独裁。
プロジェクト管理情報システム
知識管理
指示に従うこと。
情報管理
ナレッジ・マネジメントは、暗黙知を共有するために人と人とのつながりを作るために使われ、インフォメーション・マネジメントは、明示知を共有するために人と情報のつながりを作るために使われます。
変更管理ツール
プロジェクト変更管理
基本概念
プロジェクト変更とは、承認されたプロジェクト計画に対する是正処置、欠陥の是正、予防処置、計画自体の問題による修正のことです。プロジェクトの変更は避けられません。プロジェクト変更管理とは、不必要な変更を防ぎ、必要な変更を提案し、レビューし、実施し、まとめることです。
変更の理由
変更の基本的な理由は、プロジェクト管理計画の不備、プロジェクトの外部環境の変化、プロジェクト実行の非効率性などです。
変化は避けられないものであり、恐れるべきものではありませんが、変化が一定の数、一定の規模を超えると、プロジェクトは効果的なコントロールを失うことになります。従って、プロジェクトの変更は、無秩序で過剰な、そして特大の変更を防ぐために、効果的にコントロールされなければなりません。
プロジェクトの変更があまりに多く、規模が大きすぎる場合、プロジェクト憲章の改訂が必要になったり、現在のプロジェクトを終了して新しいプロジェクトを開始しなければならないこともあります。
変更管理の手順
変更管理プロセスは、次の5つの主要なステップで構成されます。変更の発生源での管理、変更要求の開始、変更要求のレビュー、承認された変更要求の実施と追跡、および教訓の学習。
ソースにおける変更の管理
プロジェクトマネージャーは受動的ではなく、能動的に動くべきです。不必要な変更を避けるために、変更の引き金となるさまざまな要因に積極的に影響を与えなければなりません。
また、プロジェクトマネージャーは、全体的な統制を回避する要因に積極的に影響を与え、変更点の包括的なレビューを意識的または無意識的に回避することを防ぐ必要があります。
PMBOKガイドには、ソースでの変更管理に特化したプロセスはありませんが、この作業はほとんどのプロセスで暗黙のうちに行われています。
変更要求の提出
変更は誰でも申請できます。変更の要請は、可能な限り書面で行ってください。
変更の要請は、書面であれ口頭であれ、正式に行われなければなりません。
変更要求を行う者は、その変更が何であり、なぜ必要なのかを明確に述べなければなりません。また、その変更がもたらす可能性のある結果や、その変更がどのような選択肢で実施される可能性があるのかについて、事前に説明しなければなりません。関係者が結果を考慮することなく、恣意的に変更を要求することを防ぐことが重要です。
プロジェクト計画が承認された後も、変更要求の可能性を考慮しながら、開始と計画のプロセスを繰り返します。
変更要求のレビュー
変更依頼をプロジェクトマネージャーに提出。正式なレビューが行われ、変更ログが作成されます。
PMP試験における「変更の記録」とは、一般的に変更ログに変更要求を書き込むことを指します。
変更要求の変更シナリオに基づき、まず、その変更がその領域に与える影響をレビューします。次に、変更要求のオプションに基づいて、その変更がプロジェクトのすべての側面に及ぼす複合的な影響をレビューします。必要であれば、レビューのための追加オプションを設計します。
変更の大小にかかわらず、変更は包括的に検討され、プロジェクト全体の利益に資するものであることが確認された上で承認されなければなりません。
承認された変更の実施と追跡
承認された変更のみが、実施、追跡、評価、報告されます。変更要求が承認されたら、プロジェクト文書とプロジェクト管理計画を適時に更新します。変更の影響を受ける関係者には、タイムリーに通知します。これは、変更を円滑に実施するために非常に重要です。
変更の承認権限
ベンチマークに影響しない変更は、プロジェクトマネージャーが承認します。ベースラインに影響するような承認は、緊急の場合を除き、プロジェクトマネージャーには承認権限がありません。
変更管理委員会および変更管理システム
変更管理委員会は正式に構成され、プロジェクトの主要な利害関係者が代表を務めます。プロジェクト・マネジャーがそのメンバーであることもありますが、通常はディレクターではありません。
プロジェクトには効果的な変更管理システムが必要です。
コンフィギュレーション管理
コンフィギュレーション管理は、プロジェクト全体の変更管理に不可欠な要素です。
コンフィギュレーション管理は、核となる技術的パラメータを特定し、これらのパラメータに対する変更を特に厳格な手順で管理することに重点を置き、コンフィギュレーションの変更が確実に管理され、管理され、追跡可能であることを保証します。
