プロジェクトを突然炎上させないために何を見たらよいか

「あのプロジェクトがさぁ、これまで『進捗はオンスケ、品質評価は問題なし』、って報告してたのに、月を跨いだら突然と進捗悪化、品質評価最悪、課題が遅延って報告してきたんだけど。」
「(ふうん)で？」
「これって、プロジェクトマネージメントでの“べからず”や“教訓”とか絶対やっていないし、そもそもちゃんとプロジェクトをマネージしていないよね。」
「そうだね。」
「でもさ、『報告がやってます。』って上がってくるんだから見つけようがないじゃない？」
「(そうかなぁ。)」
「どうすればいいと思う？」
「いや、どうしたいの？」
「勿論、トラブルプロジェクトを無くしたいし、煙くらいで消化したいんだよ。」

「いやさ、あまりこれ言いたくないんだけど。」
「いいよ、教えて。センセイ♡」
「報告書をなんで信用するの？」
「えッ？」
「ほら……。だから言いたくないって言ったんだけど。」
「いやいや、どうぞ続けて。」
「ヒントは最初にキミが言っていたジャン。」
「何さ。いいから早く教えてよ。」
「報告書なんて信用しないで現物見ればいいんだよ。」
「何を？」
「WBSと課題一覧。」
「どこを？」
「毎週の較差をトーレスすればいいんだよ。」
「どこを？」
「項目の増減。あと、due dateとの差異。」
「あぁ、もう全部言わせるなよ///」

プロジェクトは突然デスマになったり、進捗上の問題が発生したり、顧客から無理難題を突きつけられたりするわけではありません。プロジェクトの契約でのプロジェクトのゴールの共通理解、プロジェクトのキックオフでのゴールの確認、日々の小さなタスクのアウトプットの積み重ね、これらがつもりつもって大炎上につながるわけです。

じゃあ、プロジェクトを第三者の目線でレビューするロールの人はプロジェクトに直接参画しないとその「予兆を見つけられないの？」と思うかもしれないけれど、そうでもないんです。大体、マネージャなら傘下のメンバがそれぞれプロジェクトをやっているのですから事実上マネージャはプログラム(＝複数のプロジェクトの意)マネージャなんですよ。そうであるなら、現実問題としてマネージャは“危ない又はビジネス上重要な”プロジェクトに自分のリソースを配分するしかできないし、それに入らないプロジェクトもどこかでは見てなければアンコントロールになってしまうから見ざる得ない。

複数のプロジェクトを濃淡をつけて見るわけですが、その濃淡をつけてみるにしても淡く見るプロジェクトはどこを見るのか、どう見るのか、っていうところなんですね。これを文字だけの報告書を読んで安心していると冒頭のようなことに陥るんですよ。

プロジェクトは日程が進めば直近のタスクがより具体化するのですから、WBSも具体的なものになるのでWBSの総数が増えていきます。WBSのアウトプットも直近に完了しなければならないものが増えていくので予定完了日を迎えるタスクも増えてくる。それを少なくとも週次のスパンで較差を見ていくんですよ。

プロジェクトが健全に育っているなら、結合試験工程までWBSは増加していくものです。そしてWBSの予定完了日を迎えるものも逐次増加していくわけです。それが予定完了日ごとにタスクごとにはでっこみ引っ込みはあるにしても全体感としてトータルとしてイーブンになるようにコントロールされているんですよ。

何か問題があるプロジェクトだと、そうならない。健全なプロジェクトと逆の状況になっているかどうか比較してみればいいんです。工程の進捗に合わせて適度にWBSが増加しているか、予定完了日に合わせて完了しているか、を。

あと結構大事なのは課題の上がり方と消化状況です。工程の進捗に合わせて相当の課題が出てこないプロジェクトは要注意です。WBSと同じように予定完了日をオーバーランしている課題が多いプロジェクトも危ない予兆です。

そうした情報の較差の推移を抑えつつ、マイルストーンごとにアウトプットされるdeliverableの現物をちら見でもいいので現物確認をするんです。

人は人に見られるという行為がちゃんとやらなきゃといプレッシャになるのですから、そうした「現物を見るよ。」という意思表示と実際みることでの緊張感を与えるということが現場でのプロジェクトをちゃんと回そうという動機にもなるのです。