声に出して読みたくなるプロジェクト計画書

on


プロジェクトマネージャがプロジェクトをはじめるときに作るドキュメントはプロジェクト計画書です。これが無ければプロジェクトの行き先が分からないからです。
そのプロジェクト計画書は一体誰のために作るのかをかんがえたことがあるでしょうか。管理部門がレビューするだめですか。上司がチェックするためですか。それとも他に読み手が居るのですか。


プロジェクト計画書は誰のもの？
プロジェクト計画書は、プロジェクトマネージャがこれから自分が歩むプロジェクトの行く末をシナリオとして描くものであって、それ自体誰もが合意するでしょう。
では、プロジェクト計画書は誰のものか、と問われたらどう答えますか。そもそも、そんなことを問われると思ったことがあるでしょうか。
＃まぁ、余り無いのかもしれませんねぇ。

プロジェクトマネージャを中心としたステークホルダを書き出してみましょう。

  • 上司、上長
  • 品質管理部門
  • 営業
  • 顧客
  • ベンダ
  • パートナ
  • プロジェクトチーム


上司は読むでしょうね、プロジェクト計画書。眺めるくらいかもしれませんけど。
品質管理部門は、ウォークスルーでレビューするでしょう。
営業は、読まないですね。
顧客には見せないですね。組織内の見せられない情報もあるでしょし。
ベンダにも見せないですね。顧客と同じ理由です。
パートなも同じですね。
プロジェクトチームには、一部見せるでしょうね。お金以外とか。

こうして棚卸ししてみると、自分の所属する組織の中と、プロジェクトマネジメント若しくはプロジェクトの品質を所掌とする品質管理部門、そして、プロジェクトチームのメンバが読者対象になるということが分かります。

一方、顧客へはまったく見せないかというと、プロジェクトキックオフするときにお作法的なことやスケジュール的なことは見せるものです。あと、プロジェクト管理手法(進捗管理や課題管理など)も共有して合意するでしょう。

こうしてみると、へーと思うわけです。自分だけの文書ではないのだと。


読んでもらって初めて価値が生まれる
自分が作り、自分だけで帰結する文書なら、メモでも走り書きでもマインドマップでもよいでしょう。でも、読者が事前に想定されるなら、書き手の重いが誤謬無く伝わるように配慮したいものです。それが、将来生まれる無駄を省くための予防保全に当たるからです。

誤謬無く書くことも、読み手の力量とそのときに持ち合わせている情報を処理する力量に委ねられますから、まったく排除できるわけでもありません。でも、“しくみとして予防できることは予防しておけ”ということです。

プロジェクト計画書は読んでもらい、そして理解してもらい、行動を供にしてもらうのです。

プロジェクト計画書を作る意味は、そこにもあるということになります。逆に言えば、読んでもらえないプロジェクト計画書のコンテンツはゴミだということです。ダメ出しを貰ったのと同じ。
勿論、読者に要求するレベルはあるでしょうが、最低限ステークホルダとなる人たちを想定して書かねばなりません。

ステークホルダに読んでもらうプロジェクト計画書は、どこまで書ければ見せられるでしょうか。詳細まで書かれている完全版である必要があるでしょうか。

品質管理部門を除けば、完全版は早急に読ませる必要は無いでしょう。それより、早い段階で、プロジェクトと全体が見渡せる一枚モノのオーバービュな資料で読ませたほうが全体を把握できるので読み手からも喜ばれるでしょう。

そんなときに“プロジェクトチャート”が便利です。

プロジェクトマネージャがやりたいこと、プロジェクトマネージャが気にしていることなど、これ1枚で読者の理解を助けます。

また、プロジェクトマネージャも完全版のプロジェクト計画書を読むより、1枚のチャートを見せて、読み上げて説明する方がどれだけこのプロジェクトに対する気持ちが伝わるでしょうか。


レビューアのコメントは大事に戴く(だけにしておく)
完全版のプロジェクト計画書でも“プロジェクトチャート”でも読み手に読み上げて説明すれば、質疑やコメントがつくでしょう。質疑がでたらありがたく受け止め、質疑の本質が最もだと思えるのなら、プロジェクトチャートの記載内容をリファクタリングすればよいです。
気をつけておきたいことは、読み手の質疑やレビューアがつけるコメントをすべて取り込んではいけない、ということです。読み手もレビューアも初見のドキュメントに対して、夫々が持ち合わせている経験値からだけで自分がそのあとのプロジェクトのキャリーをしないことについてモノを申しているのです。

これからキャリーするのはプロジェクトマネージャです。そのコメントをそのままプロジェクト計画に取り入れたらどのような副作用が起きるかを判断できるのはプロジェクトマネージャしかいません。
だからこそ、コメントを受け止めた後、まったく取り入れないのか、一部取り入れるのか、それとも全面的に取り入れるのかを考慮しなくてはならないのです。