この数日、夏日が続いている南関東地方です。暖かいを通り越して暑い日差しが降り注いでいましたが、今朝はこの季節らしい少しひんやりと清々しい気候になりました。
季節の移り変わりは瞬く間です。そういえばもうすぐ大型連休が到来しますが皆さんのご予定はいかがでしょうか。
プロジェクトの評価のために何を準備すべきかについて考えています。プロジェクトの評価で最も重要なものはもちろん、その「目的」が達成できたかを測ることです。
ところがここに問題があります。前回述べたように、プロジェクトは有期の活動で、テンポラリの集まりですから、プロジェクトの終結とともにチームは解散することになります。
ではどのタイミングで明示的に解散をする（打ち上げをするでもいいですが）のでしょうか。
建設工事プロジェクトの場合だと、工事が完了して施主に引き渡しができたときでしょうか。ITシステム開発プロジェクトの場合だと、システムが本稼働したタイミングでしょうか。
前回考えたように、プロジェクトの目的が達成までに相当の時間が必要になる場合、つまり「１年後に市場でシェア１５％～」のような場合ですね。
別に1年と言わずとも「来月の月末時点でこのような効果が表れている必要がある」というプロジェクトは結構あります。
このような場合、プロジェクトの終結タイミングはどのように考えるべきなのでしょうか。もちろん、完全に成果を評価できるまでプロジェクトが続くという考えもあるかもしれないですが、通常そのようなことにはなりません。メンバを遊ばせるわけにはいきませんからね。
これは、終結プロセスの難しさの一つかもしれません。成果の評価をちゃんとやらなければプロジェクトが終わらないとすると、この問題を解決する必要があります。
方法は２つ考えられます。
一つは、評価タイミングをプロジェクト計画で、1年後のこの日にプロジェクトを評価する担当者が再集結するように設定しておくという方法です。
このやり方は考え方としてはリーズナブルなのですが、評価担当者が外部の人である場合や、転勤等で異動があった場合など再集結が難しいことがあります。つまりプロジェクト体制は解散した上に、その構成員そのものが組織からいなくなる場合は、まともな評価ができなくなるリスクがあります。
これを解決するために、もう一つの方法があります。それば評価そのものをプロジェクト活動から切り離す方法です。
そもそもプロジェクトがその活動の一環として”自己評価”をすることは意味があることかもしれませんが、正当で客観的な評価ができるかは異論があるかもしれません。
そういう意味でも、プロジェクト目的に対する達成についての評価活動は、別の仕組みで行うことが望ましいと考えています。
この項、次回も続きます。