プロジェクト管理

プロジェクトマネジメントとは、与えられた制約条件の中でプロジェクトの全目標を達成するために、チームの作業を監督するプロセスです。 [ 1 ]この情報は通常、開発プロセスの開始時に作成されるプロジェクトドキュメントに記載されます。主な制約条件は、スコープ、時間、予算です。[ 2 ]二次的な課題は、必要なインプットの配分を最適化し、それらを事前に定義された目標達成に適用することです。

プロジェクトマネジメントの目的は、クライアントの目標に沿った完全なプロジェクトを実現することです。多くの場合、プロジェクトマネジメントの目的は、クライアントの目標に実現可能な形で対応できるよう、クライアントの指示内容を具体化または改訂することです。クライアントの目標が設定されると、その目標はプロジェクトに関わる他の関係者（プロジェクトマネージャー、設計者、請負業者、下請け業者など）によるすべての意思決定に影響を与える必要があります。プロジェクトマネジメントの目標が明確に定義されていない、あるいは厳格すぎる場合、意思決定プロセスに悪影響を及ぼします。

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

歴史

1900年以前は、土木工学プロジェクトは一般的に創造的な建築家、技術者、そして建築の棟梁自身によって管理されていました。例えば、ウィトルウィウス（紀元前1世紀）、クリストファー・レン（1632–1723）、トーマス・テルフォード（1757–1834）、イザムバード・キングダム・ブルネル（1806–1859）などが挙げられます。[ 7 ] 1950年代には、組織は複雑な工学プロジェクトにプロジェクト管理ツールと手法をより体系的に適用し始めました。[ 8 ]

ヘンリー・ガント（1861-1919）、計画と管理技術の父

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

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

PERTとCPMはアプローチが非常に似ていますが、いくつかの違いがあります。CPMは、各アクティビティの実行時間が既知である確定的な活動時間を前提とするプロジェクトに使用されます。一方、PERTは、各アクティビティの実行時間が不確実であったり、変動したりする場合の確率的な活動時間を考慮に入れます。この根本的な違いにより、CPMとPERTは異なる文脈で使用されます。これらの数学的手法は、多くの民間企業に急速に普及しました。

5 つのマイルストーンを持つ 7 か月のプロジェクトのPERT ネットワーク チャート

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

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

種類

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

すべてのプロジェクトマネジメントの種類に共通するのは、時間、品質、コストという3つの重要な目標に焦点を当てていることです。成功するプロジェクトとは、スケジュール通り、予算内で、事前に合意された品質基準に従って完了することです。つまり、プロジェクトの成功または失敗を判断するための鉄の三角形、つまり3つの制約条件を満たすことです。[ 21 ]

プロジェクトマネージャーは、それぞれのプロジェクト管理の種類に応じて、担当する業界に特化した繰り返し可能なテンプレートを開発・活用します。これにより、プロジェクト計画は綿密かつ繰り返し性が高くなり、品質の向上、納品コストの削減、そしてプロジェクト成果の実現までの時間の短縮という明確な目的を達成できます。

アプローチ

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

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

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

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

利益実現管理

ベネフィット実現マネジメント（BRM）は、製品やアウトプットではなくプロジェクトの成果（ベネフィット）に焦点を当て、その達成度を測定することで、通常のプロジェクトマネジメント手法を強化します。これにより、合意された要件（アウトプット）は達成されるものの（つまりプロジェクトの成功）、その要件から得られるベネフィット（成果）（つまり製品の成功）が得られず、プロジェクトが失敗に終わるリスクを軽減できます。優れた要件管理は、これらのベネフィットをプロジェクトの要件として捉え、プロジェクト全体を通してその達成度を監視することに重点を置いています。

さらに、BRMプラクティスは、プロジェクト成果と事業戦略の戦略的整合性を確保することを目的としています。これらのプラクティスの有効性は、BRMプラクティスが様々な国や業界において戦略的観点からプロジェクトの成功に影響を与えることを示す最近の研究によって裏付けられています。こうした広範な効果は、戦略的インパクトと呼ばれています。[ 24 ]

要件を満たすプロジェクトの実現例としては、従業員データを処理し、給与計算、休暇、人事記録を短時間で、かつエラーを削減して管理するコンピュータシステムを納入することに合意することが挙げられます。BRM（Bring Your Own Management）では、システム導入後、従業員データの処理と維持に必要なスタッフの労働時間とエラーを、システム導入前と比較して、規定の削減を達成することが合意事項となる場合があります。

クリティカルパス法

クリティカルパス法（CPM）は、プロジェクト活動のスケジュールを決定するためのアルゴリズムです。予測に基づくプロジェクト計画に用いられる伝統的なプロセスです。CPM法は、活動の順序、必要な作業量、相互依存関係、そして結果として生じるラインシーケンスごとの余裕時間を評価して、必要なプロジェクト期間を決定します。したがって、定義上、クリティカルパスとは、ネットワーク図上で、余裕時間がない（または余裕時間がほとんどない）タスクの経路を指します。[ 25 ]

クリティカルチェーンプロジェクト管理

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

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

アーンドバリュー管理

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

反復的かつ漸進的なプロジェクト管理

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

これらの複雑さは、より探索的、あるいは反復的かつ漸進的なアプローチによってより適切に対処されます。[ 29 ]反復的かつ漸進的なプロジェクト管理モデルには、アジャイルプロジェクト管理、動的システム開発手法、エクストリームプロジェクト管理など、いくつかが進化しています。スクラムアプローチは、作業目標を「スプリント」と呼ばれる反復に分割する、一般的に使用されているフレームワークです。[ 30 ] [ 31 ]

リーンプロジェクト管理

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

プロジェクトのライフサイクル

プロジェクトライフサイクルには5つのフェーズがあり、これらはプロセスグループと呼ばれます。各プロセスグループは、完了すべき一連の明確なステップを通して作業を管理するための、相互に関連する一連のプロセスを表しています。このタイプのプロジェクトアプローチは、しばしば「従来型」[ 32 ]または「ウォーターフォール型」[ 33 ]と呼ばれます。5つのプロセスグループは以下のとおりです。

エンジニアリングプロジェクトの典型的な開発フェーズ
  1. 開始
  2. 計画
  3. 実行中
  4. 監視と制御
  5. 終わりに

一部の業界では、これらのプロジェクト段階を組織に合わせて名称変更し、様々なバリエーションで表現することがあります。例えば、実店舗の設計・建設においては、プロジェクトは通常、事前計画、概念設計、概略設計、設計開発、施工図（または契約書類）、施工管理といった段階を経て進行します。

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

プロセスベースの管理

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

プロジェクト生産管理

プロジェクト生産管理とは、オペレーションズ・マネジメントを資本プロジェクトの実施に適用することです。プロジェクト生産管理のフレームワークは、プロジェクトを生産システムとして捉え、インプット（原材料、情報、労働力、設備・機械）をアウトプット（商品およびサービス）に変換するという視点に基づいています。[ 35 ]

製品ベースの計画

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

プロセスグループ

プロジェクトの開発段階[ 38 ]

伝統的に（使用されるプロジェクト管理方法論によって異なりますが）、プロジェクト管理はいくつかの要素から構成されています。具体的には、4～5つのプロジェクト管理プロセスグループと管理システムです。使用される方法論や用語に関わらず、基本的なプロジェクト管理プロセスや開発段階は同じです。主要なプロセスグループには、一般的に以下のものがあります。[ 39 ]

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

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

プロジェクトマネジメントは、様々なアクションを調整するために様々な会議を活用します。例えば、プロジェクト開始時に幅広い関係者が参加するキックオフミーティングがあります。プロジェクトミーティングやプロジェクト委員会は、プロジェクトチームが行動計画を策定し、モニタリングすることを可能にします。運営委員会は、フェーズ間の移行や問題解決に活用されます。並行してプロジェクトを進めている組織では、プロジェクトポートフォリオとプログラムのレビューが行われます。教訓共有会議は、学習内容を統合するために開催されます。これらの会議はすべて、会議科学で用いられる手法、特に目標、参加者リスト、ファシリテーション手法の定義に用いられます。

開始

プロセスグループプロセスの開始[ 38 ]

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

開始段階では、以下の領域を網羅した計画を策定する必要があります。これらの領域は、「プロジェクト開始文書」と呼ばれる一連の文書に記録することができます。プロジェクト開始文書とは、プロジェクト期間中の指示を作成するために用いられる一連の計画文書です。これらの文書には、通常、以下の内容が含まれます。

計画

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

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

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

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

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

実行中

プロセスグループプロセスの実行[ 38 ]

実行にあたっては、実行すべき計画条件を把握しておく必要があります。実行／実装フェーズでは、プロジェクトマネジメント計画の成果物が適切に実行されることを保証します。このフェーズでは、人的資源、資材、予算などのその他のリソースの適切な配分、調整、管理が行われます。このフェーズの成果物がプロジェクト成果物です。

プロジェクトドキュメント

プロジェクト内のあらゆることを文書化することは、成功の鍵です。予算、範囲、効果、そしてペースを維持するために、プロジェクトにはそれぞれのタスクに関する物理的な文書が必要です。適切な文書があれば、プロジェクトの要件が満たされているかどうかを容易に確認できます。さらに、文書は、そのプロジェクトで既に完了した内容に関する情報も提供します。プロジェクト全体を通して文書化することで、過去の作業を遡って参照する必要がある人にとって、文書による記録が残ります。多くの場合、文書化はプロジェクトの特定のフェーズを監視および管理するための最も効果的な方法です。適切な文書化があれば、プロジェクトの成功をプロジェクトの進行に合わせて追跡および観察できます。適切に実施されれば、文書化はプロジェクトの成功の基盤となり得ます。

監視と制御

プロセスグループプロセスの監視と制御[ 38 ]

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

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

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

プロジェクトにおける監視と管理は、主に2つのメカニズムによって支えられています。一方では、契約によって一連のルールとインセンティブが提供され、多くの場合、罰則や制裁が伴います。[ 43 ]一方では、ビジネスやマネジメントの研究者は、プロジェクトの目的を達成するためのインテグレーター（プロジェクト・バロンとも呼ばれる）の役割に注目しています。[ 44 ] [ 45 ]一方では、プロジェクトマネジメントに関する最近の研究では、契約とインテグレーターの相互作用の種類が疑問視されています。一部の研究者は、これら2つの監視メカニズムは代替的であり、 [ 46 ]一方の組織タイプは他方の組織タイプの利点を低下させるため、 代替的であると主張しています。

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

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

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

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

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

プロジェクトに変更が加えられた場合、プロジェクトの実現可能性を再評価する必要があります。プロジェクトの当初の目標とターゲットを見失わないことが重要です。変更が積み重なると、予測される結果が当初の投資額を正当化できなくなる可能性があります。効果的なプロジェクトマネジメントは、これらの要素を特定し、進捗状況を追跡・監視することで、プロジェクト開始時に既に定められた時間と予算の枠内に収まるようにします。プロジェクトのライフサイクル全体を通して、進捗状況と予想期間に関して最も有益なモニタリングポイントを特定するための的確な方法が提案されました。[ 47 ]

終わりに

終了プロセスグループプロセス[ 38 ]

クロージングには、プロジェクトの正式な承認と終了が含まれます。管理業務には、ファイルのアーカイブ化と得られた教訓の文書化が含まれます。

この段階は以下から構成されます: [ 39 ]

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

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

プロジェクト管理とプロジェクト管理システム

プロジェクト管理は、プロジェクトの処理中に検証と制御の機能を実装し、定義されたパフォーマンスと正式な目標を強化します。[ 48 ]プロジェクト管理において独立した機能として確立されるべきです。

コストエンジニアリングの関連タスクは、プロジェクトコストの管理に重点を置いています。プロジェクト管理に関連するその他のタスクには、以下のものがあります。

これらのタスクの達成と実施は、特定のプロジェクト管理手法とツールを適用することで実現できます。適用可能なプロジェクト管理手法は以下のとおりです。

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

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

コスト、リスク、品質、コミュニケーション、時間、変更、調達、そして人的資源に関する管理システムが必要です。さらに、監査人は、プロジェクトが財務諸表にとってどれほど重要か、ステークホルダーが統制にどれほど依存しているか、そしてどれほどの数の統制が存在するかを考慮する必要があります。監査人は、開発プロセスとその実施手順をレビューする必要があります。開発プロセスと最終製品の品質は、必要に応じて、あるいは要請があれば評価されることもあります。企業は、問題を早期に発見し、より容易に解決できるよう、監査法人がプロセス全体にわたって関与することを望むかもしれません。監査人は、開発チームの一員として統制コンサルタントとして、あるいは監査の一環として独立監査人として活動することができます。英国では、会計検査院が2005年に主要防衛プロジェクト管理のための「ゴールドスタンダード」を策定し、監査ツールとして活用しています。この基準の主要な要素は次のとおりです。

企業では、正式なシステム開発プロセスを採用することがあります。これは、システム開発の成功を保証するのに役立ちます。正式なプロセスは、強力な統制を構築する上でより効果的であり、監査人はこのプロセスをレビューし、適切に設計され、実際に遵守されていることを確認する必要があります。優れた正式なシステム開発計画には、以下の内容が含まれます。

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

プロジェクトの特徴

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

(i) 常に特定の開始日と終了日を設定する必要があります。

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

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

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

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

たとえば、新しい車の設計や本の執筆などが挙げられます。

プロジェクトの複雑さ

複雑性とその性質は、プロジェクトマネジメントの分野において重要な役割を果たします。このテーマについては多くの議論があるにもかかわらず、複雑なプロジェクトのマネジメントにおける複雑性の定義と適切な理解が不足していることが、研究によって示唆されています。[ 54 ] [ 55 ]

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

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

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

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

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

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

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

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

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

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

肯定的、適切（必要）、否定的複雑性

ステファン・モルコフが提唱したポジティブ、適切、ネガティブな複雑性モデル[ 63 ]

必要多様性の法則や必要複雑性の法則と同様に、プロジェクトの複雑さは、プロジェクトが目標を達成するために必要となる場合もあれば、有益な結果をもたらす場合もあります。ステファン・モルコフは、複雑さの影響に基づき、それを肯定的、適切、否定的に分類することを提案しました。[ 68 ] [ 63 ]

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

プロジェクトマネージャー

プロジェクトマネージャーは、プロジェクトマネジメントの分野における専門家です。生産技術、設計技術、重工業など、多くの分野でプロジェクトマネージャーが活躍しています。

プロジェクトの成功とプロジェクトのパフォーマンス

プロジェクトの成功とプロジェクトマネジメントの成功を混同しがちです。プロジェクトの成功には2つの視点があります。

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

プロジェクトマネジメントの成功基準は、プロジェクトマネジメントの成功基準とは異なります。プロジェクトマネジメントは、合意された期間内に、合意されたスコープと予算内でプロジェクトを完了した場合に成功とみなされます。三重制約に続いて、プロジェクトの成功を確実にするために複数の制約が考慮されてきました。しかし、三重制約や複数の制約は、プロジェクトの効率性を示す指標に過ぎず、それがプロジェクトライフサイクル全体におけるプロジェクトマネジメントの成功基準となるのです。

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

プロジェクト管理に関連して使用される業績指標の例として、「委託プロジェクトのバックログ」または「プロジェクトバックログ」が挙げられる。[ 74 ]

リスク管理

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

作業分解構造およびその他の分解構造

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

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

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

これは計画の質を評価する上で不可欠な要素であり、プロジェクトの計画段階で使用される最初の要素です。例えば、プロジェクトのスケジュール作成時にはWBSが使用され、作業パッケージの使用状況を記録・追跡することができます。

作業分解構造（WBS）と同様に、他の分解技術やツールとしては、組織分解構造（OBS）、製品分解構造（PBS）、コスト分解構造（CBS）、リスク分解構造（RBS）、リソース分解構造（ResBS）などがあります。[ 78 ] [ 63 ]

国際基準

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

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

プログラム管理とプロジェクトネットワーク

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

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

プロジェクト・ネットワークとは、組織の垣根を越え、複数の異なる段階を経て発展する一時的なプロジェクトです。メガプロジェクトとメガプログラムは、規模、コスト、国民や政治家の関心、そして必要とされる能力の点で例外的なものとして定義されます。[ 63 ]

プロジェクトポートフォリオ管理

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

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

プロジェクト管理ソフトウェア

プロジェクト管理ソフトウェアは、リソースプールの計画、組織化、管理、リソース見積の作成、計画の実施を支援するソフトウェアです。ソフトウェアの高度化に応じて、見積と計画、スケジュール管理、コスト管理と予算管理、リソース割り当て、コラボレーションソフトウェア、コミュニケーション、意思決定、ワークフロー、リスク管理、品質管理、文書管理、管理システムなどの機能が含まれる場合があります。[ 84 ] [ 85 ]プロジェクト管理ソフトウェアを比較すると、異なるソフトウェアに含まれる機能の違いがわかります。

仮想プロジェクト管理

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

参照

リスト

参考文献

  1. ^フィリップス、ジョセフ (2004). PMP プロジェクトマネジメントプロフェッショナル 学習ガイド. マグロウヒル/オズボーン. p. 354. ISBN 0072230622。
  2. ^バラッタ、アンジェロ (2006). 「三重の制約、三重の幻想」 . PMI . 2022年12月22日閲覧。
  3. ^ノークス、セバスチャン、ケリー、ショーン (2007).プロジェクトマネジメント決定版ガイド：時間と予算内で仕事を成し遂げるための近道. ピアソン・エデュケーション. プレンティス・ホール・フィナンシャル・タイムズ. ISBN 9780273710974。
  4. ^ 「プロジェクトマネジメントとは何か？」プロジェクトマネジメント協会。 2014年6月4日閲覧。
  5. ^ Dinsmore, Paul C.; Cooke-Davies, Terence J. (2005年11月4日). 『Right Projects Done Right: From Business Strategy to Successful Project Implementation』. Wiley. p. 35. ISBN 0787971138。
  6. ^ Cattani, Gino; Ferriani, Simone; Frederiksen, Lars; Täube, Florian (2011).プロジェクトベースの組織化と戦略マネジメント. 戦略マネジメントの進歩 第28巻. リーズ、イギリス: Emerald. ISBN 978-1780521930。
  7. ^ロック、デニス著『プロジェクトマネジメント』（第9版）ISBN 9780566087721。
  8. ^クワック・ヨンフン (2005). 「プロジェクトマネジメントの簡潔な歴史」.エリアス・G・カラヤニス編.プロジェクトマネジメントの歴史. ブルームズベリー・アカデミック. ISBN 1567205062。
  9. ^ Cleland, David; Gareis, Roland (2006年5月25日). 「1. プロジェクトマネジメントの進化」.グローバル・プロジェクトマネジメント・ハンドブック. McGraw-Hill Education. ISBN 0071460454。
  10. ^スティーブンス、マーティン (2002).プロジェクトマネジメントの道筋. プロジェクトマネジメント協会. p. xxii. ISBN 190349401X。
  11. ^マーシュ、エドワード・R. (1975). 「カロル・アダミエツキのハーモノグラム」.アカデミー・オブ・マネジメント・ジャーナル. 18 (2): 358– 364. JSTOR 255537 . 
  12. ^ Witzel, Morgen (2003). 『経営における50人の重要人物』Psychology Press. pp.  96– 101. ISBN 0415369770。
  13. ^ Cleland, David; Gareis, Roland (2006年5月25日). 『グローバル・プロジェクトマネジメント・ハンドブック：国際プロジェクトの計画、組織化、管理』 McGraw-Hill Education. pp.  1– 4. ISBN 0071460454プロジェクト管理が経営学の分野から生まれた独自の貢献として正式に認識されたのは 1950 年代になってからでした。
  14. ^ Malcolm, DG; Roseboom, JH; Clark, CE; Fazar, W. (1959). 「研究開発プログラム評価のための手法の応用」(PDF) .オペレーションズ・リサーチ. 7 (5): 646– 669. Bibcode : 1959OpRes...7..646M . doi : 10.1287/opre.7.5.646 .
  15. ^ハリソン、FL; ロック、デニス (2004). 『プロジェクトマネジメントの高度化：構造化アプローチ』 ガワー出版. p. 34. ISBN 0566078228。
  16. ^ Saladis, FP (2006). 「PMBOK®ガイドの活用」 . PMIグローバルコングレス. シアトル（ワシントン州）：プロジェクトマネジメント協会.
  17. ^ 「Certified Construction Manager」 . CMAA. 2013年11月28日時点のオリジナルよりアーカイブ。2013年11月23日閲覧。
  18. ^ 「バイオテクノロジープロジェクトマネジメント証明書」ワシントン大学。 2013年11月23日閲覧。
  19. ^ Sha, Mandy; Immerwahr, Stephen (2018年2月19日). 「調査翻訳：研究者と管理者はなぜ、どのように関与すべきか？」 . Survey Practice . 11 (2): 1– 10. doi : 10.29115/SP-2018-0016 .
  20. ^ Sha, Mandy; Childs, Jennifer Hunter (2014年8月1日). 「定性調査手法を用いた調査研究プロジェクトへのプロジェクトマネジメントアプローチの適用」 . Survey Practice . 7 (4): 1– 8. doi : 10.29115/SP-2014-0021 .
  21. ^エッセリンク、バート（2000年）『ローカリゼーション実践ガイド』アムステルダム/フィラデルフィア：ジョン・ベンジャミンズ出版社、p.428、ISBN 978-9-027-21956-5。
  22. ^メスリー、オリヴィエ（2016年12月15日）『プロジェクトの実現可能性：脆弱性を発見するためのツール』CRC Press、Taylor & Francis、ISBN 9781498757911。。
  23. ^ The Bridger (ブログ)「プロジェクト管理: PMP、Prince 2、あるいは反復型またはアジャイル型の変種」を参照
  24. ^ Serra, CEM; Kunc, M. (2014). 「ベネフィット実現マネジメントとプロジェクトの成功およびビジネス戦略の実行への影響」 . International Journal of Project Management . 33 (1): 53– 66. doi : 10.1016/j.ijproman.2014.03.011 .
  25. ^ 「クリティカルパス法を超えて」 www.pmi.org . 2021年12月27日閲覧。
  26. ^ Mahmoudi, Amin; Bagherpour, Morteza; Javed, Saad Ahmed (2021). 「Grey Earned Value Management: Theory and Applications」 . IEEE Transactions on Engineering Management . 68 (6): 1703– 1721. Bibcode : 2021ITEM...68.1703M . doi : 10.1109/tem.2019.2920904 . ISSN 0018-9391 . S2CID 202102868 .  
  27. ^ Hass, Kathleen B. (Kitty) (2010年3月2日). 「規模が大きすぎ、期間が長すぎ、費用がかかりすぎる複雑なプロジェクトの管理」 . PM Times . 2017年6月27日閲覧。
  28. ^ Conforto, EC; Salum, F.; Amaral, DC; da Silva, SL; Magnanini de Almeida, L. F. (2014年6月). 「アジャイルプロジェクトマネジメントはソフトウェア開発以外の業界でも導入できるか？」. Project Management Journal . 45 (3): 21– 34. doi : 10.1002/pmj.21410 . S2CID 110595660 . 
  29. ^スノーデン、デイビッド・J.、ブーン、メアリー・E.（2007年11月）「リーダーの意思決定フレームワーク」ハーバード・ビジネス・レビュー。2017年6月27日閲覧。
  30. ^レイトン、マーク・C.、モロー、デイビッド（2018年4月16日）『スクラム・フォー・ダミーズ』ジョン・ワイリー・アンド・サンズ、p.1、ISBN 978-1-119-46769-4. 2025年11月13日閲覧。
  31. ^ラーマン、クレイグ (2004).アジャイル開発と反復開発：マネージャーのためのガイド. アディソン・ウェズリー・プロフェッショナル. p. 113. ISBN 978-0-13-111155-4. 2025年11月13日閲覧。
  32. ^ Wysocki, Robert K. (2013). 『効果的なプロジェクトマネジメント：伝統的、適応的、極端的』（第7版）. John Wiley & Sons . ISBN 978-1118729168。
  33. ^ Royce, Winston W. (1970年8月25日～28日). 「大規模ソフトウェアシステムの開発管理」(PDF) . Western Electronic Show and Convention (WesCon) の技術論文. ロサンゼルス. 2016年3月15日時点のオリジナル(PDF)からアーカイブ。
  34. ^ a bステルマン、アンドリュー、グリーン、ジェニファー (2005). 『応用ソフトウェアプロジェクトマネジメント』オライリーメディア. ISBN 978-0-596-00948-9. 2015年2月9日時点のオリジナルよりアーカイブ。
  35. ^ McCaffer, Ronald; Harris, Frank (2013).現代建設マネジメント. Wiley-Blackwell. p. 5. ISBN 978-1118510186. OCLC  834624541 .
  36. ^政府商務局（1996年） PRINCE2による成功するプロジェクトの管理、p14
  37. ^ 「OGC – PRINCE2 – 背景」 。2011年8月22日時点のオリジナルよりアーカイブ。
  38. ^ a b c d e f「プロジェクトマネジメントガイド」（PDF） . VA Office of Information and Technology . 2003年. 2009年1月14日時点のオリジナルよりアーカイブ。
  39. ^ a b c PMI (2010).プロジェクトマネジメント知識体系ガイド、pp. 27–35.
  40. ^ピーター・ネイサン、ジェラルド・エヴェレット・ジョーンズ (2003).『PMP 認定資格 初心者向け』 63ページ。
  41. ^カーズナー、ハロルド（2003年）『プロジェクトマネジメント：計画、スケジューリング、コントロールへのシステムアプローチ』（第8版）ワイリー社ISBN 0-471-22577-0。
  42. ^ a b Lewis, James P. (2000).プロジェクトマネージャーのためのデスクリファレンス：プロジェクトの計画、スケジュール、評価、システムに関する包括的なガイド. p. 185.
  43. ^エクルズ、ロバート・G. (1981). 「建設業界における準企業」 .経済行動・組織ジャーナル. 2 (4): 335– 357. doi : 10.1016/0167-2681(81)90013-5 . ISSN 0167-2681 . 
  44. ^デイヴィス、アンドリュー、ホブデイ、マイケル (2005). 『プロジェクトビジネス：複雑な製品とシステムにおけるイノベーションのマネジメント』ケンブリッジ大学出版局. ISBN 978-0-521-84328-7。
  45. ^ガン、デイビッド、ソルター、アモン、ドジソン、フィリップス、ネルソン (2012). 「プロジェクト・バロンの世界の内側」 MITスローン・マネジメント・レビュー53 ( 3): 63– 71. ISSN 1532-9194 . 
  46. ^ Meng, Xianhai (2012). 「建設業界における関係性マネジメントがプロジェクトパフォーマンスに与える影響」 .国際プロジェクトマネジメントジャーナル. 30 (2): 188– 198. doi : 10.1016/j.ijproman.2011.04.002 .
  47. ^ Cohen-Kashi, S.; Rozenes, S.; Ben-Gal, I. 「予想所要期間エントロピーに基づくプロジェクト管理モニタリング」（PDF）。Entropy 2020, 22, 905ページ。
  48. ^ Becker, Jarg; Kugeler, Martin; Rosemann, Michael (2003).プロセスマネジメント：ビジネスプロセス設計ガイド. Springer. p. 27. ISBN 9783540434993。
  49. ^シュラゲック、ベルンハルト (2000)。プロジェクトとプロジェクト制御のオブジェクト参照モデル: グルンドラーゲン - 建設 - 安全な管理。 ISBN 978-3-8244-7162-1、131ページ。
  50. ^リードル、ヨーゼフ E. (1990)。フォルシュングとエントヴィックルングのプロジェクト管理。 ISBN 978-3-540-51963-8、99ページ。
  51. ^スタインル、ブルッフ、ラワ (1995)。プロジェクト管理。 FAZ Verlagsbereich Wirtschaftsbücher、136 ～ 143 ページ。
  52. ^スナイダー、シンシア、フランク・パース（2006年）『ITプロジェクトマネジメント入門』 393～397頁。
  53. ^国家監査院「主要防衛プロジェクトの成功の推進：効果的なプロジェクト管理」、2005年5月20日発行、2025年11月17日アクセス
  54. ^ Abdou, Saed M; Yong, Kuan; Othman, Mohammed (2016). 「プロジェクトの複雑性がプロジェクトマネジメントのパフォーマンスに及ぼす影響 ― マレーシアの視点」 . MATEC Web of Conferences . 66 : 00065. doi : 10.1051/matecconf/20166600065 . ISSN 2261-236X . 
  55. ^ Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2020). 「ITプロジェクトの複雑性の定義、特徴、尺度 - 体系的な文献レビュー」(PDF) . International Journal of Information Systems and Project Management . 8 (2): 5– 21. doi : 10.12821/ijispm080201 . S2CID 220545211 . 
  56. ^ a b Marle, Franck; Vidal, Ludovic-Alexandre (2016). 「複雑でリスクの高いプロジェクトの管理 - 基礎と上級プロジェクトマネジメントガイド」ロンドン: Springer-Verlag.
  57. ^ Vidal, Ludovic-Alexandre; Marle, Franck; Bocquet, Jean-Claude (2011). 「階層分析プロセスを用いたプロジェクトの複雑性の測定」(PDF) . International Journal of Project Management . 29 (6): 718– 727. doi : 10.1016/j.ijproman.2010.07.005 . S2CID 111186583 . 
  58. ^ Vidal, Ludovic-Alexandre; Marle, Franck (2008). 「プロジェクトの複雑性の理解：プロジェクトマネジメントへの影響」(PDF) . Kybernetes . 37 (8): 1094– 1110. doi : 10.1108/03684920810884928 .
  59. ^ Baccarini, D. (1996). 「プロジェクトの複雑性の概念、レビュー」. International Journal of Project Management . 14 (4): 201– 204. doi : 10.1016/0263-7863(95)00093-3 .
  60. ^スノーデン、デイビッド・J.、ブーン、メアリー・E. (2007). 「リーダーの意思決定フレームワーク」ハーバード・ビジネス・レビュー. 85 (11): 68– 76.
  61. ^ Maurer, Maik (2017). 『エンジニアリング設計における複雑性管理 ― 入門』ベルリン、ハイデルベルク: Springer.
  62. ^ Kurtz, CF; Snowden, David J. (2003). 「戦略の新たなダイナミクス：複雑で入り組んだ世界における意味づけ」. IBM Systems Journal . 42 (3): 462– 483. doi : 10.1147/sj.423.0462 . S2CID 1571304 . 
  63. ^ a b c d e f Morcov, S. (2021). 「ポジティブおよびネガティブな複雑性の管理：ITプロジェクトの複雑性管理フレームワークの設計と検証」 KU Leuven University .
  64. ^モリス、ピーター (1994).プロジェクトマネジメントロンドン: T. テルフォード. p. 317. ISBN 978-0727725936. OCLC  30437274 .
  65. ^デニス・ロック、リンゼイ・スコット編 (2013). 『ガワー・ハンドブック・オブ・ピープル・イン・プロジェクトマネジメント』 ファーナム、サリー: ガワー出版. p. 398. ISBN 978-1409437857. OCLC  855019788 .
  66. ^ "PMOs" . www.theprojectmanager.co.za . 2018年3月1日閲覧。
  67. ^オーストラリア公共サービス委員会「最適な管理構造のためのAPSフレームワーク」 。 2018年3月1日閲覧。
  68. ^ Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2020). 「ITプロジェクトの複雑性管理：その要因と影響に基づく：ポジティブ、適切、ネガティブ」(PDF) . Proceedings of the Romanian Academy - Series A. 21 ( 4): 329– 336.
  69. ^ダニエル、ピエール・A.、ダニエル、キャロル（2018年1月）「複雑性、不確実性、そしてメンタルモデル：プロジェクトマネジメントにおける規制パラダイムから創発パラダイムへ」『国際プロジェクトマネジメントジャーナル』36 (1): 184– 197. doi : 10.1016/j.ijproman.2017.07.004 .
  70. ^ Pinto, Jeffrey K.; Winch, Graham (2016年2月1日). 「『定着した科学』の揺らぎ：プロジェクトマネジメントの過去と未来」. International Journal of Project Management . 34 (2): 237– 245. doi : 10.1016/j.ijproman.2015.07.011 .
  71. ^ Morcov, Stefan (2021年4月6日). 「プロジェクトの成功とプロジェクトマネジメントのパフォーマンス」 .
  72. ^ Bannerman, PL (2008). 「プロジェクト成功の定義：マルチレベルフレームワーク」 .プロジェクトマネジメントの未来を定義する. ワルシャワ、ポーランド：プロジェクトマネジメント協会.
  73. ^カミレリ、エマニュエル (2011).『プロジェクトの成功：重要な要素と行動』 Gower Publishing, Ltd.
  74. ^ KPI Institute、「KPI of the Day – ビジネスコンサルティング（BC）：委託プロジェクトのバックログ」。パフォーマンスマガジン、2021年3月16日。2022年12月23日にアクセス。
  75. ^ 「DoDD 5000.01」（PDF） . 米国国防総省. 2009年8月25日時点のオリジナル（PDF）からアーカイブ。 2007年11月20日閲覧。
  76. ^ 「リスク管理からリスクを取り除く：企業リスク管理への包括的アプローチ」 . Strategic Direction . 32 (5): 28– 30. 2016年1月1日. doi : 10.1108/SD-02-2016-0030 . ISSN 0258-0543 . 
  77. ^ a b NASA NPR 9501.2D . 2001年5月23日.
  78. ^ Levine, HA (1993). 「ウィービスとオビスの実践：プロジェクトマネージャーのための新しいダンス？」PMネットワーク、7(4)、35–38。
  79. ^ ISO/IEC/IEEE システムおよびソフトウェアエンジニアリング - ライフサイクルプロセス - プロジェクトマネジメント. doi : 10.1109/IEEESTD.2009.5372630 . ISBN 978-0-7381-6116-7。
  80. ^プロジェクト・プログラム・ポートフォリオマネジメントにおける個人能力基準(PDF)国際プロジェクトマネジメント協会 (IPMA). 2015年. ISBN 978-94-92338-01-3。
  81. ^欧州委員会。PM 2 ：欧州委員会が開発したプロジェクト管理方法論。
  82. ^ Mohindra, T., Srivastava, M. (2019).「プロジェクトマネジメントフレームワークの比較分析とプロジェクト主導型組織への提案」. PM World Journal , VIII(VIII).
  83. ^ハミルトン、アルバート (2004).プロジェクトマネジメント手順ハンドブック. TTL Publishing, Ltd. ISBN 0-7277-3258-7
  84. ^ PMBOK 4h Ed . PMI、プロジェクトマネジメント協会。2008年。p. 443。ISBN 978-1933890517。
  85. ^ケンドリック、トム (2013).プロジェクトマネジメントツールキット：仕事を正しく行うための100のヒントとテクニック、第3版. AMACOM Books. ISBN 9780814433454
  86. ^ Curlee, Wanda (2011). 『バーチャルプロジェクトマネジメントオフィス：ベストプラクティスと実証済みの手法』 . Management Concepts Press.
  87. ^カザンチ、ディーパック（2005年）「バーチャルプロジェクトにおける効果的なプロジェクトマネジメントのパターン：探索的研究」プロジェクトマネジメント協会ISBN 9781930699830. 2013年10月23日時点のオリジナルよりアーカイブ。
  88. ^ムリドゥラ、ベラガプディ (2012 年 4 月 13 日)。「2012 年以降、仮想プロジェクト管理を避けて通れない理由」。
無料の辞書「Wiktionary」でプロジェクト管理を調べてください。
ウィキメディア コモンズには、プロジェクト管理に関連するメディアがあります。
Wikiquote にはプロジェクト管理に関連する引用があります。
プロジェクト管理に関する図書館リソース
プロジェクト管理に関する図書館リソース
「 https://en.wikipedia.org/w/index.php?title=プロジェクト管理&oldid= 1328528634」より取得