Loading article…
プロジェクト管理とは、与えられた制約の中でプロジェクトのすべての目標を達成するためにチームの作業を監督するプロセスです。 [ 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年代は、中核となる工学分野が一体となって働くようになった、現代のプロジェクト管理時代の幕開けとなった。プロジェクト管理は、工学モデルを用いた管理分野から派生した独立した学問分野として認識されるようになった。 [ 13 ] 1950年代以前の米国では、プロジェクトは主にガントチャートや非公式な手法やツールを用いて、アドホックに管理されていた。当時、2つの数学的なプロジェクトスケジューリングモデルが開発された。クリティカルパス法（CPM）は、プラント保守プロジェクトを管理するために、デュポン社とレミントン・ランド社の合弁事業として開発された。プログラム評価レビュー技法（PERT）は、ポラリスミサイル潜水艦計画の一環として、米国海軍特別プロジェクト局がロッキード社およびブーズ・アレン・ハミルトン社と共同で開発した。[ 14 ]
PERTとCPMはアプローチが非常に似ていますが、いくつかの違いがあります。CPMは、各アクティビティの実行時間が確定しているプロジェクトに使用されます。つまり、各アクティビティの実行時間は既知です。一方、PERTは、各アクティビティの実行時間が不確実または変動する確率的なアクティビティ時間に対応できます。この根本的な違いから、CPMとPERTは異なる状況で使用されます。これらの数学的手法は、多くの民間企業に急速に普及しました。
同時に、プロジェクトスケジューリングモデルが開発されるにつれ、ハンス・ラングらの先駆的な研究により、プロジェクトコスト見積もり、コスト管理、エンジニアリング経済学の技術も進化を遂げました。1956年、プロジェクト管理および計画・スケジューリング、コスト見積もり、プロジェクト管理といった関連分野の初期の実務家によって、米国コストエンジニア協会（現在のAACEインターナショナル、コストエンジニアリング振興協会）が設立されました。AACEは先駆的な活動を続け、2006年にはポートフォリオ、プログラム、プロジェクト管理のための初の統合プロセス（総コスト管理フレームワーク）を発表しました。
1969年、米国でプロジェクトマネジメント協会（PMI）が設立されました。 [ 15 ] PMIは、ウィリアム・ダンカンを主著者として、1996年に「ほとんどのプロジェクトで、ほとんどの場合」共通するプロジェクトマネジメントの実践方法を記述した「プロジェクトマネジメント知識体系ガイド（PMBOKガイド）」の初版を出版しました。 [ 16 ]
プロジェクト管理手法は、あらゆるプロジェクトに適用できます。多くの場合、プロジェクトの規模、性質、業界、または分野に基づいて、特定のタイプのプロジェクトに合わせて調整されます。たとえば、建物、道路、橋などの提供に重点を置く建設業界では、建設プロジェクト管理と呼ばれる独自の専門的なプロジェクト管理手法が開発されており、プロジェクトマネージャーは訓練を受けて認定を受けることができます。[ 17 ]情報技術業界も、 ITプロジェクト管理と呼ばれる独自のプロジェクト管理手法を開発しており、計画、設計、開発、テスト、展開などのさまざまなライフサイクルフェーズを通過する必要がある技術資産とサービスの提供に特化しています。バイオテクノロジープロジェクト管理は、バイオテクノロジーの研究開発の複雑さに焦点を当てています。[ 18 ]ローカリゼーションプロジェクト管理には、多くの人がこの種の管理をまったく異なる分野だと考えているにもかかわらず、翻訳作業に多くの標準的なプロジェクト管理手法を適用することが含まれます。たとえば、プロジェクトマネージャーは、翻訳の言語を話せなくても、研究目的をよく理解して情報に基づいた意思決定を行うことができるため、翻訳を改善する上で重要な役割を果たします。[ 19 ]同様に、研究調査管理にもプロジェクト管理のアプローチを適用できます。[ 20 ]公共プロジェクト管理には、政府機関が実施したり、請負業者に委託したりする政府によるすべての公共事業が含まれます。プロジェクト管理のもう 1 つの分類は、ハード (物理的) タイプまたはソフト (非物理的) タイプに基づいています。
すべてのプロジェクト管理タイプに共通するのは、時間、品質、コストという 3 つの重要な目標に焦点を当てている点です。プロジェクトが成功または失敗とみなされるには、スケジュールどおり、予算内で、事前に合意された品質基準に従って完了する必要があります。つまり、鉄の三角形または三重制約を満たす必要があります。[ 21 ]
プロジェクトマネージャーは、それぞれのプロジェクト管理手法において、担当する業界に特化した反復可能なテンプレートを開発・活用します。これにより、プロジェクト計画は綿密かつ高い再現性を持つようになり、品質向上、納期コスト削減、プロジェクト成果物の納品時間短縮といった具体的な目標達成につながります。
2017年の研究では、プロジェクトの成功は、プロジェクトに影響を与える状況的ダイナミクスと4つの重要な側面がどれだけうまく整合しているかにかかっていると示唆されており、これらは4つのPと呼ばれています: [ 22 ]
プロジェクト活動を組織化し、完了させるためのアプローチは数多くあり、段階的、リーン、反復的、漸進的などが挙げられる。また、プロジェクト計画には、成果（製品ベース）や活動（プロセスベース）に基づくなど、いくつかの拡張版も存在する。
ベネフィット実現管理（BRM）は、通常のプロジェクト管理手法を強化し、製品や成果物ではなくプロジェクトの成果（ベネフィット）に焦点を当て、その実現度を測定することでプロジェクトを軌道に乗せます。これにより、合意された要件（成果物）は達成したものの、その要件から得られるベネフィット（成果物）が実現されず、プロジェクトが失敗に終わるリスクを軽減できます。優れた要件管理では、これらのベネフィットがプロジェクトの要件として確実に把握され、プロジェクト全体を通してその達成状況が監視されます。
さらに、BRMの実践は、プロジェクトの成果とビジネス戦略との戦略的な整合性を確保することを目的としています。これらの実践の有効性は、さまざまな国や業界において、BRMの実践が戦略的な観点からプロジェクトの成功に影響を与えていることを示す最近の研究によって裏付けられています。これらのより広範な効果は、戦略的インパクトと呼ばれます。[ 23 ]
プロジェクトを要件通りに納品する例としては、従業員データの処理、給与計算、休暇管理、人事記録管理を、より短時間でエラーを削減して行うコンピュータシステムを納品することに合意することが挙げられます。BRM（ビジネスリレーションシップマネジメント）においては、システム導入後、システム導入前と比較して、従業員データの処理と維持に必要な従業員の作業時間とエラーを、特定の割合で削減することに合意する、といったことが考えられます。
クリティカルパス法（CPM）は、プロジェクト活動のスケジュールを決定するためのアルゴリズムです。これは、予測ベースのプロジェクト計画に使用される従来のプロセスです。CPM法は、活動の順序、必要な作業量、相互依存関係、および各行のフロート時間を評価して、必要なプロジェクト期間を決定します。したがって、定義上、クリティカルパスは、ネットワーク図上のタスクの経路であり、余剰時間がまったくない（またはほとんどない）ものです。[ 24 ]
クリティカルチェーンプロジェクトマネジメント（CCPM）は、制約理論（TOC）をプロジェクトの計画と管理に応用したものであり、プロジェクト管理に内在する不確実性に対処すると同時に、プロジェクトの実行に必要なリソース（物的資源、人的スキル、管理・支援能力など）の限られた利用可能性を考慮に入れるように設計されています。
目標は、組織におけるプロジェクトの流れ（スループット）を向上させることです。TOCの5つの集中ステップのうち最初の3つを適用することで、すべてのプロジェクトにおけるシステム制約とリソースが特定されます。この制約を活用するために、クリティカルチェーン上のタスクは他のすべての活動よりも優先されます。
アーンドバリューマネジメント（EVM）は、プロジェクト管理を拡張し、プロジェクトのモニタリングを改善する手法を取り入れています。[ 25 ]これは、作業と価値（コスト）の観点から、プロジェクトの完了に向けた進捗状況を示します。アーンドスケジュールは、EVMの理論と実践を拡張したものです。
プロジェクト管理に関する重要な研究では、段階的アプローチは、大規模で複数の企業が関わるプロジェクト[ 26 ]、定義されていない、曖昧な、または急速に変化する要件を持つプロジェクト[ 27 ]、あるいはリスク、依存性、急速に変化するテクノロジーの度合いが高いプロジェクトには適していないことが指摘されている。不確実性のコーンは、プロジェクトの初期段階で行われる計画が不確実性の度合いが高いことから、このことをある程度説明している。これは、ソフトウェア開発が新しいまたは斬新な製品の実現であることが多いため、特に当てはまる。
これらの複雑さは、より探索的または反復的かつ漸進的なアプローチで対処する方が適しています。[ 28 ]アジャイルプロジェクト管理、動的システム開発手法、エクストリームプロジェクト管理など、反復的かつ漸進的なプロジェクト管理のモデルがいくつか開発されています。スクラムアプローチは、作業目標を「スプリント」と呼ばれる反復に分割する、一般的に使用されているフレームワークです。[ 29 ] [ 30 ]
リーンプロジェクトマネジメントは、リーン生産方式の原則を活用し、無駄を減らし、時間を短縮しながら価値を提供することに重点を置いています。
プロジェクトのライフサイクルには、プロセスグループと呼ばれる5つのフェーズがあります。各プロセスグループは、一連の明確なステップを通して作業を管理するための、相互に関連する一連のプロセスを表しています。このタイプのプロジェクトアプローチは、「従来型」[ 31 ]または「ウォーターフォール型」 [ 32 ]と呼ばれることがよくあります。5つのプロセスグループは次のとおりです。
業界によっては、これらのプロジェクト段階を組織に合わせて変更したり、名称を変えたりする場合があります。例えば、建物の設計・建設プロジェクトでは、通常、事前計画、概念設計、基本設計、設計開発、施工図面（または契約書類）、施工管理といった段階を経てプロジェクトが進められます。
段階的アプローチは、小規模で明確に定義されたプロジェクトには適していますが、より大規模なプロジェクトや、より複雑で曖昧さ、問題、リスクが多いプロジェクトでは、しばしば課題や失敗につながります[ 33 ] – パロディ「大規模プロジェクトの6つの段階」を参照してください。
プロセスベースの管理の導入は、 OPM3やCMMI（能力成熟度モデル統合）などの成熟度モデルの使用によって推進されてきた（画像：Capability Maturity Model.jpg参照）。
プロジェクト生産管理とは、資本プロジェクトの遂行にオペレーション管理を適用することである。プロジェクト生産管理のフレームワークは、プロジェクトを生産システムとして捉える視点に基づいており、プロジェクトはインプット（原材料、情報、労働力、設備・機械）をアウトプット（商品・サービス）に変換する。[ 34 ]
プロダクトベースプランニングは、プロジェクト目標の達成に貢献するすべてのプロダクト（プロジェクト成果物）を特定することに基づく、構造化されたプロジェクト管理アプローチです。そのため、成功するプロジェクトは、活動やタスク指向ではなく、アウトプット指向であると定義されます。[ 35 ]このアプローチの最も一般的な実装は、PRINCE2です。[ 36 ]
従来（どのプロジェクト管理手法が使用されているかによって異なりますが）、プロジェクト管理には、4 ～ 5 つのプロジェクト管理プロセス グループと制御システムという、いくつかの要素が含まれています。使用される手法や用語に関係なく、同じ基本的なプロジェクト管理プロセスまたは開発段階が使用されます。主なプロセス グループには、一般的に次のものが含まれます。[ 38 ]
探索的要素が強いプロジェクト環境（例えば、研究開発）では、これらの段階に加えて、プロジェクトの継続について議論し決定する意思決定ポイント（継続／中止の決定）が設けられる場合がある。フェーズゲートモデルはその一例である。
プロジェクト管理では、様々な会議を通じて活動を調整します。例えば、プロジェクト開始時に幅広い関係者が参加するキックオフミーティングがあります。プロジェクト会議やプロジェクト委員会では、プロジェクトチームが行動計画を策定し、進捗状況を監視します。運営委員会は、フェーズ間の移行や問題解決に活用されます。並行プロジェクトを実施している組織では、プロジェクトポートフォリオレビューやプログラムレビューが実施されます。教訓共有会議は、得られた教訓を集約するために開催されます。これらの会議はすべて、特に目的、参加者リスト、進行方法を定義するために、会議運営の手法を活用しています。
プロジェクトの開始プロセスによって、プロジェクトの性質と範囲が決定されます。[ 39 ]この段階が適切に実行されない場合、プロジェクトがビジネスのニーズを満たすことに成功する可能性は低いでしょう。ここで必要な主要なプロジェクト管理は、ビジネス環境を理解し、必要なすべての管理がプロジェクトに組み込まれていることを確認することです。不備があれば報告し、修正するための推奨事項を提示する必要があります。
プロジェクト開始段階では、以下の領域を網羅する計画を策定する必要があります。これらの領域は、プロジェクト開始文書と呼ばれる一連の文書に記録できます。プロジェクト開始文書とは、プロジェクト期間の順序を作成するために使用される一連の計画文書です。これらには、通常、以下の内容が含まれます。
開始段階の後、プロジェクトは適切な詳細レベルで計画されます（フローチャートの例を参照）。[ 37 ]主な目的は、必要な作業を見積もり、プロジェクト実行中のリスクを効果的に管理するために、時間、コスト、リソースを適切に計画することです。開始プロセスグループと同様に、適切な計画を怠ると、プロジェクトが目標を達成できる可能性が大幅に低下します。
コミュニケーションやスコープ管理の計画、役割と責任の明確化、プロジェクトに必要な物品の調達、キックオフミーティングの開催といった追加的なプロセスも、一般的に推奨されます。
新製品開発プロジェクトにおいては、最終製品の動作に関する概念設計をプロジェクト計画活動と並行して行うことが適切であり、成果物や計画活動を特定する際に計画チームへの情報提供に役立つ可能性がある。
実行段階では、計画された実行条件を把握しておく必要があります。実行／実装フェーズでは、プロジェクト管理計画の成果物が計画通りに実行されることを保証します。このフェーズでは、人的資源や資材、予算などのあらゆる資源の適切な配分、調整、管理が行われます。このフェーズの成果物は、プロジェクトの成果物です。
プロジェクトを成功させるには、プロジェクト内のあらゆる事柄を文書化することが不可欠です。予算、範囲、有効性、そしてペースを維持するためには、プロジェクトごとに各タスクに関する文書を作成する必要があります。適切な文書化があれば、プロジェクトの要件が満たされているかどうかを容易に確認できます。さらに、文書化によって、そのプロジェクトで既に完了した作業に関する情報も得られます。プロジェクト全体を通して文書化を行うことで、過去の作業を参照する必要のある人にとって、記録を残すことができます。多くの場合、文書化はプロジェクトの特定の段階を監視・管理する最も効果的な方法です。適切な文書化があれば、プロジェクトの進行状況を追跡・観察することができます。適切に実施すれば、文書化はプロジェクト成功の基盤となります。
監視と管理とは、プロジェクトの実行状況を観察し、潜在的な問題をタイムリーに特定し、必要に応じて是正措置を講じてプロジェクトの実行を管理するために実施される一連のプロセスを指します。主な利点は、プロジェクトのパフォーマンスを定期的に観察・測定することで、プロジェクト管理計画からの逸脱を特定できることです。
監視と制御には以下が含まれます。[ 41 ]
プロジェクトにおける監視と管理を支える主なメカニズムは 2 つあります。一方では、契約は、潜在的な罰則や制裁によって支えられることが多い一連のルールとインセンティブを提供します。[ 42 ]他方では、ビジネスや経営の研究者は、プロジェクトの目的を達成するためのインテグレーター (プロジェクト バロンとも呼ばれる) の役割に注目してきました。[ 43 ] [ 44 ]一方、プロジェクト管理における最近の研究では、契約とインテグレーターの相互作用の種類に疑問が呈されています。これらの 2 つの監視メカニズムは代替として機能すると主張する人もいます[ 45 ]。つまり、一方のタイプの組織を使用すると、もう一方の組織を使用する利点が減少します。
複数段階からなるプロジェクトでは、監視および制御プロセスは、プロジェクトの各段階間でフィードバックを提供し、プロジェクトをプロジェクト管理計画に準拠させるための是正措置または予防措置を実施する。
プロジェクトのメンテナンスは継続的なプロセスであり、以下が含まれます。[ 38 ]
この段階では、監査担当者はユーザーの問題がどれだけ効果的かつ迅速に解決されるかに注意を払うべきである。
建設プロジェクトの過程では、作業範囲が変更される場合があります。変更は建設プロセスにおいて正常かつ想定される部分です。変更は、必要な設計変更、現場の状況の違い、資材の入手可能性、請負業者からの変更要求、バリューエンジニアリング、第三者からの影響など、さまざまな要因によって発生します。現場で変更を実行するだけでなく、実際に何が建設されたかを示すために、変更内容を文書化する必要があります。これは変更管理と呼ばれます。そのため、発注者は通常、すべての変更、より具体的には、完成した工事の有形部分を変更する変更を示す最終記録を要求します。記録は契約書類、通常は設計図面（必ずしもそれに限定されるわけではありません）に作成されます。この取り組みの最終成果物は、業界では竣工図面、または単に「竣工図」と呼ばれるものです。これらの図面を提供することは、建設契約における標準的な要件です。建設文書管理は、オンラインまたはデスクトップソフトウェアシステムを使用して実施される、あるいは物理的な文書によって維持される非常に重要な作業です。建設業界における適切な文書管理に関する法的規制の強化に伴い、文書管理システムの必要性が高まっている。
プロジェクトに変更が加えられた場合、プロジェクトの実現可能性を再評価する必要があります。プロジェクトの当初の目標やターゲットを見失わないことが重要です。変更が積み重なると、予測される結果がプロジェクトへの当初の投資を正当化しない可能性があります。成功するプロジェクト管理では、これらの要素を特定し、進捗状況を追跡および監視して、プロジェクト開始時に既に概説されている時間と予算の枠内に収まるようにします。プロジェクトのライフサイクル全体を通して、進捗状況と予想される期間に関して最も有益な監視ポイントを特定するための具体的な方法が提案されています。[ 46 ]
プロジェクトの完了には、正式な承認と終了手続きが含まれます。管理業務には、ファイルのアーカイブ化と教訓の文書化が含まれます。
このフェーズは以下から構成されます: [ 38 ]
このフェーズには、導入後レビューも含まれます。これは、プロジェクトチームが経験から学び、将来のプロジェクトに活かすための重要なフェーズです。通常、導入後レビューでは、プロジェクトでうまくいった点を確認し、うまくいかなかった点を分析して、教訓を導き出します。
プロジェクト管理は、プロジェクトの処理中に検証および制御機能を実行し、定義されたパフォーマンスと正式な目標を強化します。[ 47 ]プロジェクト管理において独立した機能として確立されるべきです。
関連するコストエンジニアリングの業務は、プロジェクトコストの管理に焦点を当てています。プロジェクト管理に関わるその他の業務には、以下のようなものがあります。
これらのタスクの達成と実施は、特定のプロジェクト管理手法とツールを適用することによって実現できます。適用可能なプロジェクト管理手法は以下のとおりです。
プロジェクト管理とは、プロジェクトを予定通り、時間通りに、予算内で進めるためのプロジェクトの要素です。[ 41 ]プロジェクト管理は、プロジェクトの初期段階での計画から始まり、プロジェクトの後期段階での実装後のレビューで終了し、プロセスの各ステップに徹底的に関与します。プロジェクトは、進行中に監査またはレビューされることがあります。正式な監査は一般的にリスクまたはコンプライアンスに基づいており、経営陣が監査の目的を指示します。調査には、承認されたプロジェクト管理プロセスと、プロジェクトが実際にどのように管理されているかの比較が含まれる場合があります。[ 51 ]各プロジェクトは、必要な適切なレベルの管理について評価される必要があります。管理が多すぎると時間がかかりすぎ、管理が少なすぎると非常に危険です。プロジェクト管理が正しく実装されていない場合、エラーと修正の観点からビジネスへのコストを明確にする必要があります。
コスト、リスク、品質、コミュニケーション、時間、変更、調達、および人的資源には、管理システムが必要です。さらに、監査人は、プロジェクトが財務諸表にとってどれほど重要か、利害関係者が管理にどれほど依存しているか、および管理がいくつ存在するかを考慮する必要があります。監査人は、開発プロセスと、それらがどのように実装されているかの手順をレビューする必要があります。必要に応じて、または要求された場合は、開発プロセスと最終製品の品質も評価されることがあります。企業は、問題を早期に発見してより容易に修正できるように、監査法人がプロセス全体に関与することを望む場合があります。監査人は、開発チームの一員として管理コンサルタントとして、または監査の一環として独立監査人として活動することができます。英国では、国家会計検査院が2005年に主要防衛プロジェクト管理の「ゴールドスタンダード」を開発し、監査ツールとして使用しています。この基準の主要要素は次のとおりです。
企業は、正式なシステム開発プロセスを用いることがあります。これは、システムが確実に成功裏に開発されることを保証するのに役立ちます。正式なプロセスは、強力な統制を構築する上でより効果的であり、監査人はこのプロセスをレビューして、適切に設計され、実際に遵守されていることを確認する必要があります。優れた正式なシステム開発計画には、以下の要素が含まれます。
プロジェクトには5つの重要な特徴があります。
（i）開始日と終了日を必ず明記する必要があります。
（ii）それらは複数の人々によって実行され、完了される。
（iii）成果物は独自の製品またはサービスの提供である。
（iv）それらは一時的な性質のものである。
（v）それは段階的に詳細化される。
例えば、新型車の設計や本の執筆などが挙げられます。
複雑性とその性質は、プロジェクト管理の分野で重要な役割を果たします。このテーマについては多くの議論がありますが、複雑なプロジェクトの管理に関連する複雑性の定義と適切な理解が不足していることが研究で示唆されています。[ 53 ] [ 54 ]
プロジェクトの複雑性とは、プロジェクトシステムに関する十分に完全な情報が与えられたとしても、その全体的な挙動を理解し、予測し、制御することが困難になるプロジェクトの特性である。[ 55 ]
複雑なプロジェクトの特定は、複数のプロジェクトを抱えるエンジニアリング環境において特に重要である。[ 56 ]
プロジェクトの複雑さとプロジェクトのパフォーマンスは密接に関連していると考えられているため、プロジェクト管理を効果的に行うためには、プロジェクトの複雑さを定義して測定することが重要です。[ 57 ]
複雑さとは、次のようなものである。
Cynefinフレームワーク[ 59 ]に基づくと、複雑なプロジェクトは次のように分類できます。
エリオット・ジャックは、必要な組織と階層化されたシステム理論で説明されている作業の複雑さを測定する発見を適用して、裁量期間やプロジェクトの成果物の複雑さなどの基準に基づいて、プロジェクトとプロジェクト作業（段階、タスク）を7つの基本的なプロジェクト複雑性レベルに分類しています。[ 63 ] [ 64 ]
プロジェクトの複雑性を測定することの利点は、プロジェクトの複雑性のレベルを、プロジェクトマネージャーとプロジェクトメンバーそれぞれの能力レベルと、効果的な目標完了時間と一致させることで、プロジェクト担当者の実現可能性を向上させることです。[ 66 ]
必要多様性の法則や必要複雑性の法則と同様に、プロジェクトの複雑さは、プロジェクトがその目的を達成するために必要となる場合があり、有益な結果をもたらす場合もあります。複雑さの影響に基づいて、ステファン・モルコフはそれを肯定的、適切、または否定的に分類することを提案しました。[ 67 ] [ 62 ]
プロジェクトマネージャーとは、プロジェクト管理の分野における専門家です。生産工学、設計工学、重工業など、他の多くの分野にもプロジェクトマネージャーが存在します。
プロジェクトの成功とプロジェクトマネジメントの成功を混同する傾向がある。プロジェクトの成功には2つの視点がある。
プロジェクト管理の成功基準は、プロジェクトの成功基準とは異なります。プロジェクト管理は、プロジェクトが合意された期間内に完了し、合意された範囲を満たし、合意された予算内で完了した場合に成功したと言えます。トリプル制約に続いて、プロジェクトの成功を確実にするために複数の制約が考慮されてきました。しかし、トリプル制約または複数の制約は、プロジェクトのライフサイクルにおけるプロジェクトの効率性指標を示すだけであり、実際にはプロジェクト管理の成功基準です。
事前の基準では、プロジェクト完了後のより重要な結果が除外されます。この完了後の結果は、製品ライフサイクル中の出力（製品）の成功、成果（利益）の成功、影響（戦略的）の成功という 4 つのレベルから構成されます。これらの事後的な成功基準は、プロジェクトの完了と引き渡し後のプロジェクト製品、サービス、または結果の有効性尺度を示します。プロジェクト、プログラム、ポートフォリオのこの包括的な多段階成功フレームワークは、2008 年に Paul Bannerman によって開発されました。[ 71 ]言い換えれば、プロジェクトは、開発フェーズを開始する前にプロジェクトの開始と選択中に明確に特定および定義する必要がある期待されるビジネス ケースを達成することに成功したときに成功したと言われます。この多段階成功フレームワークは、意図した価値を生み出すために、入力プロセス / 活動-出力-成果-影響として描かれる変換としてのプロジェクトの理論に準拠しています。2011 年に Emanuel Camilleri は、すべての重要な成功要因と失敗要因をグループに分類し、ビジネス価値を提供するために、それぞれを多段階成功基準と照合しています。[ 72 ]
プロジェクト管理に関連して使用されるパフォーマンス指標の一例として、「委託されたプロジェクトのバックログ」または「プロジェクトのバックログ」が挙げられます。[ 73 ]
米国国防総省は、「コスト、スケジュール、パフォーマンス、リスク」が、国防総省の調達担当者がトレードオフを行い、プログラムの状況を追跡するための4つの要素であると述べています。[ 74 ]国際標準も存在します。リスク管理は、将来の問題を事前に特定し（ツールを参照）、その結果を理解することで、プロジェクトに関する予測的な意思決定を可能にします。ERMシステムは、全体的なリスク管理において役割を果たします。[ 75 ]
作業分解構造(WBS) は、ポートフォリオ、プログラム、プロジェクト、契約などの目標を達成するために必要なアクティビティの細分化を示すツリー構造です。WBS は、ハードウェア、製品、サービス、またはプロセス指向である場合があります ( NASA の報告構造 (2001)の例を参照)。[ 76 ]プロジェクト スコープ管理のための WBS の他に、組織分解構造 (チャート)、コスト分解構造、リスク分解構造 があります。
WBSは、最終目標から始めて、それを規模、期間、責任の観点から管理可能な構成要素（システム、サブシステム、コンポーネント、タスク、サブタスク、ワークパッケージなど）に順次細分化することによって作成できます。これには、目標を達成するために必要なすべてのステップが含まれます。[ 33 ]
作業分解構造は、契約全体の計画と管理を自然に進めるための共通の枠組みを提供し、作業を定義可能な増分に分割するための基礎となります。これにより、作業明細書を作成し、技術、スケジュール、コスト、および労働時間の報告を確立することができます。[ 76 ] 作業分解構造は、タスクを細分化した表、または最下位のノードが「作業パッケージ」と呼ばれる組織図の 2 つの形式で表示できます。
これは計画の質を評価する上で不可欠な要素であり、プロジェクトの計画段階で最初に用いられる要素です。例えば、WBSはプロジェクトのスケジュール作成時に使用され、作業パッケージの使用状況を記録・追跡するために用いられます。
作業分解構造 (WBS) と同様に、他の分解手法とツールには、組織分解構造 (OBS)、製品分解構造 (PBS)、コスト分解構造 (CBS)、リスク分解構造 (RBS)、およびリソース分解構造 (ResBS) があります。[ 77 ] [ 62 ]
プロジェクト管理にはいくつかの標準規格があり、以下のようなものがある。
同一または異なるプロジェクトの中には、プログラム管理として管理できるものがあります。プログラムとは、共通の目的と目標をサポートするプロジェクトの集合体です。個々のプロジェクトには明確に定義された具体的な範囲とスケジュールがありますが、プログラムの目的と期間はより細かいレベルで定義されます。
プログラムやポートフォリオの他に、それらの異なる特性を組み合わせた構造としては、プロジェクトネットワーク、メガプロジェクト、メガプログラムなどがある。
プロジェクトネットワークとは、組織の枠を超えて展開する、複数の異なる段階からなる一時的なプロジェクトのことです。メガプロジェクトやメガプログラムは、規模、コスト、世論や政治的な注目、必要な能力の点で例外的なものと定義されます。[ 62 ]
ますます多くの組織が、適切なプロジェクトを選択する手段としてプロジェクトポートフォリオ管理（PPM）と呼ばれるものを使用し、その後、プロジェクト管理技術[ 82 ]を使用して、公共、民間、または非営利組織に利益という形で成果をもたらす手段を使用しています。
ポートフォリオとは、類似したプロジェクトの集合体です。ポートフォリオ管理は、共通のツールと知識を共有するプロジェクト管理専門家グループが、ポートフォリオ内のすべてのプロジェクトに同様の標準化された手法を適用することにより、規模の効率性をサポートし、成功率を高め、プロジェクトのリスクを低減します。組織は、プロジェクトポートフォリオ管理を体系的にサポートするための組織構造として、プロジェクト管理オフィスを設置することがよくあります。[ 62 ]
プロジェクト管理ソフトウェアは、リソースプールを計画、組織、管理し、リソースの見積もりを作成し、計画を実行するのに役立つソフトウェアです。ソフトウェアの高度さに応じて、機能には見積もりと計画、スケジューリング、コスト管理と予算管理、リソース割り当て、コラボレーションソフトウェア、コミュニケーション、意思決定、ワークフロー、リスク、品質、ドキュメント、および/または管理システムが含まれる場合があります。[ 83 ] [ 84 ]プロジェクト管理ソフトウェアを比較すると、ソフトウェアごとに異なる機能が含まれていることがわかります。
仮想プログラム管理（VPM）は、仮想チームによって行われるプロジェクトの管理ですが、仮想環境を実装するプロジェクトを指すことはまれです。[ 85 ]仮想プロジェクトの管理は、リモートワークとグローバルコラボレーション（文化、タイムゾーン、言語）の懸念事項を組み合わせた 従来のプロジェクトの管理とは根本的に異なると指摘されています。[ 86 ] [ 87 ]
プロジェクトマネジメントが経営学の分野から生まれた独自の貢献として正式に認識されたのは、1950年代のことだった。
ウィキメディア・コモンズのプロジェクト管理に関連するメディア