PMOの活用は、なるべく早期から
では、PMOはプロジェクトのどのタイミングから起動させればいいのだろうか。われわれがPMOを担う場合には、遅くとも要件定義工程の後半か、設計工程の前半には参画している状態でいる必要がある、とクライアントには伝えている。その理由は、大きくは以下の2つだ。
理由（1）下流で顕在化するトラブルの多くは、上流で仕込まれている
プロジェクトにおける問題は、開発やテストなど下流工程で一気に噴出することが多いが、その原因の多くは要件定義や設計工程にある。検討スコープが漏れていた、要件定義が甘かった、ユーザー企業のキーマンの認識ギャップなどである。
よって、上流工程でそれらのリスクの芽が摘まれている必要がある。
理由（2）プロジェクト体制や契約形態が固まってからの軌道修正は困難
詳細設計・内部設計が始まり、開発工程まで進んでしまうと、SI側の体制変更や調整が難しくなり、顕在化した問題を解決するための労力が倍増する。たとえば、要件定義の甘さが原因で下流の問題が発覚したケースを想定して考えてみよう。
上流にさかのぼってのリカバリーも含めると、体制の強化やスケジュールの調整が必要となるわけだが、開発工程は、開発ボリュームや納期が契約上明記された請負契約になっていることが多く、単純にその変更だけで時間と工数が費やされていく。
また、ボリュームが大きいプロジェクトの開発では、投入人数がピークを迎える時期にあたり、参加している開発会社の数が最も多くなる。ここで計画と体制を調整することは、元締め側のSIとしても相当タフな作業になると同時に、リカバリーのための適材を見つけようにも空いていないという問題も起きやすい。
そもそも、プロジェクトの体制構築にあたっても、特定領域に強みを持つSIには、無理やり広い範囲の作業を担当してもらうよりも、得意作業に集中してもらった方がプロジェクトの成功につながる。PMOならばプロジェクトの本格稼働を前に、適材適所のアサインメントを、全体を見渡しながら実施できる。SIから一部管理業務や作業を巻き取ることで、各社に自身の強みに集中してもらうことも可能だ。
システム構築プロジェクト、トラブルの芽は前工程にある
