私、キットＰＭはプロジェクトマネジメントに関する
あらゆるご相談、ご用命を承ります。
サービス内容のご確認、ご連絡はこちらからどうぞ。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
■ずいぶん朝晩は冷え込むようになってきました。風邪などひかないようご自愛ください。
さて、前回プロジェクトの失敗を定義しようと色々考えてましたが、いまいちスッキリとまとまってないい感じでしたので、もう少し掘り下げて行こうと思います。
■前回、極端な表現をすると当初計画とどれだけ違っても”終わりよければ全て良し”ということで結論しました。ただ、終わり良ければの定義には”プロジェクトに関わる全ての人にとって”という条件が付きますので簡単なことではありません。
そういえば、成功したと言っているプロジェクトにしても誰かが我慢しているだけで、全ての人が満足などとお気楽なことを言える状況ではない物が沢山あります。例えば、IT開発で開発ベンダーが赤字を出してなんとか収まったとか、逆に発注者がやりたかった機能を諦めて妥協したとか。普通に身近で目にする話しですね。つまり、誰かは成功したと思っているけど、誰かは失敗したと思っているプロジェクトが普通の状況なのかもしれません。
それでは、成功と失敗の境界線はどこにあるのでしょうか？キットＰＭはは以下のように考えています。（完全な）成功の定義はこうなります。
１．（充分に吟味された）初期の目的を達成する
２．目的を達成するために掲げた全ての目標
（期間、コストを含む）を達成する
３．メンバが掲げた個人目標を達成する
では、完全ではないけれど成功したと見なせる定義はどうなるでしょうか。思い出して欲しいのですが、「目的と目標」のところで述べた中に、目標には優先順位をつけることが重要だというのがありました。複数設定した目標に優先順位をつけ、Ａ．絶対に達成しないといけないもの Ｂ．達成するのが望ましいもの Ｃ．できれば達成するべきもの にカテゴライズします。明確ですね。このカテゴリだと、ＡとＢが達成できればひとまずプロジェクトは成功したと言っていいかと思います。いかがでしょうか？ようするに計画段階で成功の条件付をしておくということですね。
実は前回述べた、目的そのものが変わるというシチュエーションはモダンＰＭ的に言うと、プロジェクトを中止し、新たなプロジェクトを立ち上げるというプロセスを踏むことが必要になります。ただ、最三述べてきたように、当初はプロジェクトの目的設定が曖昧な場合があります。このような時は当然ながら目的の再設定を行ないますが、プロジェクトを新規に立ち上げるというわけにはいかず、修正（なんと！）で乗り切ることもあります。つまり、再設定したプロジェクト目的を果たせれば、プロジェクトは成功となります。でも、当初掲げた目的は達成できなかった（！？）わけですから、一度失敗していることになります。まぁそれを声高に言わないのは大人の対応ということでしょう。
■いかがですか？プロジェクトの成功とはについて、随分整理が進んできたように思います。目標の優先順は、マーケットの状況や経営戦略の内容により判断が変わってくるはずです。時には全てが優先順位１番などという話になったりしますが、その状況に至るということはその時点でかなり切羽つまっているはずですので、リスクの重みも相当大きくなります。ということは、逆にコアになるものは何かを明確にしないといけないはずですが．．．もしあなたがそのようなプロジェクトのＰＭに指名されたらどう行動しますか？難しく、重要な問題です。また、別の機会に考えたいと思います。
■プロジェクトの成功と失敗を計画段階で定義しておくことが、最後の最後での決断のトリガーとなります。ＰＭにとっては使わないに越したことはないですが、準備しとくのも仕事の内ということになりますね。では、次回はテーマを改めて「コミュニケーションと信頼感」について考察します。