約束以上にすべきか、約束以下にすべきか

プロジェクトの終わりに、約束していたもの以下しか納品できなければ、あなたはひどいプロジェクト・マネジャーになります。約束していたもの以上を納品できれば、あなたはヒーローになります。実のところ、あなたは約束したのとちょうど同じものを納品するよう努力すべきです。多くてもいけませんし、少なくてもいけません。

新米のプロジェクト・マネジャーは愛想良く、経営者や顧客にフィーチャーを追加させ続けます。たとえそれによって、チームのキャパシティが小さくなったとしてもです。経営者はプロジェクト・マネジャーが事態を掌握していると信じて、この際だからと新しいフィーチャーをどんどん追加していきます。

未熟なプロジェクト・マネジャーは弱みを見せることを恐れ、無我夢中に頑張って何とか実現しようとします。しかしプロジェクトの最終日が近づくにつれ、フィーチャーリストを完了できないことが明らかになっていきます。すると仕方なく、フィーチャーを削減していきます。必ずしも最近追加されたフィーチャーが削減されるとは限りません。以前は喜んでいた経営者も、プロジェクトの終了時か、少なくともリリース後には、プロジェクト・マネジャーに懲罰を与えることを考え始めます。

経験豊富なプロジェクト・マネジャーであれば、最初から断固たる態度をとる必要があることを知っています。彼らは新しいフィーチャーやスコープ変更といったものに抵抗します。ビジネスオーナーに対して「限られた数のフィーチャーしかリリース†には収まりません」とくぎを刺すのです。新たなフィーチャーが出てきたら、将来のリリースに延期するか、計画済みのフィーチャーと入れ替えなければなりません。

経験豊富なプロジェクト・マネジャーであれば、「高、中、低」というフィーチャーの分類をしません。顧客は何もかも「高」にしてしまうおそれがあるためです。彼らはビジネス価値に基づいたフィーチャーの優先順位リストを好んで使います。すぐれたプロジェクト・マネジャーはビジネスオーナーに対して「遅れが発生した場合に、優先順位リストの下の方にあるフィーチャーは、このリリースでは実現できないかもしれません」とくぎを刺します。こうしたやり方は、ビジネスオーナー、特にフィーチャー同士の衝突について学んでこなかった人にとって、苛立ちの原因となるでしょう。ですが時間がたてば彼らもこうしたプロセスに慣れて、プロジェクトの現実として受け入れるようになります。

もちろん、経験豊富なプロジェクト・マネジャーであれば、プロジェクトの途中で変更が発生することを想定して、あらかじめ予備費を計画に組み込んでいます。予備費は懐にしまってあり、顧客やチームにすら明かさないこともあります。予備費は貴重なリソースと同様に管理され、抵抗に耐え残ったフィーチャーだけが使うことを許されます。

このときビジネスオーナーは、最終的に自分の願いを叶えてくれたとプロジェクト・マネジャーに感謝します。開発の最終段階になっても予備費が残っていれば、プロジェクト・マネジャーはその「蓄えを開放」して、新たなフィーチャーをいくつか追加するかもしれません。なぜもっと早くそうしなかったのかと問い詰めるビジネスオーナーもいるでしょうが、たいていは期待していなかった追加フィーチャーが受け取れることを喜んでくれます。

さて、プロジェクト・マネジャーはリリースを完了しました。チームは約束していたものを実現できました。追加のフィーチャーまで提供できたかもしれません。ビジネスオーナーは喜んでいます。チームも喜んでいます。プロジェクト・マネジャーの評判にも傷はつきません。さあ、リリース完了パーティを始めましょう。