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

menuclear
ホーム > ブログ > 関和美の記事一覧 > 【第9回】実際の現場を見てみよう (4)


【第9回】実際の現場を見てみよう (4)


< 前回 | 目次 | 次回 >

前回は、要件定義の標準を策定し、その導入のため実際にPMOメンバーが要件定義を実施することにより“要件定義を行うことによりサービス、業務、システムの検討漏れを減らす”という目的を理解してもらえた所まででした。

その後の要件定義は

PMOメンバーは4名であり、常に要件定義書を作り続けることはできませんし、また検討をするプロジェクトメンバーが作成なければプロジェクトメンバーのスキルアップに繋がりません。
PMOメンバーで作成した要件定義実施要領と要件定義書を基に、次のプロジェクトよりプロジェクトメンバー(A社社員)で要件定義を実施することになりました。ただ、今までモデル化したことのない人は、実施要領通りに進めようと思っても取っ掛かりから躓いたり、うまく表現できないということは多々あるため、その度にPMOメンバーと相談しながら作成していくことで、徐々にPMOメンバーの参画度が減り要件定義が定着していきました。

もう1つのPMO活動

前々回、“当面”のPMO活動(PMO要求)を2つに絞ったことを書きましたが、もう1つのPMO活動
「プロジェクト活動で発生した解決していない問題・課題ものを収集し、開発ベンダとともに原因分析、対策を検討する」
も同時に進めました。

ここで言う問題・課題とは、例えばリリース作業でミスをした場合にミスは修正したが、なぜミスが発生したかの根本原因を解決していないことを指しています。
根本原因が特定、解決されていない問題・課題が初期構築から50コ程度放置されており、それを一つ一つ関係者にヒアリングしながら原因特定と対策の検討を行いました。
中には複数の原因が絡み合って発生した事象も少なくありません。また、別々の問題・課題が同じ原因により発生したものも多数ありました。
根本原因から導きだした対策も複数ありましたので、問題の数や影響度から対策の優先度を考え、PMOで実施すべき対策については、PMO活動に盛り込んでいくということを繰り返しました。

ちなみに、先にご紹介した「要件定義の充実」についても、問題から導きだした対策に含まれていました。
#「要件定義の充実」についてはPMOメンバーが必要だと“感じたこと”からスタートしたので、問題分析により導きだした対策にあってよかったです(^^;)

最終的に実施したPMO活動

PMOチームを構築した当初に組織長から提示されたPMOのスコープのうち、私がPMOとして参画していた間に活動したものとその結果です。

<組織長から提示されたPMOスコープ>
seki_chart120501a

1. 標準化活動

(1) プロジェクトマネジメント標準の策定・維持管理
既に初期構築から1年以上経過していたため、ある程度プロジェクトマネジメントは定着していましたが、リスク管理やコミュニケーション管理(エスカレーション)が不足しており、マネジメント層から現場で起こっている問題が見えにくいという問題があったため、一からプロジェクトマネジメント標準を策定するのではなく、不足部分(リスク・コミュニケーション)を拡充しました。

(2) 開発標準の策定・維持管理
要件定義の標準以外は既に標準が存在していましたが、初期構築前に作成したものであり実情と合致していない箇所があったため標準をメンテナンスしました。

2. 開発支援

(1) 追加開発による影響範囲の特定
要件定義の充実により影響範囲の特定の精度が上がりました。

(2) 新技術検討・技術サポート
残念ながら新技術を導入するシーンがなかったため未実施です。

(3) RFP作成支援
要件定義後RFPを提示する形で統一され、PMOとしては要件定義作成を支援することによりRFP作成に影響を与えることができました。

(4) 要件定義
PMOが作成するのではなくPMOは支援という形に変更しました。

(5) 基本設計
すでに開発ベンダB社が実施していました。組織長としては「ベンダ任せではなくA社で品質の向上させることができるように設計はA社で実施したい」という気持ちからA社(PMO)のスコープに含めていたのですが、他の対策の効果を確認してから本当にスコープ変更すべきかを検討するということで未実施でした。

(6) ポートフォリオ作成・管理
組織長がプロジェクトの実情を把握することが難しかったのですが、報告書を整備することにより解消されました。(ポートフォリオとはちょっと違いますが)

(7) 品質管理
開発ベンダB社任せだった品質について、発注側としてベンダ側からの品質報告書をどのように読み取るかを教育しました。また、PMOとしても問題を検知し必要に応じて対策検討に参加しアドバイスを行いました。

私が参画していた時点ではここまでを実施しましたが、以降もPMOを設置していると聞いていますのでさらに変化していることを期待しています!

次回は、製造業A社PMO活動の纏めと、別プロジェクトでの失敗事例のご紹介です。(涙)

*******
最近結婚した人が周りに何組かいます。結婚して数ヶ月経つと「ダンナさんが家事をしない」とか「頑張って家事をしているのに奥さんは認めてくれない」なんて愚痴っています。
夫は「頑張って掃除したぞ」と思っていても、妻にしてみたら「掃除機かけたけど棚にホコリのこっているじゃない(怒)」と思っていることもあり、もしかしたら要求(どこまできれいにすれば掃除は完了するのか=品質レベル)を合意していないからかもしれません。
家庭でも要求事項を確認し合意することは必要かもしれませんね。
と言っておきながら、ウチは「気になったら自らが対処する」方式ため要求事項なし。よって合意形成もありませんが...(笑)

< 前回 | 目次 | 次回 >

| 目次

採用情報
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最近の記事