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

＜　前回　｜　目次　｜　次回　＞

ＰＭＯの具体的な役割や仕事を考える前にまずはＰＭＯがなぜ必要なのかを考えてみましょう。
皆さんプロジェクトに携わっていると以下のような場面に遭遇しませんか？

【ケース１】　チームの報告書がばらばら・・・・

• Ａチームの報告書には表がついているけど、Bチームの報告書は文章しかない。
• Ｃチームの報告書には進捗が「設計書作成：予定４０％、実績３０％、３日遅れ」と数字で表記されているが、Ｄチームの報告書には「設計工程：遅延なし」「試験計画：少々の遅延」と書かれておりどちらの方がより問題のあるチームなのか解らない。
• Ｅチームの報告書には課題とその対応策が書かれているが、Ｆチームには課題しか書かれていない。

【ケース２】　組織長やお客様への報告で突っ込まれてしまう・・・・

• ＰＭが各チームの報告を取り纏めて部長に報告。しかし纏めた報告書の内容について部長から質問を受けても詳細な部分は答えられない。
• お客様から「クリティカルな問題は？」とか「課題に対する対応策は？」と聞かれても答えられない。

【ケース３】過去のいくつかのプロジェクトを参考にプロジェクト計画を立てようとしたが、情報がバラバラ。

• Ｇプロジェクトの工程は基本設計だが、Ｈプロジェクトの工程は概要設計。これは同じ設計なのか違うのか解らない。設計書をみても記述方法が違うためどれを参考にしてよいか解らない。
• 品質基準（設計指摘密度、試験密度、バグ摘出密度）の値がプロジェクト毎に決められているため、どれを適用してよいか解らない。
• 部長への報告タイミングがプロジェクトによって違うため、どれが正しいのか解らない。

【ケース４】組織長が各プロジェクトの状況を把握したいが、資料が細かすぎてよくわからない。もしくは資料がおおざっぱすぎる。

• 各プロジェクトからの報告内容が細かすぎて問題点が見えない。
• プロジェクト毎に報告する内容が違う。
• PMが問題なしと言っているが根拠がないため、信用してよいか解らない。
• 大きなトラブルが発生してから始めてプロジェクトが問題だらけであることを知った。

どうですか？過去を思い出してみるとこのようなシーンがありましたよね。私もほとんど経験済み（涙）です。

【ケース１】と【ケース２】は、ＰＭの稼働が足りない、ＰＭの経験不足などの理由によりプロジェクトの計画、管理不足によって発生するケースです。ある程度の規模のプロジェクトになるとＰＭ一人でマネジメントするのは至難の業です。
【ケース３】は組織に基準や標準がないために個々のプロジェクトで適宜対応しているケースです。個別最適と言えば聞こえがよいですが、やはり生産性が悪いですよね。
【ケース４】は組織長に対してＰＭは的確な報告やエスカレーション（問題が対処できず上位に対応を要請すること）ができていないケースです。ＰＭは自分が「うまくできていない」ことを言いたくないと思ったり、問題を自分達で解決できるのではと過信したり、はたまた何を報告・エスカレーションしてよいか解らないということもあるでしょう。

このような問題を解決するためにＰＭＯを設置します。
【ケース１】【ケース２】の場合ＰＭＯはＰＭの負担を軽減したり、ＰＭのスキル不足を補ったり、PMの教育を行ったりします。
【ケース３】【ケース４】の場合ＰＭＯは組織の統制がとれるように基準・標準を策定したり、組織内で起きている問題を見える化して判断できるようにします。
ようは組織やプロジェクトの「裏方」なのです。
どうです、これらの問題を解決してくれるＰＭＯを設置したくなりましたか？
まだよくわからない？
では次回は、ＰＭＯの具体的な仕事について考えましょう。

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
連載のタイトルに名前が入っていたため、お客さまに気づかれてしまい私の目の前で連載を読まれています。「こんなこと書いているけどできてないじゃないか！！」って突っ込まれたらどうしようかとビクビクものです。
けんちゃん（←お客さま）あんまりいじめないでね。

＜　前回　｜　目次　｜　次回　＞

待望の方法論（Modus PMO）をリリースしました！

• 「方法論 – プロジェクトマネジメントオフィス運営方法論のご紹介」はこちら。
• 「開発者よりのメッセージ」はこちら。

PMO要員育成のための研修コース

• 「研修 – プロジェクトマネジメントコース」はこちら。
• 「研修 – ビジネスアナリシスコース」はこちら。