マインドマップギャラリー システムインテグレーションプロジェクトマネジメントエンジニアソフトウェア試験合格第6章 プロジェクトマネジメント全般(2)
システム インテグレーション プロジェクト マネジメント エンジニア/ソフトウェア試験合格/第 6 章 全体的なプロジェクト管理 (2)、プロジェクト作業の監督、全体的な変更管理の実装、プロジェクトまたはフェーズの終了などを含みます。
2024-03-03 01:16:02 に編集されました第6章 プロジェクト管理全般 (2)
実装プロセス
ステップ(4) プロジェクトの作業を監視する
意味
プロジェクト管理計画で特定されたパフォーマンス目標を達成するために、プロジェクトの進捗状況を追跡、レビュー、報告するプロセス
プロジェクトの作業全体を通して
プロジェクトの実行だけでなく、プロジェクトの開始、計画、終了も監視します
効果
プロジェクトの現在の状況、実行された手順、予算、スケジュール、範囲の予測を関係者に常に知らせます。
主な懸念事項
(1) 実際のプロジェクトのパフォーマンスをプロジェクト管理計画と比較する
(2) プロジェクトのパフォーマンスを評価し、是正措置または予防措置が必要かどうかを判断し、必要な措置を推奨します。
(3) 新しいリスクの特定、既存のリスクの分析、追跡および監視、リスクの包括的な特定の確保、リスク状態の報告、および適切なリスク対応計画の実施
(4) プロジェクト製品および関連ドキュメントを反映するために、プロジェクト全体を通じて正確かつ最新の情報ベースを維持します。
(5) 状況報告、進捗状況の測定、予測のための情報を提供する
(6) 予測を作成して現在のコストとスケジュール情報を更新します
(7) 承認された変更の実装を監視する
(8) プロジェクトがプログラムの一部である場合、プロジェクトの進捗状況とステータスもプログラム管理者に報告する必要があります。
伊藤
入力 入力
(1) プロジェクト管理計画
(2) 進捗予測
予測により、プロジェクトが許容範囲内にあるかどうかを判断し、必要な変更を特定できます。
(3) コスト予測
EAC と BAC を比較すると、プロジェクトがまだ許容範囲内にあるかどうか、および変更リクエストを行う必要があるかどうかがわかります。
(4) 確認された変更点
変更が正しく実装されたことを証明するにはデータが必要です。
(5) 仕事のパフォーマンス情報
相互関係とコンテキストを考慮し、プロジェクトの意思決定の信頼できる基礎として機能します。
(6) 事業環境要因
(7) 組織プロセス資産
ツールとテクニック ツール&テクノロジー
(1) 分析能力
1||| 回帰分析
2 つ以上の変数間の定量的な関係を判断する統計分析方法。
2||| グループ化方法
研究の目的と対象となる現象の固有の特性に従って、研究対象の集団は、グループ内の差異ができる限り小さくなるように、特定のマークまたは複数のマークに従って性質の異なるいくつかのグループに分割されます。グループ間の差異は可能な限り大きくする
3||| 原因と結果の分析
フィッシュボーン ダイアグラムまたはイシカワ ダイアグラムとも呼ばれます。詳細については、「品質管理」を参照してください。
4||| 根本原因分析 (RCA)
問題の根本原因を徐々に特定するための構造化された問題解決アプローチ 問題の症状だけに焦点を当てるのではなく、問題を解決する
分析ツール
因果関係図
ブレーンストーミング
原因と結果の分析 (特性要因図)
5||| 予測方法
what-if シナリオの分析とシミュレーション (モンテカルロ分析) については、「品質管理」を参照してください。
6||| 故障モードと影響分析 (FMEA)
これは、製品やプロセスの障害状況と、そのような障害がコンセプトや設計の初期段階で発生した場合の影響を特定するのに役立つ一連のプロセスとツールであり、考えられる障害原因をランク付けし、対応する問題を開発および実装する際にも役立ちます。対応策。
7||| フォールトツリー分析 (FTA)
論理的手法を使用して、弱点、リスク、その他の危険性を視覚的に分析します。これは、直感的で明確なアイデアと強力なロジックを特徴とし、定性的または定量的な分析に使用できます。
8||| 埋蔵量分析
詳細については、コスト管理を参照してください
9||| トレンド分析
傾向予測とも呼ばれ、プロジェクトのパフォーマンスの時間の経過に伴う変化を調べて、パフォーマンスが向上しているか低下しているかを判断するために使用されます。
具体的には、トレンド平均法、指数平滑法、線形トレンド法、非線形トレンド法が含まれます。
利点は、時系列の発展傾向が考慮されるため、予測結果が現実とよりよく一致することです。
10||| 収益価値管理
詳細については、コスト管理を参照してください
(2) プロジェクト管理情報システム
(3) ミーティング
(4) 専門家の判断
出力 出力
1||| 変更要求
2||| 仕事のパフォーマンスレポート
3||| プロジェクト管理計画の更新
4||| プロジェクトファイルの更新
ステップ(5) 総合的な変更管理を実装する
意味
すべての変更要求のレビュー、変更の承認または拒否、成果物、組織プロセス資産、プロジェクト文書、およびプロジェクト管理計画への変更の管理、および変更処理の結果の伝達のプロセス。
プロジェクト全体を通じて、プロジェクトのすべての段階で適用され、プロジェクト マネージャーがこれに対する最終的な責任を負います。
プロジェクトの関係者は誰でも変更リクエストを送信できます。口頭で行うこともできますが、すべての変更リクエストは書面で文書化し、変更管理および構成管理システムに含める必要があります。
文書化された各変更リクエストは、責任者によって承認または拒否される必要があります。この責任者は通常、プロジェクト スポンサーまたはプロジェクト マネージャーであり、プロジェクト管理計画または組織プロセスで指定する必要があります。必要に応じて、変更管理委員会 (CCB) は、全体的な変更管理プロセスを実装するかどうかを決定する必要があります。
変更管理管理のフローチャート
効果
文書化されたプロジェクトの変更を統合的な観点から検討することで、プロジェクト全体の目標や計画に対する変更の影響を考慮しないことによるプロジェクトのリスクを軽減します。
コントロールボードCCBの変更
プロジェクトの変更をレビュー、評価、承認、延期、または拒否し、変更処理の決定を文書化して伝達する責任を負う、正式に構成されたグループ
承認する
全体的な変更管理は、CCB および変更管理システムを通じて実現できます。しかし、全体的な変更管理は CCB だけの問題ではなく、プロジェクト マネージャーやプロジェクト チームの問題でもあります。
CCB は、主要なプロジェクト関係者 (顧客、ユーザー、スポンサー、経営陣、リーダー、マネージャー、プロジェクト マネージャーなど) の代表者で構成されるグループです。プロジェクト マネージャーはメンバーの 1 人になることもできますが、通常はチーム リーダーではありません。 CCB は変更リクエストをレビューし、承認または拒否する責任があります。
プロジェクトの目的に影響を与える可能性のある変更は、実装する前に変更管理委員会 (CCB) の承認を受ける必要があります。CCB の承認後、既に CCB のメンバーである場合を除き、顧客またはスポンサーの承認も必要になる場合があります。
変更管理システムとは、文書、追跡システム、変更承認レベルなどを含む、変更管理のための一連の正式な書面による手順を指します。
違い
構成制御
各プロセスの成果物と技術仕様のマッチングに重点を置く
変更管理
プロジェクト文書、成果物、またはベースラインに対する変更の特定、文書化、承認または拒否に重点を置く
構成管理アクティビティ
1. 構成の識別
2. 構成ステータスのログ記録
3. 構成の検証と監査
変更アクティビティが含まれる
(1) 発生する可能性のある変更と実際に発生した変更を特定する
(2) 承認された変更のみが確実に実装されるようにするための、全体的な変更管理に影響を与える関連要素
(3) 変更リクエストを確認して承認する
(4) 標準化された変更要求プロセスを通じて承認された変更を管理する
(5) ベースラインの完全性を管理して、承認された変更のみがプロジェクトの製品またはサービスに統合されるようにし、変更に関する構成および計画文書を維持します。
(6) 書面によるすべての是正措置および予防措置のレビューと承認
(7) 承認された変更に基づいて、プロジェクトの範囲、コスト、予算、スケジュール、品質要件を管理および更新する 変更は、プロジェクト全体の観点から調整する必要があります。
(8) 変更リクエストによるすべての影響を文書化する
(9) 欠陥修正の正確性を検証する
(10) 品質レポートに基づいてプロジェクトの品質を管理し、標準への準拠を確保します
伊藤
入力 入力
(1) プロジェクト管理計画
(2) 仕事のパフォーマンスレポート
(3) 変更要求
(4) 事業環境要因
(5) 組織プロセス資産
ツールとテクニック ツール&テクノロジー
(1) 変更管理ツール
(2) 専門家の判断
(3) ミーティング
出力 出力
(1) 承認された変更リクエスト
(2) プロジェクト管理計画の更新
(3) プロジェクトファイルの更新
(4) 変更ログ
プロジェクト中に発生した変更を記録するために使用されます。未承認の変更リクエストも変更ログに記録する必要があります。
ステップ(6) プロジェクトまたはフェーズの終了
意味
すべてのプロジェクト管理プロセス グループのすべてのアクティビティを完了して終了し、プロジェクトまたはプロジェクト フェーズを正式に終了するプロセス
このプロセスには、プロジェクト プロセスのすべてのアクティビティを完了して、プロジェクトまたはフェーズ全体を正式に終了すること、プロジェクトの成果物を顧客または資金提供者と調整して文書化して正式に承認することが含まれます。
クロージングステージの主な管理内容はクロージング管理です。本質は、プロジェクトの管理上の終了を実行することです。プロジェクトを終了する過程では、プロジェクトのスポンサーや顧客からプロジェクトの製品、サービス、結果について最終的な承諾を得る必要もありますが、この承諾は主に必要な手続きであり、実質的な技術的な承諾ではなく、形式的な承諾です。受け入れ。真の技術的承認は、範囲検証プロセスの早い段階で達成されます。
効果
経験と学んだ教訓を要約し、プロジェクト作業を正式に終了し、新しい作業のために組織リソースを解放します。
含む
1. 事務処理の終了 【運営終了】
管理上の終了作業は、プロジェクトが終了するか途中で終了する場合、またはプロジェクトの各フェーズの終了時に実行する必要があります。
コンテンツ
1||| 製品の検証
プロジェクト製品の確立された要件に従ってすべての作業が完了したことを確認します
2||| 決算
プロジェクトの最終支払いを行い、財務決済を完了する
3||| プロジェクト記録を更新する
プロジェクトの最終パフォーマンスレポートとプロジェクトチームメンバーのパフォーマンス記録を完成させる
4||| 経験と教訓を要約し、プロジェクトの完了後評価を実施する
5||| 組織プロセス資産の更新を実行する
さまざまなプロジェクト資料を収集、整理、アーカイブする
6||| プロジェクトに関するプロジェクト関係者間の関係を終了し、プロジェクト チームを解散する
結果
1. プロジェクト製品の正式受注
2. 完全なプロジェクトのアーカイブ
3. 組織プロセス資産の更新 (学んだ教訓の要約)
4. リソースの解放(人的リソースおよび非人的リソースを含む)
2. 契約締結
定義: 契約作業の終了、調達監査の実施、当事者間の契約関係の終了、関連情報の収集とアーカイブ
二人の関係
接続する
どちらも、製品の検証を実施し、経験と教訓を要約し、関連データを整理してアーカイブし、組織のプロセス資産を更新する必要があります。
違い
a. 管理上の終了は、プロジェクトおよびプロジェクトの各フェーズに対して行われます。プロジェクト全体を一度管理上終了する必要があるだけでなく、プロジェクトの各フェーズの終了時にも対応する管理上の終了を実行する必要があります。 -------------------------------------------------- ------------------- 契約の締結は契約ごとに異なります。締結する必要があるのは 1 回だけです。
b. プロジェクト全体の観点から見ると、契約の完了は管理上の完了より前に行われます。 -------------------------------------------------- ----- プロジェクトが契約の形式で実行される場合、クロージング段階では、調達監査と契約クロージングが最初に実行され、その後管理クロージングが実行されます。
c. ある契約の観点から見ると、契約締結には事務締結作業(契約の事務締結)も含まれます。
d. 管理上の終了には、プロジェクトのスポンサーまたは上級管理者が、プロジェクトの段階が完了したこと、またはプロジェクト全体が完了したことをプロジェクト マネージャーに書面で確認することが必要です。 -------------------------------------------------- ---------------- 契約終了時には、調達管理を担当するメンバー(プロジェクトマネージャーなど)が売主に契約終了の書面による確認書を発行します。
伊藤
入力 入力
(1) プロジェクト管理計画
(2) 受領のための成果物
承認された製品仕様、納品受領書、および作業実績文書が含まれる場合があります。段階的に進行したプロジェクトまたはキャンセルされたプロジェクトには、未完了または中間の成果物が含まれる場合があります。
(3) 組織プロセス資産
プロジェクトまたはフェーズの終了ガイドラインまたは要件
歴史的な情報と教訓の知識ベース
ツールとテクニック ツール&テクノロジー
a. 分析能力
回帰分析
トレンド分析
b. 専門家の判断
c. ミーティング
出力 出力
1||| 最終製品、サービス、または出力の引き渡し
2||| 組織プロセス資産の更新
プロジェクトファイル
プロジェクトまたはフェーズの終了文書
プロジェクトが完了前に早期に終了する場合、正式な終了文書にはプロジェクト終了の理由を記載し、プロジェクトの完了済みおよび未完成の成果物を他の人に引き渡すための正式な手順を記載する必要があります。
履歴情報
他の
プロジェクトを終了するとき、プロジェクト マネージャーは、すべてのプロジェクト作業が完了し、プロジェクトの目標が達成されたことを確認するために、前のフェーズの終了情報を確認する必要があります。
プロジェクト マネージャーは、プロジェクトの終了を宣言する前に、スコープ ベースラインを確認してプロジェクト作業が完了していることを確認する必要があります。
プロジェクトが完了前に途中で終了した場合、プロジェクトまたはフェーズのプロセスを終了するには、途中で終了した理由を調査して文書化する手順も必要になります。
プロジェクト マネージャーは、適切な関係者全員をこのプロセスに参加するよう招待する必要があります。