教訓を残すことは将来につなげること

PMBOKガイドのプロセス群に「プロジェクトやフェーズの終結」というプロセスがあります。

第5版と第6版では内容が若干異なりましたが、いずれプロジェクトは終結を迎えます。有期性というものですね。

その終結プロセスの中に、非常に重要な概念があることがおわかりですか?

次のプロジェクトにつなげるために絶対に必要なものです。そうです。「教訓を残す」ということです。

教訓とは?

「教訓」というまた古風な響きのある言葉です。原語は「Lessons Learned」となっています。

これは組織のプロセス資産に含まれるものです。実際の組織では異なる表現をしているかもしれませんが、以降「教訓」で統一していきます。

プロジェクトを遂行していく上で、過去のプロジェクトの教訓を見ないプロジェクトマネージャはいないと思います。

似たようなプロジェクトが、過去にどのような経緯で実施してきたのかを知りたくなりますよね。歴史は繰り返すではありませんが、大変参考にできます。

教訓を残す意義

そのような、プロジェクトの教訓を利用しておきながら、自分のプロジェクトは教訓を残さないというのは、ずるいですよ。

先人たちが教訓という資産を残してくれたおかげで、今の皆さんはそれを利用できるのですから。

まあそんな当たり前の話をしても仕方ありませんから、具体的になぜ教訓を残す必要があるのかを見ていきます。

教訓の残し方

管理人が考える教訓の残し方を書いてみます。

冷静に振り返る

良いも悪いも振り返ることがが大切です。プロジェクトマネージャは、予定と実績の乖離(かいり)を含めて振り返りを求められます。

悪かったところほど、冷静に見つめなおしてください。「たら・れば」は言いっこなしですが、この際考えてみてください。

  • 何が足りなかったのか?
  • 判断を誤ったところは何か?
  • なんで判断を誤ったのか?
  • 他に方法はなかったのか?

抽象化する

教訓は、具体的なプロジェクトの経緯から「法則を導き出す」という抽象化を行うことです。

そうすることで、プロジェクトマネージャ自信も「法則化する」ために頭を使うので、より一層、自己の経験を整理できます。

みんなで振り返ることで気づきを得られる

教訓を残すために、プロジェクトマネージャが一人で振り返っているのはもったいないことです。

できればプロジェクトに参加したメンバーを集めて、それぞれの振り返りをするのがよいでしょう。

それぞれ意見を持っていると思います。よかったところ、悪かったところ人それぞれです。そのような話を聞いていくことで「気づき」を得られます。

さらに、その「気づき」を集めて教訓集をつくり、メンバーで共有すると、各人が成長できると思います。

顧客も含めるといっそう効果的

顧客も交えて振り返りを実施すると、より気づきを得られます。

うまくいったプロジェクトは、顧客も含めて振り返りをすることは容易でしょう。

しかし、失敗したプロジェクトはどうでしょうか? 顧客と一緒に振り返りする事はできますか? 難しいですよね。

それでも、一緒に振り返りをすることが重要と管理人は考えます。

双方、非難の応酬にならないように振り返ることが必要なのです。

しかし稼働直後では、どうしてもエキサイトしてしまう人もいるので、できれば、安定稼動したタイミングで実施するとよいでしょう。

運用が不安定な時は、それどころではないでしょうから。

顧客側の視点を伝えてもらうことは、今後のプロジェクトの取り組みに非常に強い示唆を与えてくれます。

できることなら顧客のみならず、他システムを担当した他のベンダーも含めた振り返りをすると、得られるものが多いでしょう。

それらをまとめて「教訓」というアプトプットを残します。これにより、プロジェクトメンバーのレベルも上げられ、かつ、未来のプロジェクトへの資産を残せます。

まとめ

過去の資産を利用するということは、自分が担当しているプロジェクトも、将来のプロジェクトで利用してもらうという考えで臨んでください。

自分のためでもありますし、組織としてもナレッジが積み重なることで、プロジェクトマネジメントをしていく上でもより成功に近づけます。

出し惜しみせずに、ありのままのプロジェクトの姿を残してください。そして、そのプロジェクトで得た「気づき」、「示唆」を皆で共有しましょう。

ある意味、メンバーの教育も含まれていますので。

 

PM

Posted by wpmaster