遅延対策は、進捗報告と分離すること

上司であったり、プロジェクトのチームリーダーである時に聞きたくないのは、部下からの遅延報告
正直なところ、プロジェクトの遅延なんて日々、プロジェクトメンバの顔を見ていれば、いちいち報告を聞かなくでもわかるもの

とは言っても、プロジェクトは組織で行なっているものですし、マネジメント（経営層）への報告も必要なので進捗会議を行なって、議事録を回付するといった約束事を省く訳にもいきません

自分がチームリーダーでプロジェクトを回していた時には、遅延対策もなく、ただ遅延が発生しましたと報告してくるプロジェクトメンバを見ると「馬鹿野郎！」と怒鳴りつけたくなったこともあったのです
でも、プロジェクト監査の立場で外からプロジェクトを見るようになって考え方が変わりました

「進捗報告（遅延報告）をするときは、遅延対策は考えてくるな！」です
以前は、遅延の回復策も考えずに遅延報告をするなんて責任感に欠けるのではと考えていました
考え方が変わったのは、大規模プロジェクトで外部のコンサルによるプロジェクト管理支援を導入したケースを見たからなのです

コンサルの提供するプロジェクトマネジメント支援業務は、沢山のワークシートや定量的に進捗を管理する手法を提供もあり、それはそれでとても勉強になるものですが
プロジェクトの進捗会議では遅延が発生したチームのリーダーは、遅延の原因分析と（遅延）回復策がセットで求められます

これ自体は、教科書通りの対応ですが、綻びが出始めたプロジェクトでこれをやるとどうなるか？
報告の質が急速に低下するのです
ひとつは、隠蔽の意図のあるなしに関わらず、遅延が発生していないことにしたくなる。具体的には、リスケをして納期を伸ばすことでオンスケと報告したり、レビューや上位者の承認を待たず担当者の作業が終わったところで作業完了とする
ふたつめは、遅延対策を考えてから報告を行うため遅延発生報告が遅れることです
進捗報告の正確性を担保することは、プロジェクトマネジメントの生命線であるに関わらず、そんな事象が発生するケースが少なくありません

そんな事例を何件か見てきたので、進捗報告と遅延対策はそれぞれ分けて管理するのが良いのではないかと考えるようになりました
そのため、現在のスタンスは、進捗報告は進捗報告。遅延対策を考える暇があったらまず、遅延発生のファクトだけを伝えること
これが、
「進捗報告（遅延報告）をするときは、遅延対策は考えてくるな！」の趣旨なのです