上級システムアーキテクトプロジェクト管理ソフトウェア試験

今日は 2023 年 9 月 6 日です。上級ソフト試験まであと 58 日です。さあ！

コンセプト

一時的な性質: 各プロジェクトには明確な開始時刻と終了時刻があることを意味し、一時的な性質はプロジェクトが 1 回限りであることも意味します。

プロジェクトの選択

プロジェクトの目標と動機
- 基礎研究の実施
- 応用研究開発の実施
- 技術サービスの提供
- 製品ユーザー
- 市場の需要
- ポリシーガイダンス
- 技術開発
プロジェクトの価値判断
プロジェクトの選択と決定
- 核となる価値観を持つプロジェクトを選択する
- 選択したプロジェクトを評価する
- プロジェクトの優先順位付け
- 評価プロジェクトを実施するためのさまざまな方法
- バランスを考慮して適切なソリューションを選択する
予備調査
- 事前のニーズ分析
- 企業の基本的な状況
- 管理方法と基本的なデータ管理状況
- 現在のシステムステータス
実行可能性分析

危険

リスクには、客観性、偶然性、相対性、社会性、不確実性という特徴があります。

リスクの 4 つの要素: 事象、原因、結果、発生確率。

ネガティブなリスクまたは脅威に対する対処戦略: 回避、移転、軽減、受け入れ
ポジティブなリスクまたは機会に対する対処戦略: 活用、改善、共有、受け入れ

リスクを特定するためのツールと手法:

SWOT分析：強さ、弱さ、弱さ、機会、脅威

チャーター

プロジェクト憲章には以下が含まれます。

プロジェクトの概要とプロジェクトの製品説明
プロジェクトの目的またはプロジェクトを承認する理由、つまりなぜこのプロジェクトを行うのか
プロジェクトの全体的な範囲と全体的な品質要件を含む、プロジェクトの全体的な要件
測定可能なプロジェクト目標と関連する成功基準
プロジェクトの主なリスク (プロジェクトの主なリスクカテゴリなど)
全体的なマイルストーンスケジュール
全体の予算
プロジェクトの承認要件、つまりプロジェクトの計画、実行、監視、終了中に誰がどのような承認を行う必要があるか
委任されたプロジェクトマネージャーとその責任と権限
プロジェクト憲章を承認したスポンサーまたはその他の人の名前と権限

実行可能性分析

実現可能性分析は、プロジェクトへの投資、建設、または大規模な改革の開始時に実行する必要があるタスクです。プロジェクトの実現可能性分析は、多要素、多目的システムに基づく分析、評価、意思決定のプロセスです。

実現可能性調査は通常、経済的実現可能性、技術的実現可能性、法的実現可能性、ユーザーの実現可能性という 4 つの側面から分析されます。

経済的実現可能性

投資収益分析または費用便益分析とも呼ばれ、主に建設コスト、運営コスト、およびプロジェクト完了後に起こり得る経済効果を評価します。ほとんどのプロジェクトでは、企業が許容できる予算内で建設コストを管理できる場合にのみ、プロジェクトの実施が承認される可能性が高くなります。経済的利益の考慮は非常に幅広く、直接的利益と間接的利益、有形的利益と無形的利益、一度限りの利益と非一度限りの利益、定量化可能な利益と定量化不可能な利益などに分けることができます。システム開発の初期段階では、ユーザーの要件やシステムソリューションの候補がまだ決まっていないため、コストを正確に見積もることができません。したがって、現時点での経済性分析では、システムのコストと便益を大まかに見積もり、情報システムを構築する価値があるかどうかを判断することしかできません。

技術的な実現可能性

技術リスク分析とも呼ばれ、情報システムが実現すべき機能や性能、技術的能力の制約などを研究対象とします。技術的な実現可能性は、主に次の問題を考慮することによって実証されます。

テクノロジー: 既存の技術能力と情報テクノロジーの開発状況が、システムの目標の実現をサポートするのに十分であるかどうか。
リソース: 既存のリソース (技術スキルを持つ従業員、企業の技術蓄積、コンポーネントライブラリ、ソフトウェアおよびハードウェアの状態など) がプロジェクトの実装をサポートするのに十分であるかどうか。
目標: 実現可能性調査の段階では、プロジェクトの目標は比較的曖昧であるため、技術的な実現可能性は、プロジェクトの機能、パフォーマンス、および制約の定義と同時に実行するのが最適です。実現可能性調査の段階では、プロジェクトの目標を調整し、実現可能な技術システムを選択することができますが、プロジェクトが開発段階に入ると、調整にはより多くの費用がかかります。技術的実現可能性は、技術的手段によって達成可能かどうかを示すだけでなく、実際には現在のリソース条件下での技術的実現可能性を含みます。技術的な実装手段のみを考慮し、企業の現在のリソース条件や環境を無視し、技術的な実現可能性分析で過度に楽観的な結果を得ると、後のプロジェクトの実装に壊滅的な結果をもたらすことが実践で証明されています。テクノロジーの選択に関しては、新しいテクノロジーを好む企業もあれば、成熟したテクノロジーの使用を好む企業もいます。プロジェクトの実際の状況 (開発環境、開発者の品質、システムのパフォーマンス要件など) に基づいて決定する必要がありますが、一般的に推奨されるのは、可能な限り成熟したテクノロジを使用し、先進的なテクノロジを慎重に導入することです。

法的実現可能性

社会的実現可能性とも呼ばれ、情報システム構築の現実性を政策、法律、倫理、制度などの社会的要素から実証する必要がある比較的幅広い内容です。たとえば、開発されたシステムが国の法律や政策に抵触する、政府の情報化分野で未承認の暗号化アルゴリズムが使用される、保護された技術や他社のコンポーネントを許可なく製品に使用する、などです。このようなプロジェクトは法的観点から単純に実行不可能です。実現可能性。

ユーザーの実現可能性

導入実現可能性とも呼ばれ、企業の管理管理や業務体制、利用者の品質や教育要件など、情報システム利用者の視点からシステムの実現可能性を評価します。これは、管理の実現可能性と運用の実現可能性にさらに分けることができます。

経営の実現可能性。経営実現可能性とは、企業経営の観点からシステム構築の実現可能性を分析することを指します。上司の支援がなければプロジェクトは失敗するのが一般的で、中上級管理職の抵抗が大きいため、状況を作り出すためには時間をかけて積極的に思想活動を行う必要がある。さらに、管理手法が科学的であるか、対応する管理システム改革の機が熟しているか、規程や規定が完備されているかなども考慮する必要があります。
運用の実現可能性。運用実現可能性は、運用実現可能性とも呼ばれ、分析測定情報システムが特定の環境で効果的に動作し、ユーザーが容易に使用できる程度と能力を指します。例えば、ERPシステム構築後のデータ収集やデータ品質の問題、企業スタッフのITスキル不足などが挙げられます。これらの問題はシステムそのものとは関係ありませんが、評価されなければ、せっかく莫大な投資をして構築した情報システムが役に立たなくなる可能性があります。運用の実現可能性には、既存の IT 施設への影響、ユーザー組織への影響、既存のビジネスプロセスへの影響、場所への影響、資金支出への影響など、システムのさまざまな影響を評価することも必要です。特定の影響によってユーザーの現在の状況が大きく変化する場合は、これらの要因についてさらに話し合い、ユーザーとコミュニケーションをとり、提案される解決策を提案する必要があります。そうしないと、システムが構築された後、または構築途中であっても、ユーザーからの激しい反対が発生し、システムの使用に抵抗することになります。

事業化可能性調査は、予備的事業化調査と詳細的事業化調査に分かれており、前者は予備的事業化報告書を作成することができ、両者の内容はほぼ同じであり、小規模プロジェクトでは通常後者のみを実施し、前者は省略できるが、後者は省略可能である。方法: 投資見積り法、増分利益法。

スコープ管理

スコープ計画→スコープ定義→WBS作成→スコープ確認→スコープ管理

スコープ管理とは、プロジェクトの境界を決定すること、つまり、プロジェクト内でどの作業を実行する必要があり、どの作業をプロジェクトに含めるべきかを決定することです。このプロセスは、プロジェクトの関係者が、プロジェクトの成果となる製品やサービス、およびそれらの製品を開発するために特定されたプロセスについて共通の理解を確実に持つために使用されます。
WBS (作業分解構造) は、プロジェクト全体または主要な成果物を、管理と制御が容易な複数のサブプロジェクトに分解します。サブプロジェクトは、さらに作業パッケージに分解する必要があります。プロジェクト全体が管理可能な作業パッケージに分割され、プロジェクトの合計作業範囲が合計されるまで、このプロセスを続けます。WBS を作成する目的は、プロジェクトの範囲を指定し、範囲のベースラインを確立することです。具体的には、主な目的と用途は次のとおりです。

プロジェクトチームのメンバーがタスクの性質と作業する必要がある方向性を明確に理解できるように、プロジェクトの範囲を明確かつ正確に記載します。
プロジェクトを完了するために必要な技術的および人的リソースを決定するために、独立した各部門に担当者を割り当て、これらの担当者の対応する責任を指定します。
独立したユニットごとに、時間、コスト、およびリソースの要件を見積もり、見積もりの精度を向上させます。
計画、予算編成、スケジュール、コスト管理のための共通基盤を確立し、プロジェクトの進捗状況の測定と管理のベースラインを確立します。
プロジェクト作業をプロジェクトの財務口座にリンクする
責任の分割と割り当てを容易にするためにプロジェクトの境界を明確に定義し、プロジェクトの目標を上から下まで特定のタスクに実装し、これらのタスクをプロジェクト内外の個人または組織に割り当てて完了させます。
作業内容と作業順序を決定します。作業内容がグラフィカルに表示され、誰でもプロジェクトの段階や作業単位を明確に把握し、実際の進捗状況に応じて調整・管理することができます。
プロジェクトの全体コストとプロセスコストを見積もる
需要の伝染を防ぐのに役立ちます。ユーザーや他のプロジェクト関係者がプロジェクトに機能を追加しようとする場合、対応する作業を WBS に追加すると、関連するコストやスケジュールもそれに応じて変更する必要があることが理解しやすくなります。

原価管理

コスト管理プロセスには、コスト見積もり、コスト予算編成、およびコスト管理が含まれます。コスト予算編成の意味は、総コスト見積もりをさまざまなアクティビティや作業パッケージに割り当てて、コストのベースラインを確立することです。コスト見積もりは、プロジェクト活動を完了するために必要な資金のおおよその見積もりです。

CV、コスト差異、コスト偏差 = アーンドバリュー (EV) - 実際コスト (AC)
CV がプラスの場合、実際に消費された労働力 (またはコスト) が予算値よりも低い、つまり、余剰があることを意味します。効率が高い; CV がゼロの場合 CV が負の値の場合、実際に消費された労働力 (または経費) が予算値を超えているか、予算を超えていることを意味します。

費用便益分析

含まれる概念:

料金
- 固定費: 生産量に応じて変化しない
- 変動費: 生産量に応じて変化します
- 混合コスト:
- 直接コスト: プロジェクトに直接投資されます。
- 間接費: プロジェクトに割り当てられます。
所得
- 目に見えるメリット
- 無形の利益
損益重要分析
正味現在価値分析
返済期間

損益重要分析

売上高＝固定費＋変動費＋利益
売上高＝固定費＋変動費損益
分岐点売上高＝固定費合計／（売上単価－変動費単価）
損益分岐点売上高＝固定費合計／（ 1-変動費合計/売上収益)、

正味現在価値分析

現在価値：P = F/(1+i)^n
現在の現在価値をn年後に換算した実際の価値正味現在価値
：
NPV=∑(CI-CO)(1+i)^-t
ここに画像の説明を挿入します

返済期間

静的な投資回収期間: 金利を考慮せずに赤字を均衡させるのに何年かかりますか?
動的回収期間: 金利を考慮した場合、赤字を均衡させるのに何年かかりますか?

投資回収率= 1 / 投資自己
-回収期間
内部収益率 = 正味現在価値が 0 に等しい場合の割引率

時間管理

プロジェクトを予定通りに完了させるために必要な管理プロセスが含まれます。プロジェクト時間管理のプロセスには、アクティビティの定義、アクティビティの順序付け、アクティビティのリソースの見積もり、アクティビティの期間の見積もり、スケジュールの計画、および進捗管理が含まれます。

SV、スケジュール差異、スケジュール偏差 = プロジェクトの完了予定時間 - プロジェクトの実際の完了時間。
スケジュール偏差がマイナスの場合はスケジュールが遅れていることを意味し、スケジュール偏差がゼロの場合は実際の状況が計画と一致していることを意味します。進捗偏差が正の場合、進捗が予定より進んでいることを意味します。

道具

PDM

PDM (優先順位図法) は、アクティビティオンノード (AON) としても知られ、クリティカルパス法で使用され、プロジェクトスケジュールネットワーク図を記述するために最も一般的に使用される方法の 1 つです。長方形はプロジェクトタスクを表すノードであり、これらのノードを接続する矢印はタスク間の依存関係を表します。

PDM には、次の 4 つの依存関係と先行関係があります (前: 先行タスクを表します。後: 後続タスクを表します)。

(Pre)Complete - (Post)Start (FS タイプ、終了-開始): 先行タスクの完了により後続タスクが開始されます。
(前)完了-(後)完了(FF型、仕上げ-仕上げ): 先行タスクの完了が後続タスクの完了につながります。
(前) 開始 - (後) 開始 (SS タイプ、開始 - 開始): 先行タスクの開始が後続タスクの開始につながります。
(前)開始-(後)終了(SFタイプ、開始-終了): 先行タスクの開始が後続タスクの完了につながります。

上記の関係のうち、終了-開始パターンは最もよく使用されるタスク関係であり、開始-終了パターンは最も使用されないタスク関係です。通常、各ノードのアクティビティには、最早開始時刻 (ES)、最遅開始時刻 (LS)、最早終了時刻 (EF)、および最遅終了時刻 (LF) の時刻があります。

ここに画像の説明を挿入します

ガントチャート

ガントチャートは、水平棒グラフや棒グラフとも呼ばれ、棒グラフを使用して、プロジェクト、スケジュール、その他の時間関連のシステムの進行状況の内部関係を時間の経過とともに表示します。提案者のヘンリー・ローレンス・ガント氏にちなんで命名されました。

ガントチャートは内容に応じて、計画チャート、負荷チャート、機械アイドルチャート、人員アイドルチャート、スケジュールチャートの 5 つの形式に分かれています。

利点: ガントチャートは直感的で、シンプルで、作成が簡単で、理解しやすく、各タスクの開始時間と終了時間を明確に示すことができるため、一般に比較的単純な小規模プロジェクトに適しており、あらゆるレベルおよび進捗管理に使用できます。 WBS、リソースの最適化、リソースとコストの計画の作成。

デメリット：プロジェクトに含まれるさまざまなタスク間の複雑な関係を体系的に表現できず、定量的な計算や分析、計画の最適化などが難しい。

ここに画像の説明を挿入します

クリティカルパス方式

クリティカルパス法とは、スケジュールを策定する際に使用されるスケジュールネットワーク分析手法です。クリティカルパス法は、プロジェクトのスケジュールネットワークのルートに沿って順方向および逆方向の分析を実行し、計画されたすべてのアクティビティの理論上の最も早い開始日と完了日を計算します。最も遅い開始日と終了日、リソースの制約に関係なく

合計スラック (余裕時間): 総建設期間を遅らせることのないアクティビティの操作時間。アクティビティの合計時間差は、アクティビティの最も遅い終了時間と最も早い終了時間の差、またはアクティビティの最も遅い開始時間と最も早い開始時間の差に等しい

自由時間差: 直後のアクティビティの最も早い開始時間に影響を与えないアクティビティの操作時間。

後続アクティビティを伴うアクティビティの場合、その空き時間の差は、すべての後続アクティビティの最も早い開始時刻からこのアクティビティの最も早い完了時刻を引いた差の最小値に等しくなります。
後続アクティビティのないアクティビティ、つまりネットワーク計画終了ノードを完了ノードとするアクティビティの場合、空き時間の差は、計画期間とこのアクティビティの最も早い完了時刻との差に等しくなります。

終了ノードを完了ノードとするネットワークプランのアクティビティの場合、空き時間の差は合計時間の差に等しくなります。また、アクティビティの空き時間差は合計時間差の構成要素であるため、アクティビティの合計時間差がゼロの場合、その自由時間差もゼロになる必要があり、特別な計算を行う必要はありません。

PERTチャート

ここに画像の説明を挿入します
プロジェクトのクリティカルパスの余裕時間を見つけるために使用されます。
クリティカルパス: プロジェクト全体を完了できる最長のパス
スラックタイム: 総工期に影響を与えることなくタスクをアイドル状態にできる時間。

最も早い開始時間: 特定のプロジェクトの開始時点より前の最長の入力ストリームの合計
テストの最新の開始点: クリティカルパス - プロジェクト全体の開始点から最終終了点までの距離
最早終了: 特定のプロジェクトの終了点より前の最長の入力ストリームの合計
最新の終点: クリティカルパス - この終点からプロジェクト全体の最終終点までの距離

余裕時間 = 最も遅い開始 – 最も早い開始 ② – ①
余裕時間 = 最も遅い終了 – 最も早い終了 ④ – ③
余裕時間 = クリティカルパス – 必要なアクティビティの最長のパス

進捗管理

進捗管理: プロジェクトが予定どおりに完了するようにするために必要な管理プロセス。

スケジュール管理プロセス:
ここに画像の説明を挿入します
アクティビティ定義:
作業分解構造 (WBS) で最低の成果物を取得するには、一連のアクティビティを実行する必要があります。これらのアクティビティを特定して文書化するプロセスがアクティビティの定義です。

WBS 分解の基本要件:

WBS 作業パッケージは制御可能で管理可能であり、あまり複雑にすることはできません。
タスクの分解はあまり詳しく説明できませんが、一般に WBS のツリー構造は 6 階層を超えないようにしてください。
各作業パッケージには成果物が必要です
各タスクには明確に定義された完了基準が必要です
WBS は責任の割り当てを容易にする必要があります

アクティビティのリソース見積もり: どのリソースをいつ、どのくらいの量で使用するかを決定します。このプロセスはコスト見積もりと密接に連携します。

アクティビティ所要時間の推定値: つまり、作業負荷の推定値。

一般的に使用される方法: エキスパート推定、3 点推定法、ファンクションポイント推定、トップダウン推定、ボトムアップ推定。3 点見積もり方法が一般的に使用され、その公式は次のとおりです。
ここに画像の説明を挿入します
スケジュールを作成します。
クリティカルパス方法 (CPM): これは、プロジェクトの全パスの中で最も長いパスであり、プロジェクト完了までの最も短い時間です。クリティカルパスは複数存在する可能性がありますが、クリティカルパスが多いほどプロジェクトのリスクは大きくなります。クリティカルパスから時間を要求し、非クリティカルパスからリソースを要求します。

合計時間差 [つまり、余裕時間]: 総建設期間を遅らせることなく作業を行った作業時間。アクティビティの合計時間差は、アクティビティの最も遅い完了時間と最も早い完了時間との差、またはアクティビティの最も遅い開始時間と最も早い試験時間との差に等しい。

進行管理

分析条件:

それは重要な活動ですか?
偏差は合計時間差より大きいですか?
偏差は自由時間の差より大きいですか?

2 つの方法:

仕事を急ぐ: リソースを増やす、残業する、または人を追加する
迅速なフォローアップ: アクティビティは並行して実行されます

品質管理

品質マネジメントは、品質システムにおける品質計画、品質保証、品質管理、品質改善を通じてその管理機能を実現します。

品質管理には、PDCA（Plan、Do）で使用される、フローチャート、因果関係図、検査図、パレート図、ヒストグラム、管理図、散布図の7つの基本的な品質ツールがあり、7QCツールとも呼ばれます。、Check、Act) ) のサイクルの枠組み内で品質関連の問題を解決します。

フローチャート: プロセスの品質コストの理解と推定に役立つプロセス図
特性要因図: 特性要因図、特性要因図、石川図 (発明者: 石川馨)、石川図、なぜなぜ分析図、問題の根本原因を調査し、問題ステートメントの原因を個別の分岐に分解、問題の主な原因または根本原因を特定するのに役立ちます。
検査チャート：計算シート、データ収集、欠陥を特定するための検査の実施のためのチェックリスト
パレート図: 特別な縦棒グラフ、80/20 ルール、確率分布、ほとんどの問題の重要な原因の特定
ヒストグラム: 数字とバーの相対的な高さを使用して、問題の最も一般的な原因を示し、特定の状況の発生数を示します。
管理図: プロセスが安定しているか、パフォーマンスが予測可能であるかを判断します。
散布図: 相関図とも呼ばれ、2 つの変数間の関係を示します。データポイントが特定の傾きに近づくほど、2 つの変数間の関係が緊密になります。

管理ツール

プロジェクト管理ツールは、ソフトウェアプロジェクト管理活動を支援するために使用されます。通常、プロジェクト管理活動には、プロジェクト計画、スケジュール設定、コミュニケーション、コスト見積り、リソース割り当て、品質管理が含まれます。プロジェクト管理ツールは通常、管理活動に対する包括的なサポートを提供することなく、1 つまたはいくつかの特定の管理リンクに焦点を当てています。

プロジェクト管理ツールには次の特徴があります。

ソフトウェアのライフサイクル全体をカバー
プロジェクトのスケジュール設定に複数の効果的な手段を提供する
推定モデルを使用してソフトウェアのコストと労力を見積もる
複数のプロジェクトとサブプロジェクトの管理をサポート
クリティカルパス、スラックタイム、リードタイム、ラグタイムを決定する
プロジェクトチームのメンバーとプロジェクトタスク間のコミュニケーションを支援する
自動リソースバランシング
リソースの使用状況を追跡する
固定形式のレポートとカスタマイズされたプロジェクトレポートを生成する

プロジェクト管理ツールの代表的なものとして、コスト見積りツールがあります。

責任

RAM、責任割り当てマトリックス。プロジェクトの組織分解構造 (OBS) と作業分解構造 (WBS) をリンクして、プロジェクトの作業範囲の各コンポーネントが個人または特定のチームに確実に割り当てられるようにする構造。RAM は、作業パッケージまたはアクティビティとプロジェクトチームのメンバー間の接続を示します。RAM では、どのタスクに対しても 1 人だけが責任を負うため、混乱が回避され、すべてが誰かによって管理されることが保証されます。同時に、プロジェクトチームは一時的な組織であり、怠惰な人々をサポートすることはなく、RAM はプロジェクトチームのメンバー全員がプロジェクト中にやるべきことを持っていることを明確にしています。RAM の典型的なアプリケーションは、個人またはグループに作業を割り当てる RACI (実行、責任、コンサルティング、情報提供) です。RAM は、人事管理プロセスを計画するためのツールです。

風邪をひく

責任者 (R = Responsible)、つまりタスクの実行に責任を負う役割であり、具体的にはプロジェクトの管理と問題の解決に責任を負います。
承認者 (A = Accountable)、つまりタスクに対して全責任を負う役割であり、その承認または署名がなければプロジェクトを進めることができません。
相談を受ける人 (C = Consulted)、プロジェクトを完了するために必要な情報または能力を持つ人。
誰に通知するか（I = Informed）、つまり特権を持っている人に結果を適時に通知する必要がありますが、相談したり意見を求めたりする必要はありません。

RACI モデルでは、さまざまな役割や関連する責任について議論し、伝達するために RACI テーブルがよく使用されます。RACI 図は RAM の 1 つのタイプにすぎません。プロジェクトマネージャーは、プロジェクトのニーズに応じて、リーダー、リソース、またはその他の適切な単語を選択して、プロジェクトの責任を割り当てることもできます。チームが社内および社外の人材で構成されている場合、役割と期待が明確に区別されるようにするために、RACI 図が特に重要です。

プロジェクトスコープステートメント

スコープ検証プロセスで使用されるツールとテクニック:

診る
グループでの意思決定テクニック

プロジェクトスコープ定義への入力は次のとおりです。

プロジェクト計画書。プロジェクト憲章または初期範囲記述がプロジェクト実行組織内で使用されていない場合は、詳細なプロジェクト範囲記述を作成するために、同じ情報をさらに収集して作成する必要があります。
プロジェクト範囲管理計画
組織プロセス資産
承認された変更リクエスト

プロジェクトのスコープとは、プロジェクトの目的を達成し、特定の製品またはサービスを提供するためにプロジェクトが行うべきことを規定したものです。情報システムプロジェクトにおいて、プロダクトスコープとは情報システム製品やサービスに含まれるべき機能を指し、プロジェクトスコープとは情報システムプロジェクトを実現するために実行しなければならない作業を指します。製品範囲はプロジェクト範囲の基礎であり、製品範囲定義は情報システム要件の尺度であり、プロジェクト範囲定義は生産プロジェクト計画の基礎です。製品範囲の説明は、プロジェクト範囲ステートメントの重要な部分です。

予備的なスコープステートメント

最初のプロジェクトスコープステートメントは、スポンサーまたは後援者から提供された情報に基づいて作成され、スコープ定義プロセス中にプロジェクト管理チームによってさらに洗練されます。内容には以下が含まれます:

プロジェクトと範囲の目標
製品またはサービスのニーズと機能
プロジェクトの要件と成果物
製品の合格基準
プロジェクトの境界
プロジェクトの制約
プロジェクトの前提条件
初期プロジェクト組織
最初に定義されたリスク
進歩のマイルストーン
プロジェクト作業の初期内訳
暫定的な規模のコスト推定
プロジェクト構成管理のニーズ
承認要件

詳細なスコープステートメント

スコープ定義の主な成果物はスコープステートメントであり、プロジェクトの成果物と、それらの成果物を作成するために実行する必要があるプロジェクト作業の詳細が記述されます。プロジェクトスコープステートメントは、すべての利害関係者間でプロジェクトスコープについての共通理解を確立し、プロジェクトの主な目標を説明し、プロジェクトチームがより詳細な計画を立てることを可能にし、プロジェクトの実施中にプロジェクトチームの作業をガイドし、プロジェクトが適切かどうかを評価するための基礎を提供します。クライアントが必要とする変更や追加作業がプロジェクトの範囲内であるかどうかのベースラインを提供します。内容は以下の通りである。
(1) プロジェクトの目的。達成目標と拘束力のある目標を含みます。
(2) 製品範囲の説明。プロジェクトが提供することを約束する製品、サービス、または成果の特徴を説明します。
(3) プロジェクトの成果物。プロジェクトの製品、サービス、または結果だけでなく、プロジェクト管理レポートやドキュメントなどの補助的な成果物も含まれます。
(4) プロジェクトの境界。境界は、何がプロジェクトの一部であり、何がプロジェクトの範囲外であるかを厳密に定義します。
(5) 製品の合格基準。成果物を受け入れるためのプロセスと原則が明確に定義されています。
(6) プロジェクトの制約。プロジェクトチームの選択に影響する、Southwest Equity Group の範囲に関連する特定の制約を説明し、リストします。
(7) プロジェクトの前提条件。プロジェクトの範囲に関連する特定の前提条件と、これらの前提条件が当てはまらない場合のプロジェクトへの潜在的な影響を説明し、リストします。

PMO

プロジェクト管理オフィス (PMO) は、プロジェクト関連のガバナンスプロセスを標準化し、リソース、方法論、ツール、およびテクノロジの共有を促進する組織部門です。

PMO の責任は、プロジェクト管理サポートサービスの提供から 1 つ以上のプロジェクトの直接管理まで多岐にわたります。PMO には、サポート、制御、指示など、プロジェクトに対するさまざまな程度の制御と影響力を持ついくつかの異なるタイプがあります。PMO は、企業の戦略的プロジェクトからデータと情報を取得し、包括的な分析を実施し、プロジェクトが戦略的目標をどの程度達成しているかを評価します。

PMO は、プロジェクトポートフォリオ、プログラム、プロジェクトと企業評価システム (バランススコアカードなど) の間のリンクを確立します。PMO によってサポートおよび管理されるプロジェクトは、一元的に管理されるだけでなく、必ずしも相互に関連しているわけではありません。PMO の具体的な形式、機能、構造は組織のニーズによって異なります。プロジェクトが組織のビジネス目標を確実に満たしていることを確認するために、PMO は、各プロジェクトのライフサイクルにおいて重要な利害関係者および主要な意思決定者として機能し、推奨を行ったり、プロジェクトを一時停止したり、その他の措置を講じたりする権限を有する場合があります。必要に応じてアクションを実行します。さらに、PMO は、共有リソースまたは専用リソースの選択、管理、展開にも関与する場合があります。

PMO の主な機能の 1 つは、次のようなさまざまな方法でプロジェクトマネージャーにサポートを提供することです (ただし、これらに限定されません)。

PMO の管轄下にあるすべてのプロジェクトの共有リソースを管理します。
プロジェクト管理方法論、ベストプラクティス、標準を特定し、開発する。
指導、コーチング、トレーニングおよび監督。
プロジェクト監査を通じて、プロジェクト管理の標準、ポリシー、手順、テンプレートへの準拠を監視します。
プロジェクトのポリシー、手順、テンプレート、その他の共有ドキュメント (組織プロセス資産) を開発および管理します。
プロジェクト間のコミュニケーションを調整します。