| « 2007年7月19日 | 2007年7月20日の投稿 |
2007年7月23日 » |
先日のエントリを引合に、例の（？）シリーズものの続きを解説します。テーマはタイトル通りです。なお今回から勝手ながら志向を変えて簡潔なエントリにしました。
（連載モノ第４弾デス。しばらくご無沙汰してしまいスミマセン。経験談に基づきですが、重要と思われるプロジェクト管理上のチェックポイントを整理しましたので、参考になる方がいらっしゃれば幸いです。）
私の理解では、成果物管理とはPMBOK的に言う「TIME」と「QUALITY」にまたがる機能です。
少々抽象的になりますが、「決められた期限に向かって着々と進捗を見極めながら期待品質通りの成果物を納入する」プロセスの管理です。
最小限のキーポイントが６つあります。
１．成果物一覧と基本様式（テンプレート＆サンプル）および作成手順が作成前に提示され、顧客と合意されていること。
２．必ず完成前に1回以上、「中間」チェックがなされ、「その流れで完成させてよい」という確認がされること。
３．最終成果物と中間成果物が分類されていること（注１）。
４．電子媒体であるかどうかにかかわらず、適切なバージョン管理がなされていること。
５．各種成果物の相関が定義・管理されていること。
６．本質的な成果物品質（仕様や要件）を、レビュー等により管理する機能を持つこと
最後のポイントは非常に大事なことだと思っています。
「品質管理」の機能としては、「ファンクションには深い理解がないけどそれでも品質管理をする」ルーティンでもいいのですが、成果物の本質的なチェックを「成果物管理」機能が果たさないとしたら、プロジェクトマネジメント（メンバー）は、誰も本質的な成果物品質を見ないことになります。これは極めて危険なことです。
必ずしもプロジェクトマネジャーが本質的チェック機能を果たせと言っているのではありません。マネジメントメンバーの誰かが、それを果たせればいいのです。そしてその人は「成果物管理」者であって欲しいのです。
各チームの成果物は、チーム間での横串的典型が薄くなりがちですので、そこを押さえて欲しいのです。
「共通チーム」とか「（業務）統括チーム」とかがカバーするという理論はあると思いますが、それならば、その管理・運営は「成果物管理」のできる（プロジェクト）マネジメントメンバークラスが担当すべきです。
１~３は、できていなければお話になりません。
４と５は、一度でも手戻り的変更が発生したときに必要となりますから、これも省略することはできません。
６は意外に考慮されないことが多いです（最近）。ですが、とっても重要です。
「品質を確認しないで管理責任者が納品する」ことになります。
八百屋や魚屋では有り得ないことです。
暴言でしたらお叱り受けたいと存じますが、６を軽視する人は「ダンボール入り肉まん」や「ミートホープ」を嘲笑する資格はないと思います。
これからプロジェクトを編成される方には是非参考にしていただきたく存じます。
（注１）ここでは、システムの完成後も最新状態として更新されることが必要なものを最終成果物、次工程に進むために作成は必須であれば、システムが完成した後は参照が不要になるものと中間成果物、と定義しています。
| « 2007年7月19日 | 2007年7月20日の投稿 |
2007年7月23日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命