「プロジェクトの進捗は遅れるもの」という考えはもう許されない。追加メンバーの投入やスコープダウンが難しくなったことで、工程やタスクごとに進捗を守ることが求められる。チームのマネジメントや個人の仕事を工夫し、進捗遅れを一掃しよう。
ITベンダーA社のプロジェクトマネジャーである山田氏（仮名）は2年前、システム開発の進捗遅れで、悔しい思いをした。それは、外資系のユーザー企業B社の勤怠管理システムの構築を担当したときのことだった。
このプロジェクトは当初、A社の別のプロジェクトマネジャーが担当していた。しかしB社の勤怠の業務ルールが極めて複雑なこともあり、途中からプロジェクトが進まなくなった。そこで、勤怠管理システムの構築経験が豊富な山田氏が、プロジェクトマネジャーとしてプロジェクトを引き継ぐことになった。
プロジェクトオーナーであるB社の人事部長と協議して納期を設定し直したが、要件定義を最初からやり直す必要があり、ほとんど余裕期間（バッファー）を確保できなかった。
稼働が2日遅れ人事部長が更迭
タイトなスケジュールだったにもかかわらず、山田氏は「いいシステムを構築してB社の信頼を得たい」と考え、要件定義や基本設計をじっくりと行った。その分、進捗遅れが生じた。しかし「プロジェクトの終盤に挽回すればいい」とあまり気に掛けなかった。
実際、プロジェクトの終盤になるとチーム5人が一丸となって追い込みをかけた。地方の営業所でのテストで大きなトラブルが発生したこともあり納期には間に合わなかったが、なんとか2日遅れで稼働させることができた。B社の人事部長から感謝の言葉を掛けてもらい、山田氏は手応えを感じた。
ところがしばらくして、山田氏はその人事部長が更迭されたことを知った。新システムの稼働が計画よりも2日遅れた責任を取らされたらしい。プロジェクトの事後監査で、プロジェクトオーナーである人事部長のマネジメント能力が不足している、と判断されたようだった。
この1件で山田氏は、進捗遅れに対する自らの考えの甘さを痛感した。「プロジェクトの終盤には予期せぬトラブルが起こる。納期を守るには序盤から進捗遅れを起こしてはいけない」（山田氏）。それ以来、進捗遅れを防ぐため、進捗管理や課題管理のやり方を改善するなど、プロジェクトマネジメントの工夫を積み重ねている。
人員追加やスコープダウンが難しく
2日遅れで責任者が更迭というのは極端な例だが、一般にプロジェクトの事後監査が厳しくなっており、稼働の遅れによってプロジェクトオーナーやプロジェクトマネジャーの責任が問われることがある。双日システムズの小松原 健氏（エンタープライズソリューション本部 SGソリューション部 部長）は「利用部門におけるビジネスのスピードが上がっており、少しでも早く新システムを使いたいという要望が近年ますます強くなっている」と話す。
一方で、「進捗が遅れたときに挽回するための打ち手が減り、プロジェクトマネジャーにとってハードルが上がっている」とNECの奥沢 薫氏（システム技術統括本部 主席PMO）は指摘する（図1）。例えば、プロジェクトの予算の縮減で、進捗遅れを挽回するための追加メンバーの投入が難しくなった。さらに、2次開発プロジェクトへの先送りを前提としたスコープダウン（システム機能や帳票などの削減）もできないケースが増えている。2次開発プロジェクトが本当にあるのかどうか、あったとしてもどれだけの予算がつくのかが分からないからである。
このように、今やいったん進捗が遅れると挽回するのは容易ではない。そのため、プロジェクトの全工程を通じて、工程やタスクごとに進捗を守ることが求められる。
