PERT図を描け。騙されて描け。 - 室長のひとりごち

プログラム開発のように要件定義から工程を進めることでToDoを詳細化するプロジェクトのWBSは（スコープ漏れや機能漏れは除いて）、何をすれば作業が完了するか明確なので計画も見積もりも予実の較差の把握も対処もし易いのです。

ですが、企画や構想立案や事業立ち上げ的なものは、そうは行かないのです。なぜなら、アウトプットと要求品質が定義しようがないから。

＃うーん、アウトプットは企画書などのドキュメントには違いないけれど、何を書けばいいかはそのときどきによるんですよねぇ。あっても標題だけは統一フォーマットがあるかもしれないけれど、大体カウンターになるクライアントや偉い人の気分で変わるんだよなぁ。

流され易い

企画系のプロジェクトはとにかく流され易いのです。何に流され易いかって。それは、ステークホルダーが多くてそれぞれ好き勝手なことを思いつくままコメントするのを全部、受け止めなくてはと思って仕事をするから。

そう、仕事の進め方が流され易い。コンサルのように自己流であっても軸を持ってこのやり方に乗れと言い切れればいいのだけれど、まだ、経験の浅い担当だとそうも行かないのです。

特に、エンジニア上がりは流されますね。

なぜなら、お伺い体質が染み付いてしまっているから。どれだけ口すっぱく言ってもダメです。

本来であれば、委託を受けているとしても、シナリオを描いてステークホルダー全員を同じバスに乗せないといけないのです。バスに乗せる以上、どこを目指すのかバスガイドもしなくちゃいけない。

結果的に、お伺い体質のエンジニアは風見鶏になってしまうのです。

流されないために

では流されないために何をしたら良いか。

少なくとも何をするか、企画なら企画書を作らないとプロジェクトは終われないのだから、それがゴールになるのだけれど、その企画書のコンテンツはたたき台を作って、合意形成をしつつ、修正を掛けてどこかにソフトランディングさせないといけないのです。

こうした企画系のプロジェクトはシステム開発のように細く作業のWBSを切ったり、日程を当てはめてスケジュール化はしないので、そこに担当者が甘えてしまう悪魔の誘惑に負けてしまうパターンが多いです。

どうしたらいいかといえば、PERT図を描くのです。どうせ、WBSのワークパッケージの作業量は見積もりなんてできないでしょうが（仕切れていないのだから）、だからこそ、スケジュールをPERT図にしてマイルストーンからいつまでに終わらないと全体のスケジュールがオーバーランしますよと、企画系のプロジェクトで示し続けるのです。

PERT図を使ってステークホルダーの時間感覚を揃える、ということですね。