プロジェクト計画書のバランス

SPI

CMMIベースでプロセス改善に取り組んでいると、
GPに関しては大部分が計画に含まれる内容と判断する事が多いですね。
全てのPAのGPを考えると、プロジェクト計画のカバーすべき範囲が
如何に大きいか、頭クラクラしてきます。(^^;


通常、多くの組織では、CMMIでプロジェクト計画に該当する文書は、
Wordだったり、Excelだったり、PowerPointだったり、
ともかく様々なドキュメントで記述している事が多い。


理由は、プロジェクト計画に該当する活動を段階的に実施して、
それぞれの活動を記述するのに最適な文書形式が、
一つにまとまらないからなんだけど・・・つまりWord使えない、と。(--;
結局の所、後の分析を考えると、Excelが使い易いし、
構造や簡単な図形を説明する内容だとPowerPointの方が便利だしね。


それ以外の理由にプロジェクト計画だとあまりに粒度が大きすぎるので、
WBSで作業分割していると別活動＝別ドキュメントという事になるのかもしれません。
ただ、分割し始めると、クロスリファレンスとか構成管理とかやらなくなる。
結局、「最初の希望的観測」が残り、日々の管理は、スケジュールだけに
なってしまうんですよね。


全てをツールで管理するのは理想なんですけど、そこまでやらない場合は、
１）ドキュメントとしての記述平易度
２）作業管理を考慮した適切な作業粒度
３）基本は、統合／一元管理
を意識したプロジェクト計画に関する文書をまとめるしかないんですよね。


プロジェクト計画に関しては、CMMIも結局はベースはPMBOKなので、
最近は色々と読みながら考えますが・・・なかなか現状での最適解を
出すのは難しいですね。


そういえば、計画で良く遭遇する考え方に、
「スケジュールは変えるけど、計画は変えてはいけない」
というのがありますね。
基準計画は後でデータ分析する為に残すべきだろうけど、
最初に絶対ブレない計画を作れる人なんていないと思うけどなぁ。
その固定観念こそが、「なかなか計画書作れない」理由なんですけどね。