『プログラム管理の甘さ』デグレにより不幸を招いたプロジェクト
いくら不具合修正を行なってもプログラム管理ができていないと品質は劣悪になります。
✅プログラム管理（修正履歴、世代間り）を十分に行わない方
✅PJリスクを集めているPMやPMO
✅プロマネ初心者を抱える管理者
にお伝えしたいプロジェクトリスクの情報です。
プロジェクトでは、システムの品質を向上させるために各工程でテストを実施していきます。
テストの過程では、不具合が発生することは当たり前のことです。
不具合があれば、プログラムを修正して、正常な動作を保証しなければなりません。
しかし、１つのプログラムが複数の機能に関連するのであれば、修正履歴による関係者との共有、最新バージョンとしてのプログラム管理を行わなければ『デグレ』という厄介なトレブルに巻き込まれ、時間とコストを無駄に浪費してしまいます。
意外にも、このことを知らないPMが多いって、ご存知でしょうか？
続きを読む■今回のテーマ
プロジェクト計画における『品質基準の策定』の検討の中で、『プログラムの修正履歴、世代管理が厳密に行わなかった』ことにより、『重複障害やデグレートの多発による品質劣化』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
『総合テストの範囲を明確にする』誰でもすぐ失敗しない出来るコツ！
テスト工程で各チームの進捗にバラツキがでたら、スコープの理解度をチェックしてください。
総合テストは、プロジェクトにおいて重要な品質チェックの作業です。
プロジェクトでは、入念にテスト計画を策定して慎重に実施していくでしょう。
特に、複数のチームで総合テストを分担して実施する時は、テスト計画の『テストスコープ』、『テスト方針』、『テスト手順』を正確に作っておかないと、各チームでテストの品質にバラツキが出るものです。
これは、『各チームにお任せ』という丸投げマネジメントであり、テストを全て消化しても品質基準をクリアしているかが不明確となり、再テストという事態も否めません。
意外にも、このことを知らないPMが多いって、ご存知でしょうか？
■今回のテーマ続きを読む
プロジェクト計画における『スコープの明確化』の検討の中で、『スコープを理解していないことから各チームの進捗にバラツキが出た』ことにより、『総合テストのスケジュール遅延』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
『次工程の見切り発車』PMなら押さえておきたい失敗しないポイント！
作業工程の見切り着手は、慎重に行わなければプロジェクトは炎上します。
✅スケジュールが厳しい時、次工程を見切り着手する癖がある方
✅PJリスクを集めているPMやPMO
✅プロマネ初心者を抱える管理者
にお伝えしたいプロジェクトリスクの情報です。
プロジェクトにおいて計画は、重要であると誰もが認識しているものです。
計画と言うと『スケジュール』、『コスト（工数）』を思い浮かべてしまいますが、『コミュニケーションマネジメント』も重要な一つです。
多くのプロジェクトでコミュニケーションマネジメントを疎かにした結果、クライアントの想定していたシステムができない、プロジェクト実行中にクライアントやメンバとの思わぬ意識齟齬が起こっています。
また、スケジュールが厳しくなるにつれ、現工程の作業を『ある程度完了』したら、次工程の着手するという『見切り着手』することで、進捗の帳尻を合わせようとするPMいます。
これは、次工程に着手するための前提条件やコミュニケーションルールが存在しないプロジェクトであり、危険なマネジメントと言えるでしょう。
仮に、見切り着手するのであれば、『現工程の残課題が全体の品質や作業に、どのような影響を与えるのか』を把握していなければなりません。
意外にも、このことを知らないPMが多いって、ご存知でしょうか？
計画と言うと『スケジュール』、『コスト（工数）』を思い浮かべてしまいますが、『コミュニケーションマネジメント』も重要な一つです。
多くのプロジェクトでコミュニケーションマネジメントを疎かにした結果、クライアントの想定していたシステムができない、プロジェクト実行中にクライアントやメンバとの思わぬ意識齟齬が起こっています。
また、スケジュールが厳しくなるにつれ、現工程の作業を『ある程度完了』したら、次工程の着手するという『見切り着手』することで、進捗の帳尻を合わせようとするPMいます。
これは、次工程に着手するための前提条件やコミュニケーションルールが存在しないプロジェクトであり、危険なマネジメントと言えるでしょう。
仮に、見切り着手するのであれば、『現工程の残課題が全体の品質や作業に、どのような影響を与えるのか』を把握していなければなりません。
意外にも、このことを知らないPMが多いって、ご存知でしょうか？
■今回のテーマ続きを読む
プロジェクト計画における『コミュニケーションマネジメント計画の作成』の検討の中で、『次工程へ進むためのルールが決められていなかった』ことにより、『基本設計の承認を得ず詳細設計に見切り着手』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
『要件定義のコスト（工数）算出』PMで成功したいなら取り組んでおくポイント！
要件定義では、RFPでは予想できなかった仕様が、明確になるものです。
プロジェクトにおいて、計画コストをオーバーすることは赤字プロジェクトと言います。
コストオーバーは、開発の各工程で発生する可能性を秘めています。
この時の原因は、
①追加仕様によるコストオーバー
②スキル不足によるコストオーバー
③見積もりミスによるコストオーバー
④リスク工数の不備によるコストオーバー
⑤その他このようなことが考えられます。
また、開発工程で見た場合に『要件定義工程』でのコストオーバーを経験されたPMも多いとのことです。
それは、RFPでは予想できなかった仕様（機能含む）が、明確になることが原因だからです。
意外にも、このことを認識して『要件定義工程のコスト（工数）』を算出しないPMが多いって、ご存知でしょうか？
■今回のテーマ続きを読む
プロジェクト計画における『工数の算出』の検討の中で、『RFPから必要とされる仕様（機能）を予測できなかった』ことにより、要件定義工程で、『要件が明確になったことによりコスト増加』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
意外にやってない『システムのリリースにおける前提条件』プロジェクトで注意したいポイント！
前提条件・制約条件を決めないとプロジェクトのボリュームはどんどん膨れていきます。
プロジェクトにおいて、仕様書と実装の差異は致命的です。
所謂、『品質劣化』のレッテルを貼られシステムのリリースができずプロジェクトの失敗を意味します。
仕様の中でも、ビジネスに悪影響を与えない部分（例：画面デザインのフォント種別、微妙なドット単位でのズレ）は、『大目に見てもらえる』場合もあります。
しかし、これは計画段階でクライアントとシステムのリリースにおける前提条件を協議しておかなければ成り立ちません。
意外にも、事前の協議を怠るPMが多いって、ご存知でしょうか？
■今回のテーマ続きを読む
プロジェクト計画における『前提条件、制約条件の明確化』の検討の中で、『システムのリリースに関する前提条件、制約条件』を取り決めておかなかったことにより、ユーザテスト工程（受入）で、『仕様書と実装の差異による品質劣化』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
意外と難しい『必要スキルの洗い出し』知らないと失敗するPM論理的な手法！
プロジェクトを成功させるには、開発する機能の難易度を知って、対応できるスキルを考えなければなりません。
プロジェクトにおいて、新規機能の開発と既存機能の改修といセットはよくあることです。
このような時に、計画段階で改修対象となる既存機能の難易度を把握しておくことで、設計、製造、テストが効率的に進めることができます。
しかし、意外にも既存機能の難易度を把握することなくプロジェクトを開始して、製造段階でハマってしまうPMが多いって、ご存知でしょうか？
このような時に、計画段階で改修対象となる既存機能の難易度を把握しておくことで、設計、製造、テストが効率的に進めることができます。
しかし、意外にも既存機能の難易度を把握することなくプロジェクトを開始して、製造段階でハマってしまうPMが多いって、ご存知でしょうか？
■今回のテーマ続きを読む
プロジェクト計画における『スコープの明確化』の検討の中で、既存機能の『改修難易度』の把握をしなかったことにより、製造／単体テスト工程で、『特定機能の進捗遅延による品質劣化』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
『スコープ間違いは命取り』プロジェクトめんば全員に教えたいシステム化範囲の調査ポイント！
計画段階でスコープを決定しなければ開発工程で工数が肥大します。
要件定義工程は、プロジェクト計画で検討されたスコープを業務運用面、システム面を明確に具体的に絞って確定していきます。
そのため、プロジェクト計画の中ではスコープ調査を実施していくものです。
スコープ調査、特に調査範囲、方法を間違ってしまうと要件定義のスケジュールは、あっという間に時間オーバー。
意外にも、スコープ調査の方法を知らないPMが多いことをご存知でしょうか？
そのため、プロジェクト計画の中ではスコープ調査を実施していくものです。
スコープ調査、特に調査範囲、方法を間違ってしまうと要件定義のスケジュールは、あっという間に時間オーバー。
意外にも、スコープ調査の方法を知らないPMが多いことをご存知でしょうか？
■今回のテーマ続きを読む
プロジェクト計画における『スコープの明確化』の検討の中で、『顧客の要求事項を整理することでスコープが広がった』ことにより、『スコープ定義のやり直し』という問題が起こりました。
この問題を取り上げて、原因の追求、解決策、リスク対策を解説していきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
