プロジェクトの教訓の学び方


ここのところ、プロジェクトを終えたプロジェクトマネージャの完了報告に関わることが建て続いたのはゴールデンウィークの最中にシステムをリリースしたプロジェクトが続いたからというのと、こんな本を読んでいるから。



プロジェクトの完了報告もこの本も何れも終わったプロジェクトの教訓を学ぶためにことを為すのです。


あるプロジェクトの完了報告では、そのプロジェクトマネージャが若手だったので書き方を含め助言をすることになったんですが、プロジェクトの報告で教訓を書くという行為がその書き手によって報告書に向かう姿勢や言葉の使い方に特徴があるのを思うと、完了報告のレポートを手に取る度に、一人ひとりのプロジェクトマネージャのタレント性と経験の量の差が見え隠れして、勝手な感想ながらなかなかおもしろいなぁ、と一人ニンマリとするのでした。


ワタシは何からもで何かしら自分のふるまいと違う差異に気付くことが出来れば「日常から学ぶことが出来る。」と思っています。その学びの対象の行為をしている人は先の若手のプロジェクトマネージャからベテランのプロジェクトマネージャまで広いですから、若手だからといって学ぶことが無いなんていうことは有り得ないです。どっちかと言うと、過ぎ去ってしまった過去に感じたことを若手のプロジェクトマネージャをとおして改めて疑似体験させてもらうようなものです。


プロジェクトは上手くいかない方の割合の方が多いのだから
プロジェクトが終わってほっとしているのはやっぱりプロジェクトマネージャに違いないでしょう。だって、何かあれば一番先に問われるのはプロジェクトマネージャだし、上手くいっても上手くやるのが当然な空気もあったりすると減点評価のようなものですから。


もう少し、プロジェクトを受注するとき、プロジェクトを計画するとき、プロジェクトを実行しているとき、プロジェクトは失敗する、上手くいかない可能性の方が高いということをステークホルダーは認識しないといけないと思うんです。だから、リスクを識別するのだし、だから、ステアリングコミッティの場を持ってプロジェクトにとって重要な課題を判断していくんですから。


プロジェクトは工期の長短に関わらず、deliverableを作るためのWBSを展開し、作業し、deliverableを構成していく行為を成していくわけで、そうした行為の一つひとつに誰かしらの判断がされている。その判断が当時は正しいと思って判断を下したとしても、工程が進むと間違いであることを自ら、周りから知らされる。


こうした判断の間違いを手早く打ち取ればプロジェクトは計画する方向に向くし、そうした間違を間違いのまま放置すればプロジェクトはその間違いを積み重ねて失敗に突き進むんです。


評価と教訓
プロジェクトの評価は、プロジェクト計画に対して、QCDの観点での較差をみることです。プロジェクトマネージャの立場で言えば、Qualityは顧客要求を実装することです。Costは1円でも計画費用をした回ることです。Deliveryは納期までに納めることです。これを全部満たせて初めてプロジェクトは成功した、と評価されます。逆に、3つのうち、1つでもおーばらーんすればプロジェクトは失敗の扱いです。これでプロジェクトの良し悪しを判断するのが評価です。


でも、終わったプロジェクトから教訓を学ぶには、何をしたらその結果にたどり着いたのかを見ていかなければわかりません。つまり、プロジェクトのプログレスをトレースする必要があるわけです。でも、全部をトレースするわけにはいきませんから、何等かフィルタをとおしたもので見る必要があります。


出来事はWBSの数だけたくさんあります。でも、80:20の法則のとおり、QCDで何等かオーバーランするのは、数多くあるWBSの内で発生した課題の中の20%の中にあります。その20%の内の課題の中の1つか2つの課題がオーバーランした事象の犯人なんです。


それがどうしてオーバーランの結果になったのか、それを追うのです。そこには、何を選ぶかという恣意的なフィルタが掛かる可能性があるのは、プロジェクトマネージャがネガティブに考えているかどうかです。プログレスをトレースすることがプロジェクトマネージャを糾弾するのが目的ではなくて次に関係者が同じパターンを認識したときにそれに気づき、対策するアクションを録れるようにするためであるだとスタートラインを明示的に定義することで回避するのが良いでしょう。


オーバーランに至った経緯を時系列に追いながら、コトにかかわった関係者を明らかにし、都度の判断をどうしてそう判断したのか、今であればそのタイミングは適切だったのか、今であれば他の対策が打てるのか、と検証していきます。


この検証で得られることが一つの教訓です。もう一つの教訓が、プロジェクトマネージャが普段から普通にやっている工夫を共有することです。それが朝会かもしれないし、メンバと毎日1分はなすことかもしれない。そうした普段の行動がメンバの体調や悩みを抱えている状況を知ることや残業が続いていて負荷が高い状況の深刻さなどプロジェクトを回している現場の潜在化しているリスクを知るための手段なのかもしれないんですよね。それを知ることも教訓です。


そうした評価と教訓を改めてみれば、評価は定量的にするものであって、教訓は定性的にみるものなのですよね。