朝に昇った太陽も夕べには必ず沈みますし、楽しい時にも必ず終わりが訪れます。
それと同様に、プロジェクトを定義し、立ち上げ、その後管理・コントロールしながら実行していくと、そのプロジェクトはいつか終わりを迎えるでしょう。
プロジェクトによっては、適切な終結を迎えることなしに、目標・ミッションを達成したという公式の認定もないまま、ずるずると定常業務に流れ込むものもありますが、これは適切ではありません。
プロジェクトとして、今まで行っていたことがプロジェクト終了後に定常業務へ付加される場合もありますが、そのような場合でも明確な開始・終了の時期があるはずです。
多くの企業やプロジェクトにおいて、終結フェーズに重きが置かれていませんが、プロジェクトを終了させるタイミングは、最後の締めくくりとしてスムーズに終わらせることが大切です。
「言うは易し、行うは難し」と言われるように、プロジェクトを終了させるプロセスでしっかりと区切りをつけ、その後のプロジェクト等にも生かせるように振り返るのは大変なことです。
しかし、プロジェクトから学んだことを話し合い、記録することは、個人にとっても会社にとっても大きな意味があります。
そのため、プロジェクトの終結は立ち上げ時と同様に、慎重に行うようにしましょう。
「終結フェーズ」が必要なワケとチームの行方
プロジェクトが終わりに近づくと、チームのメンバーにはゴールが見えて喜ぶ人もいれば、不安になる人もいます。
「次にどのような仕事やプロジェクトが待っているのか？」、契約社員の場合、「次の仕事はあるのか？」などといった不安に駆られることもあります。
不運なことに、こういった士気の問題は、プロジェクトがほぼ終了するという最悪のタイミングで生じることが少なくありません。
問題が生じる原因は、自分がこの後どのような状況になるかということに気を取られることだけではありません。
上手く進んでいるプロジェクトであっても、メンバーと一緒に仕事・交流をして、楽しく付き合う時間に終わりが来るということなども含まれます。
継続的改善の観点からも、終了時にプロジェクトの振り返りをする意味は大きいものがあります。
その他にも、人間関係や教訓を学び取って記録に残すといったことが、プロジェクトを適切に終わらせる契機となります。
また、プロジェクトが終了した後にチームは①包含、②統合、③絶滅のいずれかの形態で解散されることになります。
包含はプロジェクトの成功、終結とともにチームごと組織に吸収される一種のハッピーエンドです。
上手くいけば、メンバーの多くがそのまま仕事を続けられるかもしれませんが、プロジェクト終了後の役割との兼ね合いから、メンバーが入れ替わることや、メンバー自ら抜けることもあります。
復帰はそれぞれのメンバーが自分の出身組織に戻るという解散後によくある形のものです。
以前の職場が別のメンバーに埋められている可能性もあるため、戻ってきたメンバーが納得のいく役割を見出すことが大切です。
ステークホルダーにはこれを手当てする時間が必要なので、予め相談しておきましょう。
絶滅はプロジェクトとそれに関係するすべてが消滅する形で、プロジェクト失敗時に起こりえます。
プロジェクトの終結とともに全員が解雇されることもあり、極力避けるべきものです。
マネージャーは、このうちどれが適当であるのかよく考える必要があります。
さもなければ、メンバーが路頭に迷うことにもなりかねません。
最後にマネージャーがするべき5つのこと
プロジェクトの終わりに向けて、次の5つのことをして公式な終結としましょう。
1.ステークホルダーに会い、成果物の承認をもらう
プロジェクトの存在意義はステークホルダー(顧客・承認する立場の上司など)にあるので、ステークホルダーから承認を得ることで、そのプロジェクトは完成となります。
同時に、サプライヤーやメンバーにプロジェクト終了期日を伝えましょう。
2.次の担当者に責任・権限を引き継ぐ
プロジェクトの最終成果物が、定常業務や別の新規プロジェクトのインプットとなることもあります。
ここで、マネージャーの仕事が終了したことを確認しましょう。
例えば、顧客データベース構築プロジェクトの事例を考えてみましょう。
プロジェクト終了とともに、データベースの運用主体は営業・マーケティングなど他部門に移ります。
課金データベースの構築チームは役割を終え、運用・保守の責任者は情報システム部門に移管されます。
パイロット・テスト(事前調査)で顧客の質問に対応していたチームは、責任を顧客サービス部門に引き継ぎます。
こうした活動のすべては、プロジェクトから定常業務への移管に含まれます。
3.人事部門と連動し、チームメンバーを新たな役割に異動させる
もとの機能部門に復帰する人もいれば、新規プロジェクトに配属される人も出てきます。
指揮下にあったメンバーと個別に面談し、プロジェクトのフィードバックを一緒に行い、その人が将来どのようなことをしたいのかを聞いて記録しましょう。
4.会計処理を完了させる
コストの集計や請求の支払い、会計帳簿を閉じることも含みます。
すでに存在しない予算に対して、請求がなされるのを食い止めましょう。
5.プロジェクトの結果を文書化し、将来に向けた推奨事項をまとめる
過去に行ったことを思い返しながら、反省点をまとめます。
このプロセスの負担を小さくするために、プロジェクトでの行動を日々記録しておくことが大切です。
その他に、プロジェクト終結時にプロジェクト目標の達成度とともに、プロジェクトマネージャーの力量も経営陣から評価されます。
以下のような分野と質問に対して、回答を具体的に書き留めておけば、終了後の振り返りで教訓を抽出するのに役立つでしょう。
注力する分野：コミュニケーション、スケジュールと予算、品質、人的資源、使用した書式やツール
質問項目
- どのようなやり方をしたか？
- 上手くいったこと、いかなかったことは何か？
- 改善すべきところとその改善方法は？
- 今後プロジェクト(特に類似したもの)が進められる際の推奨案は？
規模が大きいものや複雑なプロジェクトは「パンチ・リスト」を活用
プロジェクトの規模は、大小様々なものがあります。
小規模なものは、マネージャーとメンバー、ステークホルダーがプロジェクト振り返りの会議を開き、目標達成の確認をして最終報告書をまとめれば十分でしょう。
しかし、大規模プロジェクトでは、個々のメンバーが将来の不安を感じていることやメンバー間の絆の強さから困難も伴います。
報告書作成に協力せず、すでに終了した関連作業を続けるメンバーがいるかもしれません。
そのような不安を鎮めるために、各メンバーの貢献を認めて、できるだけ早く新たな役割に就けることや、公式のお祝い会を開くなどしましょう。
大規模プロジェクトの終結は、いつもすっきりいくわけではありません。
メインの大きなプロジェクトの他に、多数のサブプロジェクトが存在するなど、細かな案件が残ることがあります。
主要な部分が終了していても、それ以外の詳細な作業に延々と時間や資源を投入してしまう恐れがあるのです。
プロジェクトマネージャーはこうした残務にどこかで見切りをつけ、プロジェクトの終了を判断する必要があります。
しっかりとケリをつけて、詳細を定常業務に引き継ぐことが大切です。
残作業の一覧表は「パンチ・リスト」と呼ばれ、そこに載せるものはチームを煩わせるまでもない小さな案件です。
パンチ・リストの詳細をスポンサーとレビューする必要はありませんが、パンチ・リストが存在し、そこにある案件の責任が定常部門にあることはスポンサーに知ってもらいましょう。
まとめ
プロジェクトの成功・失敗どちらにせよ、行う必要がある終了目前から終了直後にかけての仕上げについて述べてきました。
加えて、プロジェクト終結の3～6カ月ほど後に主要なチームメンバーと数人のステークホルダーで会議を開くことも大切です。
取り上げるのは、成果物の定常業務への移管後に何があったかについてです。
プロジェクトから距離を置くことで、将来変えるべきことなど新たな洞察が得られることも多く、問題点が生じるのもこれくらいの時期でしょう。
プロジェクトマネージャーとして一つの目標に注力するあまり、達成後どうすればいいかわからない、方向性を失ったという気持ちになるかもしれません。
しかし、別のプロジェクトを任されるなど、新たにするべきことがあるでしょう。
その時は、今までマネージャーとして行ってきたことや、各プロセスの進め方を思い出しながら取り組んでみましょう。
きっと、過去の経験や考え方が生きてくるはずです。
