post-1395

システム管理計画変更時にプロジェクト・スコープの修正ができず、収支も悪化

職業:システムエンジニア
困った依頼:金融機関の業務管理システムの開発

大手システム開発専門会社のシステム管理計画作成を担当

困った案件は、大規模システム開発プロジェクトを開始するにあたって、プロジェクト・マネジメント・オフィスを設置。システム管理計画の作成を依頼されたもの。

クライアントは500名規模のシステム開発専門会社。拠点は東日本と西日本に点在しており、各拠点間でロケーションギャップがあった。

クライアント側のプロジェクト・マネジメント・オフィスの担当者はシステム開発を10から20年以上経験してきており、システム開発にプロジェクト・マネジメントの知識、スキルを一定有している。

口頭指示が多く、寄せ集めメンバーなので全体会議もできない

しかしながら、作業に関する指示は口頭が多く、その内容を当方に文章化させる「丸投げ体質」の印象。また、プロジェクト・マネジメント・オフィスの立ち上げと同時に寄せ集められたメンバであること、他業務と兼務している担当者も多く、全員が打ち合わせに参加できる会議体は、週2回、1回2時間程度が限界であった。

本案件はPM1名、メンバーが2名。パートタイムの作業支援サポート1名の全4名で関わったプロジェクト。キックオフから管理計画の作成作業を完了し、納品まで3ヶ月かかった。

プロジェクト・マネジメント・オフィスの合意形成に時間を要する

開発期間が長期間に亘ることと、システム開発規模が900人月を超える見積もりであったため、システム管理計画を作成するにあたって基本方針を作成。基本方針に基づいて、個々のシステム管理計画案を作成し、担当者へレビュー。その後、プロジェクト・マネジメント・オフィス全体会議で説明し、PM承認を得る流れで作業を進めていた。

しかしながら、プロジェクト・マネジメント・オフィス全体会議で合意形成をとることに多くの時間を要してしまった。

例えば、システム管理工数を2割設定するか、否かという議論の際に、論点設定、複数の対応案を検討し、メリットとデメリットを比較し、当方が対応案を設定し、担当者レビューを経たものの、プロジェクト・マネジメント・オフィス全体会議の説明の場で紛糾してしまう。

その理由は、実際の開発現場で予算管理をできない、システム担当役員がシステム管理工数を認めないなどの理由であった。そこで、システム管理工数を極小化して、システム管理計画を作成した。

リスク管理重視のシステム管理計画に変更

クライアントでは、本プロジェクトと並行して、中規模のシステム開発の検討に着手していた。そのシステム開発は新技術を導入するプロジェクトという特徴をもっており、リスク管理にコストや人員を配置したプロジェクトであった。そのため、システム管理計画もリスク管理に重点をおいて進めていた。

そのプロジェクト説明直後にシステム担当役員へ本プロジェクトのシステム管理計画を説明したため「大規模プロジェクトこそ十分なリスク管理を行うべき」という指摘を受け、リスクと対応策の説明を行うべきところ、システム管理計画をリスク管理に重点をおいた内容に修正する必要があった。

システム管理計画の修正が相次ぎモチベーションダウン

上述の通り、リスク管理に端を発して、要員管理、品質管理をプロジェクト間で共通で行うことになった。期間、規模、担当者も相違するプロジェクトのため、共通化すべき箇所の洗い上げは困難を極めた。

つまり、共通化すべき箇所は当方に「丸投げ」され、固有箇所の指摘がなかったからである。この主体性の欠如の対応には、極めて苦労した。また、上位会議体からの指摘事項を100%対応する必要があったからだ。

加えて、作成した変更案が上位会議体からの評価が低い場合に、当方のスキル問題へ発展することもあった。それゆえ、当方のメンバは疲弊し、1名はプロジェクト途上で要員交代をせざるを得なくなった。

クライアント側担当者も相次いでプロジェクトを離脱

クライアント側担当者においても、他プロジェクトとの作業調整により、時期をずらしたものの主担当者が離脱した。それぞれが担当していた範囲は別の担当者や新任担当者が一応引き継いだものの、これまでの経緯説明を当方が行い、システム管理計画の内容を理解することから再スタートさせる必要があった。

過去の会議議事録、資料、修正履歴を説明することとなり、再実施となるタスクが多数発生した。このことにより、当方のプロジェクト上の収支状況を悪化させた。

クライント側の外部環境は3ヶ月の間でかわっていたにもかかわらず、当初設定、合意していたプロジェクト・スコープで進めていたことが悔やまれる。基本方針をぼんやりと広義に定義したために、下位文書の修正範囲が広がってしまった。今後は、プロジェクト・スコープを明確にして、作業の変更に対して妥当な評価をうける様にしたい。