今日は大型連休のなか休みです。連休のなか休みとは変な言い方ですが勘弁してください。なか休みではなくて連休の真ん中という方もいらしゃるかと思いますが、キットPMはクライアントが製造業のため、工場カレンダーでは今日明日は振替休日に便乗してお休みをいただき、故郷の長崎に来ています。
今日の長崎は雨は降っておらず、曇りで風が強く吹いていますが、気持ちのよい日よりとなっています。おかげ様でのんびり過ごしています。
さて予告通り、今回はプロジェクトの評価タイミングについて考えていきます。
これまで考察してきたプロジェクトの評価は、プロジェクトの終結プロセスのタイミング、つまりプロジェクトの成果物の引き渡しがすべて完了した後のタイミングが一つありました。
また、プロジェクト終了時点では評価ができない評価項目が存在する可能性があるため、プロジェクト終了後予め定めた期間を経て評価するものがあると考えました。そのために、評価するための機能が組織の中に必要になるわけです。
このように、プロジェクトの評価というと当然ですが、プロジェクトの結果を評価することになるので、以上の２つのタイミングが評価タイミングであることに違和感はないと思います。
これに対して三つ目の評価タイミングがあると、キットPMは考えています。それはプロジェクトフェーズの区切りでの評価タイミングです。
プロジェクトが大型になればなるほど、この途中でのプロジェクト評価は重要になってきます。逆に言うと、コンパクトなプロジェクトではその必要性はコストととの見合いで実施しない場合もあります。
ただ、最近のITシステム構築プロジェクトにおいては、ベンダとの契約がフェーズ単位に異なる契約となることが多くいため、契約単位でのプロジェクト評価が存在するようになっています。
これには大きく２つの意味があります。
一つは契約結果としてのフェーズ完了を評価し、次のフェーズに進めるかどうかを判断するためです。結果の評価ですね。
この評価は対価の支払いが絡むので、ベンダにとってもクライアントにとっても重要な作業となります。
もう一つは、プロジェクト運営の評価です。特に初期のフェーズ、例えば「要件定義フェーズ」などの終了時点で、プロジェクトがどう運営されて、その結果どうであったかを評価します。
プロジェクト運営に問題はあったか、その問題はどうして発生したのか、その対策はどうだったか、もっといい対策はなかったか、などについて考えます。
もちろんそれはただ反省するためだけではなく、すぐに始まる次のフェーズで活用するための知見をまとめるためです。
例えば、コミュニケーション状況を分析したり、進捗報告の在り方とその管理手法、成果物の品質などの評価を行い、もし不都合があればその原因を追究し改善策を検討します。
初期のフェーズでもし課題の存在を認識したら、その根本原因を追究することが必要です。なぜなら、プロジェクトの終わりはまだ先にあり、これから困難さはますます増大していく（多分）からです。初期に発生した課題は徹底的に分析し、根本的な対策をとることが重要で、そのための時間的な余裕もまだあるからです。
もしプロジェクトの最終段階のフェーズで課題が発生したら、第一に考えるのはプロジェクトの完成となる場合があります。それは根本原因を解消する時間とコストをかけられないかもしれないからです。この場合状況によっては、その場しのぎの対応をとることがベターな対応となる可能性があります。
いずれにしてもフェーズ毎の中間評価は、その契約内容やフェーズ内容などを考慮し、計画段階で実施を組み込むことが必要なのは言うまでもありません。
いかがでしょうか。プロジェクトを確実に終了し、その経験と知見を後続のプロジェクトのために明示的に残すために、プロジェクト終結プロセスだけではなく、時間差によるプロジェクトの結果評価や、プロジェクトの中間での評価の実施など、考える必要のあることはたくさんあります。
これらのことを、プロジェクト計画時に設計しプロジェクトマネジメントのプロセスとして組み込むことは、とても意味があることです。
ややもすると面倒くさく、無視しがちになる評価という行為ですが、それを行うことで様々なメリットを得ることができます。
というよりも、コストをかけて実施したプロジェクトから得た資産として、これを整理し残しその情報へのアクセスを保証することは、プロジェクトマネ-ジャの義務だと考えます。
そのためにも、計画段階でこの評価を意識した計画をたて、確実に実施することが望まれます。
これで、本シリーズは終了します。まだまだ考える必要のある要素は沢山ありますが、続きはまたの機会にい譲り次回からは新テーマに挑戦することにします。