PMBOKを昔導入しましたが、あまりうまくいきませんでした。どうしてでしょうか？（組織編）
wpmaster先日、ある勉強会でプロジェクト・マネジメントについて１時間ほどお話しする機会を頂きました。プロジェクト・マネジメントと言えば私的にPMBOKですが、PMBOKを教科書通りに説明すると、聴衆者の皆様は眠くなるのは容易に想像できます。そのため、私の実務経歴や経験談を交えた内容で事例を交えながら説明しました。その甲斐あって、終了後にもいくつか聴衆者から質問がありました。発表者の私としては何かしらの反応が掴めたので、とてもうれしかったです。その中の１つに、以下のような質問がありました。
「PMBOKを昔導入しましたが、あまりうまくいきませんでした。どうしてでしょうか？」
実は、この質問よくある類です。そこで
「なぜうまくいかなかったのか？ 分析やレビューはしましたか？」と尋ねますと、
「いや、していません。組織が分析やレビューをする習慣がないので。」とご返事を
頂きました。
確かに、この点は 私も PMBOK の課題と感じています。PMBOK はプロジェクト・マネジメントのツールとしてはとても良いガイドラインですが、プロジェクト運営の組織文化や組織の成熟度の土台が確立していることがどうしても不可欠です。
組織の成熟度の例として、CMMI があります。
| レベル１ | 『初期』 |
| ソフトウェアプロセスは場当たり的、時には混沌としたものと特徴付けられる。ほとんどのプロセスは定義されておらず、成功は個人の努力に依存する。 | |
| レベル２ | 『反復できる』 |
| コスト、スケジュール、機能充足性を確認するために、基本的なプロジェクト管理プロセスが確立されている。同様のアプリケーションのプロジェクトに関しては、以前の成功経験を反復するためのプロセス規律がある。 | |
| レベル３ | 『定義された』 |
| 管理およびエンジニアリングの活動に対するソフトウェアプロセスが、「組織の標準ソフトウェアプロセス」として文書化、標準化、そして統合化されている。ソフトウェアの開発と保守において、承認されテーラーリングされたバージョンの「組織の標準ソフトウェアプロセス」をすべてのプロジェクトが使用する。 | |
| レベル４ | 『管理された』 |
| ソフトウェアプロセスおよび成果物品質に関する詳細な計測結果が収集されている。ソフトウェアプロセスも成果物も、定量的に理解され制御される。 | |
| レベル５ | 『最適化する』 |
| 革新的なアイディアや技術の試行、およびプロセスからの定量的フィードバックによって、継続的なプロセス改善が可能になっている | |
http://www.compita-japan.com/kaisetsu/what-cmmi-2.html より
ここで、PMBOK が発揮するのは、一般的にレベル２からレベル４の組織体です。一方、レベル１の組織体では、プロジェクトで得たスキルや経験が組織の資産として移管されずに属人的な管理に陥ってしまいます。そのため、その組織体は、常日頃から人的資源面で高いリスクを背負うことになります。その組織状況を回避するため、レベル１の組織体に対して、PMBOKを部分的に導入することを私はお勧めします。それも立上げプロセスでなく、むしろ終結プロセスからです。
プロジェクトで強化されていく母体組織体
PMBOK の終結プロセス群では、「すべての経験や情報を保管して、将来のプロジェクトに役立てる」というとても重要な作業があります。これは、将来のプロジェクトに適用できる経験情報、課題、リスク等を教訓として、プロジェクト運営の母体組織へ移管することが目的となっています。仮に組織体の長が導入に2の足を踏んでいるケースでは、「組織のプロセス資産を増やす」と言って持ち上げて、PMBOK の終結プロセスを部分的に導入してはどうでしょうか。
よって、上記の問いに対する回答として、
- まずは、組織の成熟度を分析しましょう。その成熟度に合わせて、PMBOKを導入しないと失敗は目に見えています。
- PMBOK を導入する場合、運営側負担が重ければ手始めに部分導入から試みましょう。つまり、テーラリングが必要ですね。
- 特にレベル１の組織体では、終結プロセス群の導入がベストです。組織体への費用対効果が最も高いプロセスです。
以上です。
プロジェクト・マネジメントに興味がある方は、 「 プロジェクトマネジメント 」 一覧へ
Follow me!
