フェーズの完了基準(Phase Exit Criteria)



先日、ある失敗プロジェクトについて上層部と話しをしていたときに、失敗プロジェクトでよく見られる特徴の代表的な例として、各フェーズの作業が未完了のまま、次のフェーズに突入して、プロジェクトの後半で破綻しているケースが多いことに気付いた。


ありがちな例として、

  • 顧客の要件が未確定の状態で要件定義を終結し、基本設計に突入する。
  • 基本設計時に発生した設計上の課題を放置したまま、詳細設計に突入する。
  • 結合試験の不具合改修が残っている状況で、総合試験や性能試験に突入する。

などなど、挙げればきりがないし、厳しいスケジュールの中でプロジェクトを回しているのだから、ある程度は仕方がないと個人的には思う。
現に、現場ではスケジュール短縮のためにファストトラッキングという手法が一般的に利用されている。


要はプロジェクトマネージャが、どの課題や残作業を次フェーズに積み残したのか明確化できていて、それらをコントロールできていることが重要なのだと思う。


きちんとコントロールするためには、プロジェクト計画時に、各フェーズ毎の完了基準(Phase Exit Criteria)を明確化しておき、各フェーズのエンドでチェックをして、仮に積み残した場合も何を積み残したのか、可視化できる仕組みが必要となってくる。


また、顧客に対してもキックオフの場などで、「我々は、原則としてこれらの基準を満たしていないと先のフェーズには進みません。ご協力をお願いします。」と宣言してしまっても良いかもしれない。
(往々にして顧客の決定や顧客の回答が遅延することが多いため)


プロジェクトが厳しい局面にある時は特に、目の前にある厄介な課題やタフネゴシエーションが必要なステークホルダーとの交渉をつい後回しにして、後々事の重大性に気付かされることが多く、自分自身も過去に苦い経験を何度かしたことがある。


今まで、「フェーズの完了基準プロジェクト」として、計画時に定義したことがなかったので、早速運用を検討してみようと思う。