プロジェクトの特徴

プロジェクトの役割

プログラムとポートフォリオ

プロジェクト管理 VS 運用管理

予測的

増分

反復的な

アジャイル

ニーズ評価

ビジネスケース

給付管理計画

事業環境要因

組織プロセス資産

マトリックス型

プロジェクトの種類

機能的

階層的な

責任割り当てマトリックス

テキストタイプ

資源管理計画の内容と機能

価値観、行動規範、問題解決プロセスに関する合意

リソース カレンダー 組織メンバーの空き状況を理解する

プロジェクト カレンダーでは、プロジェクト全体の休日と祝日を特定します。

多基準の意思決定分析

プロジェクトの開始前に上級管理者によってプロジェクトに割り当てられたリソース

最初に社内で、次に社外で、機能マネージャーまたはサプライヤーと交渉 (折衝) してリソースにアクセスします。

チームメンバー間の交流を促進し、チーム全体の雰囲気を改善してプロジェクトのパフォーマンスを向上させるプロセス

形成: チームメンバーの役割と責任を明確にする(指示)。

ショック：衝突が起こる（コーチング型）

規範: 問題を解決しようとする、協力して作業する (参加型)

成熟：成熟した部隊のように秩序正しく動作し、効率的に仕事を完了する（認可型）

解散: プロジェクトが終了し、チームが解散します。

便利で効率的なコミュニケーションを実現する集中オフィス

仮想チームは地理的な違いに対処します

共有ポータル、ビデオ会議、音声会議、電子メール/チャット ソフトウェアが含まれます

評価と報酬

5 つのモチベーション理論を区別する

メンバーは能力、知識、スキルが不足しており、拘束されない

個人の感情と他人の感情を含む、人々の感情的性質と社会への適応性

紛争管理の定義

対立を解決する 5 つの方法

チームの士気を向上させ、チームの社会的関係を強化し、前向きで協力的な作業環境を作り出す

プロジェクトマネージャーには、パフォーマンスが不十分なメンバーをケアし、問題を分析して成長を達成できるように支援する責任があります。

チームのコラボレーションを促進し、チームメンバーの仕事を統合して効率的なチームを作成します。

制御リソースのプロセスは、機器、材料、施設、インフラストラクチャなどの物理リソースに焦点を当てます。

管理チームのプロセスはチームメンバーに焦点を当てます

最初に分析し、後で行動する

組織内での立場、プロジェクト内での役割

プロジェクトへの関心、期待、サポートのレベル、プロジェクト情報への関心

利害関係者の権利と利益に応じて管理する

ハイパワー、ハイメリット: 集中管理

高出力、低メリット: 満足

低消費電力、大きなメリット: 常に最新情報を入手

低電力、低メリット: 監視

大規模かつ複雑なステークホルダー関係ネットワークを対象に、権力、緊急性、正当性の観点から分析します。

上、下、外側、横

ステークホルダーの基本情報、評価情報、ステークホルダー分類分析

利害関係者が変更された、または特定されていないことが判明した場合は、利害関係者登録簿を適時に更新します。

利害関係者の関与を管理する方法

5 つのレベル (無自覚、抵抗、中立、支持的、リーダーシップ)

戦略を特定し策定するための現在と願望の間のギャップ

コンテンツ

役割: プロジェクトへのステークホルダーの参加の指導と管理

公式と非公式

書面と口頭

内部と外部

公式 vs 非公式

上、下、横

コミュニケーションニーズ分析

通信チャネル数の計算

通信方法

コミュニケーションモデル

出力 - コミュニケーション管理計画

意味

コミュニケーションの変更により、コミュニケーション管理計画が更新される場合があります

情報伝達に問題があった

新しい利害関係者が特定されるか、利害関係者に関する情報が変更されます。

ステークホルダーの参加レベルに問題がある場合は、それに応じた経営戦略を策定

関係者全員のニーズを事前に収集する必要がある

要件文書

要件追跡マトリックス

やるべき仕事とやるべきでない仕事を説明する

要件トレーサビリティ マトリックス: 要件と成果物がリンクされています

範囲宣言: 成果物の入手場所

業務範囲全体の階層的内訳

WBSとWBS辞典

成果物がビジネス要件を満たし、受け入れ基準を満たしていることを確認する

範囲のベースライン (受け入れ基準) または契約

完了→品質管理→スコープ確認→クロージングまでの流れ

監督範囲と管理範囲のベースライン変更

サポートされていない場合は、その範囲内でのみ作業を行ってください。

実行されていることに気付いた場合は、すぐに停止して影響を分析してください

これで完了です。変更管理プロセスを追加する必要があります

プロジェクトの成果物を完了するために実行された具体的なアクションを特定して文書化する

アクティビティ リスト VS アクティビティ属性 VS マイルストーン リスト

終了-開始、終了-終了、開始-開始、開始-終了

オプションと必須、内部と外部

後続アクティビティを先行アクティビティと比較して前倒しまたは遅延できる時間。

プロジェクト進捗ネットワーク図

アナログ推定、パラメータ推定

三点推定

ボトムアップ評価

準備金分析（緊急準備金と管理準備金）

含意

フロート時間

リソースバランシング

リソースのスムージング

急ぎの仕事

素早いフォローアップ

What-Ifシナリオ分析の結果に基づいて、さまざまな条件下でのプロジェクトスケジュールの実現可能性を評価します

プロジェクト スケジュール、スケジュール ベースライン、プロジェクト カレンダー

進捗状況を監視し、進捗ベースラインへの変更を管理する

逸脱の原因を分析する

スケジュールに対する逸脱の影響を評価する

対応するソリューションを開発する

プロジェクトに直接参加するかどうか

プロジェクトのワークロードによって変化しますか?

すでに発生しており、今後も変わらないコスト

1 つのプロジェクトを選択し、別のプロジェクトを放棄し、他のプロジェクトによってもたらされる収入

具体的なコストデータはなく、測定単位などを定めたガイドライン文書があるだけだ。

大まかな大きさの推定値と決定論的な推定値

「アクティビティ期間の推定」の詳細な説明を参照してください。

緊急予備、管理予備

作業パッケージの見積もり 緊急準備金 = コスト ベースライン

コストベースライン管理準備金 = 予算

プロジェクトを監視する範囲にコストをマッピングする

現在を分析する

未来を予測する

品質管理のプロセスでは、検査よりも予防​​が重要です

品質とグレードは直接の関係はなく、必要な品質とグレードのレベルを同時に達成するために比較検討する必要があります。

属性サンプリングは合否の結果であり、変数サンプリングは合格の度合いです。

含意

アーティファクト

含意

含意

アーティファクト

入札への招待 VS 情報への招待 VS 提案への招待

時間

効果

提案書はバイヤーの調達方針に基づいて作成され、提出される必要があります

サプライヤー選定基準に基づき提案を選定・審査

交渉：契約に署名する前に、契約の構造、当事者の権利と義務、その他の条件を明確にして、両当事者が合意に達することができるようにする

契約の内容: 調達作業明細書または主要な成果物、検査、品質および合格基準を含みますが、これらに限定されません。 終了条項と裁判外紛争解決

契約の役割: プロジェクトにサプライヤーが関与するすべての矛盾については、契約が優先されます (相違がある場合は、契約を参照してください)。

パフォーマンスレビュー VS 検査 VS 監査

契約要件と一致しない、または契約の範囲を超える

交渉が第一選択であり、次にADR（裁判外紛争解決手段）、仲裁、訴訟が続きます。

すべての成果物は納品されており、未払いの請求はなく、すべての最終支払いが行われています。

リスク管理活動をどのように計画し、実行するか

強み、弱み、機会、脅威を分析し、リスクをより包括的に検討する

リスクレジスター

リスクレポート

リスクに優先順位を付け、優先度の高いリスクに重点を置く

リスクの影響と確率の積に基づいてリスクに優先順位を付けます

特定された個々のプロジェクトのリスクやその他の不確実性源がプロジェクト全体の目標に及ぼす影響を定量的に分析する

モンテカルロ分析

竜巻図

期待金銭価値の計算

報告、転送、回避、軽減、受け入れ

報告、共有、開発、改善、承認

緊急時対応計画、リバウンド計画、緊急時対応策

特定されたリスクを監視し、新たなリスクを特定する

リスクを継続的に再特定、再分析、再評価する

リスク管理の有効性を評価する

コンテンツ

初期、初期、初期、オリジナル、スタートアップ段階: 上位レベル、メイン、全体、管理

仮定と制約

コンテンツ

効果

改訂

プロジェクトの目標を伝達し、プロジェクトに対するチームのコミットメントを獲得し、各関係者の役割と責任を明確にする

プロジェクト管理計画で特定された作業を実行し、プロジェクト目標を達成するために承認された変更を実装します。

成果物の最初の出力

問題が発見され、問題ログに記録され、リアルタイムで更新されます

問題処理プロセス: 記録 - 分析/評価 - 解決策の開発 - 実装

形式知と暗黙知

プロジェクト文書とその他の学んだ教訓がリポジトリ (または PMIS) にあることを確認し、人材の離職や知識の損失を防ぐためにそれらが最新であることを確認します。

効果

環境要件

ジョブ パフォーマンス データ VS ジョブ パフォーマンス情報 VS ジョブ パフォーマンス レポート

変更管理計画と変更ログ

ベースラインを含まない変更

ベースラインに関係する変更

— 承認が完了すると、変更は行われません。

やるべきことが行われていない場合、または製品の品​​質に問題がある場合を除きます。

早期終了の理由を調査し、閉鎖を実行する必要がある

1.引継ぎ結果

2. 決算

3.満足度調査

4. 教訓記録を更新する

5. 文書の更新（組織プロセス資産の更新）

6. 最終報告書

7. 文書のアーカイブ

8.祝賀会

9. チームを解散する

入手可能なソフトウェアはドキュメントよりも優れていますが、ドキュメントが完全に不要というわけではありません

詳細な文書がすでに要件の一部となっている場合は、その価値に焦点を当てて調整する必要があります。

関係者が詳細な資料や詳細な計画を求めている場合、成功体験を示して説得することができます。

私たちは、お客様との意見の相違がある場合には、契約をむやみに遵守するのではなく、コミュニケーションと協力を重視して合意に達し、Win-Winの協力を追求します。

計画やニーズなどは変更される可能性があるため、積極的に対応する必要があります

変化を受け入れることは、すべての変化を無条件に受け入れることを意味するものではありません

原則 1: 当社の最大の目標は、価値のあるソフトウェアを早期かつ継続的に提供することで顧客のニーズを満たすことです

チームメンバーのビジネスパーソンと開発者は常に一緒に働き、チームはやる気と信頼に満ちた自己組織化されたチームです

無駄のないミニマリスト、この原則を実現する方法は「正反省」です

面と向かって

すべての作業の順序付きリスト。価値指向で段階的に詳細が記載されています。

価値、リスクなどの要素に基づいたランキング。

機能的なコンテンツと非機能的なコンテンツ

イテレーション計画ミーティングでのアウトプット、イテレーションの目標の定義、具体的なタスクの明確化、そしてチームが独自に議論して受け取ります

通常、これは任意に変更されることはありません。まず、反復タスクがスムーズに完了するようにする必要があります。 (ユーザーストーリーに価値がなく、プロジェクトの生死に関わる場合は別ですが)

チームの能力とプロジェクトの特性を考慮する

タイムボックスは固定されており、任意に調整されることはありません。

反復タスクと目標を決定し、それらを完了する方法について話し合い、反復バックログを作成します。

ニーズの変化を理解するために関係者を参加に招待できます

プロジェクトのステータス情報（マスター進捗状況）、チームの個人ステータス、コンセンサス情報を理解し、問題を特定する

チームは自らを組織し、チームの誰でもスタンドアップ ミーティングを主催できます。

制限時間は通常 15 分です (他の理由が会議の有効性に影響を与えない限り、延長することができます)

問題を発見するだけで、解決するものではない

PO評価「完了」、顧客の承認、フィードバックの提供

未完成または未承認のユーザー ストーリーは製品バックログに戻されます。

次回の予想と傾向について話し合う

自らを見つめ、プロセスに着目し、対策の効果を検証し、原因を究明し、改善案を提案する

ビジョン

製品ロードマップ

リリース計画

反復計画

毎日の計画

計画された作業を完了しなければならない一定の比較的短い期間

シーンとキャラクターを構築する

国防総省

ユーザーストーリーの粒度

ストーリーポイントのコンセプト

ユーザーストーリーの推定

優先順位を付ける

優先順位付けの方法

リスク調整のバックログ

新しいテクノロジー、新しい手法、新しい問題、不明瞭なリスクを探索する

バックログを反復する

実行における技術的スキル

チームワークと顧客の協力をガイドする

完了したストーリーポイントに基づいて

コンセプト

初速の目安

特徴

見せる

モニター

ワークアイテム内のプロセスの流れを特定する

欠陥（無駄）を特定し、改善を図る（製品に付加価値を与えない活動を見つける）

合理的な計画、チームの効率性、ボトルネックの特定

カンバン ボードのさまざまなモジュールの完了統計に基づいて、現在のプロジェクトの範囲の変更と傾向を判断します。

2 人の開発者が協力して作業し、1 人がコードを作成し、もう 1 人がそれをリアルタイムでレビューします

その役割は、より集中して効率的になり、チームの壁を打ち破り、新しいスキルを開発することです。

半プライベートスペース（洞窟と公共エリア）

すぐに統合してコードの問題をすばやく見つけて解決します

開発前にテスト ケースを作成し、コーディング中にテストします。テストが失敗した場合は、リファクタリングできます。

納品後の頻繁な故障を回避し、手動テストのコスト増加を回避します。

機能を変更せずにコードを最適化および再編成し、コードの保守性を向上します。