PMBOK、プロジェクトマネジメント/プロジェクトマネジメント

プロジェクト管理協会 (PMI) は、プロジェクト管理の標準的な順序と基準を確立しようとする組織です。

この目的のために、PMI はプロジェクト管理知識の書 (PMBOK) を維持しています。これは、すべてのプロジェクト マネージャーが知っていて適用する必要がある一連のツールと優れた実践方法を確立しています。

他の方法論 (スクラムなどのアジャイル方法論など) とは対照的に、PMBOK は予測プロジェクト管理を指向しています。 PMBOK は、プロジェクトのいくつかのフェーズを直線的に示します (フェーズを一度乗り越えると、そのフェーズには戻りません)。ここでは、ニーズ/解決策、範囲、計画 (実行する各タスクのコストと期間など) が示されます。 ）は初期段階で確立されます（それが予測管理と呼ばれる理由です）。

したがって、PMBOK はプロジェクト管理のより古典的な分野に属すると考えることができます (英国で人気のある補完的な PRINCE2 標準も同様です)。ただし、この事実は、提供されるツールの一部が他のより俊敏で柔軟な方法論と組み合わせて使用できないことを意味するものではありません。

本題に入る前に、PMBOK に従ってプロジェクトの定義と特性を確立する必要があります。

• プロジェクトは問題を解決しようとします (ニーズをカバーします)。
• それは一時的なものです
• それは時間的にユニークであり、同じ状況下では再現できません。
• 不確実性を伴う
• 時間、お金、材料、労力などのリソースを消費します。

プロジェクトには独自のライフサイクルがあり、次のフェーズに分かれています。

• 開始: ニーズが特定され、プロジェクトを実行できるかどうかが尋ねられます。

• 企画:
  • ソリューションはより詳細に開発されます。
  • タスクの定義、カレンダー。
  • 時間とお金のコスト見積もり。
  • 繰り返しになりますが、問題はプロジェクトが実行可能かどうかです。

• 実行: 調整の監視と計画。
• 終了: プロジェクトが検討の必要性を満たしているかどうかが検証されます。

これらすべてのフェーズは、次の一般的なプロセスを意味します。

• 問題または機会を特定する

• 理想的なソリューションを特定して定義する

• 必要なタスクとリソースを特定します。

• スケジュールを準備し、リソースを入手する

• プロジェクトの費用を見積もり、予算を立てます

• リスクを分析し、ステークホルダー（プロジェクトに直接的または間接的に利害関係を持つ人）との関係を確立する: 定期的なリスク管理

• 実行中に適切なレベルで制御とコミュニケーションを維持します。逸脱を検出して報告するための定期的な会議

• 成功したクロージングを管理する
  • パンチ リスト: プロジェクトを完了するためのタスクのリスト。
  • プロジェクトが終了に近づくと、チーム メンバーは分散する傾向があります。

ただし、プロジェクトは、人間関係の観点など、別の観点から見ることもできます。

• チームのモチベーションを高める: 適切な環境を作り出す
  • 各役割がプロジェクトにどのように貢献するかを時間をかけて説明します
  • 会議に時間を投資して、メンバーの積極的な貢献を強調します。
  • 委任された作業を信頼する
  • 個人に目標を割り当て、その道を選択できるようにします。
  • 求められている以上の努力を評価します。
  • 模範を示す

• 多様性を管理する
  • 考えられる個人の目標を特定して、それを最小化するか、グループの目標に変換します。
  • グループの団結を求めます（習慣、文化などを調和させます）。

さらに、プロジェクト管理および人間関係の内部プロセスに加えて、プロジェクトは組織内で開発および実行されます。現在、コンサルティングや監査部門など、プロジェクトの実行を主な業務とする企業が見受けられます。組織全体がプロジェクト管理に重点を置いているため、これは最も前向きなシナリオです。

しかし、ほとんどの企業は、さまざまな機能を持つ部門と、特定のタスクを実行する従業員で構成される階層構造を持っており、従業員の流動性は非常に散発的である傾向があります。このタイプのシナリオでは、内部協力者によるプロジェクト (確立されたものとしては一時的なもの) の実行は、管理がより困難なシナリオになります (これが、プロジェクトが外部のコンサルタントや監査人に委託されることが多い理由の 1 つです)。

この 2 番目の状況は、従業員に「サイロ メンタリティ」を与える可能性があります。つまり、目標が割り当てられたプロジェクトではなく、自分の職務領域に関連付けられている人々です。彼らはプロジェクトの成功には関心がなく、部門からの安定した義務を果たすことを優先するかもしれません。この問題は、チームワークの協力（水平思考）を妨げる可能性があります。

つまり、組織の成熟度と確立された内部手順が、プロジェクトの成功または失敗に影響する可能性があります。

• 組織が通常プロジェクトに取り組んでいる場合、すでに定義されたガイドラインがあります。

• 正式なコミュニケーションチャネル: 厳格すぎると、仕事が中断される可能性があります

• 非公式のコミュニケーション チャネル (友人、知人など): 頻度が多すぎると、誤った情報が生成される可能性があります。

最後に、PMBOK は、プロジェクトが成功したとみなすには、次の期待が満たされる必要があると定めています。

• レベル I. プロジェクト目標の達成

• レベル II。プロジェクトの効率化。
  • クライアントの作業中断レベル。
  • 資源の効率的な利用
  • チームメンバーの増加
  • 経営上の対立

• レベルⅢ。エンドユーザー/顧客向けのユーティリティ。
  • 最初の問題は解決されましたか?
  • 給付金は増加しましたか、それとも実質的な節約はありましたか?
  • ユーザーは現在その製品を使用していますか?
• レベル IV。組織改善：経験から学ぶ

プロジェクトマネージャ

プロジェクト マネージャーまたはプロジェクト マネージャーには次の責任があります。

• プロジェクト: コスト、スケジュール、機能、品質の目標。
  • 組織
  • 投資収益率。

• 情報の流れ: 積極的に提供します。上司が何らかの情報に驚いた場合、それは正しく情報を伝えていないことを意味します。

• チーム: フィードバックと評価を提供します。

• あなた自身について: 個人的な成長。

一方で、プロジェクト マネージャーは常に次のような課題に直面しています。

• 責任 vs.権限の不在
  • 高いレベルの責任。
  • 私は直接の権限を持たない人々と仕事をしています。

• 非現実的な目標
  • これは最も一般的な問題の 1 つです。
  • これは、プロジェクトの範囲を正しく分析して計画するという考えを強化します。

• 機能的指向
  • 人々は自分の機能的な知識領域に焦点を当てる傾向があります。
  • 一時的なものであることを考えると、プロジェクトよりもその機能分野の方が重要です。

• 不確実性をめぐる根本的な対立
  • 少ない情報で迅速な意思決定を行います。
  • 間隔の見積もり (コストなど)
  • 見積もりの難しさを上司やチームメンバーに理解してもらうように努めてください。

プロジェクト管理に伴う責任と課題にうまく対処するには、プロジェクト マネージャーは次のスキルを常に磨く必要があります。

• プロジェクト管理: 計画と監視のためのツール。
• 人間関係
  • リーダーシップ、交渉、委任のスキル。
  • 口頭および書面によるコミュニケーションスキル
  • 紛争解決。
  • メンター（コーチング）の役割を開発するためのスキル

• 技術的な知識
  • 産業および技術分野の知識
  • 製品および/またはプロセスの知識
  • デザインスキル

• 個人スキル
  • 正直さ、誠実さ
  • グローバルに考える
  • 不確実性と曖昧さに対する高い耐性
  • 説得力があり、断定的である
  • オープンでアクセスしやすい
  • 決定的
  • 商業。アイデアやプロジェクトの利点を販売する能力。
  • 教師。知識をチームメンバーに伝達します。

プロジェクトの定義

プロジェクトの定義は次のフェーズで構成されます。

• フェーズ I. 問題または機会を理解します。
• フェーズ II。最適なソリューションを特定する
• フェーズⅢ。ソリューションを開発し、計画を立てる
• フェーズ IV。プロジェクトの立ち上げ

フェーズ I. 問題または機会を理解します。

プロジェクトが満たそうとしている本当のニーズを特定することが重要です。このニーズが十分に満たされているかどうかに基づいて作品が評価されます。

まず、ニーズとソリューションを区別する必要があります。

必需品:

• クライアントに目的を説明する

• 目標と目的を指定する

• これをどのように行うかという質問はそのままにしておきます。

• なぜこれが行われるのかに対する答えは、ビジネス上の正当性を示している必要があります。

代わりに、次のような解決策があります。

• チームの手段を説明する
• 目標と目的を達成するための戦略とアイデアを指定します。
• その方法を指定します。
• なぜこれを行うのかという答えは、顧客のニーズを示している必要があります。
• 本当のニーズを特定するよう求めると、第三者があなたの基準を信頼できないと不快に感じる可能性があります。

これらの定義に基づいて、このフェーズでは、ソリューションを提供するものではなく、ニーズを説明するだけのプロジェクト要件文書が生成されます。この文書には次のセクションが含まれている必要があります。

• 問題または機会の説明
• 問題の影響または影響
• 問題の影響を受ける人または内容を特定する
• 問題を無視した場合の影響
• 望ましい状況
• 望ましい状況に到達することに伴う利点
• 組織の戦略との整合性
• 組織の他の領域との互換性の競合
• 不確実性
• 主な前提条件
• ソリューションの制限
• 環境への配慮
• 過去のサポート情報

これらの情報をすべて収集したら、問題が解決する価値があるかどうかを再評価し、潜在的な解決策があるかどうかを判断する必要があります。

フェーズ II。最適なソリューションを特定する

特定されたニーズをカバーするソリューションを特定するには、次の手順に従うことができます。

• 今後のエンゲージメント チームのメンバーまたは関係者とのグループ ブレーンストーミング。
• プロジェクトの要件文書の記述をどの程度満たしているかを確認します。
• 解決策の候補を 2 ～ 5 つ選択します。

選択した候補ソリューションについては、詳細な分析を行って、対応するニーズに最も適しており、手頃なコストを意味するものを特定する必要があります。

財務分析 (コスト x 利益):

プロジェクトの財務的実行可能性を検証するには、プロジェクトの実施によって得られる利益（売上の増加、コスト削減など）や、プロジェクトの開始にかかる費用など、プロジェクトによって生み出されるキャッシュフローを特定する必要があります。 up はプロジェクトの進捗と管理の略です。

したがって、さまざまなキャッシュ フローの大きさを推定し、4 つの基本指標を計算することで、どのプロジェクトが最も高い財務収益性をもたらすかを特定できます。

少なくとも次の指標を検討する必要があります。

• 正味現在価値 (NPV)。 お金の時間的価値を考慮して、プロジェクトが生み出す金額を決定します。
• 内部収益率 (IRR) 。投資収益率を決定します。
• 期間 戻る 。投資がいつ回収されるかを決定します (NPV = 0)。
• お金の穴 。必要な最大投資額を決定します。

非財務分析 (加重因子スコアリング モデル - 意思決定マトリックス)

加重要因スコアリング モデル (「意思決定マトリックス」) を使用した分析は、評価される属性のリストを作成することから始まります。それぞれについて重み付けが確立され、各候補ソリューションの準拠度を示すスコアが割り当てられます。

アドバンテージ：

• 財務データをはじめとするさまざまなデータの活用が可能です。
• 管理者の関与と感度分析が可能になります。

短所:

• 非常に主観的なプロセス。
• これはプロジェクトの魅力を示していますが、商業的な正当性を示すものではありません。

どのソリューションを選択するかについての最終決定は、財務分析またはマトリックス分析に加えて、他のツールの使用に基づいて行うことができます。

• 市場調査
• パイロットテスト。限られたエリアでテストします。
• プロトタイピング。正しい予測を検証するためにプロジェクトの一部を構築します。
• コンピューターシミュレーション。

つまり、実行された分析は、ソリューションの選択に役立つだけでなく、ソリューションが実行可能かどうか、プロジェクトを続行する価値があるかどうかを判断することもできます。