プロジェクト管理

プロジェクト管理とは、与えられた制約内ですべてのプロジェクト目標を達成するためにチームの作業を監督するプロセスです。 ^[1]この情報は通常、開発プロセスの開始時に作成されるプロジェクトドキュメントに記載されています。主な制約は、範囲、時間、予算です。^[2]二次的な課題は、必要な入力の割り当てを最適化し、事前に定義された目的を満たすためにそれらを適用することです。

プロジェクト管理の目的は、クライアントの目的に適合する完全なプロジェクトを作成することです。多くの場合、プロジェクト管理の目的は、クライアントの目的に実行可能な形で対処するために、クライアントの概要を形作ったり修正したりすることです。クライアントの目的が確立されると、その目的は、プロジェクトに関与する他の人々、たとえばプロジェクト マネージャー、設計者、請負業者、下請け業者によるすべての決定に影響を与える必要があります。プロジェクト管理の目的が適切に定義されていないか、厳格に規定されすぎると、意思決定に悪影響を及ぼします。

プロジェクトとは、明確な開始と終了（通常は時間的制約があり、資金や人員によって制約されることも多い）を伴い、製品、サービス、または結果を生み出すために設計された一時的かつ独自の取り組みであり、独自の目標と目的を達成するために実行され、典型的には有益な変化や付加価値をもたらす。^{[3] [4]}プロジェクトの一時的な性質は、製品やサービスを生産するための反復的、永続的、または半永続的な機能活動である通常の業務（または運用）^[5]とは対照的である。実際には、このような明確な生産アプローチの管理には、明確な技術スキルと管理戦略の開発が必要である。^[6]

1900年まで、土木プロジェクトは一般的に創造的な建築家、エンジニア、マスタービルダー自身によって管理されていました。たとえば、ウィトルウィウス（紀元前1世紀）、クリストファー・レン（1632-1723）、トーマス・テルフォード（1757-1834）、イザムバード・キングダム・ブルネル（1806-1859）などです。^[7] 1950年代には、組織は複雑なエンジニアリングプロジェクトにプロジェクト管理ツールとテクニックをより体系的に適用し始めました。^[8]

プロジェクトマネジメントは、土木建設、エンジニアリング、重防衛活動など、いくつかの応用分野から発展した学問分野です。 ^[9]プロジェクトマネジメントの2人の先駆者は、計画と制御技術の父と呼ばれるヘンリー・ガントです。 ^[10]ガントチャート（カロル・アダミエツキが最初に提案したハーモノグラムとも呼ばれる）をプロジェクトマネジメントツールとして使用したことで有名です。 ^[11]そしてアンリ・ファヨールは、プロジェクトおよびプログラムマネジメントに関連する知識体系の基礎となる5つの管理機能を考案しました。^[12]ガントとファヨールはどちらも、フレデリック・ウィンスロー・テイラーの科学的管理理論を学んでいました。彼の研究は、作業内訳構造（WBS）や資源配分など、 現代のプロジェクトマネジメントツールの先駆けとなっています。

1950 年代は、中核的なエンジニアリング分野が 1 つにまとまって機能するようになった、現代のプロジェクト管理時代の始まりでした。プロジェクト管理は、エンジニアリング モデルを持つ管理分野から生まれた独自の分野として認識されるようになりました。^{[13] 1950 年代以前の米国では、プロジェクトは主に}ガント チャートと非公式の手法やツールを使用して、アドホック ベースで管理されていました。当時、2 つの数学的なプロジェクト スケジューリングモデルが開発されました。クリティカル パス法(CPM) は、デュポン社とレミントン ランド社の合弁事業として、プラント保守プロジェクトを管理するために開発されました。プログラム評価およびレビュー手法(PERT) は、ポラリス ミサイル潜水艦プログラムの一環として、ロッキード社およびブーズ アレン ハミルトン社と共同で、米国海軍特別プロジェクト局によって開発されました。^[14]

PERTと CPM はアプローチが非常に似ていますが、それでもいくつかの違いがあります。CPM は、アクティビティ時間が決定論的であると想定するプロジェクトに使用されます。つまり、各アクティビティが実行される時間は既知です。一方、PERT は、アクティビティ時間が確率論的であると想定します。つまり、各アクティビティが実行される時間は不確実または変動します。この根本的な違いにより、CPM とPERT は異なるコンテキストで使用されます。これらの数学的手法は、多くの民間企業に急速に広まりました。

同時に、プロジェクト スケジューリング モデルが開発されるにつれて、プロジェクト コスト見積、コスト管理、エンジニアリング経済学のテクノロジが進化し、Hans Lang らによる先駆的な研究が行われました。1956 年には、プロジェクト管理と、それに関連する計画とスケジューリング、コスト見積、プロジェクト制御の専門分野の初期の実践者によって、米国原価技術者協会 (現在のAACE International、原価工学振興協会) が設立されました。AACEは先駆的な研究を続け、2006 年にはポートフォリオ、プログラム、プロジェクト管理の統合プロセス (総コスト管理フレームワーク) を初めてリリースしました。

1969年、米国でプロジェクトマネジメント協会（PMI）が設立されました。 ^[15] PMIは1996年にウィリアム・ダンカンを主著者として「ほとんどのプロジェクト、ほとんどの場合」に共通するプロジェクトマネジメントの実践を説明した「プロジェクトマネジメント知識体系ガイド（PMBOKガイド）」のオリジナル版を出版しました。 ^[16]

プロジェクト管理手法は、あらゆるプロジェクトに適用できます。プロジェクトの規模、性質、業界、またはセクターに基づいて、特定の種類のプロジェクトに合わせて調整されることがよくあります。たとえば、建物、道路、橋などの提供に焦点を当てている建設業界では、建設プロジェクト管理と呼ばれる独自のプロジェクト管理形式が開発されており、プロジェクトマネージャーはトレーニングを受けて認定を受けることができます。^{[17]情報技術業界も進化して、} ITプロジェクト管理と呼ばれる独自のプロジェクト管理形式を開発しており、計画、設計、開発、テスト、展開などのさまざまなライフサイクルフェーズを通過する必要がある技術資産とサービスの提供に特化しています。バイオテクノロジープロジェクト管理は、バイオテクノロジーの研究開発の複雑さに焦点を当てています。^[18] ローカリゼーションプロジェクト管理には、多くの人がこのタイプの管理を非常に異なる分野と見なしているにもかかわらず、多くの標準的なプロジェクト管理手法を翻訳作業に適用することが含まれます。たとえば、プロジェクトマネージャーは、翻訳の言語を話せなくても、十分な情報に基づいた決定を下すために研究の目的をよく知っているため、翻訳を改善する上で重要な役割を果たします。^[19]同様に、研究調査管理にもプロジェクト管理アプローチを適用できます。^[20]政府によるすべての公共事業をカバーする公共プロジェクト管理があり、政府機関によって実行されるか、請負業者に委託されます。プロジェクト管理の別の分類は、ハード（物理的）またはソフト（非物理的）タイプに基づいています。

すべてのプロジェクト管理タイプに共通するのは、時間、品質、コストという3つの重要な目標に焦点を当てていることです。成功するプロジェクトは、スケジュールどおりに予算内で、事前に合意された品質基準に従って完了します。つまり、プロジェクトが成功または失敗と見なされるためには、鉄の三角形または3つの制約を満たす必要があります。^[21]

プロジェクト管理の種類ごとに、プロジェクト マネージャーは、担当する業界に固有の繰り返し可能なテンプレートを開発して活用します。これにより、プロジェクト計画は徹底的かつ繰り返し可能になり、品質の向上、納品コストの削減、プロジェクト結果の納品までの時間の短縮という具体的な目的を達成できます。

2017年の研究では、プロジェクトの成功は、プロジェクトに影響を与える文脈的ダイナミクスと4つの主要な側面がどれだけうまく一致しているかにかかっていると示唆されており、これらは4つのPと呼ばれています。^[22]

• 計画: 計画と予測の活動。
• プロセス:すべてのアクティビティとプロジェクトガバナンスに対する全体的なアプローチ。
• 人々:彼らがどのように協力し、コミュニケーションをとるかというダイナミクスを含みます。
• 権力:権限系統、意思決定者、組織図、実施方針など。

プロジェクト活動を組織化して完了させるには、段階的、リーン、反復的、増分的など、さまざまなアプローチがあります。また、成果 (製品ベース) やアクティビティ (プロセスベース) に基づくなど、プロジェクト計画にはいくつかの拡張があります。

どのような方法論を採用するにせよ、プロジェクト全体の目的、タイムライン、コスト、そしてすべての参加者と利害関係者の役割と責任を慎重に考慮する必要がある。^[23]

利益実現管理 (BRM) は、製品や出力ではなくプロジェクトの成果 (利益) に焦点を当て、プロジェクトを順調に進めるためにそれがどの程度実現されているかを測定することで、通常のプロジェクト管理手法を強化します。これにより、合意された要件 (出力) は達成されても (つまりプロジェクトの成功)、それらの要件の利益 (成果) は達成されず (つまり製品の成功)、完了したプロジェクトが失敗するリスクを軽減できます。適切な要件管理により、これらの利益がプロジェクトの要件として取り込まれ、プロジェクト全体を通じてその達成が監視されることに注意してください。

さらに、BRMの実践は、プロジェクトの成果とビジネス戦略の戦略的整合性を確保することを目的としています。これらの実践の有効性は、BRMの実践がさまざまな国や業界の戦略的観点からプロジェクトの成功に影響を与えることを証明した最近の研究によって裏付けられています。これらの幅広い影響は戦略的影響と呼ばれています。^[24]

要件を満たすプロジェクトを実現する例としては、スタッフ データを処理し、給与、休暇、およびスタッフの人事記録をより短時間で、より少ないエラーで管理するコンピュータ システムを実現することに合意することが挙げられます。BRM では、システムをインストールしない場合と比較して、システムをインストールした後にスタッフ データの処理と維持に必要なスタッフの作業時間とエラーを、指定された値まで削減するという合意が考えられます。

クリティカル パス法 (CPM) は、プロジェクト活動のスケジュールを決定するためのアルゴリズムです。これは、予測に基づくプロジェクト計画に使用される従来のプロセスです。CPM 法は、活動の順序、必要な作業量、相互依存性、およびライン シーケンスごとの結果のフロート時間を評価して、必要なプロジェクト期間を決定します。したがって、定義上、クリティカル パスは、ネットワーク図上のタスクの経路であり、余分な時間がまったくない (または余分な時間がほとんどない) 経路です。" ^[25]

クリティカル チェーン プロジェクト管理 (CCPM) は、制約理論(TOC) をプロジェクトの計画と管理に適用したもので、プロジェクトの実行に必要なリソース(物理的、人的スキル、管理およびサポート能力)の限られた可用性を考慮しながら、プロジェクト管理に固有の不確実性に対処するように設計されています。

目標は、組織内のプロジェクトの流れ (スループット) を増やすことです。TOC の5 つの焦点ステップのうち最初の 3 つを適用して、すべてのプロジェクトのシステム制約とリソースを特定します。制約を活用するために、クリティカル チェーン上のタスクは、他のすべてのアクティビティよりも優先されます。

アーンドバリューマネジメント（EVM）は、プロジェクトモニタリングを改善する技術を用いてプロジェクトマネジメントを拡張します。^[26]これは、作業と価値（コスト）の観点からプロジェクトの完了までの進捗状況を示します。アーンドスケジュールは、EVMの理論と実践の拡張です。

プロジェクト管理の批判的研究では、段階的アプローチは、大規模で複数の企業が関与するプロジェクト、^[27]、要件が未定義、あいまい、または急速に変化するプロジェクト、^[28]、またはリスク、依存性が高く、技術が急速に変化するプロジェクトには適していないことが指摘されています。不確実性の円錐は、プロジェクトの初期段階で作成された計画が高度な不確実性に悩まされるため、この一部を説明します。ソフトウェア開発は多くの場合、新しい製品や斬新な製品の実現であるため、これは特に当てはまります。

これらの複雑さは、より探索的または反復的かつ漸進的なアプローチでより適切に処理されます。^[29]アジャイルプロジェクト管理、動的システム開発手法、エクストリームプロジェクト管理、イノベーションエンジニアリング®など、反復的かつ漸進的なプロジェクト管理のいくつかのモデルが進化してきました。 ^[30]

リーン プロジェクト管理では、リーン製造の原則を使用して、無駄を減らし、時間を短縮しながら価値を提供することに重点を置きます。

プロジェクトライフサイクルには、プロセスグループと呼ばれる5つのフェーズがあります。各プロセスグループは、完了すべき一連の個別のステップを通じて作業を管理するための一連の相互に関連するプロセスを表します。このタイプのプロジェクトアプローチは、「伝統的」^[31]または「ウォーターフォール」^[32]と呼ばれることがよくあります。5つのプロセスグループは次のとおりです。

1. 開始
2. 計画
3. 実行中
4. 監視と制御
5. 終わりに

業界によっては、これらのプロジェクト ステージのバリエーションを使用し、組織に適した名前に変更する場合があります。たとえば、実店舗の設計と建設に取り組む場合、プロジェクトは通常、事前計画、概念設計、概略設計、設計開発、建設図面 (または契約文書)、建設管理などのステージを経て進行します。

段階的アプローチは、小規模で明確に定義されたプロジェクトではうまく機能しますが、より大規模なプロジェクト、またはより複雑で、より多くの曖昧さ、問題、リスクがあるプロジェクトでは、課題や失敗につながることがよくあります^[33] - パロディの「大規模プロジェクトの6つのフェーズ」を参照してください。

プロセスベースの管理の導入は、 OPM3やCMMI（能力成熟度モデル統合）などの成熟度モデルの使用によって推進されてきました。画像：Capability Maturity Model.jpgを参照してください。

プロジェクト生産管理は、資本プロジェクトの実施にオペレーション管理を応用したものである。プロジェクト生産管理フレームワークは、プロジェクトを生産システムとしてとらえ、入力（原材料、情報、労働力、設備、機械）を出力（商品やサービス）に変換するという考え方に基づいている。^[34]

成果物ベースの計画は、プロジェクト目標の達成に貢献するすべての成果物（プロジェクト成果物）を特定することに基づいた、プロジェクト管理に対する構造化されたアプローチです。そのため、成功するプロジェクトは、活動指向やタスク指向ではなく、成果指向であると定義されます。 ^[35]このアプローチの最も一般的な実装はPRINCE2です。^[36]

伝統的に（どのようなプロジェクト管理方法論が使用されているかによって異なりますが）、プロジェクト管理には、4〜5つのプロジェクト管理プロセスグループと制御システムといういくつかの要素が含まれています。使用される方法論や用語に関係なく、同じ基本的なプロジェクト管理プロセスまたは開発段階が使用されます。主要なプロセスグループには、通常、次のものが含まれます。^[38]

• 開始
• 計画
• 制作または実行
• 監視と制御
• 終わりに

重要な探索的要素を持つプロジェクト環境（研究開発など）では、これらの段階に、プロジェクトの継続について議論して決定する決定ポイント（継続/中止の決定）が追加されることがあります。一例として、フェーズゲート モデルが挙げられます。

プロジェクト管理では、さまざまな会議を利用してアクションを調整します。たとえば、プロジェクトの開始時に関係者が幅広く参加するキックオフ ミーティングがあります。プロジェクト ミーティングまたはプロジェクト委員会では、プロジェクト チームがアクション プランを定義および監視できます。運営委員会は、フェーズ間の移行と問題の解決に使用されます。プロジェクト ポートフォリオとプログラムのレビューは、並行してプロジェクトを実行している組織で実施されます。教訓会議は、学習内容を統合するために開催されます。これらのすべての会議では、特に目的、参加者リスト、および促進方法を定義するために、会議科学で見られる手法が採用されています。

開始プロセスは、プロジェクトの性質と範囲を決定します。^[39]この段階が適切に実行されなければ、プロジェクトがビジネスのニーズを満たすことに成功する可能性は低くなります。ここで必要な主要なプロジェクト管理は、ビジネス環境を理解し、必要なすべての管理がプロジェクトに組み込まれていることを確認することです。欠陥があれば報告し、修正を推奨する必要があります。

開始段階には、次の領域を網羅する計画を含める必要があります。これらの領域は、プロジェクト開始文書と呼ばれる一連の文書に記録できます。プロジェクト開始文書は、プロジェクト期間中の順序を作成するために使用される一連の計画文書です。これらには、次のような内容が含まれる傾向があります。

• プロジェクト提案（プロジェクトの背景にあるアイデア、全体的な目標、期間）
• プロジェクトの範囲（プロジェクトの方向性と軌道）
• 製品内訳構造(PBS) (成果物/成果とその構成要素の階層)
• 作業分解構造(WBS) (毎日のタスクに至るまで、実行すべき作業の階層)
• 責任割り当てマトリックス(RACI - 責任者、説明責任者、相談先、情報提供先) (成果物/結果に合わせた役割と責任)
• 暫定的なプロジェクトスケジュール（マイルストーン、重要な日付、期限）
• 測定可能な目標に対するビジネスニーズと要件の分析
• 現在の業務の見直し
• 予算を含むコストと利益の財務分析
• プロジェクトのユーザーやサポート担当者を含む利害関係者の分析
• コスト、タスク、成果物、スケジュールを含むプロジェクト憲章
• SWOT分析：ビジネスの強み、弱み、機会、脅威

開始段階の後、プロジェクトは適切なレベルの詳細さで計画されます（フローチャートの例を参照）。^[37]主な目的は、必要な作業を見積もり、プロジェクト実行中のリスクを効果的に管理するために、時間、コスト、リソースを適切に計画することです。開始プロセスグループと同様に、適切な計画に失敗すると、プロジェクトが目標を達成できる可能性が大幅に低下します。

プロジェクト計画は一般的に^[40]から構成される。

• 従うべきプロジェクト管理方法論を決定する（例：計画が完全に事前に定義されるか、反復的に定義されるか、段階的に定義されるか）
• スコープステートメントの開発。
• 企画チームの選定
• 成果物を特定し、製品と作業の内訳構造を作成する。
• それらの成果物を完了するために必要な活動を特定し、それらの活動を論理的な順序でネットワーク化する。
• 活動に必要なリソースを見積もる。
• 活動にかかる時間とコストの見積もり。
• スケジュールの作成;
• 予算の策定;
• リスク計画;
• 品質保証措置の開発
• 作業を開始するための正式な承認を得る。

コミュニケーションとスコープ管理の計画、役割と責任の特定、プロジェクト用に購入するものの決定、キックオフ ミーティングの開催などの追加プロセスも一般的に推奨されます。

新製品開発プロジェクトでは、最終製品の運用の概念設計がプロジェクト計画活動と並行して実行され、成果物や計画活動を特定する際に計画チームに情報を提供するのに役立ちます。

実行中は、実行する必要がある計画条件を把握する必要があります。実行/実装フェーズでは、プロジェクト管理計画の成果物がそれに従って実行されるようにします。このフェーズでは、人材や資材、予算などのその他のリソースの適切な割り当て、調整、管理を行います。このフェーズの出力は、プロジェクトの成果物です。

プロジェクト内のすべてのものを文書化することが、成功の鍵です。予算、範囲、有効性、ペースを維持するために、プロジェクトには各タスクに関連する物理的な文書が必要です。適切な文書があれば、プロジェクトの要件が満たされているかどうかを簡単に確認できます。それに加えて、文書は、そのプロジェクトですでに完了している内容に関する情報を提供します。プロジェクト全体にわたる文書化は、過去の作業に戻って参照する必要がある人のために、紙の証跡を提供します。ほとんどの場合、文書化は、プロジェクトの特定のフェーズを監視および制御するための最も効果的な方法です。適切な文書化があれば、プロジェクトの成功をプロジェクトの進行に合わせて追跡および観察できます。文書化を正しく実行すれば、プロジェクト成功の基盤となります。

監視と制御は、プロジェクトの実行を観察するために実行されるプロセスで構成され、潜在的な問題を適時に特定し、必要に応じて是正措置を講じてプロジェクトの実行を制御できるようにします。主な利点は、プロジェクトのパフォーマンスを定期的に観察および測定して、プロジェクト管理計画との差異を特定できることです。

監視と制御には以下が含まれる: ^[41]

• 進行中のプロジェクト活動の測定（「現在の状況」）
• プロジェクト管理計画とプロジェクト パフォーマンス ベースライン (あるべき位置)に照らして、プロジェクト変数 (コスト、労力、範囲など) を監視します。
• 問題とリスクに適切に対処するための是正措置を特定する（どうすれば再び軌道に戻ることができるか）
• 統合変更管理を回避する可能性のある要因に影響を与え、承認された変更のみが実装されるようにします。

プロジェクトにおける監視と制御をサポートする主なメカニズムは 2 つあります。一方では、契約によって一連のルールとインセンティブが提供され、多くの場合、潜在的な罰則や制裁が伴います。^[42]一方では、ビジネスやマネジメントの研究者は、プロジェクトの目的を達成するためのインテグレーター (プロジェクト バロンとも呼ばれる) の役割に注目しています。^{[43] [44]}一方、プロジェクト管理に関する最近の研究では、契約とインテグレーターの相互作用の種類が疑問視されています。一部の人は、これら 2 つの監視メカニズムは代替物として機能し^[45]、一方の組織を使用すると、もう一方の組織を使用する利点が減少すると主張しています。

複数フェーズのプロジェクトでは、監視および制御プロセスによってプロジェクト フェーズ間のフィードバックも提供され、プロジェクトをプロジェクト管理計画に準拠させるための是正措置または予防措置が実行されます。

プロジェクトのメンテナンスは継続的なプロセスであり、これには以下が含まれます。^[38]

• エンドユーザーへの継続的なサポート
• 誤りの訂正
• 時間の経過とともに製品が更新される

この段階では、監査人はユーザーの問題がどれだけ効果的かつ迅速に解決されるかに注意を払う必要があります。

建設プロジェクトの進行中に、作業範囲が変わることがあります。変更は建設プロセスの正常かつ予想される部分です。変更は、必要な設計変更、現場の状況の違い、材料の入手可能性、請負業者が要求した変更、バリュー エンジニアリング、第三者の影響など、いくつかの原因によって発生します。現場で変更を実行するだけでなく、変更内容は、実際に建設されたものを示すために文書化する必要があります。これは変更管理と呼ばれます。したがって、所有者は通常、すべての変更、より具体的には、完成した作業の有形部分を変更する変更を示す最終記録を必要とします。記録は契約文書に作成されます。通常は設計図面ですが、必ずしもこれに限定されるわけではありません。この作業の最終成果物は、業界では完成図、またはより簡単に「完成図」と呼ばれるものです。これらを提供することは、建設契約の標準です。建設文書管理は、オンラインまたはデスクトップ ソフトウェア システムの助けを借りて実行されるか、物理的な文書によって維持される非常に重要なタスクです。建設業界における正確な文書の維持に関する法的規制の強化により、文書管理システムの必要性が高まっています。

プロジェクトに変更が加えられた場合、プロジェクトの実現可能性を再評価する必要があります。プロジェクトの当初の目的と目標を見失わないことが重要です。変更が積み重なると、予測される結果がプロジェクトへの当初の投資を正当化しなくなる可能性があります。成功するプロジェクト管理では、これらの要素を特定し、プロジェクト開始時にすでに概説された時間と予算の枠内に収まるように進捗状況を追跡および監視します。プロジェクトの進捗状況と予想される期間に関して、プロジェクトのライフサイクルに沿って最も有益な監視ポイントを特定するための正確な方法が提案されました。^[46]

終了には、プロジェクトの正式な承認と終了が含まれます。管理活動には、ファイルのアーカイブ化と、学んだ教訓の文書化が含まれます。

この段階は以下から構成される: ^[38]

• 契約の終了: 各契約を完了して決済し (未解決項目の解決を含む)、プロジェクトまたはプロジェクト フェーズに該当する各契約を終了します。
• プロジェクト終了: すべてのプロセス グループにわたるすべてのアクティビティを完了し、プロジェクトまたはプロジェクト フェーズを正式に終了します。

このフェーズには、実装後のレビューも含まれます。これは、プロジェクト チームが経験から学び、将来のプロジェクトに適用するための、プロジェクトの重要なフェーズです。通常、実装後のレビューは、プロジェクトでうまくいった点を確認し、うまくいかなかった点を分析して、教訓を得ることから構成されます。

プロジェクト管理（コストエンジニアリングとも呼ばれる）は、プロジェクト管理における独立した機能として確立されるべきである。プロジェクト管理は、定義されたパフォーマンスと正式な目標を強化するために、プロジェクトの処理中に検証と制御機能を実装する。^[47]プロジェクト管理のタスクは次のとおりです。

• 正しい情報の提供と更新のためのインフラの構築
• プロジェクトパラメータの相違を伝える方法の確立
• イントラネットに基づくプロジェクト情報技術の開発、またはプロジェクトの主要業績評価指標システム (KPI)の決定
• 相違分析と潜在的なプロジェクト規制の提案の生成^[48]
• 適切なプロジェクト構造、プロジェクトワークフロー組織、プロジェクト管理、ガバナンスを実現するための方法の確立
• プロジェクトパラメータの透明性の創出^[49]

これらのタスクの達成と実施は、プロジェクト管理の特定の方法と手段を適用することで実現できます。次のプロジェクト管理方法を適用できます。

• 投資分析
• 費用便益分析
• 価値利益分析
• 専門家調査
• シミュレーション計算
• リスクプロファイル分析
• 追加料金の計算
• マイルストーントレンド分析
• コスト傾向分析
• 目標と実績の比較^[50]

プロジェクト管理は、プロジェクトを予定通り、時間通りに、予算内で進めるための要素です。^[41]プロジェクト管理は、プロジェクトの初期段階で計画から始まり、プロセスの各ステップに徹底的に関与しながら、プロジェクトの後期段階で実装後のレビューで終わります。プロジェクトの進行中に、プロジェクトを監査またはレビューすることができます。正式な監査は、一般的にリスクまたはコンプライアンスに基づいて行われ、経営陣が監査の目的を指示します。検査には、承認されたプロジェクト管理プロセスとプロジェクトの実際の管理方法の比較が含まれる場合があります。^[51]各プロジェクトは、必要な管理の適切なレベルを評価する必要があります。管理が多すぎると時間がかかりすぎ、管理が少なすぎると非常にリスクが高くなります。プロジェクト管理が正しく実装されていない場合は、エラーと修正に関してビジネスにかかるコストを明確にする必要があります。

コスト、リスク、品質、コミュニケーション、時間、変更、調達、および人的資源には、コントロール システムが必要です。さらに、監査人は、プロジェクトが財務諸表にとってどの程度重要か、利害関係者がコントロールにどの程度依存しているか、およびコントロールがいくつ存在するかを考慮する必要があります。監査人は、開発プロセスと、その実装方法の手順を確認する必要があります。開発プロセスと最終製品の品質も、必要または要求に応じて評価される場合があります。企業は、問題を早期に発見してより簡単に修正できるように、プロセス全体に監査会社が関与することを望む場合があります。監査人は、開発チームの一員としてコントロール コンサルタントとして、または監査の一環として独立監査人として働くことができます。

企業では、正式なシステム開発プロセスを使用する場合があります。これにより、システムが正常に開発されることが保証されます。正式なプロセスは強力な制御を作成するのに効果的であり、監査人はこのプロセスを確認して、適切に設計され、実際に遵守されていることを確認する必要があります。適切な正式なシステム開発計画には、次の内容が含まれます。

• 組織のより広範な目標に合わせて開発を整合させる戦略
• 新しいシステムの標準
• タイミングと予算に関するプロジェクト管理ポリシー
• プロセスを説明する手順
• 変化の質の評価

プロジェクトには 5 つの重要な特性があります。

(i) 開始日と終了日を必ず明確にしておく必要があります。

(ii) グループの人々によって実行され、完了される。

(iii) アウトプットは、独自の製品またはサービスの提供です。

（iv）それらは一時的な性質のものである。

(v) 段階的に詳細化される。

たとえば、新しい車を設計したり、本を書いたりすることなどです。

複雑性とその性質は、プロジェクト管理の分野で重要な役割を果たします。この主題については多くの議論がありますが、研究では、複雑なプロジェクトの管理に関して、複雑性の定義と適切な理解が不足していることが示唆されています。^{[52] [53]}

プロジェクトの複雑さとは、プロジェクトシステムに関する十分な情報が与えられたとしても、プロジェクトの全体的な動作を理解し、予測し、制御することが困難になるプロジェクトの特性である。^[54]

複雑なプロジェクトの特定は、複数のプロジェクトが存在するエンジニアリング環境において特に重要です。^[55]

プロジェクトの複雑さとプロジェクトのパフォーマンスは密接に関連していると考えられるため、プロジェクト管理を効果的に行うためには、プロジェクトの複雑さを定義し、測定することが重要です。^[56]

複雑さは次のようになります:

• 構造的複雑さ（詳細の複雑さ、複雑性とも呼ばれる）、すなわち、多くの多様な相互に関連する部分から構成される。^[57]これは通常、プロジェクト構成要素の規模、多様性、相互依存性の観点から表現され、技術的要因と組織的要因によって説明される。
• 動的複雑性とは、曖昧さ、不確実性、伝播、出現、混沌などの現象、特性、現れを指します。^[54]

Cynefinフレームワーク^[58]に基づくと、複雑なプロジェクトは次のように分類できます。

• 単純な（または明確で、自明で、既知の）プロジェクト、システム、またはコンテキスト。これらは、既知の知識、安定性、および明確な因果関係を特徴としています。これらは、標準的な運用手順とベスト プラクティスで解決できます。
• 複雑：既知の未知数によって特徴付けられる。複雑なシステムは、その構成要素の総和である。原理的には、より小さな単純な構成要素に分解することができる。困難だが複雑な問題は、追加リソース、専門知識、分析、還元主義、単純化、分解技術、シナリオ計画、および優れた実践に従うことで理論的に解決可能である。^{[59] [60]}
• 複雑なシステムは、未知の未知と出現によって特徴付けられます。パターンは発見される可能性がありますが、明白ではありません。複雑なシステムは、全体は部分の総和よりも大きいというユークリッドの主張によって説明できます。
• 本当に複雑なプロジェクト、つまり非常に複雑または混沌としたプロジェクトは、不可知の要素によって特徴付けられます。本当に複雑なプロジェクトではパターンは識別できません。原因と結果は後から振り返っても不明です。アリストテレスの言葉を借りれば、本当に複雑なシステムは、その部分の合計とは異なります。^[61]

エリオット・ジャックスは、必須組織と階層化システム理論で説明されている作業の複雑さを測定する発見を適用して、プロジェクトとプロジェクト作業（段階、タスク）を、裁量の範囲やプロジェクトの出力の複雑さなどの基準に基づいて、プロジェクトの複雑さの7つの基本的なレベルに分類しています。^{[62] [63]}

• レベル 1 プロジェクト - 最大 3 か月の目標完了時間で、ビジネス プロセス内のアクティビティの直接的な出力 (数量、品質、時間) を改善します。
• レベル 2 プロジェクト - 3 か月から 1 年の目標完了時間で、ビジネス プロセスへのコンプライアンスを開発および改善します。
• レベル 3 プロジェクト - 1 ～ 2 年の目標完了期間でビジネス プロセスを開発、変更、改善します。
• レベル 4 プロジェクト - 目標完了期間 2 ～ 5 年で機能システムを開発、変更、改善します。
• レベル 5 プロジェクト - 5 ～ 10 年の目標完了期間で、機能システム/ビジネス機能のグループを開発、変更、改善します。
• レベル 6 プロジェクト - 目標完了期間を 10 年から 20 年に設定して、企業の単一のバリュー チェーン全体を開発、変更、改善します。
• レベル7プロジェクト – 企業の複数のバリューチェーンを開発、変更、改善し、目標完了期間を20年から50年とする。^[64]

プロジェクトの複雑さを測定することの利点は、プロジェクトの複雑さのレベルを、効果的な目標完了時間と、プロジェクトマネージャーとプロジェクトメンバーのそれぞれの能力レベルと一致させることにより、プロジェクトの実現可能性を向上させることです。^[65]

必要多様性の法則や必要複雑性の法則と同様に、プロジェクトの複雑さは、プロジェクトが目的を達成するために必要となる場合もあれば、有益な結果をもたらす場合もあります。複雑性の影響に基づいて、ステファン・モルコフは、複雑性をポジティブ、適切、ネガティブに分類することを提案しました。^{[66] [61]}

• ポジティブな複雑性とは、プロジェクトに価値を付加し、プロジェクトの成功への貢献が関連するネガティブな結果を上回っている複雑性です。
• 適切な（または必要な）複雑さとは、プロジェクトが目的を達成するために必要な複雑さ、またはプロジェクトの成功への貢献がマイナスの影響を相殺する複雑さ、または軽減コストがマイナスの兆候を上回る複雑さです。
• ネガティブな複雑さとは、プロジェクトの成功を妨げる複雑さのことです。

プロジェクトマネージャーは、プロジェクト管理の分野の専門家です。プロジェクト マネージャーは、プロジェクトに関わる人材を管理します。人材は、プロジェクトを成功させる鍵です。適切な人材が適切な場所に適切なタイミングでいなければ、プロジェクトは成功しません。プロジェクト マネージャーは、通常、建設業界、エンジニアリング、建築、コンピューティング、通信に関連するあらゆるプロジェクトの計画、実行、管理、終了を担当します。生産工学、設計工学、重工業など、他の多くの分野にもプロジェクト マネージャーがいます。

プロジェクト マネージャーは、プロジェクトを正しくスケジュールするためにプロジェクトの実行順序を理解している必要があります。また、プロジェクト内の各タスクの達成に必要な時間も理解している必要があります。プロジェクト マネージャーは、クライアントに代わって定められたプロジェクト目標を達成する責任を負う人物です。プロジェクト マネージャーは、その分野で数年の経験を持つ傾向があります。プロジェクト マネージャーは、プロジェクトと作業員を監督しながら、プロジェクトを隅々まで理解している必要があります。通常、ほとんどの建設、エンジニアリング、建築、および工業プロジェクトでは、プロジェクト マネージャーの横には別のマネージャーがいて、そのマネージャーは通常、日常的にタスクの実行を担当します。この役職は、監督者と呼ばれる場合もあります。監督者とプロジェクト マネージャーは、日常のプロジェクト タスクを完了するために協力して作業します。プロジェクト管理の主な責任には、明確で達成可能なプロジェクト目標の作成、プロジェクト要件の構築、プロジェクトの3 つの制約(現在はより多くの制約が含まれ、競合制約と呼ばれています) の管理が含まれます。3 つの制約とは、最初の 3 つがコスト、時間、品質、範囲ですが、現在のプロジェクト管理ではさらに 3 つあります。典型的なプロジェクトは、プロジェクト マネージャーの下で作業し、時間と予算の目標内で課題を完了する作業員のチームで構成されます。プロジェクト マネージャーは通常、プロジェクトの完了と成功について、より上位の人物に直接報告します。

プロジェクト マネージャーは多くの場合、クライアントの代表者であり、代表する企業に関する知識に基づいて、クライアントの正確なニーズを判断し、実行する必要があります。契約当事者のさまざまな社内手順に適応し、指名された代表者と緊密な関係を築く能力は、コスト、時間、品質、そして何よりもクライアントの満足度という重要な問題を確実に実現するために不可欠です。

完全なプロジェクト マネージャーとは、Robert J. Graham がシミュレーションで初めて作った用語で、Randall L. Englund と Alfonso Bucero によってさらに詳しく述べられています。彼らは、完全なプロジェクト マネージャーを、リーダーシップ、影響力、交渉、政治、変更と対立の管理、ユーモアなど、複数の分野を網羅する人物と説明しています。これらはすべて、プロジェクト リーダーがより効果的に働き、最適化された一貫した結果を達成できる ようにする「ソフト」な対人スキルです。

プロジェクトの成功とプロジェクト管理の成功を混同する傾向があります。これらは 2 つの異なるものです。「プロジェクトの成功」には 2 つの観点があります。

• プロセスの観点、つまり効率的な出力の提供。通常はプロジェクト管理パフォーマンスまたはプロジェクト効率と呼ばれます。
• 結果の観点、すなわち有益な成果の提供。通常はプロジェクトパフォーマンス（時には単にプロジェクトの成功）と呼ばれる。^{[67] [68] [69] [自費出版のソース? ]}

プロジェクト管理の成功基準は、プロジェクトの成功基準とは異なります。プロジェクト管理は、プロジェクトが合意された時間内に完了し、合意された範囲を満たし、合意された予算内で完了した場合に成功とみなされます。3 つの制約に続いて、プロジェクトの成功を確実にするために複数の制約が考慮されています。ただし、3 つの制約または複数の制約は、プロジェクトの効率性指標のみを示しており、これは実際にはプロジェクト ライフサイクル中のプロジェクト管理の成功基準です。

事前基準では、プロジェクトの完了後のより重要な結果が除外されます。これは、製品ライフサイクル中の出力（製品）の成功、結果（利益）の成功、影響（戦略）の成功という 4 つのレベルで構成されます。これらの事後成功基準は、プロジェクトの完了と引き渡し後のプロジェクト製品、サービス、または結果の有効性の尺度を示します。プロジェクト、プログラム、ポートフォリオのこの包括的なマルチレベル成功フレームワークは、2008 年にポール バナーマンによって開発されました。^[70]言い換えると、プロジェクトは、開発フェーズを開始する前のプロジェクトの開始と選択中に明確に特定および定義される必要のある期待されるビジネス ケースを達成できた場合に成功と見なされます。このマルチレベル成功フレームワークは、意図した価値を生み出すために、入力-プロセス/アクティビティ-出力-結果-影響として表される変革としてのプロジェクトの理論に準拠しています。エマニュエル カミレリは 2011 年に、すべての重要な成功要因と失敗要因をグループに分類し、それぞれをマルチレベル成功基準と照合してビジネス価値を実現しています。^[71]

プロジェクト管理に関連して使用されるパフォーマンス指標の例としては、「委託プロジェクトのバックログ」または「プロジェクトバックログ」がある。^[72]

米国国防総省は、「コスト、スケジュール、パフォーマンス、リスク」が国防総省の調達専門家がトレードオフを行い、プログラムのステータスを追跡する4つの要素であると述べています。^[73]国際基準もあります。リスク管理では、将来の問題を積極的に特定し（ツールを参照）、その結果を理解することで、プロジェクトに関する予測的な決定を下すことができます。ERMシステムは、全体的なリスク管理において役割を果たします。^[74]

作業分解構造（WBS）は、ポートフォリオ、プログラム、プロジェクト、契約など、目標を達成するために必要な活動を細分化して示すツリー構造です。WBSは、ハードウェア指向、製品指向、サービス指向、プロセス指向のいずれかになります（NASAの報告構造（2001）の例を参照）。^{[75]プロジェクトスコープ管理のためのWBSの他に、}組織分解構造（チャート）、コスト分解構造、リスク分解構造 があります。

WBSは、最終目標から始めて、規模、期間、責任の観点から管理可能なコンポーネント（システム、サブシステム、コンポーネント、タスク、サブタスク、作業パッケージなど）に分割することで作成できます。これらのコンポーネントには、目標を達成するために必要なすべてのステップが含まれます。^[33]

作業分解構造は、契約の全体的な計画と管理の自然な発展のための共通の枠組みを提供し、作業を定義可能な増分に分割するための基礎となり、そこから作業明細書を作成し、技術、スケジュール、コスト、労働時間の報告を確立することができます。^[75] 作業分解構造は、タスクの細分化を示す表、または最下位のノードが「作業パッケージ」と呼ばれる組織図の2つの形式で表示できます。

これは、計画の品質を評価する上で不可欠な要素であり、プロジェクトの計画中に使用される最初の要素です。たとえば、プロジェクトのスケジュールを設定するときに WBS を使用すると、作業パッケージの使用を記録して追跡できます。

作業内訳構造（WBS）と同様に、他の分解手法やツールとしては、組織内訳構造（OBS）、製品内訳構造（PBS）、コスト内訳構造（CBS）、リスク内訳構造（RBS）、リソース内訳構造（ResBS）などがあります。^{[76] [61]}

プロジェクト管理の標準には次のようなものがあります。

• ISO 規格ISO 9000 は品質管理システムの規格群であり、ISO 10006 :2003 は品質管理システムおよびプロジェクトにおける品質管理のガイドラインです。
• ISO 21500 :2012 –プロジェクト管理に関する手引き。これは、ISO が発行したプロジェクト管理に関する最初の国際規格です。21500 ファミリーの他の規格には、21503:2017プログラム管理に関する手引き、21504:2015ポートフォリオ管理に関する手引き、21505:2017ガバナンスに関する手引き、21506:2018用語、21508:2018プロジェクトおよびプログラム管理におけるアーンド バリュー管理、および 21511:2018プロジェクトおよびプログラム管理の作業分解構造があります。
• ISO 21502:2020 プロジェクト、プログラム、ポートフォリオ管理 - プロジェクト管理に関するガイダンス
• ISO 21503:2022 プロジェクト、プログラム、ポートフォリオ管理 - プログラム管理に関するガイダンス
• ISO 21504:2015 プロジェクト、プログラム、ポートフォリオ管理 – ポートフォリオ管理に関するガイダンス
• ISO 21505:2017 プロジェクト、プログラム、ポートフォリオ管理 - ガバナンスに関するガイダンス
• ISO 31000 :2009 – リスク管理。
• ISO/IEC/IEEE 16326:2009 – システムおよびソフトウェアエンジニアリング - ライフサイクルプロセス - プロジェクト管理^[77]
• 国際プロジェクトマネジメント協会（IPMA）の個人能力ベースライン（ICB）。^[78]
• ソフトウェア エンジニアリング協会の能力成熟度モデル(CMM) 。
• GAPPS ( Global Alliance for Project Performance Standards)は、プロジェクトおよびプログラム マネージャーの能力を記述するオープン ソース標準です。
• スイスの一般的なプロジェクト管理方法であるHERMES メソッドは、ルクセンブルクおよび国際組織で使用するために選択されています。
• 国際開発組織で人気の論理フレームワークアプローチ（LFA）。
• プロジェクトマネジメント協会(PMI)によるPMBOK ガイド。
• AXELOSのPRINCE2。
• PM ² : [欧州委員会]によって開発されたプロジェクト管理方法論。^[79]
• インド国防省によるプロジェクト策定および管理手順（PPFM）^[80]
• ソフトウェア エンジニアリング研究所のチーム ソフトウェア プロセス(TSP) 。
• 総コスト管理フレームワーク、AACE International の統合ポートフォリオ、プログラム、プロジェクト管理の方法論。
• 独自のシステム開発手法「Vモデル」 。

一部のプロジェクトは、同一または異なるものであれ、プログラム管理として管理できます。プログラムとは、共通の目的と一連の目標をサポートするプロジェクトの集合です。個々のプロジェクトには明確に定義された特定の範囲とタイムラインがありますが、プログラムの目的と期間はより細かいレベルで定義されます。

プログラムとポートフォリオの他に、さまざまな特性を組み合わせた追加の構造として、プロジェクト ネットワーク、メガ プロジェクト、メガ プログラムがあります。

プロジェクトネットワークとは、組織の枠を越えた、いくつかの異なる段階を経て発展する一時的なプロジェクトである。メガプロジェクトとメガプログラムは、規模、コスト、国民や政治の注目度、必要とされる能力の点で例外的なものとして定義される。^[61]

適切なプロジェクトを選択する手段として、いわゆるプロジェクトポートフォリオ管理（PPM）を使用し、プロジェクト管理手法[81]を使用して、成果物を公共、民間、または非営利組織に^利益の形で提供する手段として使用する組織が増えています。

ポートフォリオとは、類似したプロジェクトの集まりです。ポートフォリオ管理は、プロジェクト管理の専門家のグループが共通のツールと知識を共有することで、ポートフォリオ内のすべてのプロジェクトに同様の標準化された手法を適用し、規模の経済性、成功率の向上、プロジェクトリスクの削減をサポートします。組織では、プロジェクトポートフォリオ管理を構造的にサポートするための組織構造として、プロジェクト管理オフィスを作成することがよくあります。^[61] そのため、PPMは通常、エンタープライズプロジェクト管理オフィス（PMO）内に編成された専任のマネージャーチームによって実行されます。このチームは通常、組織内に拠点を置き、PMOディレクターまたは最高プロジェクト責任者が率います。組織の戦略的イニシアチブがPPMの大部分を占める場合、PPMの責任者は最高イニシアチブ責任者と呼ばれることがあります。

プロジェクト管理ソフトウェアは、リソースプールの計画、整理、管理、リソース見積の作成、計画の実施を支援するために使用されるソフトウェアです。ソフトウェアの高度さに応じて、機能には見積もりと計画、スケジュール、コスト管理と予算管理、リソース割り当て、コラボレーションソフトウェア、コミュニケーション、意思決定、ワークフロー、リスク、品質、ドキュメント、管理システムなどが含まれます。^{[82] [83]}

仮想プログラム管理（VPM）は、仮想チームによって行われるプロジェクトの管理ですが、仮想環境を実装するプロジェクトを指すことはほとんどありません。 ^[84] 仮想プロジェクトの管理は、従来のプロジェクトの管理とは根本的に異なり、^[85]リモートワークとグローバルコラボレーション（文化、タイムゾーン、言語）の懸念が組み合わされていることに注意してください。^[86]

• アジャイル建設
• 建築工学
• 建設管理
• コストエンジニアリング
• ファシリテーション（ビジネス）
• 工業工学
• プロジェクト生産管理
• プロジェクト管理ソフトウェア
• プロジェクトポートフォリオ管理
• プロジェクト管理オフィス
• プロジェクト人材管理
• ソフトウェアプロジェクト管理
• システムエンジニアリング

• アジャイル管理とは、アジャイル ソフトウェア開発とリーン管理の原則をさまざまな管理プロセス、特に製品開発に適用することです。
• 意思決定
• ゲーム理論
• アーンドバリュー管理
• ヒューマンファクター
• カンバン（開発）
• キックオフ ミーティングは、プロジェクトのクライアントの有無にかかわらず、プロジェクト チームとの最初のミーティングです。
• オペレーションズリサーチ
• プロジェクト管理の概要
• 事後検証ドキュメントは、プロジェクトの失敗の原因を特定し、将来的にそれを防ぐ方法を特定するために使用されるプロセスです。
• プロセスアーキテクチャ
• プログラム管理
• プロジェクト会計
• プロジェクトガバナンス
• プロジェクト管理オフィス
• プロジェクト管理シミュレーション
• 投資した時間に対するリターン
• 小規模プロジェクト管理
• ソフトウェア開発プロセス
• ソーシャルプロジェクト管理
• システム開発ライフサイクル(SDLC)

• プロジェクト管理ソフトウェアの比較
• プロジェクト管理用語集
• コラボレーションソフトウェアのリスト
• プロジェクト管理トピックのリスト
• プロジェクト管理のタイムライン

• 英国ビジネス・企業・規制改革省（BERR）によるプロジェクト管理ガイドライン

• ウィキメディア・コモンズのプロジェクト管理に関連するメディア