前回の続きで、プロジェクト内における進捗管理の頻度と方法について。
※ここでプロジェクトとはITシステム構築プロジェクトを差します。
まず、プロジェクトにおける進捗確認・会議の頻度ってどの位でしょう？
プロジェクトの規模や工期によって差はあるでしょうが、一般的なのが週に１回程度では
ないでしょうか？（それが遅れが発生しだすと間隔が短くなり、トラブルが発生すると
酷いときは数時間毎になったりしますが）
また、進捗の確認方法としては各作業・機能毎に「○％の進捗」という報告を元にガント
チャートに稲妻線を引いて、遅れが見えるものに対して「対策を報告させる」という方法
が多いのではないでしょうか？
私の見聞きした中での話ですが、この方法で何の問題も無く成功したプロジェクトはあり
ません。もしあったら教えて欲しいくらいです。
では、どうするか？
私が一番参考にしているのが、ゴールドラット博士の著書、
「
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?」です。
本の中には、工程作成の考え方から書かれていますが、今回は割愛して進捗管理の
部分のみ書きます。
前回書いた、作業分割及び担当の割り当てができている前提ですが、進捗管理の方法として
やるべきは、以下の２点のみです。
（１）後何日で終わるのか？
（２）それで終わらない可能性として、どんな問題が想定されるのか？
（１）について、例えば「進捗９０％」の状態が、それに達するまでよりも長く続いてい
るなんてことありませんか？（そもそも何を基準に％を出しているのかさえ不明だったり）
始まりからではなく、終わりを基準に進捗を管理しようというのが（１）の意味です。
また終わりを基準に考えると、それまでに後何をしなければならないのかを意識します。
そこでもう一歩深く考えさせるのが（２）の確認になります。
「予定通り終わるには、残り○○という作業をしなければならない」
→「その為には△△と□□の準備をしておかなければならない」
→「もし△△が予定通り準備できなかったら、○○という作業に着手できない」
となると、「△△が予定通りに準備可能かどうか、事前に確認しなければいけない」という
アクションアイテムが明確になり、事前にリスクを回避でき、遅れが防げるという訳です。
最初のうちは、作業を落とし込むことが難しいかもしれませんが、やってみる価値は
絶対にあります！
まずは、小さなプロジェクトからでも試してみる価値はあります！