DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 関和美の記事一覧 > 【第11回】あまり思い出したくない失敗事例


【第11回】あまり思い出したくない失敗事例

Pocket

< 前回 | 目次 | 次回 >

今回は失敗したPMO活動の事例についてご紹介します。
こちらも私がPMOとして参画したプロジェクトで、成果が出ないまま解散した事例です。お客様は小売業B社情報システム部、新規事業立ち上げのため基幹システム構築するプロジェクトです。

まずはプロジェクトスコープ・体制です

  • 情報システム部で基幹業務の構築を実施。
  • 構築の支援としてSIerC社が参加。
  • B社及びC社チームは商品管理・受注管理・課金管理等の幾つかの業務チーム、基盤チーム、試験チーム、運用チーム、管理チームで構成されている。
  • 要件定義フェーズは、基本はB社情報システム部の数名で実施。C社は支援レベルで参画。
  • 設計フェーズ以降はC社が主体で実施。

プロジェクトの進捗具合、状況は

  • 構築途中の設計フェーズ、サービス開始まで一年。
  • 設計フェーズを行っているが、B社の各チームリーダーしか設計の可否を判断できず、遅延している。
  • 試験計画、準備が全く進んでいない。
  • 運用準備についても全く進んでいない。
  • チームリーダーが忙しくプロジェクトマネージャへの報告がないため、プロジェクトマネージャが機能していない。(全体スケジュールがない、報告書がない)
  • 上層部への報告・エスカレーションがなく、うまく進んでいるのかどうかわからない。

PMOを設置する背景は...

  • CIOには、情報システム部でうまく進んでいないとの状況は伝わっているが、詳細状況は把握できない。
  • 情報システム部の立て直しのためCIOがPMOを設置
    このような状況でPMOメンバーの一人として参画したのです。

PMO活動を定義する

先に書いたプロジェクトの状況をヒアリング等により確認した後、PMO活動を定義しました。

  • プロジェクト全体スケジュールを作成する。
  • プロジェクトマネージャが各チーム状況を把握することができるように報告書を整備する。
  • 工程の承認プロセスを定義する。
  • 試験計画を作成し、先の工程の準備を行う。障害管理方法を定義する。
  • サービスイン後に運用ができるよう体制と運用プロセスを定義する。

定義したPMO活動の中で、一番大変だったプロジェクトマネジメントに関する活動の詳細について記載します。

全体スケジュールを作成する

まずは、チーム毎にC社が作成したスケジュールはあったのですが、全体が把握できるスケジュールがなかったこと、B社で実施すべきタスクが上がっていなかったことから、B社のタスクを洗い出し、チーム毎のスケジュールと整合性を取りながらB社タスクを入れた全体スケジュールを作成しました。また、スケジュールには進捗を記入できるようにしました。
進捗と一緒に課題が解るように報告書のフォーマットも作成しました。

しかし、全体スケジュールの進捗報告を導入しようとしたところ...

PMOで作成したスケジュールを各チームリーダーに説明し、PMOであげたB社タスクの実現性の確認、必要に応じて詳細化してもらうよう依頼しました。また週一回の進捗の記入と報告書の記入を依頼しました。
が、報告日になってもスケジュールに記載しているタスクが詳細化されることも、進捗が記入されることも、報告書が提示されることもありませんでした。
催促すると「忙しくてタスクを確認する時間も報告書を作成する時間もない」とのことです。

一方で承認プロセスを定義しました

各チームでは仕様変更が多発していますが、プロジェクトマネージャはどのような仕様変更が発生しているか把握しておらずチーム内で勝手に合意し設計変更を行っている状況でしたので、設計変更、工程完了等のタイミングでプロジェクトマネージャの承認を行うようにプロセスを定義しました。

でも、これも承認プロセスを導入したところ...

仕様変更について必ず仕様変更書を記入しプロジェクトマネージャの承認を得るようにしました。
しかし、プロジェクトマネージャはそもそもの仕様を把握していないため、内容を聞いても理解することができず「仕様変更するしかないんだろう」と言って承認するようになりました。
工程完了も全く同じで「承認するしかないんだろう」といって承認している状況でセレモニーになってしまいました。

このように進捗報告の運用、承認プロセス その他マネジメントプロセスを導入しようとしたところ現場では理解されなく、にっちもさっちもいかなくなりました。むしろ、混乱を招いた形になりPMOに対する風当たりが厳しいものとなりました。PMOチームは、頭を抱える結果となる一方、至急改善の命がくだりました。 私たちは、結果PMO活動の中で特にプロジェクトマネジメントプロセスの改善の活動はうまく導入に漕ぎ着けることができませんでした。なぜでしょうか?
次回は導入がうまく行かなかった原因です。

**********
本格的な夏になってきましたね。現在何カ所かのオフィスビルで仕事をしていますが、去年の節電を忘れたかのようにエアコンがガンガン効いていて寒いくらいのビルもありエアコン依存症です。家でもエアコンを入れようかと思ったら、なんとエアコンの吹き出し口を見てみると真っ黒!掃除しても中の方まで掃除できません。ということでハウスクリーニング業者にお願いしたところ、7月下旬まで予約でいっぱいとのこと。
現在エアコンなしで生活、連載を書こうと思っても暑くてダレダレ、なかなか筆が進まない回でした。

< 前回 | 目次 | 次回 >

| 目次
Pocket

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
関和美
奈良女子大学 理学部 物理学科(現 物理科学科)卒業 日本電信電話株式会社に入社(NTT分社化によりエヌ・ティ・ティ・コミュニケーションズ株式会社に転籍)。主に金融系のSEとしてNWシステム 構築の設計、アプリケーション開発の要件定義、設計工程を経験し、その後プロジェクトマネジャーとしてプロジェクトに携わる。 2007年より現職。大規模プロジェクトにおけるPMO(Project Management Office)の運営およびプロジェクトマネジメント支援や、IT構想企画の支援を行っている。PMP。

Recent Entries最近の記事