前回は、私が参画したPMOで成果が出ないまま解散した事例をご紹介しました。
【前回のおさらい】
なぜ、PMO活動の成果が出せなかったのでしょうか?
報告・エスカレーションの必要性
各チームでは、遅延しながらも先になんとか進めていましたが、チーム間の連携はなく、チーム間での仕様のずれが発見されることもしばしばありました。
また、問題が山積してもすべてチーム内での解決になるため、メンバーの負担がどんどん増えていきました。
・・・・などなど
を目的として進捗や報告書の提示を依頼したのですが、目的を十分理解し納得してもらえなったのではないかと思っています。
稼働が集中しているチームリーダーをさらに追い込んでしまい・・・
前回プロジェクトの状況を記載しましたがその中で
と書きましたが、要件定義フェーズでのB社情報システム部の数名とは、各チームリーダーのことなのです。よって、設計フェーズに入っても要件定義を実施していた各チームリーダーがキーマンとなり、チームリーダーでないと判断できない事項が山積になっている状態なのです。
この状況の中、進捗記入や報告書作成をチームリーダーに依頼してしまったためにさらにチームリーダーの負担になりPMOが提案した計画が定着しなかったのでしょう。
承認すべき基準・内容が曖昧
仕様変更やスケジュール変更を各チームリーダーが判断して実行していたのですが、先にも記載した通りプロジェクト内で情報共有が出来ていないため、チーム間での仕様やスケジュールのずれが後になって発覚することがしばしばありました。
これを解消するために、仕様変更やスケジュールの変更、工程完了の際には承認プロセスにのせることでプロジェクトマネージャのコントロール下で統制を取ろうとしたのですが、全仕様変更に対してまで承認プロセスにのせてしまった結果、日々承認しなければならない事項が発生し、プロジェクトマネージャは「よくわからんが承認するしかないんだろう」という発言が出るようになりました。
など基準の設定や報告内容を明確にすることが必要だったと思います。
このプロジェクトから学んだ教訓
以上のように個々の活動に対して反省すべき点がありましたが、そもそもPMOチームの参画の仕方にも問題がありました。
このPMOはプロジェクトの要請ではなくCIOが設置したPMOなので、CIOへの報告も定期的に行っており、第3回目で挙げた「組織内で立ち上がっているプロジェクトの状況を纏め、組織長に報告する」PMOとしての動きをしていました。
プロジェクトから疎ましい存在からスタートしているのにも関わらずさらに「○○○が出来ていない」「×××を提出してください」という客観的な立場で(見方によっては上から目線で)プロジェクトにも接したために、プロジェクトからは何の信頼を得ることが出来なかったのです。
PMOの中で客観的に評価しエスカレーションするメンバーと、プロジェクトマネージャやチームリーダーを支援し、時には代わってプロジェクトマネジメントするくらいプロジェクトに入り込むメンバーという形で役割を分担することで「トップダウンの要求」と「ボトムアップの要求」の両方を満たせたのではないかと思います。
では、次回は私が見たイケテないPMO事例です。
**********
忙しい日々が続いており食生活も乱れています。週末くらいは栄養のあるものを・・・ということで、何度か行ったことのあるうなぎ屋さんに行きました。って、以前行った時の1.5倍の値段になっているではないですか!!
高騰しているとは解っていたのですが、目の当たりにすると衝撃ですね。
想定外の出費をした週末でした。でも美味しく元気がでました(^^)Y