プロジェクトの進捗定例でよく聞く「順調です」の報告を聞いて満足していませんか？
PM・PMOをするならしっかりと自分の目と耳で作業や成果物を見て、聞いて判断しましょう！
たかはし主任はこれまで何度も炎上案件を見てきました。
その多くは、遅延そのものよりも「遅延の向き合い方」を間違えたことが原因でした。
PM・PMOをこれからやる人に伝えたいのはひとつ。
遅延は必ず起こします。マネジメントの腕の見せどころです。
遅延の原因はだいたい3つに分かれる
遅れが見えたとき、まずやるべきは犯人探しではありません。
冷静な分類です。
自社要因
・見積りが甘い
・設計の品質が低く手戻り
・スキル不足
・レビューが機能していない
よくある遅延の多くはここです。
たかはし主任が若手PMだった頃、「設計2週間」と見積もった工程が、実際には4週間かかりました。
理由は単純で、優秀なエンジニア前提でスケジュールを計画していたからです。
理想で引いたスケジュールは、現実では崩れます。
他ベンダ要因
・APIが来ない
・環境が準備されない
・仕様が固まらない
ある案件では、外部ベンダのAPI提供が3週間遅れました。
でも当時の私は「待つしかない」と思っていました。
後から振り返ると、
代替モック作成や並行テストなど、打てる手はあったのです。
他ベンダに依存しているからといて自分たちでできることは無い、と考えることは違います。
顧客要因
・承認が遅い
・要件が揺れる
・決裁者が不在
顧客都合はコントロールできないと思いますよね。
でも、期限を明文化できていなかった、承認に至る判断材料が準備できない、説明が足りない、資料に不備があるなど、多くの場合、PM側にも要因があります。
遅延したら最初に確認するのは「クリティカルパス」
若い頃の私は、遅延報告を受けるたびに全員に作業を急がせました。
でもある先輩に言われました。
「それ、クリティカルなの？」
そこで初めて真剣にクリティカルパスを意識しました。
クリティカルパスとは、
そこが1日遅れればプロジェクト全体が1日遅れる経路。
逆に言えば、
そこ以外は吸収できる可能性がある。
全部を急がせるのはマネジメントではありません。
構造を見抜くことがPMの仕事です。
立て直しの3つの選択肢
クラッシング
人を増やす、残業する、外注する。
コストを増やして時間を買う方法。
ただし経験上、
人を増やせば早くなる、は幻想です。
教育コストとコミュニケーション負荷が増え、
逆に遅れることもあります。
私は一度、応援要員を5人入れて混乱させました。
あのとき学んだのは、
増員は戦略的にやらないと逆効果ということ。
ファストトラッキング
順番を並列にする方法。
設計が完全に終わる前に開発を始める。
テスト設計と実装を同時に進める。
短縮効果は大きい。
でも手戻りリスクも大きい。
これは「覚悟」がいる打ち手です。
スコープ調整
実は最も現実的。
すべての要件、成果物を納期どおりに納めることは理想ですが、納期・品質・コストはトレードオフです。
ある案件で、機能の一部を次フェーズに送ったことで、炎上を回避できたことがあります。
削るのは悪ではありません。守るべきものを守る判断です。
PM・PMOがやるべきこと
遅延が見えたら、
- 事実確認（本当にクリティカルか）
- 回復シナリオを複数提示
- リスクを可視化して合意形成
「どうしますか？」ではなく「この3案があります」。
これがPMの価値です。
最後に
遅延ゼロのプロジェクトは存在しません。
違いは、
・感情で動くPM
・構造で動くPM
どちらかです。
クリティカルパスを理解し、クラッシングの限界を知り、スコープ調整を恐れない。
それができれば、炎上は経験値に変わります。
PM・PMOは調整役ではありません。プロジェクトの舵取り役です。
遅延は怖くない。怖いのは、構造を見ずに走ることです。