少し肌寒い日が続き、初夏というにははばかる感じでしたが、今日は気温も上がりそうです。
しまいました。当初はもっとあっさりと終わるかと考えていたのですが、意外と手間取っています。もっともボリュームのあるプロセスなので、当たり前といえば当たり前ですが。
ここで簡単にこれまでの流れをまとめておきます。
ＰＭの最大の関心は、プロジェクトの進行を妨げるトラブルの発生を、防止することと、発生してしまったトラブルをうまく治めることです。
そのために、第一に考えるべきことは、トラブル発生の予兆を捉え、できるだけ早期にその「芽」を摘むことです。
では、その「芽」の存在をどうやって知るのか？ 一つは、現場のプロジェクトメンバの経験や知見を探るということでした。
もう一つは、経営者などの上位管理者に集まる情報を取得するということです。
▼その上で前回は、
果たして経営者やプロジェクトオーナーが、自分に集まる情報から、特定のプロジェクトに影響を与えるものをピックアップして、ＰＭに伝えることができるか疑問であると、指摘しました。
結論から言えば、できることもあればできないこともあるという、なんとも締まりのないことになります。
言い方を変えると、プロジェクトに情報が与えられたとしても、それは単に偶然であって、そこにシステマチックな網羅性は期待はできないということです。
唯一、可能性があるのは、経営者に近い存在であるプロジェクトオーナーが、積極的に情報収集を行うことです。
これには、オーナーの負担が大きいので、オーナーの自覚と覚悟が必要になります。難しそうですね、あまり期待できないですか？
▼そこでプロジェクトに
必要になるのが、プログラムという概念とＰＭＯの役割となります。
プログラムは、ある戦略に基づいて実施する複数のプロジェクトを統合的に管理するという概念です。複数のプロジェクトですから、あるプロジェクトのＰＭが行えるものではありません。従ってプロジェクトを超越した、組織による管理が必要になります。それが、プロジェクト・マネジメント・オフィスとなります。もちろんＰＭＯの機能の一部ですが。
まだまだ、日本ではＰＭＯの必要性については認知が進んでいませんが、今のような厳しい時代だからこそ、戦略に基づく統合管理の要として必要な機能になると、キットＰＭは考えています。
▼ちょっと本筋から
ズレてしまったようです。このテーマは今回で終了します。次回は、次の「監視プロセス」に進もうかと思っていましたが、「～プロセスって何？」シリーズはお休みして、全く別のテーマに挑戦します。
