プロジェクト管理：そのWBSって本当にFinish to Startですか？

Finish to Startは４つのタイプのうち、１番時間がかかるタスク依存性なので。

■　クリティカルパスを詳細レベルで把握していない
クリティカルパスの定義はプロジェクト管理をする者ならば誰でも知っています。
でも、実際で有効に使っている人は結構少ないです。

原因は、フェーズに区切られたウォーターフォール型のシステム開発プロジェクトが多く、概要レベルで見るとクリティカルパスは一見明白だから。

「クリティカルパスはどこですか？」と私が質問すると
「フェーズ1→フェーズ2→フェーズ3→フェーズ4 がクリティカルパスです。」と答えるPMもいます。

確かに、概要レベルのクリティカルパスとしては正解です。

しかし、クリティカスパスでの遅延が発生する場所はあくまでも詳細なタスクレベルです。

マスタースケジュール図などの概要レベルではなく、WBSなどの詳細なレベルでクリティカルパスを特定することが重要です。

詳細レベルで見ると、クリティカルパスは複雑で、遅延が発生すると変化することもあります。

クリティカルパスの自動計算機能があるので、MS-Projectなどのプロジェクト管理ツールはできるだけ使いましょう。

PMの勘とは違った意外な計算結果が出ることもあります。

--- 中級者でもよくある間違い ---------

■　プロジェクト管理工数に十分な工数・時間が割り当てられていない
・ プロジェクト管理計画書の作成タスク
・ 進捗会議の準備タスク
などのPM自身が費やす工数や時間が十分に想定されていないケースです。

「PMの仕事も大変なんです・・・」と言えないPM自身のプライドや照れが原因の場合もあります。

プロジェクトの規模や性質にもよるので一概には言えませんが、目安としては、プロジェクト全体工数のうちの5～15%はプロジェクト管理工数を想定するべきです。

■　一人の頭に頼りすぎたスケジュール作成
PMが一人でゼロからタスクを抽出してしまうケースです。

ゼロから作成するアプローチ以外にも
現実的なスケジュールを作成する際のアプローチにはいくつかあります。

・ 似たようなプロジェクトを参考にする
・ 各メンバーに詳細タスクを抽出してもらって積み上げる
・ 業務領域の専門家にレビューしてもらう
・ 成果物の一覧から逆算してタスクを抽出する
・ 業務領域の専門家にレビューしてもらう

特に、組織あるいは個人として過去に経験のあるプロジェクトの場合は、恥も外見も捨てて、古いスケジュールをパクリましょう。
なぜなら、
・ 過去の実績はヘタな見積よりも数十倍も精度がいいから
・ 過去の実績はどの部分がムリな計画になりやすいかを教えてくれるから