セクション 1: 概要
1. プロジェクトが置かれている組織環境
(1) 企業環境要因 (EEF)
組織内のビジネス環境要因:
どの企業にもビジョン、使命、価値観があり、それが企業の発展の方向性を決定します。初心を忘れず、自分の道をしっかりと貫く、このような経営理念が企業における「やっていいプロジェクトとやってはいけないプロジェクト」の基本原則を決定します。
企業は、プロジェクトに着手する前に、自社のソフトウェアとハードウェアの条件を十分に考慮する必要があります。例えば、敷地や設備はプロジェクトの意思決定計画やコスト、進捗、コミュニケーションなどの諸計画に大きく影響し、企業の情報基盤やシステム、管理プロセス、システムなどのソフトウェア状況もプロジェクトに大きく影響します。計画と実行。
組織外部のビジネス環境の要因:
プロジェクトに取り組む際には、自国およびプロジェクトの所在地の法律、規制、業界標準、規範を遵守する必要があり、法令遵守は重要な責務であるため、チームは慎重な調査と研究を行う必要があります。プロジェクト管理の最終ライン。
また、市場、経済、自然環境などの要因を十分に検討する必要があり、既にプロジェクトが開始されている場合でも、市場状況、開発状況、国際情勢の変化を分析し続ける必要があります。自然環境要因に敏感なエンジニアリング プロジェクトの場合、チームは水文学、地質学、気象学、災害などがプロジェクトに与える影響にも注意を払う必要があります。
(2) 組織プロセス資産 (OPA)
プロセス、ポリシー、手順
プロセス、ポリシー、手順は、プロジェクト管理を標準化し、導くために使用されます。たとえば、プロジェクトの承認にはどのような手順が必要か、プロジェクトの承認にはどのような条件を満たす必要があるか、要件の変更にはどのような手順に従う必要があるかなどです。
プロセス、ポリシー、手順には、プロジェクト管理オフィス (PMO) によって照合および編集されたプロジェクト計画ボード、操作マニュアル、プロジェクト管理ガイドラインなども含まれます。
組織とリポジトリ
成熟した管理を行う企業は、ナレッジ マネジメントを非常に重視しており、完了したすべてのプロジェクトには、プロジェクト計画、プロジェクトの経験、学んだ教訓を含む、完全で標準化された安全なファイルがあり、将来のプロジェクト チームが参照できるようになります。
企業が収集および購入した業界データ、アイデアや資料も、プロジェクトにおいて非常に重要なリソースです。
標準化された厳格な管理を通じてのみ、上記の知識を適切に保存、維持、検索、共有することができ、その価値を最大限に発揮することができます。
企業環境要因と組織プロセス資産の違い
| 企業環境要因 (EEF) | 組織プロセス資産 (OPA) | |
|---|---|---|
| から | 政府、業界団体、企業経営者 | 歴史あるプロジェクトチームとPMO |
| のために | 従う | 参考 |
| 方法 | 消極的な受け入れ、ローマ人に倣う | 積極的な参加、更新、メンテナンス |
事業環境要因（B）は以下のとおりです。
A. 前回のプロジェクトから学んだ教訓の記録
B. プロジェクト管理情報システム (PMIS)
C. 企業が購入した最新の業界データ
D. 全体的な変更管理手順
答え：B. 企業が提供するプロジェクト管理情報システム (PMIS) は、他の企業情報プラットフォーム (CRM、ERP、OA など) と同じ性質を持ち、すべてのプロジェクト チームが標準化された方法で使用する必要があります。プロジェクト チームが従わなければならない組織の内部プロセス システム。ただし、PMIS に保持される過去のプロジェクトのデータ、テンプレート ログ、レポートなどは組織のプロセス資産です。オプション A、C、D はすべて組織のプロセス資産です。オプション D は、全体的な変更管理手順です。各プロジェクトの変更手順は、スポンサーおよび参加者全員の意見に基づいて、このプロジェクトで個別に策定されます。これはプロジェクト参加者全員の合意であり、異なるプロジェクトには普遍的なものではありません。
2. 組織形態の種類
下図の行列 (弱い行列、バランス行列、強い行列) は、 PMP 試験問題に出てくる「コンパクト行列」とは同じカテゴリではないことに注意してください。コンパクトマトリックスとは、マトリックス組織ではなく、チームメンバーの集中オフィス（ウォールーム）を指し、チームビルディングに役立ち、チームのコミュニケーションとコラボレーションの効率を向上させます。
機能別組織
以下の図に示すように、機能別組織ではリソースは機能上の経験によって管理され、プロジェクトのコラボレーションは少なくとも機能別マネージャーのレベルで伝達される必要があります。
機能別組織は通常、小規模かつ短期間のプロジェクト、または工場や病院などテクノロジーとオペレーションを主体とする組織に適しています。
マトリックス組織
以下の図に示すように、マトリックス組織には異なる機能部門 (垂直) と異なるプロジェクト チーム (水平) があります。
マトリックス組織は広く使われており、機能別の利点を最大限に発揮できるだけでなく、プロジェクト管理の要件にも対応できます。
プロジェクト組織
下図に示すように、プロジェクトベースの組織では、独立したプロジェクト会社または会社役員が複数のプロジェクトマネージャーを直接管理し、プロジェクトマネージャーがプロジェクトチームを管理します。
プロジェクトベースの組織は、航空宇宙工学、大規模インフラ建設プロジェクト、総合不動産開発プロジェクトなど、長期にわたる大規模かつ複雑なプロジェクトに適しています。
機能型、マトリックス型、プロジェクト型のメリットとデメリットの比較
| タイプ | アドバンテージ | 欠点がある |
|---|---|---|
| 機能的 | 機能部門にリソースが集中する利点を最大限に発揮し、 人材活用の柔軟性が向上する 部門担当者とのコミュニケーションが容易でありながら、 経験やプロジェクト担当者の流動が技術の継続性に影響を与えることはありません 。この部門の従業員の通常の昇進パス。 |
プロジェクトが機能部門の仕事の中心にならないことが多い 異なるプロジェクト間では、リソース使用の優先順位が衝突しやすい プロジェクトの 所有者が明確でなく、誰も責任を持たない状況になりやすい 顧客への対応が遅く、困難を伴う プロジェクトへの人員配置のモチベーションが高くない 部門間のコミュニケーションが難しい |
| マトリックス | 組織リソースを最大限に活用し、重複した設定を回避することで、 各部門の技術力と経営上のメリットを集中し、 顧客および社内組織内で迅速かつ柔軟に対応し、 プロジェクトチームは会社方針との一貫性を維持できます。 |
指揮統一原則の違反 プロジェクトマネージャーと機能マネージャーの仕事の優先順位が相反する |
| プロジェクトの種類 | プロジェクトオーナーの 指示は明確で、意思決定は迅速で、 コミュニケーションと調整が容易で、 チームの利点を最大限に発揮でき、 顧客への迅速な対応が可能で、 組織構造はシンプルで柔軟で、運営が容易です。 |
リソースの独占は無駄な 組織構築につながる可能性があり、チームメンバーの共有に役立たない 安心感や帰属意識の欠如 チーム間の横のつながりが少なく、経験の共有が 困難で社内ルールの実行に一貫性がないさまざまなプロジェクトチームによる規制。 |
さまざまな組織におけるプロジェクトマネージャーの特徴
3. ガバナンスモデルと管理プロセス
ガバナンスとマネジメント
ビジネスにおけるガバナンスとマネジメントのつながりを見てみましょう。
ガバナンスは、社内の誰が誰に報告し、誰が誰に責任を負うかなど、責任、権利、利益の合理的な配分と抑制とバランスを達成するための「ルールを設定する」ことと理解できます。管理とは、ガバナンスの枠組み内でビジネス目標を達成するために実行されるすべての行動です。
ガバナンスとマネジメントはどちらも組織の健全な発展を目的としており、相互補完的です: ガバナンスは方向性を示し、ルートを計画し、経営に明確な境界線を描きます。相互作用により取締役会は動的に調整できます。ガバナンス構造を最適化します。
企業におけるガバナンスとマネジメントの違いは次のとおりです。
| ガバナンス | 管理 | |
|---|---|---|
| 位置 | マクロ、安定 | 具体的かつ柔軟 |
| 目的 | 組織形成の設計、ルールの策定、意思決定メカニズムの定義 | 組織の効率を向上させ、ビジネス目標を達成する |
| 本体 | 取締役会 | 管理 |
組織ガバナンスとプロジェクト ガバナンス
また、組織ガバナンスとプロジェクトガバナンスの違いと関連性も理解する必要があります。組織ガバナンスは、組織全体の指示、サポート、監督、および制御のための高レベルのフレームワークです。プロジェクト ガバナンスは、組織がプロジェクトに対して確立する、指示、サポート、監督、および制御のための高レベルのフレームワークです。プロジェクトのガバナンスはプロジェクト運営委員会によって実行されます。プロジェクト運営委員会は、プロジェクトの最高意思決定機関として、プロジェクトの主要なステークホルダーのハイレベル代表で構成されており、当社の取締役会に相当します。
プロジェクトガバナンスとプロジェクト管理
プロジェクトガバナンスは組織ガバナンスとプロジェクト管理の架け橋であり、プロジェクトマネージャーやプロジェクト管理チームはプロジェクトガバナンスの枠組みに基づいてプロジェクト管理業務を遂行しなければなりません。プロジェクトガバナンスとは、プロジェクトマネージャーが対処できない、または不便なプロジェクトの「政治的」問題（ステークホルダー間の利益相反など）を分離し、プロジェクト運営委員会に引き渡し、プロジェクトマネージャーが集中できるようにすることです。プロジェクト自体の管理。
プロジェクト ガバナンスのレベルはプロジェクト管理のレベルよりも高く、プロジェクトの高レベルの意思決定メカニズムです。プロジェクト ガバナンスの役割には次のものが含まれますが、これらに限定されません。
- プロジェクトの方向性に関するガイダンスを提供する
- 高レベルの外部サポートを提供する
- プロジェクト管理業務の監督
- プロジェクト所有者の変更やプロジェクトの終了などの主要な問題について意思決定を行う
例えば、企業におけるプロジェクトポートフォリオ管理やプログラム管理の仕組み、プロジェクトマネージャーの資格や昇進規定、PMOの権限や責任の定義、プロジェクトの設立基準やレビュープロセスなどはすべてプロジェクトガバナンスに属しますが、プロジェクトの企画・立案はプロジェクトガバナンスに属します。コストや品質などの目標の実現は、プロジェクト管理のカテゴリに属します。
企業文化
企業文化には次のような低位から高位までの 3 つのレベルがあります。
- 素材レイヤー：企業イメージ、ロゴ、作業環境など
- 制度層: 企業のプロセス、システム、人間関係。
- コンセプト層：企業の伝統、追求、価値観。
企業文化 企業の魂である優れた企業文化は、従業員の使命感を刺激し、帰属意識を凝縮し、責任感を強化し、名誉心を与え、達成感を実現します。企業文化は世代から世代へと受け継がれ、企業に独特の個性と特徴を持たせ、企業の経営理念を体現し、企業のブランド評判と独自の競争力を構成します。
戦略
プロジェクトは戦略実装の担い手であり、この位置付けにより、プロジェクトが組織の開発戦略に役立つ必要があることが決まります。プロジェクトと戦略の関係は、次の4つの側面から理解できます。
投資決定
組織開発戦略は組織開発の方向性を決定し、どのプロジェクトを実行する必要があるか、どのプロジェクトを実行できるか、どのプロジェクトを実行できないかも決定します。エネルギーの集中、資源の集中が必要であり、ある分野を深く育てることによって初めて能力が蓄積され、競争優位性が得られます。数多くのプロジェクトの機会に直面して、私たちは誘惑に耐え、組織の発展戦略に従って毅然として決断を下さなければなりません。
リソースの割り当て
異なるプロジェクトは企業の発展戦略にとって異なる意味を持っているため、組織がこのプロジェクトに投資することを選択した場合でも、科学的にリソースを割り当て、投資利益を最大化するという目標を達成するために、プロジェクトの優先順位を客観的に分析する必要があります。
戦略的提携
プロジェクトのライフサイクルにおいては、さまざまな外部環境や社内連携の影響により、プロジェクト計画は常に調整、変更される必要があります。計画がどのように変更されたとしても、プロジェクトと組織開発戦略との整合性を常に確保する必要があります。
戦略的価値
組織は、組織の開発戦略に対するプロジェクトの価値と貢献を継続的に評価する必要があります。これは、市場シェアや財務指標だけでなく、人材育成、効率向上、技術的進歩、モデルの革新、品質向上への環境への貢献、および環境への貢献にも反映されます。ブランド価値。
企業内のソフトウェアとハードウェアの状況
企業が所有する職場、設備、ツールなどはハードウェア条件に属し、情報システム、知識、経験、手法、工芸品などはソフトウェア条件に属し、計画、実装に直接的または間接的に影響を与えます。そしてプロジェクトの成功さえも。
たとえば、当社はハイエンドチップを製造するためのリソグラフィーマシンを持たないため、他社の管理下にあり、ハイエンドチップに依存する多くの製品開発プロジェクトは停滞または暗礁に乗り上げています。グループはアジア最大の大型自走カッターサクション船「天吉」を所有し、浚渫プロジェクトで才能を発揮し、国際市場では無敵でした。
4. プロジェクトが置かれているビジネス環境
プロジェクトが置かれているビジネス環境には、職業、産業、経済、社会、自然などのさまざまな側面が含まれます。
- プロフェッショナル: 多くの場合、チームが信頼できる利点を指します。たとえば、チームはビッグ データ アルゴリズム、AR、VR、人工知能などに焦点を当て、豊富な経験や独自のテクノロジーに依存してコアの競争力を構築しています。
- 業界: 金融、製薬、自動車業界への人工知能の応用など、複数のプロジェクトを伴う専門的なアプリケーション分野。
- 経済: 国内経済、貿易、金融、サプライチェーン、競争関係を含みます。
- 自然: 交通状況、気候、衛生状態などを含む。
セクション II: 原則
1. システムの相互作用を認識して応答する
プロジェクトは常に、複数の要因から構成される複雑で動的かつ有機的なシステム内にあり、業界の要因がプロジェクトに与える影響を分離することは困難です。さまざまな要因が相互作用し、影響を及ぼします。
- プロジェクトチームは、次の 3 つのキーワードを含む体系的な思考を持たなければなりません。
- コラボレーション：多職種、多部門、多組織による多協働体制を推進します。
- バランス: 要素間のロジックを明確にし、テーマ間の関係のバランスをとります。
- 効率: システムを生き物として扱い、継続的に最適化および進化し、システムの効率を向上させます。
これら 3 つのキーワードをマスターすると、プロジェクト チームが正しい判断を継続的に行い、不測の事態を減らし、目標を実行可能な方法や手順に変え、逸脱や間違いを時間内に発見して修正できるようになります。
システム思考を実現する一般的な方法は、モデリングと演繹です。例えば、サッカーの試合では、コーチは試合前に戦術ボードを使って、試合中の敵とこちらのフォーメーションや戦術を選手に説明し、どうすれば守備を安定させることができるかなど、さまざまな状況を推測します。相手がハイポジションプレスをしてきた場合、その解決策、チャンスをどう見つけるか。別の例として、湾岸戦争中、国連軍は戦争モデルを構築し、さまざまな戦闘計画を導き出し、起こり得るさまざまな状況をシミュレーションしました。
2. 複雑さを活用する
プロジェクトの複雑さは受け入れなければなりませんが、その複雑さの理由には次の 3 つの側面が含まれます。
- システムの動作: プロジェクトには専門職、人員、設備、情報などの多数の要素が必要であり、それらは相互に依存し、影響し合っています。
- 人間の行動: さまざまな組織、さまざまな部門、さまざまな専門的背景を持つ人々の相互作用。
- 不確実性: プロジェクトの開発傾向やさまざまな要素の変化には未知の領域が存在し、十分に理解されておらず、予測することもできません。
これら 3 つの要素の相互作用により、プロジェクトの複雑さが指数関数的に増加します。
複雑さを乗り越える方法
「変化の受け入れ」「マネジメントの知識」「継続的な学習」**の3つの側面からスタートし、複雑なプロジェクトを管理する能力を態度、認知、行動習慣の面で継続的に向上させ、徐々に自分自身の習慣を形成していきます。経営思考と経営モデル。
たとえば、アジャイル開発は小規模かつローカルな実践から始まり、図に示すように開発と成熟を続け、さまざまなニーズやシナリオに対応する比較的完全で体系的なアジャイル企業文化を形成します。
プロジェクトの知識を管理する
プロジェクトのナレッジの管理とは、プロジェクトの目標を達成し、組織の学習を支援するために、既存のナレッジを使用し、新しいナレッジを生成するプロセスを指します。
下図に示すように、知識は形式知と暗黙知に分けられます。編集・表現が容易な知識は形式知に属します。例えば、言葉、絵、数字、表などで表現でき、共有・普及が容易な知識です。編集や表現ができない知識とは、人の経験や勘、洞察力などの暗黙知です。
ナレッジマネジメントのPSCAサイクル
PSCAサイクルの意味は、図に示すように、知識管理を知識の生成（Produce）、知識の蓄積（Stockpile）、知識の交換（Communication）、知識の適用（Application）の4つのプロセスに分けることです。
知識の生成（プロデュース）
知識の生成とは、知識の獲得と創造を指します。知識の獲得とは、既存の知識を蓄積して形式知とすることを指し、知識の創造とは、具体的な業務や業務を遂行する上で知識を要約し創造することを指します。
知識の蓄積（備蓄）
断片的なデータや情報は知識とは言えず、整理されて初めて知識と言えます。
例えば、本を読むとき、整理せずにざっと目を通すだけで、メモを取ったり、マインドマップを描くなどして著者の考えを推敲して考え、著者の考えと私たちの既存の知識を突き合わせて融合させたり、再構成して表現し直すと、本の内容はすぐに忘れられてしまいますし、本の知識は蓄積されなければ自分の知識になりません。
組織は、次のようにさまざまな方法でさまざまな形の知識を蓄積します。
- 形式知の蓄積：「知識ベース」を構築し、維持・運用し続ける。
- 暗黙知の蓄積：共有、実演、観察、師弟を通じて暗黙知を失わないようにする一方で、暗黙知による人材の流出を減らすことも必要である。
知識交換（コミュニケーション）
知識交換とは、さまざまな種類の知識に対するさまざまな主題のニーズを満たすために、直接的または間接的な手段を介した知識の伝達と共有を指します。
すべての知識労働者は、真実がますます明確になるように、オープンな心で知識を交換し、議論する必要があります。
知識の応用（アプリケーション）
知識は使わなければあなたのものではありません。
たとえば、私たちは長年英語を学習し、多くの文法を学び、数え切れないほどの単語を覚えてきましたが、まだ自分の英語レベルに満足していません。
3. 適応性と回復力を大切にする
適応性を受け入れる
VUCA の時代では、環境は変化しやすく、要件は未知数ですが、適応性を受け入れ、プロジェクトの回復力を構築することによってのみ、ツバメのように身軽になり、素早く動き回り、複雑で変化しやすい背景の下でプロジェクトを管理し、成功を収める。
このような背景のもとに生まれたアジャイルは、単なるプロジェクト開発手法ではなく、プロジェクトの適応性を高めるための考え方でもあります。アジャイル開発の一般的なフレームワークには、スクラム、エクストリーム プログラミング (XP)、カンバン (Kanban)、リーンなどが含まれます。その中でも、世界中のチームの 50% 以上がスクラム フレームワークを使用しています。
スクラムという言葉は、スクリメージの儀式であるラグビーのゲームに由来しており、チームが同じ方向を向いて並んで戦う必要性を表しています。フレームワークにおけるSprintはスプリントと訳されており、選択サイクルが非常に短く、スプリントの方がより良い適応力や変化への対応力が得られるという意味で使われます。
アジャイルは分散化を重視し、それについて話すことを避けます。チーム全員の可能性と知恵を刺激し、民主主義の精神を促進し、チームメンバーが異なる意見に出会った場合には挙手で投票する必要があります。
従来のプロジェクトシナリオでは、範囲と進捗が基本的に変わらないという前提の下で、コストは最適であり、プロジェクトの欠陥はコストの無駄であることを強調します。
アジャイル シナリオでは、ユーザーに価値を生み出さないアクティビティは無駄です。Eric Ries (エリック・リース) は、著書「The Lean Startup」(リーン・スタートアップ) の中で、革新的な製品を作る場合、顧客が誰であるか、顧客のニーズが不明であり、急速に変化する場合、そのような不確実な環境では困難になると述べています。 、製品の機能、作業の優先順位、技術的なルートについて議論するのは本当に無駄です。
フィードバック サイクル全体を短縮して、より早くユーザーの声を聞いてみてはいかがでしょうか? リーン起業家精神の核となる考え方は、製品コンセプトが決まったら、製品の開発に急いで多くのリソースを投資すべきではなく、製品を開発する必要があるということです。最初に実行可能な最小限の製品 (Minimum Viable Product、MVP)、MVP を初期の顧客に提供してコンセプトの価値を検証し、その後、初期の顧客からのフィードバックに基づいて製品コンセプトを調整します。MVP は必ずしも実際の製品である必要はありませんが、最小限の労力と最速の速度で「構築、測定、認識」のフィードバック ループを完了するテスト製品です。製品コンセプトを検証するプロセス中、チームは複数の検証サイクルを経ます。
たとえば、近年、知識に対する支払いが非常に人気になっています。Get、Chaos University、Fandeng Reading Club などのプラットフォームは、知識に対する支払いの新たな高みを継続的に打ち立てています。オンライン コースには数十万人の有料ユーザーがおり、数十人のユーザーが支払いを行っています。単一製品の収益が数百万元になる人も珍しくありません。これには多くの人々の目が飛びつき、知識にお金を払うという路線で反撃したいと思う人も多いでしょう。では、まず 100 セッションのコースを計画し、次にチームを編成してアプリの録音、編集、パッケージ化、開発を行い、それから広告に投入する必要がありますか? 費用と時間はどれくらいかかりますか?あなたはそれを作ります、誰かがそれを作ります あなたの講義を聞くためにお金を払う気はありますか? これらは不明です! このように資金を使い果たし、製品が作られる前に死んでしまったスタートアップがどれだけあるでしょうか。
では、どうすればよいでしょうか? まず、10 分間のコース内容を用意します。コースの特徴を反映できれば、綿密に作成する必要はありません。その後、興味のある人を WeChat のサークルの WeChat グループに呼び出します。友達と約束をしてグループで話すことができます。次に、嵐のような苦情に直面する心の準備をしておく必要があります! みんなのフィードバックによると、多くの人がお金を払って聞いてくれるまで、常に製品のポジショニングを修正し、試行錯誤を繰り返し、適切なコンテンツを見つけては放置しなければなりません。あなたのクラスへ。どれくらいの費用がかかり、どれくらいのリスクがあるのでしょうか? 起業は手の届かないことではありませんね。
MVP の原則は、最小限のリソースと最短の時間を使って実験し、初期のユーザーからフィードバックを得て、製品の価値を検証することです。
一般的に使用される MVP メソッドは次のとおりです。
ビデオ: 製品開発前に、製品を紹介するビデオを作成できます。有名な Dropbox は、製品の主要機能を紹介するビデオを通じて、登録ユーザーを一夜にして 5,000 人から 75,000 人に増加させました。実際、Dropbox はこの製品の開発を開始する前に、これらの機能がユーザーに好まれているとコメントしていました。
シミュレーション: 製品を開発する前に、企業は製品の機能を手動でシミュレーションします。たとえば、米国最大のオンライン靴店であるザッポスの創設者であるニックは、人々がオンラインで靴を購入する必要があるかどうかを知りたかったのですが、彼は電子商取引プラットフォームを開発しませんでしたが、さまざまなショッピング モールを訪問して、靴の写真を撮ってオンラインに掲載します。誰かが注文すると、店に買いに行き、ユーザーに送ります。在庫のプレッシャーや開発コストがありません。彼の意見では、ビジネス ロジックの確立はシステムの立ち上げよりもはるかに重要です。
クラウドファンディング: 企業は製品を開発する前にクラウドファンディングを開始し、クラウドファンディングに基づいて製品に対する人々の態度を判断します。私の国の有名な空気清浄機ブランド「Three Dads」は、JD.com でクラウドファンディングを開始し、すぐに十分な開発資金を集めただけでなく、製品の初期ユーザーも見つけました。
プロトタイプ: 製品の開発とは、未検証の要件をチームに引き渡すことではなく、まず製品のプロトタイプ (Prototype) をユーザーにデモンストレーションすることです。これらのプロトタイプは、手描き、粘土、または紙を貼り付けたものであり、偽物ではありますが、非常に直感的で鮮明であり、多くの曖昧な説明よりもはるかに価値があります。
先行販売：商品開発前に先行販売ページを立ち上げ、先行販売数量が合意された基準に達した場合、企業は商品開発を開始できます;企業は商品が本当に人気があるかどうかを確認するのが簡単であるだけでなく、費用はかかりません。
インタビュー：コンサルタントはクライアント組織の様々な担当者との接触や対話を通じて、クライアント組織の主観的な重要な課題を得ることができ、インタビュー対象者もプロジェクトへの貢献を実感することができる。面接プロセスは、創意工夫と思慮深い構築を必要とする時間のかかるプロセスであり、面接の前に、資料の準備や思想的な準備など、十分な準備を行う必要があります。
回復力を受け入れる
プロジェクトがリスクにさらされたり中断されたりした場合、プロジェクト チーム全体が以下を維持できます。
- 状態を維持する能力
- すぐに回復する能力
- 将来の不確実性に対処する能力が向上する
これら 3 つの能力について一般的に説明されるのは、プロジェクトが堅実で耐久性があり、それが投げられたということです。
4. 環境に応じた作物を作る
事業を行う場合には、環境が事業に与える影響、いわゆる状況の把握と現地の状況に応じた対策を十分に考慮しなければなりません。最初のステップは、環境に応じてプロジェクトの目標を設定することです。考慮する必要がある環境要因には次のものがあります。
- 組織ガバナンスモデル
- 遵守しなければならないプロセス体系
- 代替プロジェクト開発方法
- 参考にできるテンプレートや素材
- プロジェクトのライフサイクル
目標を設定するときは、環境要因を考慮するだけでなく、次のことも考慮する必要があります。
- 環境固有の目標に適応する
- 利害関係者と関連する複雑さ
- 統一性と個性の組み合わせ
- チームメンバーは重要な意思決定に参加します
- トリミングは継続的かつ反復的です
- 目標の有効性を継続的に評価する
環境に応じて目標を設定し、以下の達成に努めます。
- 価値の最大化
- リソースをより効率的に使用する
- イノベーション、効率、生産性の向上
- 複数の分野を効果的に統合する
- 共有された教訓
- 組織の方法論を改善する
5. リスク対応を最適化する
リスクは、否定的な脅威や肯定的な機会などの不確実性から生じます。リスクには、確率と影響という 2 つの属性があります。リスク管理は、ポジティブな機会の確率と影響を高め、ネガティブな脅威の確率と影響を軽減するために、リスクを特定、分析し、対応するプロセスです。
リスクエクスポージャー
リスクエクスポージャーとは、保護されていないリスクのことであり、「リスクエクスポージャー」とも呼ばれ、リスクに対して予防策が講じられなかった場合に損失が発生する可能性のある部分を指します。
たとえば、プロジェクトが顧客の要件に従って納品された場合でも、プロジェクトの最終支払いの 10% がさまざまな理由により回収できない可能性があるため、このプロジェクトの場合は 10% のリスクが存在します。
既知のリスクのリスクエクスポージャはゼロからリスクによって引き起こされる最大損失まで、未知のリスクのリスクエクスポージャはゼロから無限大までです。
個々のプロジェクトのリスクとプロジェクト全体のリスク
リスク管理の専門家であるデイビッド・ヒルソン博士は、個々のプロジェクトのリスクのみに注目するとプロジェクト全体のリスクが無視され、プロジェクトの局所的なリスクのみに注目してプロジェクト全体のリスクが無視され、プロジェクトの短期的なリスクのみに注目してプロジェクトの長期的なリスクが無視されると考えています。期間リスク ; プロジェクトの戦略的リスクを無視して、プロジェクトの戦術的リスクのみに焦点を当てることは、リスク近視眼の現れです。
たとえば、インターネット金融の P2P プロジェクトの場合、コードのバグ、システム セキュリティの脆弱性、サーバーのダウンタイム、プロジェクト チームの主力の辞任はすべて個別のプロジェクト リスクですが、P2P ビジネスを制限する国家政策はプロジェクト全体のリスクです。
イベント以外のリスク
非イベントリスクには、変動リスクと曖昧さリスクが含まれます。
変動リスク
プロジェクトが依存する重要な条件や制約に異常な変化があった場合、よく「ブラックスワン現象」や「草の根の反撃」と呼ばれる不合理な状況など、変動リスクが生じます。
モンテカルロ手法などのシミュレーション手法を使用して定量的なリスク分析を実行し、変動リスクの確率と影響を評価できます。
曖昧さのリスク
あいまいさのリスクとは、人々が将来何が起こるかわからないことを意味します。知識が不十分であると、チームがプロジェクトの目標を達成する能力に影響を与える可能性があります。たとえば、技術開発の方向性や速度、将来の政策や規制の変更、急速に変化するユーザーのニーズなどを予測できなくなる可能性があります。チームは、反復開発、増分開発、適応型 (アジャイル) 開発モデルを採用して、そのようなリスクへの適応性を向上させることができます。
リスクに対するステークホルダーの態度
ステークホルダーが示すリスクに対する態度は、通常、リスク選好度とリスク許容度に関連しています。リスク選好とは、ステークホルダーが期待リターンに対する不確実性をどの程度負担するかという主観的な意欲を指し、リスク許容度はステークホルダーが負担できるリスクの程度や量を指し、客観的な能力に属します。
通常、リスクに対する利害関係者の態度を表すためにリスク閾値を使用します。つまり、リスクが閾値よりも低い場合、利害関係者はリスクを受け入れ、リスクが閾値よりも高い場合、利害関係者はリスクを拒否します。
統合リスク管理
統合リスク管理とは、プロジェクト、プログラム セット、プロジェクト ポートフォリオ、およびプロジェクト組織における複数レベルの全体的なリスク管理を指します。一部のリスク管理はプロジェクト マネージャーに委任する必要がありますが、一部のリスクはプロジェクト管理の範囲を超えているか、複数のプロジェクトに影響するため、適切な上級管理者にエスカレーションする必要があります。企業はプロジェクト管理のあらゆるレベルでリスク管理を実施し、有機的で動的なリスク管理システムを形成する必要があります。
リスクを積極的に管理する
リスクに直面したとき、急いでも無駄であることが多く、後悔しても遅すぎるのです。チームが事前にリスクを特定し、リスクの確率と影響を評価し、合理的に仕事を分割し、各個人に責任を割り当て、リスク対応戦略と方法を事前に計画していて初めて、危機の際にチームは冷静さを保つことができます。リスクを積極的に管理するこの意識と習慣は、チームが環境に適応し、プロジェクトを完了するのに役立ちます。
チームがリスクを積極的に管理する際には、次のことを推奨します。
- 早期の開始と継続的なリスクの特定
- ステークホルダーのリスク閾値を評価し、管理戦略を決定する
- 定性的なリスク分析を実行して優先順位を決定する
- 定量的なリスク分析を実行し、ストップロスメカニズムと準備金を設定します
- トリガーメカニズムを研究し、早期警告メカニズムを設定する
- 脅威と機会のバランスをとり、リスクポートフォリオを積極的に構成する
- リスク対応方法を計画し、リスクを管理する
- リスクを追跡し、対応計画を動的に調整する
- 対応策の有効性を評価し、二次リスクを防止
リスクを特定する
リスクの特定は、どのリスクがプロジェクトに影響を与える可能性があるかを判断し、その特徴を文書化するプロセスです。このプロセスの主な目的は、既存のリスクを文書化し、プロジェクト チームが将来の出来事を予測するための知識とスキルを構築することです。リスクを特定するためのツールと手法を以下に示します。
ブレーンストーミング
リスク特定に関わるグループメンバーは、通常の和気藹々とした自由な雰囲気の中で会議形式で議論や議論を行っており、会議ではグループメンバーが日常を打ち破り、前向きに考え、自由に発言し、自分の意見を存分に表現することができます。グループのメンバーは互いに刺激し合い、軽々しく判断することはなく、できるだけ多くのアイデアを得るために、一見ばかばかしいアイデアさえも奨励します。
デルフィ法
Delphi 法は、専門家規定手順調査法としても知られています。この方法は、調査員が定められた手順に従って調査票を作成し、専門家グループの構成員に手紙で意見を出し、専門家グループの構成員が匿名（手紙）で意見を提出する方法です。数回にわたる協議とフィードバックを経て、専門家グループのメンバーの意見は徐々に集約される傾向にあり、最終的に精度の高い総合的な判断結果が得られました。
デルフィ法の特徴は、専門家同士が一度も会わず、他の専門家が誰であるかを知らないため、専門家個人の偏見による他の専門家の誤った判断を極力回避できることである。
根本原因分析 (根本原因分析)
根本原因分析は、問題の症状だけに焦点を当てるのではなく、問題の根本原因を徐々に特定して修正するために使用される、問題解決への構造化されたアプローチです。根本原因分析は、問題の原因の特定と分析、問題の解決策の特定、および問題の予防策の開発を含む体系的な問題処理プロセスです。
チェックリスト分析
プロジェクトにおける人員、設備設備、材料、ワーク、作業、管理、組織対策におけるリスクを発見するために、事前に検査対象を分解し、大きなシステムをいくつかの小さなサブシステムに分割して検査を行います。項目リストの項目は一つ一つチェックされ、漏れがないようチェックされます。このフォームはチェックリストと呼ばれ、チェックリストとも呼ばれます。チェックリストを使用してプロジェクトのリスクを棚卸しする方法をチェックリスト分析と呼びます。
what-if 分析
すべてのプロジェクトとその計画は、一連の仮定に基づいて構築されます。仮説分析とは、プロジェクトにおける仮定の妥当性をテストし、不正確、不安定、矛盾、または不完全な仮定によって引き起こされるプロジェクトのリスクを特定することです。仮定分析の手順は次のとおりです。
- 私たちが恐れている結果をもたらすかもしれない仮説を思いつく
- 仮説をテストする、確認する、または仮説を除外する
- 除外された場合は 2 番目の仮説を提案し、確認された場合は次のレベルのより具体的な仮説を提案します。
- 検証を通じて徐々に範囲を狭め、問題の真の原因を突き止める
図は「オンラインライブ授業凍結」問題の仮説分析プロセスを示したものです。この問題の分析には合計の仮定があります: 設定 1、教師側の問題、ほとんどの生徒がビデオがスムーズであるとフィードバックしたため、この項目は除外されます: 設定 2、生徒側の問題、他のビデオ同じ生徒が見たものはスムーズなので、このアイテムは除外されます; 販売 3、サーバー側の問題。これら 3 つの仮定のうち、最初の 2 つの仮定は除外されているため、問題は 3 番目の仮定からのみ発生すると考えられます。
3 番目の仮説には 3 つのサブ仮定が含まれています: サブ仮定 1、サーバー ソフトウェアの問題、ソフトウェアはテストされすぎているため、この項目は除外されます; サブ仮定 2、サーバー ハードウェアの問題、ハードウェアはすでに最高レベルです。 -line であるため除外されます。サブ仮定 3 、帯域幅負荷の問題、および一部の地域での負荷の不均衡は、ライブ ネットワーク クラス カードの問題の原因であるはずです。
特性要因図
「特性要因図」は「原因と結果図」とも呼ばれ、問題の「根本原因」を発見するための方法です。見た目は魚の骨に似ており、その特徴はシンプル、実用的、奥深く直感的です。プロジェクトのリスク、問題、欠陥 (つまり、結果) には、「魚の頭」のマークが付けられます。原因が相互にどのように影響し合うかを説明するために、問題の考えられる原因を発生順にリストします。
システムまたはプロセスのフロー図 ( システム フローチャート )
フローチャートは、システムの物理モデルを表すための従来のツールです。その基本的な考え方は、システム内の各コンポーネント (プログラム、ファイル、データベース、テーブル、手動プロセスなど) をグラフィック シンボルを使用してブラック ボックスの形で記述し、さまざまなコンポーネント間の情報の流れを次のように表現することです。図に示されています。
専門家の判断
同様のプロジェクトやビジネス分野の経験を持つ専門家は、リスクを直接特定できます。専門家の判断に頼る場合には、専門家のバイアスに注意する必要があると同時に、専門家の直観にも注意を払う必要があります。
仮定と制約の分析
すべてのプロジェクトとそのプロジェクト管理計画は、一連の仮定 (不確実) に基づいて考案および開発され、一連の制約 (確実) によって制限されます。これらの仮定と制約は、スコープのベンチマークやプロジェクトの見積もりに組み込まれることがよくあります。前提条件と制約の分析を実施することで、前提条件と制約条件の妥当性、およびそれらのどれがプロジェクトのリスクを引き起こす可能性があるかを判断し、不正確、不安定、一貫性のない、または不完全な前提条件から脅威を特定し、機会の創出を通じて脅威を特定できます。プロジェクトまたはプロセスの実行に影響を与える制約を削除します。例えば、制約を適切に緩和した場合、6 人にさらに 2 人追加すると、プロジェクトが完了しないリスクは減少します;)、プロジェクトのリスクが顕在化します。
SWOT分析
SWOT 分析は状況分析としても知られ、1980 年代初頭にサンフランシスコ大学の経営学教授ハインツ ヴァイリッヒによって提案されました。
SW（分析手法とは、プロジェクトの現実をより客観的かつ正確に分析・検討できる手法です。このうち、Sは強み、Wは弱みを表し、内部要因に属します。Oは機会、Tは脅威を表します） （脅威）、これは外部要因です。
個々のプロジェクトのリスクとプロジェクト全体のリスク
リマインダー リストは、個々のプロジェクト リスクを引き起こす可能性があり、プロジェクト全体のリスクの原因となる可能性があるリスク カテゴリの事前設定されたリストです。即時チェックリストは、プロジェクト チームがリスク特定手法を採用する際のアイデアを開発するのに役立ちます。以下の図に示すように、リスク ブレークダウン ストラクチャ (RBS) の下部にあるリスク カテゴリをリマインダー リストとして使用して、個々のプロジェクトのリスクを特定できます。
戦略的枠組み
「PESTLE」（政治経済、社会、技術、法律、環境）、「TECOP」（技術、環境、商業、運用、政治）、または「VUCA」など、プロジェクト全体のリスクの原因を特定するには、特定の共通の戦略的枠組みがより適切です。 「（変動性、不確実性、複雑性、曖昧性）。
階層チャート（バブルチャート）
図に示すように、バブル チャートでは、各リスクをバブルとして描画し、X 軸の値、Y 軸の値、バブルのサイズを使用してリスクの 3 つのパラメーターを表します。 。このうち、x 軸は監視可能性、y 軸は近接度を表し、影響度はバブルの大きさで表されます。
緊急性、待ち時間、管理性、制御性、接続性、影響力、親密さなどの指標を選択することもできます。
セクション 3: タスク
1. プロジェクトコンプライアンスの計画と管理
プロジェクトのコンプライアンス環境を計画および管理するには 4 つのステップがあります。
- コンプライアンス要件の確認: 安全と健康、環境保護、品質基準、業界規制など。
- コンプライアンス違反の結果を分析します。コンプライアンスのカテゴリを区別し、潜在的な脅威を特定します。
- 必要な方法と行動を決定する: 事前に安全策と規制を策定します。
- コンプライアンスの度合いの測定: 監査とレビューによる継続的なレビューと継続的な改善。
プロジェクト管理計画とプロジェクト文書
答えは間違いなく「ノー」です。プロジェクト管理計画とプロジェクト計画を混同すべきではありません。広義の「プロジェクト計画」とは、プロジェクト管理計画やプロジェクト文書を含む総称であり、狭義の「プロジェクト計画」とは、具体的にはプロジェクト文書上の「実施計画」を指します。
表にあるように、プロジェクト管理計画書には「スケジュール管理計画書」があり、プロジェクトファイルには「プロジェクトスケジュール」が存在します。コストと品質の間に同様の対応関係があることを見つけるのは難しくありません。
PMP 試験問題では、「プロジェクト管理計画」と「プロジェクト計画」という 2 つの名称の使用が厳密ではない場合があるため、問題の意味を注意深く分析し、文脈に応じて判断する必要があることに注意してください。質問は「計画」または「プロジェクト計画」について言及しています。
プロジェクト管理計画
- ルールの手順
プロジェクト管理計画において、プロジェクトコスト管理計画はプロジェクト予算を指すものではなく、「プロジェクトにいくらかかるか」といった情報はありませんが、予算作成単位（米ドルなど）の正確性を指定します。 、ユーロ、人民元など）（10,000元または元まで正確な、など）、予算を作成するための方法と根拠（たとえば、どの会計基準を参照するか、どの関連する社内規制を実施するか、どの国家および業界の規範を参照するかなど）フォローする）。
同様に、スケジュール管理計画にはプロジェクトの期間はありません。スケジュール管理計画では、進捗単位（日、週）、スケジュール計画方法（クリティカルパス方式、クリティカルチェーン方式）、スケジュール計画ツール（バーダイアグラム、ネットワークダイアグラム）を定義します。
「xx 管理計画」は、計画単位、ルール、プロセス、方法、ツールなどを定義するルール プログラムであり、プロジェクトの特定の情報やデータは含まれていないことがわかります。
- プロジェクトのベンチマーク
プロジェクトのパフォーマンスの良し悪しをどのように評価するか? たとえば、スケジュールの遅れをどのように定義するか? コスト超過をどのように定義するか? この測定基準がプロジェクトのベンチマークです。プロジェクトマネージャーは、チームを率いてプロジェクトの期間、コスト、作業内容を評価し、レビューとプロジェクトスポンサーと組織の上級管理職とのコミュニケーションを経て確認し、スコープベンチマーク、進捗ベンチマーク、コストベンチマークを形成します。これらは、プロジェクト管理のパフォーマンスを測定する 3 つのベンチマークです。
ベンチマークを決定した後に修正することはできますか?
もちろん、答えは「はい」です!しかし、ベースの変更はファイルの更新よりもはるかに深刻です。計画を立てるとき、私たちは通常、いわゆる予備のための余地を残しておきます。たとえば、コストを 45 万元と見積もって予算を 50 万元に設定した場合、追加の 5 万元がコスト予備費となります。プロジェクトは 80 日で完了できると見積もっていますが、報告されている工期は 90 日で、余分な 10 日は進捗予備です。したがって、何らかの需要の変化やリスクに遭遇したとき、これらの準備金はしばらくの間抵抗し、緩衝材として機能することができるため、問題の最初の兆候が現れたときにベンチマークを変更する必要がなくなります。
変更がベースラインに影響を与える場合は、ベースラインを修正する必要があります。たとえば、顧客が増やしたいと考えている新しい需要は「大きすぎます」。この需要を満たすには、残りの時間が足りず、さらに 30 日かかります。この場合、新しい進捗ベースラインが必要です。 。ベースラインの更新はプロジェクトの変更管理委員会 (CCB) によって承認される必要があります。また、変更がベースラインに影響しない場合、プロジェクト マネージャーは CCB を経由せずに決定を下すことができます。これらの変更で更新する必要があるのは、図に示すように、プロジェクト ファイル内の実装計画です。
プロジェクトのベンチマークに「品質ベンチマーク」がないのはなぜですか? 品質は重要ではないのでしょうか?
もちろんそうではありません。品質は重要ではないわけではありませんが、重要すぎるのです!品質基準はプロジェクト レベルから企業基準、業界基準、さらには国家基準にまで高まっています。特定のプロジェクトだけでなく、この業界のすべてのプロジェクトの品質は、統一された基準に従って管理され、受け入れられる必要があります。
プロジェクトファイル
プロジェクトの具体的な情報やデータはどこにありますか? プロジェクトファイル内。プロジェクト文書は、実施計画と情報文書に分かれています。実施計画では、スケジュールはプロジェクトの期間を説明するために使用され、コスト見積もりはプロジェクトのコストを説明するために使用されます。データ ファイルには、問題ログ、変更ログ、通信記録などのさまざまなログや記録ファイルが含まれます。
プロジェクト管理計画書とプロジェクト文書の役割は異なります。プロジェクト管理計画書はルールや手順を定義するものであり、一夜にして変更することはできませんが、プロジェクト文書は具体的な実施計画およびデータファイルであり、大量のプロジェクトが含まれます。詳細とデータ。プロジェクトの不確実性により、要件、範囲、スケジュール、コストなどが今後も変化し続けることが判明するため、これらの文書は頻繁に更新および保守する必要があります。
以下の表に示すように、プロジェクト管理計画書とプロジェクト文書は改訂頻度が異なるだけでなく、改訂プロセスも異なります。プロジェクト管理計画のベースライン更新は全体的な変更管理手順を経る必要があり、CCB の承認を受ける必要があります。一方、プロジェクト文書の実装計画の更新も全体的な変更管理手順を経る必要がありますが、必要なのは CCB のみです。プロジェクトマネージャーの承認。プロジェクト ファイル内のデータ ファイル (問題ログ、通信記録など) については、プロジェクト チームのメンバーがいつでも変更管理手順を経ずに記録します。
マイルストーン計画とマイルストーンチェックリスト
マイルストーンは、プロジェクト内の重要なポイントまたはイベントです。マイルストーンは、同じ構造と属性を持つ通常のスケジュール活動に似ていますが、マイルストーンは、たとえばソフトウェア プロジェクト、署名、承認、リリースなどの象徴的な時点を表すため、マイルストーンの期間はほぼゼロです。画期的なイベント。
マイルストーン計画とは、図に示すように、プロジェクト全体の進捗を管理するために、時間軸上にマイルストーン イベントを順番にマークすることを指します。
マイルストーン計画の役割
- 計画: 段階的な目標に分割します。
- 制御: 各段階での目標の実現を制御するための必須の制約。
- コミュニケーション: 経営陣やステークホルダーとの良好なコミュニケーションを促進します。
- 責任: プロジェクトに関与するすべての当事者の責任と義務を明確に規定します。
- レポート: 簡潔、鮮やか、人気があり、実用的です。
マイルストーン チェックリストとは、プロジェクトのすべてのマイルストーンをリストし、各マイルストーンが必須（契約の要求に従って）であるか、オプション（過去の経験に基づいて決定される）であるかを示すことを指します。
プロジェクトキックオフミーティングとプロジェクトキックオフミーティング
プロジェクト開始会議 (開始会議)
プロジェクト憲章を策定する過程で、プロジェクト スポンサーは主要な関係者を招集してプロジェクトのキックオフ ミーティングに参加させ、主に次のタスクを実行します。
- プロジェクト憲章を発行する
- プロジェクトマネージャーを任命する
- プロジェクトの正式な開始を発表する
キックオフミーティング
プロジェクト計画が作成されると、プロジェクト マネージャーは主要な関係者を招集してプロジェクトのキックオフ ミーティングに出席し、主に次のタスクを完了します。
- プロジェクト計画の完了を発表
- リソースが計画どおりに配置されていることを確認する
- プロジェクトが実行フェーズに入ったことを発表
プロジェクトが複数のフェーズに分割されている場合、実行を開始する前に、各フェーズでフェーズのキックオフ ミーティングを行う必要があります。プロジェクトのキックオフミーティングは、サッカーの試合におけるミドルサークルでのキックオフに由来しており、試合開始時やゴールが決まるとホイッスルが鳴り、ボールがミドルサークルの外に蹴り出される。サービスを提供する側は「キックオフ!」をマークするため、プロジェクトのキックオフ ミーティングは「プロジェクト キックオフ ミーティング」とも呼ばれます。
プロジェクトキックオフミーティングとプロジェクトキックオフミーティングの違いは下表のとおりです。PMP 試験では、「Kick-Of Meeting」が「プロジェクト開始会議」と誤って翻訳される場合があることに注意してください。そのため、「プロジェクトキックオフミーティング」をご覧になった際には、必ず英語を確認してください。
2. プロジェクトの利点と価値を評価して提供する
プロジェクトの利点と価値を特定する
プロジェクトのメリットと価値を評価して提供するには、次の 3 段階のプロセスがあります。
- プロジェクトの利点と価値を特定する
- プロジェクト利益管理計画の策定
- プロジェクトの価値を追跡および評価する
プロジェクトの利益と価値を特定するには、経済的利益、社会的利益、環境的利益の 3 つの側面から開始する必要があります。これらには、それぞれ有形の利益と無形の利益が含まれます。
たとえば、ビデオ会議の普及により、移動コストと移動時間が削減され、移動による排出量も削減されました。ビデオ会議の利便性により人々の仕事体験は向上しましたが、対面でのコミュニケーション機会の減少により人々の付き合い方も変化し、社会的利益に大きな影響を与える可能性があります。
一方で、ビデオ会議とオフライン会議ではコミュニケーション効率やコミュニケーション効果に差があり、コミュニケーションコストが増加するのか減少するのかも評価する必要があります。
プロジェクト利益管理計画
プロジェクトで期待される利益を達成するために、プロジェクト スポンサーは事前に以下を含むプロジェクト利益管理計画を作成する必要があります。
- プロジェクトの利益目標と組織戦略の調整
- 給付金管理の責任
- メリットを実現するためのタイムライン
- 効果測定指標と測定方法
- リスクと対応
プロジェクト管理者が決定した後、プロジェクト利益管理計画はプロジェクト管理者によって維持され、利益目標の合理性を常に確保するだけでなく、プロジェクトの実際の進捗状況や環境要因の変化に応じて常に更新および修正される必要があります。利益目標が計画どおりに達成されるようにするためでもあります。
3. 外部事業環境の変化による影響の評価
外部ビジネス環境の変化が範囲に及ぼす影響を評価し、対処する手順は次のとおりです。
- 環境の変化を調査する
例えば、動力電池プロジェクトの開発においては、新技術や新素材の登場、新エネルギー車に関する政策の変化、自動車会社の開発戦略や競争状況などに常に注意を払う必要があります。それらはプロジェクトのパフォーマンスに直接影響し、プロジェクトの成否を決定することさえあります。
- 影響を評価して優先順位を付ける
プロジェクト環境の変化はあらゆる側面から起こり、いつでもどこでも起こりますが、その変化にプロジェクトチームが同じエネルギーを注いで対応することは不可能であり、その発生確率によって対応の優先順位が決定されます。
- 変更を提案する
直面しなければならない変化に対して、プロジェクト チームは対応計画を立て、変更提案を正式に提案し、承認後にプロジェクト計画を適時に修正する必要があります。
- 影響の継続的なレビューと評価
チームがプロジェクト環境の変化を評価して対応するとしても、環境変化が動的であることは無視できないため、変更がプロジェクトに与える影響を継続的にレビューおよび評価し、変更の優先順位と対応者を動的に決定する必要があります。調整した。
組織変革の支援
効率と管理を改善するために、組織は戦略的ニーズに応じて、ガバナンスモデル、組織構造、プロセスシステム、組織文化などの変化を求め続けます。
変更は必然的に今後のプロジェクトや進行中のプロジェクトに影響を及ぼします。プロジェクト チームはまず、組織の変更の要件を満たすようにプロジェクト管理モデルとプロジェクト管理計画を動的に調整する必要があります。同時に、実際に発生した問題を積極的にフィードバックして、組織が次のことを行うことができるようにします。変更の効果をタイムリーに検証し、変更計画を調整して最適化します。
セクション IV: パフォーマンス
1. プロジェクト後の評価
プロジェクト評価モデル
プロジェクトのパフォーマンスを評価するために、多くの組織がプロジェクト評価モデルを開発しました。代表的な例としてIPMAの「Excellent Project Management Model」があります。
図に示すように、優れたプロジェクト管理モデルには、3 つの分野、9 つのサブ分野、20 の評価、107 の要素基準が含まれており、多数の事例、プロセス記録、認証文書も含まれています。
図に示すように、優れたプロジェクト管理モデルにおける3つの領域と9つのサブ領域の内容には、人間のプロセスと結果という主な評価指標が含まれています。
プロジェクト後の評価
プロジェクト事後評価とは、プロジェクトの実施プロセス、利益、機能、完了したプロジェクトまたは計画されているプロジェクトへの影響を体系的かつ客観的に分析することを指します。
プロジェクトの事後評価では、プロジェクトの実施プロセス、結果、影響について調査研究と包括的かつ体系的なレビューを実施し、プロジェクトの意思決定時に決定された目標や技術的、経済的、環境的、社会的指標と比較して決定します。プロジェクトの期待された目標が達成されたかどうか プロジェクトまたはプロジェクト計画が合理的かつ効果的であるかどうか、プロジェクトの主な利益指標が実現されているかどうか 分析と評価を通じて成功または失敗の理由を見つけ、経験と教訓を要約するタイムリーかつ効果的な情報フィードバックを通じて、将来の新規プロジェクトの意思決定レベルと管理能力を向上させるための基盤を提供します プロジェクト後の評価は、プロジェクト運営上の問題に対する改善提案も提供し、投資を改善するという目的を達成します効率。
プロジェクト後の評価には次のものが含まれます。
- 客観的評価：プロジェクト目標の達成度
- 実施プロセスの評価：プロセスの合理性と規範性
- 便益評価：財務指標と経済学
- 影響評価: 経済的、社会的、環境的影響
- 持続性評価：持続性と再現性
2. 環境志向の価値提供
プロジェクトが置かれる環境には、組織環境、産業環境、社会環境、自然環境が含まれます。プロジェクトは環境に影響され、プロジェクトも環境に影響を与えます。
したがって、チームはプロジェクトと環境の相互作用を特定して評価し、プロジェクトの計画とモニタリングを通じてプラスの影響を増幅させながらマイナスの影響を軽減する必要があります。
環境影響評価では、プロジェクトが自然環境や社会環境に与える影響が主に注目されますが、例えば、新しい化学プラントのプロジェクトは、水、大気、土壌、固形廃棄物への影響を確認するための環境影響評価に合格する必要があります。 、騒音、光、放射線、地質、生態学など。影響の側面は国内の法律や規制の要件を満たしています。
環境影響評価には、判定機能、予測機能、選択機能、誘導機能が含まれます。
3. プログラムの適応性と回復力
プロジェクトの適応性とは、変化する状況に対応するプロジェクト チームの能力を指します。もちろん、ここでいう環境とは、組織環境、業界環境、市場環境、経済環境、自然環境など多岐にわたります。プロジェクト管理のプロセスでは、プロジェクトと環境の適応性を継続的に評価し、プロジェクトのパフォーマンス指標と環境要因の間の乖離を避けるために逸脱を適時に調整する必要があり、その結果、取り返しのつかない消極的な状況が生じることになります。
外部環境の変化に対処するために、プロジェクトのレジリエンスを向上させることは避けられない選択です。プロジェクト チームの耐干渉能力、自己修復能力、自己学習能力を継続的に向上させることによってのみ、組織は複雑な環境で刻々と変化する機会を把握し、危険なシナリオを回避し、最終的にプロジェクトの目標を達成することができます。
4. 組織プロセス資産
契約の終了と管理上の終了
プロジェクトのクロージングは、目的に応じて契約クロージングと管理クロージングに分けられます。表に示すように、契約のクロージングは調達クロージング、管理クロージングは管理クロージングとも呼ばれ、両者の違いは重要なテスト ポイントとなります。
契約の締結とは、下請け業者やサプライヤーとの納品受領の完了、顧客との納品受領の完了、顧客からの代金回収、下請け業者やサプライヤーへの支払いなど、契約に定められた責任と義務を履行することを指します。
管理上の終了には、すべてのバージョンのプロジェクト計画、プロジェクト文書、学んだ教訓と取得した知識を含む、プロジェクト文書、学んだ教訓の社内ファイリングと報告が必要です。
管理終了でアーカイブおよび報告されたプロジェクト データは、プロジェクト管理オフィス (PMO) によって整理、検査、要約、洗練されます。その中でも、参照価値や共有意義のあるその他のプロジェクトについては、PMO は組織の学習、共有、観察、コミュニケーションを通じて、組織プロセス資産にその価値を発揮させます。