目次
Previous:第 5 章、プロジェクト管理
第6章 管理全般
6.1 プロジェクト管理全体の概要
概要: プロジェクト全体管理とは、プロジェクト管理プロセス グループごとにさまざまなプロセスやアクティビティを特定、定義、組み合わせ、統合、調整するために実行される作業を含み、プロジェクト管理における包括的かつ全体的な管理作業です。
全体的なプロジェクト管理には、次の 4 つの側面が含まれます。
- ① 範囲、時間、コスト、品質など、競合するプロジェクトの下位目標間の統合。
- ② 建築プロジェクトのオーナー、設計者、請負業者など、利害の異なるプロジェクト関係者の統合。
- ③ 各種技術作業など、プロジェクトに必要な異なる専門作業間の統合。
- ④ プロジェクト管理のさまざまなプロセス間の統合。たとえば、プロジェクトのスケジュールとコスト管理を同時に考慮する必要があり、スケジュールまたはコスト管理を実行する際にはリスクを考慮する必要があり、プロジェクト範囲の変更は、それに伴うコストとスケジュールの変更の可能性と併せて考慮する必要があります。 。
プロジェクト マネージャーは総合的に管理し整合者、インテグレーターとして次のことを行う必要があります。
- 1) プロジェクト関係者との積極的かつ包括的なコミュニケーションを通じて、プロジェクトに対するニーズを理解します。
- 2) 競合する多くの利害関係者の間でバランスを見つけます。
- 3) 丁寧かつ綿密な調整作業により、諸要求のバランスを図り、統合を実現します。
6.2 メインプロセス
含む：
- プロジェクト憲章の作成 (開始プロセスグループ)
- プロジェクト管理計画の作成 (計画プロセス グループ)
- プロジェクト作業を指揮および管理する (実行プロセス グループ)
- プロジェクトの作業を監視する
- 統合変更管理の実装 (監視プロセス グループ)
- プロジェクトまたはフェーズの終了 (終了プロセス グループ)
6.2.1 プロジェクト憲章の作成
概要: プロジェクト憲章の作成は、プロジェクトを正式に承認し、プロジェクト マネージャーがプロジェクト活動で組織リソースを使用することを承認する文書を作成するプロセスです。プロジェクト憲章は、プロジェクトの正式な開始、プロジェクト マネージャーの任命を発表し、プロジェクトの目標、範囲、主要な成果物、主要な制約、および主要な前提条件の一般的な説明を提供します。
機能:
- ① プロジェクト管理者を決定し、プロジェクト管理者の権限を規定する
- ② プロジェクトの存在を正式に確認し、プロジェクトに法的地位を与える
- ③ プロジェクトの範囲、時間、コスト、品質などの全体的な目標を定義します。
- ④ プロジェクトを開始した理由を説明し、プロジェクトと実施組織の日常業務や戦略計画を結び付ける
プロジェクト憲章を作成するためのインプット:
- 1) プロジェクト作業明細書 (SOW)
- 内容: ① ビジネスニーズ、② 製品範囲の説明、③ 戦略計画
- 2) ビジネスケース
- 概要: ビジネス ケースまたは同様の文書は、商業的な観点からプロジェクトに投資する価値があるかどうかを判断するために必要な情報を提供します。
- 内容: ① ビジネスニーズと費用便益分析を実施する; ② プロジェクトの合理性を実証する; ③ プロジェクトの境界を決定する
- スポンサーはビジネスケースの範囲と限界を認識する必要がある
- 3) 合意
- フォームは、契約書、覚書、サービス品質協定、同意書、意向表明書、口頭協定、電子メール、その他の書面による協定に分類できます。
- 4) 組織プロセス資産
- 5）事業環境要因
プロジェクト憲章を作成するためのツールとテクニック:
- ①専門家の判断
- 概要: 組織内の他の部門、コンサルタント、プロジェクト関係者 (顧客やスポンサーを含む)、専門家および技術団体、業界団体、対象分野の専門家 (SME)、およびプロジェクト管理オフィス (PMO) などが含まれます。
- ②誘導技術
- 概要: ファシリテーション手法はさまざまなプロジェクト管理プロセスで広く使用されており、プロジェクト憲章の作成をガイドするために使用できます。
- 用途: ブレーンストーミング、対立管理、問題解決、会議管理など。
プロジェクト憲章の作成から得られる成果:
项目章程- コンテンツ：
- ①プロジェクト概要と製品概要
- ② 事業の目的又は事業を承認する理由
- ③ プロジェクトの一般要件
- ④ 測定可能なプロジェクト目標とそれに伴う成功基準
- ⑤ プロジェクトの主なリスク
- ⑥ 全体マイルストーンスケジュール計画
- ⑦ 全体予算
- ⑧ プロジェクトの承認要件
- ⑨ 任命されたプロジェクトマネージャーとその任務と権限
- ⑩ プロジェクト憲章を承認したスポンサーその他の者の氏名及び権限
- コンテンツ：
6.2.2 プロジェクト管理計画を作成する
概要: プロジェクト管理計画の作成は、他の計画プロセスの結果を、包括的で承認された現実的で正式なプロジェクト計画文書にまとめるプロセスです。プロジェクト管理計画は、経営陣からの承認を必要とするだけでなく、他の主要なプロジェクト関係者からの承認も必要とする場合があります。
機能:
- ① プロジェクトの実行、監視、終了をガイドします。
- ② プロジェクトのパフォーマンス評価とプロジェクト管理のベンチマークの提供
- ③ プロジェクト計画の前提となる前提を文書化する
- ④ 事業計画策定過程における関連スキームの選定を記録する。
- ⑤ プロジェクト関係者間のコミュニケーションの促進
- ⑥ マネジメントレビュープロジェクトの時期、内容、方法を明示する
- ⑦ 計画は、プロジェクトのライフサイクルの後続段階で継続的に見直し、洗練され、更新される必要がある
手順:
- ① 特定の知識領域ごとに個別のサブプランを策定
- ② 総合的な経営知識の分野では、各サブプランを収集し、プロジェクトマネジメント計画に統合します。
- ③ プロジェクト管理計画を活用してプロジェクトの実施とモニタリングを指導し、実施プロセス中のモニタリングを行う
- ④ 変更管理プロセス全体の実施に必要な変更申請を提出し、承認を得る
- ⑤ 承認された変更要求に従ってプロジェクト管理計画を更新します
プロジェクト管理計画を作成するための入力:
- 1) プロジェクト憲章
- 2) 他のプロセスからの出力
- ３）事業環境要因
- 4) 組織プロセス資産
プロジェクト管理計画を作成するためのツールとテクニック:
- ①専門家の判断
- ②誘導技術
プロジェクト管理計画の作成から得られる成果:
项目管理计划- 概要：
- プロジェクト管理計画は、一気飲みの。プロジェクト チームのメンバーは、密接に関連する部分に対応する計画を策定し、階層ごとに報告および要約し、最終的にプロジェクト マネージャーがそれらを統合して、包括的かつ全体的なプロジェクト管理計画を形成します。
- これは、プロジェクトの実施、監視、終了をガイドするための一連の小項目管理計画とその他の内容を統合した結果であり、他のプロジェクト管理計画プロセスの結果に基づいて策定されます。他のすべての計画プロセスは、プロジェクト管理計画の策定、プロセスの基礎。
- プロジェクト管理計画は、プロジェクトがどのように実行、監視、終了されるかを定義します。、その内容はプロジェクトの複雑さとその応用分野によって異なります。
- プロジェクト管理計画の作成は、他の計画プロセスの結果を、包括的で承認済みの現実的かつ正式なプロジェクト計画文書にまとめるプロセスです。プロジェクト管理計画には、経営陣だけでなく、他の主要なプロジェクト関係者の承認も必要になる場合があります。。
- プロジェクト管理計画を策定する過程で、プロジェクトマネージャーとプロジェクトチームのメンバーは、他の主要なプロジェクト関係者の意見にも十分に耳を傾け、関係者のニーズをプロジェクト管理計画にできる限り反映する必要があります。プロジェクトに対する利害関係者の偏見を避けるため、実行の結果は異なります。
- プロジェクト計画の作成プロセスは段階的かつ詳細なプロセスです。
- サブプラン:
- ① 範囲管理計画
- ② 需要管理計画
- ③進捗管理計画
- ④コスト管理計画
- ⑤ 品質管理計画
- ⑥ プロセス改善計画
- ⑦ 人材計画
- ⑧ コミュニケーション管理計画
- ⑨ リスク管理計画
- ⑩調達管理計画
- ⑪ プロジェクトコミュニケーション計画
- 主目的：
- (1) プロジェクトの実行、監視、終了をガイドします。
- (2) プロジェクトのパフォーマンス評価とプロジェクト管理のベンチマークを提供する
- (3) プロジェクト計画の基礎となる前提を文書化する
- (4) プロジェクト計画策定の過程で関連するスキームの選択を記録する
- (5) プロジェクト関係者間のコミュニケーションの促進
- (6) マネジメントレビュープロジェクトの時期、内容、方法を明示する
内容：- 1. 使用されるプロジェクト管理プロセス
- 2. それぞれの特定のプロジェクト管理プロセスがどの程度実施されているか
- 3. これらのプロセスを実行するためのツールと手法の説明
- 4. プロジェクトが選択するライフサイクルと各段階で採用されるプロセス
- 5. 選択したプロセスを使用して特定のプロジェクトを管理する方法
- 6. プロジェクトの目的を達成するために作業がどのように実行されるか、およびプロジェクトの目的の説明
- 7. 変更を監視および制御する方法、および構成管理を実行する方法を明確にする
- 8. 構成管理計画。構成管理の実行方法を明確にするために使用されます。
- 9. プロジェクトパフォーマンスベースラインの維持に関する誠実性に関する声明
- 10. プロジェクトの関係者とコミュニケーションをとるための要件と手法
- 11. プロジェクトのライフサイクル モデルを選択する
- 12. 特定の残された問題および保留中の決定の内容、重大度、緊急性に関する主要な管理レビュー
- 側面概要: 作業計画、人員組織計画、設備調達供給計画、その他のリソース供給計画、変更管理計画、スケジュール計画、コスト投資計画、文書管理計画、サポート計画
- 概要：
6.2.3 プロジェクト作業の指示と管理
概要: プロジェクト管理計画で特定された作業を主導および実行し、プロジェクトの目標を達成するために承認された変更を実装するプロセスです。
プロジェクト作業の入力を指示および管理します。
- 1) プロジェクト管理計画
- 2) 承認された変更リクエスト
- ２）事業環境要因
- 4) 組織プロセス資産
プロジェクト作業を指示および管理するためのツールとテクニック:
- ①プロジェクト管理情報システム
- ②打ち合わせ
- ③専門家の判断
プロジェクト作業の指揮と管理の成果:
- ①成果物
- ②勤務実績データ
- ③変更依頼
- ④プロジェクト管理計画の更新
- ⑤プロジェクトファイルの更新
承認された変更を実装するためのアクティビティには次のものが含まれます。
- 是正措置: プロジェクトの作業パフォーマンスをプロジェクト管理計画に沿った状態に戻すために行われる目的のある活動
- 予防措置: 将来のプロジェクト作業のパフォーマンスがプロジェクト管理計画と一致していることを確認するために行われる目的のある活動
- 欠陥回復: 不適合な製品または製品コンポーネントを修正するために行われる目的のある活動
6.2.4 プロジェクト作業のモニタリング
注意が必要です:
- プロジェクトの実際のパフォーマンスとプロジェクト管理計画を比較する
- プロジェクトのパフォーマンスを評価し、是正措置または予防措置が必要かどうかを判断し、必要な措置を推奨します。
- 新しいリスクの特定、既存のリスクの分析、追跡および検出、包括的なリスクの特定の確保、リスク状態の報告、および適切なリスク対応計画の実施
- プロジェクト全体を通じて、プロジェクト製品および関連文書のステータスを反映する正確かつ最新の情報ベースを維持します。
- ステータスレポート、進捗状況の測定、予測のための情報を提供します。
- 予測を作成して現在のコストとスケジュール情報を更新します
- 承認された変更の実装を監督する
- プロジェクトがプロジェクト統合の一部である場合、プロジェクトの進捗状況とステータスもプログラム管理者に報告する必要があります。
プロジェクトの作業入力を監視するには:
- 1) プロジェクト管理計画
- ２）進捗予想
- 3) コスト予測
- 4) 確認された変更点
- 5) 職務実績情報
- 6）事業環境要因
- 7) 組織プロセス資産
プロジェクト作業を監視するためのツールとテクニック:
- ①分析技術
- 回帰分析
- 概要: 互いに依存する 2 つ以上の変数間の定量的な関係を判断するための統計分析の方法。
-
- 概要：統計的グループ分けの計算と分析を通じて、分析対象のさまざまな特性、さまざまな性質、および相互分析の方法を定性的または定量的な観点から理解します。研究の目的と客観的現象の固有の特性に応じて、研究中の計画全体を、特定の記号または複数の記号に従って性質の異なるいくつかのグループに分割し、グループ内の差異ができる限り小さくなるようにします。グループ間の差は可能な限り大きくします。
- 因果関係分析
- 根本原因分析
- 概要: 根本原因分析は、問題の症状だけに焦点を当てるのではなく、問題の根本原因とその解決策を段階的に特定するための構造化された問題解決アプローチです。
- 予測方法
- 概要: シナリオ分析、what-if 分析。
- 故障モードと影響分析
- 概要: これは、構想と設計の初期段階で製品またはプロセスで起こり得る障害状況と、そのような障害状況が発生した場合の影響を特定するのに役立つ一連のプロセスとツールです。
- フォールトツリー分析
- 概要: 論理的な手法を採用し、弱点やリスク、その他の危険性を視覚的に分析します。直観力、明晰さ、明晰な思考、強力な論理性を特徴とし、定性分析と定量分析の両方に使用できます。
- 埋蔵量分析
- トレンド分析
- 概要: 傾向分析 (傾向予測とも呼ばれます) は、プロジェクトのパフォーマンスが時間の経過とともにどのように変化したかを調査し、パフォーマンスが向上しているか低下しているかを判断するために使用されます。具体的には、トレンド平均法、指数平滑法、線形トレンド法、非線形トレンド法が含まれます。主な利点は、時系列の発展傾向を考慮することで、より現実に即した予測結果を得ることができることです。
- 獲得価値管理
- 回帰分析
- ②プロジェクト管理情報システム
- ③打ち合わせ
- ④専門家の判断
プロジェクト作業の出力を監視します。
- ①変更依頼
- ②業務実績報告書
- ③プロジェクト管理計画の更新
- ④プロジェクトファイルの更新
6.2.5 統合変更管理の実装
概要：
- 統合変更管理の実装は、すべての変更要求のレビュー、変更の承認または拒否、成果物、組織プロセス資産、プロジェクト文書、およびプロジェクト管理計画への変更の管理、および変更プロセスの結果の伝達を行うプロセスです。このプロセスでは、プロジェクト文書、成果物、ベースライン、またはプロジェクト管理計画に対するすべての変更要求がうまく受け入れられず、それらの変更が承認または拒否されます。
- 統合変更管理プロセスをプロジェクト全体に実装し、プロジェクトのすべてのフェーズに適用します。プロジェクト マネージャーは、変更管理プロセス全体に対する最終的な責任を負います。
- プロジェクトの関係者は誰でも変更リクエストを送信できます。
- 変更リクエストは口頭でも書面でも可能です。公式でも非公式でも構いません。ただし、すべての変更リクエストは書面で文書化し、変更管理および構成管理システムに含める必要があります。。契約変更は最初から書面で正式に行われなければなりません。
- 統合変更管理は実際にはプロジェクトのベンチマーク変更管理を行います。
- プロジェクトの目的に影響を与える可能性のある変更は、実装前に変更管理委員会の承認を受ける必要があります。
変更制御ボード (CCB) :
- 概要：
- CCB は、プロジェクトの変更をレビュー、評価、承認、延期、拒否すること、および変更の処理に関する決定を文書化して伝達する責任を負う、正式に設立された団体です。一部の特定の変更リクエストは、CCB の承認後に、CCB メンバーでない限り、顧客またはスポンサーの承認が必要になる場合があります。。
- 全体的な変更管理は変更管理委員会と変更管理システムを通じて行うことができますが、全体的な変更管理は変更管理委員会だけの問題ではなく、プロジェクト マネージャーとプロジェクト チームの問題でもあります。その理由は次のとおりです。
- ① 変更管理委員会は、プロジェクトの主要な関係者の代表で構成されるグループです。プロジェクト マネージャーはメンバーの 1 人になることができますが、通常はチーム リーダーではありません。この委員会は、変更要求を検討し、承認または拒否する責任があります。プロジェクトの目的に影響を与える可能性のある変更は、実装前に変更管理委員会の承認を受ける必要があります。
- ② 変更管理システムとは、文書、追跡システム、変更の承認レベルなど、変更管理のための一連の正式な書面による手順を指します。
- 役割: 変更リクエストを承認または拒否する直接組織
統合変更管理を実装するための入力:
- 1) プロジェクト管理計画
- 2) 業務実績報告書
- 3) 変更リクエスト
- 4) 組織プロセス資産
- 5）事業環境要因
統合変更管理を実装するためのツールと手法:
- ①打ち合わせ
- ②変更管理ツール
- ③専門家の判断
統合変更管理の実装による成果:
- ① 変更申請の承認
- ②変更履歴
- ③プロジェクト管理計画の更新
- ④プロジェクトファイルの更新
变更控制流程：
- まず連絡してから、変更申請を書面で提出してください。
- 範囲、コスト、スケジュール、品質などへの影響を含め、変更による影響を十分に評価し、評価結果を関係者に通知します
- 規制に従ってプロセスを変更し、CCB の承認を受ける
- 変更の承認が失敗した場合、変更はキャンセルされ、監視対象に含まれます。
- 変更が承認された場合、対応するプロジェクト計画と文書が調整および更新され、関係者に通知されます。
- 要件に従って変更を実行し、変更の実装を記録します。 7. 変更の検証、アーカイブなど。
変更理由：
- 1. プロジェクトの外部環境の変化
- 2. プロジェクト範囲の計画が完全かつ詳細ではなく、特定の誤りや漏れがある
- 3. 新しい技術、手段、新しいスキームが市場に登場するか、設計者が提案する
- 4. 州の事業実施組織の変更
- 5. プロジェクト、プロジェクト製品またはサービスに対する顧客の要件が変更された場合
6.2.6 プロジェクトまたはフェーズの終了
含む:
- 契約締結
- 概要：契約書の規定に従い、プロジェクトチームがオーナー様と契約内容が全て完了しているか確認し、契約を締結します。
- 管理上の閉鎖 (管理上の閉鎖)
- 概要：経験を蓄積し「組織プロセス資産」を形成する。プロジェクトが早期に完了または終了した場合、またはプロジェクトの各フェーズの終了時に、管理上の仕上げ作業が必要になります。
- 含む：
- (1) 製品の検証。プロジェクト成果物の確立された要件に従ってすべての作業が完了したことを確認します
(2) 財務上の完了。最終的なプロジェクトの支払いが行われ、財務決済が完了します。
(3) プロジェクトの記録が更新されます。最終プロジェクト パフォーマンス レポートとプロジェクト チーム メンバーのパフォーマンス記録を完成させます
(4) 学んだ教訓を要約し、プロジェクト後の評価を実施します
(5) 組織プロセス資産を更新します。プロジェクトの各種資料の収集、整理、アーカイブ
(6) プロジェクトに関するプロジェクト関係者の関係を終了し、プロジェクトチームを解散する
- (1) 製品の検証。プロジェクト成果物の確立された要件に従ってすべての作業が完了したことを確認します
- 結果：
- (1) プロジェクト成果物の正式な受諾
(2) プロジェクト関係書類の完成
(3) 組織プロセス資産の更新 (学んだ教訓の要約)
(4) リソースの解放 (人的および非人的リソースを含む)
- (1) プロジェクト成果物の正式な受諾
連絡先と、契約締結と管理上の締結の違い:
連絡先: どちらも製品の検証が必要で、両方とも経験と教訓を要約する必要があります。調達監査を実施し、当事者間の契約関係を終了し、関連データを収集してファイルし、組織プロセス資産を更新します。
違い：
- ① 事務処理はプロジェクトとプロジェクトの各段階を対象としており、プロジェクト全体の事務処理だけでなく、プロジェクトの各段階の終了時にも、契約の完了を目的とした事務処理を行う必要があります。契約時に、各契約が必要であり、契約の完了のみが必要です。
- ② プロジェクト全体の観点から、契約の締結は管理上のクロージングよりも前に行われ、プロジェクトが契約の形で実施される場合、クロージング段階では調達監査と契約のクロージングが最初に行われなければなりません。 、その後、管理上の閉鎖を実行する必要があります。
- ③ 契約の締結には、ある契約の観点から見ると、管理上の締結作業（管理上の契約締結）も含まれます。
- ④ 管理上の終了については、プロジェクトの開始者または上級管理者が、プロジェクト段階の終了またはプロジェクト全体の完了についてプロジェクトマネージャーに書面による確認書を発行する必要があります。一方、契約の終了については、担当の調達管理メンバー（プロジェクトマネージャーまたはその他）は、売り手に契約書を発行し、閉鎖の書面による確認を行う必要があります。
プロジェクトまたはフェーズを終了するための入力:
- 1) プロジェクト管理計画
- 2) 成果物の受領
- 3) 組織プロセス資産
プロジェクトまたはフェーズを終了するためのツールとテクニック:
- ①分析技術
- ②打ち合わせ
- ③専門家の判断
プロジェクトまたはフェーズの終了からの出力:
- ① 最終的な製品、サービスまたは成果の引き渡し
- ② 組織プロセス資産の更新
Previous:第 5 章、プロジェクト管理