当社で同時に実施される多数のプロジェクトで最大の管理効率を達成するために、階層構造の分解と作成の原則を適用します。
プロジェクトポートフォリオ->プロジェクトプログラム->プロジェクト。
このような分解により、特定の特性に応じて経営資源と活動のバランスを取り、単純で理解しやすい組織管理構造、権限、および責任レベルを決定できます。
階層構造のコンポーネントが使用されるため：
•プロジェクト-時間と予算の制限内で、独自の製品、サービスを作成するか、適切な品質の結果を取得することを目的とした一時的な活動。
•プログラム-共通の目標、割り当てられたリソース、実装の時間、技術および実装条件によって統一された相互接続プロジェクトのセットであり、管理性を高めるために形成されました。
•ポートフォリオ-戦略的な目標を達成するための効果的な管理の目標と組み合わされた一連のプロジェクトとプログラム。
プロジェクト管理の最も最適で効果的な組織構造を決定するために、プロジェクトはカテゴリに分類されます。 プロジェクト分類では次のことができます。
•対応するカテゴリのプロジェクト管理に必要なコストを最適化します。
•対応するカテゴリのプロジェクト管理に必要なコストを最適化します。
•プロジェクト管理のための適切な組織構造を確立します。
•プロジェクト管理のためのプロセスと手順のリストを確立します。このカテゴリのプロジェクトでは、規制の厳密な遵守が必須です。
•開発のための人件費を削減しながら、プロジェクト管理用のドキュメントの単一のフォーム、構成、およびコンテンツを確立します。
•カテゴリに従って、プロジェクト管理の品質指標のシステムを確立します。
すべてのプロジェクトは、条件付きで4つのカテゴリに分類できます。
•メガプロジェクト-多数の参加者が関与する大規模プロジェクト（外部組織、たとえば政府機関、顧客、請負業者、プロジェクトの結果に関心がある可能性のあるその他の関心組織）。 原則として、このようなプロジェクトは優先事項であり、革新的です。 このカテゴリのプロジェクトには、継続的な統合管理が必要です。 このようなプロジェクトには、管理の面で高い要件があります：管理の複雑な組織構造（管理レベルの最大数、役割の最大数、プロジェクトに関与する参加者）、多数のプロセス（プロジェクト管理のすべての可能な機能分野がカバーされています）および管理文書、常時監視時間、リソース、コスト管理。
•マルチプロジェクト-特定された高いリスクを伴わない大規模で複雑なプロジェクト。 このカテゴリのプロジェクトでは、タイムライン、リソース、コストを継続的に管理する必要があります。
•単一プロジェクト-原則として、特定の結果を達成することを目的としたプロジェクトであり、1つの企業単位の労働リソースが関与します。 このようなプロジェクトの簡素化された要件は、管理の観点から提示されます。実装のためのリソースの計画と会計、管理ポイントによる管理、期限内および予算内での完了管理。
•プロジェクトタスク-最小限の労働リソースで明確に定義された結果を達成することを目的としたプロジェクト。 計画と管理の観点から、このようなプロジェクトの要件はありませんが、時間通りの完了の実装と監視のためにリソースを考慮する必要があります。
もちろん、プロジェクト活動を形式化する過程で他の組織や企業は、プロジェクトを1つまたは別のカテゴリ（定量的および定性的）に分類するための独自の基準を開発します。
プロジェクトチームの組織構造は、プログラム、プロジェクト、作業パッケージを組織単位の管理および実行と関連付けるように配置された、プロジェクトアクティビティの組織の階層的に組織されたイメージです。 プロジェクトでは、プロジェクトチームにいくつかのタイプの組織構造を使用します。 これらの構造は、管理階層のレベル数、プロジェクト参加者の必須の役割、請負業者の管理組織が異なります。
プロジェクトアクティビティでは、次の管理レベルが使用されます。
•戦略管理レベル：戦略管理レベル。
•管理の運用レベル：プロジェクトポートフォリオ管理のレベル（プロジェクトポートフォリオマネージャー）。
•管理の運用レベル：プログラムおよびプロジェクト管理（プロジェクト管理委員会、プロジェクトキュレーター、プログラムマネージャー、プロジェクトマネージャー）;
•パフォーマンス管理のレベル：作業パッケージ（チームリーダー、アーキテクト、エグゼキューター）の管理。
メガプロジェクトの管理レベルごとの組織階層の図を図1に示します。
図1メガプロジェクトの組織階層図の例
このような組織構造では、プロジェクトの1つの管理レベルの参加者は、階層の次のレベルの参加者のみと直接通信します。 レベル間の「ボトムアップ」および「トップダウン」と説明できるコミュニケーションの方向は、どのような形式で情報交換が行われるか、いつどこでコミュニケーションが行われるか（人と情報の間の重要な接続）、そして誰が各タイプの通信を提供する責任があります。
エスカレーション手順は、管理レベルのプリズムを介して構築され、管理レベルの各参加者は、特定のプロジェクトで定義された能力と権限の枠組み内で決定を下します。 エスカレーション手順は、プロジェクト管理の下位レベルで解決策または妥協案が見つからなかった場合に、問題および/または競合（リスクを回避するための対策、リスクに対処するための対策、変更要求を実装することを含む）について決定を下すために使用されます。
大規模で複雑なプロジェクトでは、多くの場合、中間レベルの管理をバイパスして参加者間でコミュニケーションが発生します。これは、プロジェクトの実装に悪影響を与える可能性があります。
プロジェクトの管理レベル外の相互接続の例を図2に示します。
図2プロジェクトの管理レベル外の相互接続の例
制御レベル外の通信の原因として、以下を選択できます。
1.さまざまなレベルの管理職にいるプロジェクト参加者のコラボレーションの以前の経験。
2.プロジェクトのサブジェクト領域の特定のレベルでマネージャーの知識が不十分であるため、請負業者が顧客の担当者のレベルに連絡すると、参加者が上位レベルから下位レベルに強制的に移動します。
3.プロジェクトに関与する特定の組織におけるプロジェクト管理の内部企業文化。
ただし、プロジェクトマネージャーがそのようなコミュニケーションを抑制し、一般に受け入れられている「古典的なスキーム」に従ってそれらを構築しようとする試みが常に成功するとは限りません。 管理レベル以外で通信が発生する場合、プロジェクト管理者は、これらの通信が各管理レベルでの意思決定にどのように影響するか、およびこれらの通信がプロジェクトの主要パラメーターの変更を開始するかどうかを理解することが非常に重要です。 この機能が定義されている権限内の人が意思決定を行う場合は、反対にコミュニケーションを形式化し、プロジェクトコミュニケーション管理計画に追加する必要があります（プロジェクト計画段階のプロジェクトマネージャーは、プロジェクトの情報源の説明とその取得方法を含むコミュニケーション管理計画を準備します;情報の消費者とその配信方法が決定される情報の配布、プロジェクトで結果として生じる文書の詳細な説明、性別であるべき その形式と内容を含めて、学習または送信されました）。
制御レベル外で追加の関係を構築すると、肯定的な結果につながります。 プロジェクトの詳細と参加者の経験を考慮して、特定のプロジェクト内でルールを作成しただけで、最適な方法で関係を構築できます。