気になることはそのままにしない
ベンダーは、オンスケジュールの報告をしたがる。遅れていても、都合の良い過大解釈をして、オンスケジュールとして報告する。
報告を受ける側からすれば、安心するが、よくみて見ると、辻褄が合わないところがある場合がある。そのときは、説明を求めなければならない。本当にオンスケジュールではない可能性があるからである。
経験的に説明を求めた場合、ほぼ都合のよい解釈をしてオンスケジュールの報告をしていた。ベンダーも結局のところはバレることになり、進捗報告会の場で指摘をされ、事実の再報告を求められる。
また、リスケをして、リスケ後のスケジュールでオンスケジュールと報告をする。だが、違う。遅れには、変わらないのである。リスクを高めているだけである。このようなことをするのは、世界に1社だけかと思いきや、何社も経験した。遅れは遅れで、遅れを認識することが大切である。リスケは、リリースを遅らせた時にするのものである。
このような経験から、ベンダーからの進捗報告は次のようにした。
数値化での報告を求める
定性（文章）は、人によって理解が違うため、認識齟齬が発生する。基本は数値化して報告をする。
注意すべきは、数値化する際の定義である。
たとえば、プログラム開発完了とした場合、完了数と総数、そして進捗率を報告する。
では、プログラム開発完了をどのように定義するかが、ポイントになる。あるベンダーは、コーディングと定義していた。あるベンダーは、単体テスト完了と定義していた。
コーディングとすると、品質のよっては時間がかかるということになる。つまり、質の良し悪しに影響する報告となる。だから、単体テスト完了と定義するべきである。
このように、進捗の数値化をする場合には、定義を決めることも忘れていはいけない。
報告のための作業は減らす（事実を知ることと分析は違う）
管理とマネジメントは違う。進捗報告は、事実を知ることを目的であるので、アレコレと分析は不要で手間の割に効果は薄い。
実は、実際にプロジェクトマネージャーとしての経験がない、コンサルタントや、理解せずにネットで調べた教科書的なことを要求する人が多い。進捗には、分析は必要だが、分析をベンダーに指示して作成させることは意味がない。また、当然ながらベンダーは手間をかけなければならないため、嫌がる。
分析が必要なら、自分たちでればよい。そもそも、進捗に分析は不要である。あるのは、品質管理図だけである。
進捗は事実を知り、プロジェクトをマネジメントする材料であることをを忘れていはいけない。
