「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

スコープ検証、プロジェクトの終結

プロジェクトマネジャーがプロジェクトを終結させる前に求められる作業は、もともとの計画に立ち返ることです。プロジェクトチャーターや品質計画などに立ち返り、そこに記載されていた内容がもれなく実現されているかをしっかりチェックするのです。

プロジェクトの終結には4つのタイプがあります。

• 定常業務／保守運用へと発展（付加）
  定常業務へと発展するケースです。期限が決まっていて独自の内容をもつものをプロジェクトと呼びます。そうでない継続的な作業は定常業務ということになります。
• プロジェクトの完了（消滅）
  プロジェクトが全て完了し、クライアントに受け入れられるケースです。2次開発が発生するような場合は、また新たにプロジェクトが立ち上がったことになります。理想的なプロジェクト終結のひとつです。
• プロジェクトの統合（統合）
  他のプロジェクトや組織に統合されてしまうケースです。
• 途中で終結（欠乏）
  資金や資源の消滅などにより、プロジェクトが未完のまま終結してしまうケースです。何となくなし崩しで終わってしまわないように、「プロジェクトが終わった」というコンセンサスをメンバー間で共有しておくようにしましょう。

プロジェクトの終了過程は、次回への改善につなげるための大切な振り返りポイントです。次のような作業の実施が必要です。

• 最終成果物を納品する
• 契約書に書かれている内容が正式に納品されていることを保証するドキュメント（検収書）をクライアントから受け取る
• 請求書を発行する
• プロジェクト報告書を作成して全メンバーに配布する
• ステークホルダーにプロジェクトの満足度を確認する（フィードバック）
• プロジェクト情報を大切なナレッジ（プロセス資産や教訓）として保存する

特に大切だと思われるのが、プロジェクトの過程で得た数々の教訓（レッスンズ・ラーンド）をとりまとめることです。プロジェクトメンバーが分散する前にミーティングをもってヒアリングを行い、「うまくいった作業」や「失敗した作業とその原因」「次回改善すべき事項」などを文書化しておきます。また、実行プロセス中に随時教訓をためていくことも可能です。レッスンズ・ラーンド（アウトプット）は、次のプロジェクトのインプットになります。