プロジェクト完了報告書
昔のいたある会社に「プロジェクト完了報告書」というドキュメントがありました。
「そのプロジェクトで得られた教訓を(自分も含めた)組織の別のプロジェクトの改善につなげる」ために作られ、プロジェクトの情報、経緯、様々な指標をまとめられているものです。
当時は規模や金額など一定条件のプロジェクトに対し、作成することが義務付けられていました。
ただそれが当時は有効に活用されていないと感じていました。
書くタイミング
1つは書くタイミングが遅いため、有用な情報が記載されにくい問題がありました。
当時、プロジェクト完了報告書は、カットオーバーやお客様が検収を終えた時など「プロジェクトの終了時」に書くことが大半でした。
そのため、「プロジェクト完了報告書」を書けるほど最初から最後まで携わり、内容を理解しているリーダーは、すでに別プロジェクトに参画していることが多くありました(そしてそういうリーダーは新しいプロジェクトでも忙しくなっています)。
それが原因で「プロジェクト完了報告書」を書く時間もなかなか取れず、さらに時間も経っているので記憶も薄れがちでした。その結果、既存資料からの抜粋などが多くなり、教訓や改善ポイントなどが抜け落ちてしまいます。
＃リーダー以外のメンバーも、プロジェクトやお客様の目的、経緯、改善ポイントなどを把握できていることが望ましい形だと思います。しかしながらインセプションデッキとか書くと驚く程、違うってのも普通にあるので、これはこれでなかなか難しい問題です。
「終わってから作る」ことが原因の1つなので、ウォーターフォールであれば工程毎に数字や背景、ノウハウなどをサマリーして「少しずつ」完了報告書を作っていけば良かったと今になっては思います。
活用の仕方
守秘義務などもあるのでしょうが、ポイントとなる情報などは公開されていないことが多く、あまり有効に活用できませんでした。
「何かあって情報漏洩と言われたら困る」というディフェンシブな発想からか、隠さなくても良いノウハウなども書かれていないことも多くありました。
結局、当時の感じたところは以下のようなものでした。
作る側：(管理する側から)やいやい言われてうるさいから仕方なく作っている。
管理する側：これまでプロジェクト完了報告書を未提出のプロジェクトがありますた！が、注意したところこれだけ提出されるようになりました！！(えっへん)
その完了報告書がどれだけ他のプロジェクトに活用されたかを評価の指標に組み込んだり、作り手にフィードバックすれば良かったとこれも今になっては思います。
そのアクションや成果物の目的が何のためで、それが「期待通りに活かされているか？」「より良い活かし方がないか？」などを計測したり考えていかないと、せっかくの良い施策もムダになってしまいます。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像：http://www.flickr.com/photos/printhousecorp/6543078999/
コメント