気候はすっかり初夏の陽気となりました。今朝もカラットした素晴らしい天気でスタートしました。本当に 気持ちがいいですね。気分も明るくなります。
さて前回は、プロジェクトのアウトプットのマネジメントに視点を置くことによって、これまでと違ったマネジメントのあり方があるのではないかと、問題提起しました。
キットＰＭとしてもなかなか興味深い分野ですので、この件はまた別の機会に掘り下げて行きたいと思います。
もう少し、プロジェクトのアウトプットの課題について考えていきます。
プロジェクトの目的達成のために必要なアウトプットの構造をデザインし、あらかじめその作成を計画することが重要なことであるのはご説明しました。
またアウトプットには、リリース範囲の程度によっていくつかのステータスがあるわけですが、そのために必要なステータス変更のタイミングを意識することが必要になります。
ところが、何をもってステータスの変更を行うかが明確になっていないプロジェクトは多いのです。それが小さなステータスの変更ではなく、プロジェクトオーナーの承認が必要なレベルであっても、はっきりしていないことがあります。
ですから、アウトプットの構造をデザインするときに、ステータス変更のルールも規定することが必要になります。しごく当然のようで、キットＰＭの経験上なかなかできていないことであると思います。
プロジェクト計画時点で、このステータス変更のタスクを意識したWBSを作成することは重要になります。
月一回の取締役会の承認が必要だというルールがあった場合、そのタイミングに合わせた作業計画が必要になるのは、とても分り易い例ではないでしょうか。
重要なフェーズの切り替わりのタイミングなどで、どのレベルでの承認がどのような手続きを通して必要になるのかなど、ＰＭは把握しておくことは当たり前ですが、そのルールや過程をプロジェクトメンバーも十分に理解することも重要です。また、その責任はＰＭにあります。
もう一つアウトプットで重要なことは、将来のプロジェクトが過去のプロジェクトのアウトプットを参照して、今のプロジェクトに役立てることができるかということです。
アウトプットの構成管理は、プロジェクト実施中のものとプロジェクト終了後の２つのあり方を考える必要があります。
前者はもちろんプロジェクトを円滑に進めるためと、進捗を図るために必要なものです。
後者は、プロジェクトが産出したすべての成果物は、間違いなく組織の重要な資産であるわけですから、それを２次利用するような環境を用意するのは当たり前だとキットＰＭは思うわけです。
これは、プロジェクトが解決する課題というよりも、組織が取り組まないといけない課題ですね。
いかがでしたでしょうか。プロジェクトのアウトプットのあり方を見直すと、より良いプロジェクトマネジメントのヒントになるかも知れませんね。
次回は新テーマの予定です。