Public Memo For Me

プライベートなメモ帳だけど、公開することで理性を保つ

炎上プロジェクトの進捗管理あるある

今まで数々の炎上案件に突っ込まれ感じたことは、燃えるべくして燃えるケースが大半である。その中で特に共通項が多いの進捗管理。数々の炎上プロジェクトで共通する、イケてない進捗管理の内容をまとめ、自分が炎上プロジェクトを生み出さないようにと思いまとめた。
 
それでは早速、代表的な3つイケてない進捗管理の内容をデフォルメして紹介をさせていただき、当時にタイムスリップできるのであれば、どうすれば回避できたのか持論を述べていきたい。
 

 

進捗管理をしていない
早速の出オチ。そんなわけないでしょ、と思うかもしれないが、本当に多いケースである。ただ始めから進捗管理をしていなかったとわけでない。最初は進捗管理をしようとイロイロ管理表を作成し管理しようとしていた。ただここで緊急でやらないといけないこと、例えば顧客からの問い合わせやバグ対応等、が積み重なってしまい、目の前のタスクを消化することに精一杯となり進捗管理がお注科になる。そして、重要だけど緊急度のタスクがおざなりになり、ファイヤー!となる。
 
炎上の始まりはほとんどこのケースではないか、というのが持論である。
 
どうすればよかったのか?
 
全員で緊急度の高いタスクに向かわないこと、例えば全体を俯瞰できる人を1人残しておき、そいつに優先度や顧客との交渉をさせる。つまり手足部隊と頭部隊に分けて人を配置することが肝要である。
 
■作業担当者が複数名
炎上しないプロジェクトでもよく見られるケースである。例えば「ログイン画面設計書のレビュー」というタスクがあり、その担当者がAさん / Bさんとなっていた場合どうなるか?結論を言うと放置されてしまうことが大半である。またまだ2名の連名であれば放置される可能性は低いが、ひどいプロジェクトの場合、3名、4名の連名で定義されていれば、誰も手を付けないのは目に見えるであろう。
 
どうすればよかったのか?
 
答えは単純で担当者は必ず1名にすること。高いレイヤーで管理する場合、担当者名ではなくチーム名で担当を管理する場合もあるだろう。その場合はチーム名の隣に担当者名を用意し、そこにチームリーダ名を書くようにするだけで、タスクの遂行率は格段にあがり、炎上の火種を事前に消すことができる。
 
■タスクが細分化できていない
WBSやスケジュール表の最下層タスクの長さがどの程度が適切か?という問いがあるが、今までみてきた中で一番ひどいのは 20日”!?
 
よく考えてほしい、20日は営業日換算すれば、1カ月である。その間の進捗はどういう風に管理するのは非常に疑問であり、また、こんな管理をしているプロジェクトやチームは大体、毎回の進捗報告では、「順調です!!」と報告をしてくる。そして、完了日直前になり蓋を開けてみると、ほぼ手付かず、みたいなオカルトはよくある話しである。
 
これに関して言えば、管理する側も悪い。何をもって進捗管理をしているのか?報告内容の信ぴょう性はどう担保すればよいのか?を突っ込んで考えなかった代償である。
 
どうすればよかったのか?
 
個人的には最下層のタスクは最長3日までというルールにしているので、まずは長さにキャップをはめてスケジュールを引きなおさせる。また、絶対に3日間でないとだけか?と言われるとそうではない。ただその場合、進捗報告を受ける時に、「どこまで作業が進んでいて全体作業量から鑑みたうえで報告をしてほしい」と伝える。結果、逆にそっちのほうがメンドクサイので、割と3日間ルールに従ってくれる。
 
--------------------------
ここまで、代表的な3つを挙げたがこれ以外にも、
・タスクの階層化がイマイチ
・管理されていないタスクがある(抜け漏れだらけ)
・進捗率が99%から進まない問題
 
といった内容があるが、今回は割愛。プロジェクトの管理領域はいろいろあるが、個人的に一番大切な管理領域は、進捗管理であると考えている。そう、進捗管理を制すことができれば、プロジェクト管理の半分を制することになるというのが私の考えである。