PMstyleプロデュース

◆ある失敗プロジェクト事例

たとえば、あるＩＴのプロジェクトで顧客Ａ社の責任者のＫさんが自分の忙しくて動いてくれなかったため、ユーザの要求の取りまとめが計画より１ヶ月遅れて、プロジェクトスケジュールが遅れました。あとで聞いたところ、プロジェクトの計画段階でＫさんにはすでに要求取りまとめの時期に忙しくなることが分かっていたそうです。

そのリカバリーをする中でメンバーに残業、休日出勤をお願いしたところ、終盤でミスが増え、品質検査に計画の倍近くの時間を要し、テスト工程が予定の３倍、最終的に３カ月のスケジュール遅れになってしまいました。

◆教訓には適度な一般化（抽象化）が必要

あなたなら、このプロジェクトの出来事をどのように教訓として残しますか。

この情報をそのまま残しても、あまり、役には立ちません。でも、実際にはそこで止まっているケースがたくさんあります。今度、Ａ社のＫさんと仕事をするときにはきちんと予定を聞いてからスケジュールを立てようといった感じです。

では、「顧客も自分の仕事があって忙しいので、要求分析の期間は余裕をとろう」というのはどうでしょうか？実際にこういう教訓を残しているケースも少なくありません。

これは一般化のし過ぎです。どの会社も、あるいはＡ社のＫさん以外の人もそうだとは限りません。いわゆる熱さに懲りてなますを吹くというやつで、これも使える教訓にはなりません。

この場合、

「「要求分析」のスケジュールは相手の意向を確認してから、実施可能なように決めよう」

というあたりが妥当な一般化だと思われます。

◆結果ではなく、思考過程が重要

それから使えないケース教訓としてもう一点あるのは、結果（現象）だけを情報として残しているケースです。

たとえば、上のケースで（Ａさんは）自分の仕事に忙しくて動いてくれなかったわけですが、そのまま放っておいたわけではないでしょう。Ａさんと交渉することはもちろん、支援を申し出るとか、しかるべき人にＡさんの業務スケジュールの調整をお願いしてみるとか、いろいろやっているはずです。

実は教訓として重要なのは、問題の原因ではなく、問題に対してどういう行動をとり、その結果どうなったかです。もちろん、ここにも一般化は必要になりますが、他のプロジェクトにしてみれば、この情報にこそ値打ちがあるわです。

◆まとめ

以上のように、教訓を他のプロジェクトに応用できるようにするためには、

・思考過程をきちんと記録しておくこと
・学んだことを一般化しておくこと

が必要なのです。ぜひ、そういう振返りをするようにしましょう！

◆関連セミナーのご案内

このセミナーでは、他のプロジェクトに応用できる教訓の残し方を、レゴ（Ｒ）による作業の実践を踏まえながら考えていきます。

╋【開催概要】━━━━━━━━━━━━━━━━━━━━━━━【2015.03.13】╋
■　振返り講座～質の高い振返りでプロジェクトを変える　　　　　　 ◆7PDU's
　　日時：2015年 03月 13日（金）　 10:00-18:00（9:40受付開始）
　　場所：国際ファッションセンター（東京都墨田区） 
　　講師：好川　哲人（株式会社プロジェクトマネジメントオフィス）
　　詳細・お申込　http://pmstyle.biz/smn/lesson20.htmh
　　主催　プロジェクトマネジメントオフィス、共催：ＰＭＡＪ
╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋
　【カリキュラム】
１．振返りとマネジメント
２．組織レベルの振り返り方法
３．プロジェクト・業務レベルの振り返りの方法
４．個人レベルの振り返り
５．３つのレベルの振返りを統合する
６．プロジェクトのタイプと振り返りの目的と方法（討議）
　・ルーティン
　・クリエイティブルーティン（アジャイル）
　・イノベーション 
╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋