プロジェクトは、終了にあたって最後にやらないといけないことがいくつかあります。
やるとやらないとでは、大違いなプロジェクト最後の一仕事について、今回はまとめます。
プロジェクトの完了にあたって実施すべき項目
プロジェクト完了時に実施すべきこと
プロジェクト完了にあたり実施すべき項目です。
・プロジェクトメンバーおよび関係者へのお礼
・プロジェクトメンバーの今後の継続調整
・完了報告書作成および報告会
これだけははずせない、意識してやるべきことは３つです。
・プロジェクトメンバーおよび関係者へのお礼
システム開発のプロジェクトは一人で実施しているわけではありません。
開発がひとりだとしても、要件を出してくれたお客様がいるし、多くのプロジェクトは一人ではないため、一緒に作業していただいたメンバーがいると思います。
その方々に、一緒にやっていただいたお礼、感謝の気持ちを伝えることは、プロジェクトマネージャーの最後の主要な仕事だと思います。
結果があまり良くなかったとしたら、おそらくは苦労をかけたけど最後までやってくれたことへのお礼になるし、上手くいった場合には、頑張ってくれたことのお礼になります。
もちろん、節目節目で感謝の気持ちは伝えるべきですが、プロジェクトが立ち上がったタイミングでは、数が多い場合には顔合わせてとまではいかないにしても、何らかの手段でお礼を伝えるべきです。
その際は、開発などの切れ目で途中で抜けてしまったメンバーに対しても、可能であれば連絡してあげるといいと思います。
お客さんなどのステークフォルダーに対しては、普通にやるにしてもメンバーまではやっていないこともよくありますが、これがあるのとないのでは、やはり違うと思います。
プロジェクトを離れた後に、やはりあのプロジェクトどうなったんだろう？、と気になったとき、無事立ち上がったって連絡が来たら売れしいですよね。
くわえて僕がやるのは、実際のプロジェクトに入ってくださったリーダーの方のその上の上司の方へのお礼メールです。
相手との関係で、写し（ＣＣ）で入れるのか、個別にお礼連絡をするのか、それとも自分の上司を通して言ってもらうのか、いろいろなやり方はあるかと思いますが、これもやった方が、次につながってくると思っています。
・プロジェクトメンバーの今後の継続調整
２つ目が、プロジェクトのメンバーの次の仕事をどうするかの調整です。
プロジェクトを単発の仕事と考えると、契約完了調整で終わるのですが、優秀なメンバーであれば継続してプロジェクトを一緒に実施していきたいものです。
プロジェクトだけの話ではなくなるかも知れませんが、プロジェクトマネージャーをやっているのであれば、１つ完了したら、次の仕事が待ち受けているものだと思います。
気心のしれたメンバーと継続する場合と、知らないメンバーと一緒にやる場合では、自分のやり方を理解してもらう時間などもかかるし、効率に差がでるものです。
社内メンバー、社外メンバーに限らず、抑える人はおさえておくのは、プロマネでプロジェクトを成功させる大きなポイントだと考えています。
実際、優秀なＰＭほど、社内・社外にかかわらず、この人集めに長けていました。
あれ、部署違うはずなのに、なんでこの人がこのプロジェクトを手伝っているんだ？
よく上司が許したな、と驚くことは、何度も見てます。
次のプロジェクトのメンバーは様々な理由で決まってしまっていて、一緒に仕事をしたいけどそれができない、ことも普通にあると思います。
その場合には、次の就職先のプロジェクトも探すことまで、しっかりやるのもまた、プロジェクトマネージャーの仕事だと思っています。
もちろん、ここに書いていることが、全てのＰＭの役割になっているかはわかりませんが、コスト管理、要員管理もプロジェクトマネージャーの仕事だと思えば、このあたりまでやっておくと、しばらくして困ったときに、タイミングがあえば助けてもらえるとかもあるかも知れません。
もちろん、次のプロジェクトを探しているときは、そんなことを期待してやるわけではありませんが。
・完了報告書作成および報告会
プロジェクトメンバーの話がある程度目途がついたら、最後の実は大切な仕事があります。
完了報告書を作ることと、その報告およびクロージングのミーティングです。
クロージングのミーティングと報告は同一の場でできる場合はそれでもいいのですが、完了報告書はプロジェクトとしての、納期・品質・コストなどの評価をするべきなので、プロジェクトを一緒にやったメンバーが全員参加できない方が多いです。
なので、クロージングは別途、打ち上げと言い換えてもいいかも知れませんが、打ち合わせで立ち上がりました、ありがとうと感謝の言葉を述べたら、その後食事になだれこむパターンが、自分は多かったです。
完了報告書の記載項目は後述しますが、今回のプロジェクトで得たことをしっかりと組織に残して次につなげるためにも、時間をとって整理、形に残しておくべきです。
実際の報告会でのポイントは、たとえあまりうまくいかなかった、失敗したプロジェクトであっても、責めるだけにはならないことですね。
自分は、報告する側も報告を受ける側もどちらの立場も何度となく経験していますが、そもそも失敗プロジェクトは報告を受ける側も責任がある立場のはずだし、プロジェクトマネージャーがもっとも現場をわかっていたとした場合でも、対応方法がわからなかったので失敗したというケースが多いはずです。その場合は、次にどうするかを話し合えばいいだけです。
完了報告書をつくって、報告会をする理由は、組織としてのノウハウ蓄積と成長が目的ですので、その目的に見合う結果を出して完了とすべきです。
完了報告書への記載項目
完了報告書への記載項目は、納期品質、コストにかかわるもので、例えば下記のようなものです。
・プロジェクトを実施した全体評価（下記トータルでの総合評価）
納期、品質、コスト面での総合評価
お客様の目標の達成度・満足度
プロジェクトの課題、その対応等、特徴的なものは抜き出して報告書に記載すると、他のプロジェクトマネージャ―の参考になります。
・納期：
予定通りに立ち上がったか。
工程別で、遅延した工程はなかったか。あった場合は、その原因と教訓。
・品質：
リリース後の障害発生件数：リリース１カ月間の集計等。
各局面別の不具合件数（品質指標があれば、それとの対比）
仕様・設計：レビュー指摘件数、テスト以降での手戻り件数
製作：単体テスト不具合発生率（規模あたり）
結合・システムテスト、ユーザテスト：不具合発生率
ユーザテスト：不具合発生率、手戻り件数
立上げ・切替：切替時の不具合件数、初期不良件数
など、数値化できるものは数値で把握し、基準があれば基準からのＧＡＰ分析すると、プロジェクトの特性などもわかってくるので、次につながります。
例えば、他システムとつながる数が多いシステムなので、結合テストでの不具合発生率が他のプロジェクトの２倍もあり、対応工数が不足した、などです。
外部連携が多い類似プロジェクトは、他システム連携対応テスト工数を２倍で見積もる、とかです。
・コスト
利益率・利益額
工程別の予定工数、実績工数
予定実績の差が大きい場合には、その分析
見積もり精度：
見積もり規模と実際の規模との差、生産性（１人月あたりの開発規模）の算出
・育成
人材育成はプロジェクトにアサインされたメンバーの育成状況です。
人材育成はプロジェクトとは別に組織として全体を見て行うのはもちろん必要ですが、プロジェクトリーダーやマネージャーが人材育成の視点を持つためにも、人材育成の視点は完了報告書に記載すべきだと考えています。
失敗プロジェクトでは、嫌でも書くものの成功したらやりっぱなし、次に目がいくと完了報告はおざなりになってしまうことも多いです。
実際のプロジェクトのスケジュールを、完了報告書の作成まで含めた計画にしておくといいと考えます。
プロジェクトひとつひとつが、人と組織の成長につながります。完了報告は、それを後押しする、プラス１する大切な機会だと思います。
せっかくの機会は十分に活用して、次につなげたいものです。
最後までお読みいただきありがとうございました。
機会とご縁がありましたら、次回の投稿もお読みいただけるとありがたいです。
