Magicode logo
Magicode
0
3 min read

【プロジェクト最終報告書テンプレ】うわ・・・弊社、プロジェクトの振り返りしてなさすぎ・・・?

まさかプロジェクトやりっぱなしってこと、ないですよね・・?

ドキッとした貴社に捧げる記事です。

振り返りをすることの良さは

(個人・組織問わず)ナレッジが溜まるこれに尽きると思います。

次プロジェクトをよりよく実施するためのヒントや、

現在進行形で進んでいるプロジェクトが直面した課題に対して

先人たちがどのように乗り越えてきたかなど、旨味成分たっぷりです。

ですが、いろいろ調べてみてもテンプレートや考え方がなかなか見つからなかったので、

ここに置いていきます。

そんな資料作るのめんどくさいよ

お気持ちは察します。

受験勉強で過去問解いても、その振り返りって面倒ですからね。

ただ!

個人としても組織としても成長し続けるために、

一度立ち止まって行う振り返り導入してみませんか。

人間振り返りをするときこそ、自己研鑽のチャンス!

それではいきましょう!

プロジェクト最終報告書フォーマット

目次

最低限以下が必要かと思います。 必要に応じて追加していただくのが良いかと。

1 プロジェクト報告
1-1プロジェクト概要
1-2 実績
1-2-1 コスト
1-2-2 スケジュール
1-2-3 スコープ
1-3 リスク対応
2 残課題
3 振り返り
3-1 ステークホルダー
3-2 チーム
3-3 開発アプローチとライフサイクル
3-4 計画
3-5 プロジェクト計画
3-6 デリバリー
3-7 測定
3-8 不確かさ

各項目の説明

1.プロジェクト報告

1.1 プロジェクト概要

プロジェクト名・期間・総工数・業種・プロジェクトの目的・成果

1.2 実績

基本的には各項目の計画と実績の差分を書いていきます。

どうして差分が生まれたのかを明らかにして次プロジェクトに活かしたいです。

1.2.1 コスト

予算と実コスト。

差分があればなんでそうなったかの根拠。

EVM(アーンド・バリュー・マネジメント)なんかを導入すると、

どの段階でメンバーが気持ちよく仕事ができていて、

いつから燃えそうになっていたかがわかって良いです。

EVM・・記事書こうかな・・

1.2.2 スケジュール

計画と実働。

差分があればなんでそうなったかの根拠。

1.2.3 スコープ

計画と実際の成果物・納品物。

差分があればなんでそうなったかの根拠。

1.3 リスク対応

プロジェクトで使用していたリスク管理表を引っ張ってきて、

対応したのかしていないのか、

2. 残課題

プロジェクト期間ないで収まりきらなかった課題について記載します。

運用時に対応するのか、次フェーズで対応するかなど。

RACIをはっきりとさせておきましょう。

R:Responsible 工程の実行責任者

A:Accountable 説明責任者

C:Consulted  協業先あるいは相談先

I:Informed   報告先

3. 振り返り

PMBOK第7版準拠で振り返りをします。

PMBOK第7版はプロジェクトを実施する上でのバイブルです。

これまでのハウツー本ではなくなり、「原理・原則」を書いたものとなるので、

振り返りにも8つのパフォーマンス領域が十分に果たされたか確認していきます。

PM・PLが評価点とその理由を具体的に書くことでより充実した

振り返りを実現できると思います。

3.1 ステークホルダー

プロジェクト期間中、ステークホルダーと良好な関係が築けたか。

3.2 チーム

プロジェクトチームは円滑なコミュニケーションが取られ、

十分なパフォーマンスが発揮されていたか。

3.3 開発アプローチとライフサイクル

適切な開発アプローチ(ウォーターフォール・アジャイルなど)を選択できたか。

3.4 計画

計画通り進んだか

3.5 プロジェクト作業

期待される成果物と成果は効果的・効率的に提供されたか。

3.6 デリバリー

スコープ・品質ともに期待される基準を満たし、

プロジェクトの目指す成果を達成することができたか

3.7 測定

テスト件数やバグ摘出数など、定められた基準によって査定され、

適切な対応が実施されたか

3.8 不確かさ

リスク・チャンスについて積極的に調査・対応したか

最後に

作った最終報告資料は誰もが見えるところにおいて、

いつでも参照できるようにしておくのがベストです。

作りっぱなしはよくないです。お後がよろしいようで。。

Discussion

コメントにはログインが必要です。