ステータスという間違った考え

私は最初のプロジェクトに成功したあと、自信満々で2 番目のプロジェクトに取りかかりました。これは大きなプロジェクトでした。私の雇用主にとって、はるかに戦略的なプロジェクトで、私はさまざまな専門分野にわたる人たちで構成されるチームを管理することになりました。そこで初めて、私は自分のスキルが役に立たないことを実感しました。非常に興味深いことに、最終的にプロジェクトが失敗した原因は、私がチームのステータスレポートを信頼していたことでした。

プロジェクトが始まってから2 か月ほどたったころ、インフラストラクチャチームのリーダーが「私たちが下したアーキテクチャ上の想定のいくつかに根拠がないことがわかりました」と私に打ち明けました。彼は「でも月末までには軌道に戻せます」と私に保証しました。彼の保証と私が用意した予備バッファがあるにもかかわらず、私は何かがおかしいという予感を振り払うことができませんでした。

月末になって、そのチームリーダーのフォローアップをしました。彼はいかにしてリファクタリングが予定通り完了したか、いかにして開発者が来月の目標を達成することになっているかを私に説明しました。インテグレーションチームのリーダーと話し合ったときに確認すると、彼女の目からもすべてうまくいっているように見えると教えてくれました。モジュールは仕様にしたがっており、それぞれ十分にテストされ、アーキテクチャの各層は最初のインテグレーションに向けて十分に安定していました。

かなりでこぼこした最初のインテグレーション（たいていの場合がそうですが）とお決まりのQA サイクルの結果、ほとんどすべてのユースケースに重大なバグがあることがわかり、私はかなり驚きました。15 か月のスケジュールのうち5 か月ほどのところにいましたが、プロジェクト作業の3 分の1 が完了するには遠く及びませんでした。

それでも私は、チームメンバー全員が協力して予定通りに終えてくれるものと信じていました。システム稼動日の1 か月前には、自分の仕事の少なくとも95% が完了していると全員が報告しました。しかし、システムを実際に試しているユーザーのひとりを呼んだところ、彼女ははっきりとこう言いました。「いろいろなところに問題があります。これで仕事をするのは耐えられません」

どう考えても、私にはプロジェクトの95% が完了しているようには聞こえませんでした。

経験豊富なプロジェクト・マネジャーであるパトリックが、「この窮地からプロジェクトを救う」ために呼ばれました。プロジェクトの救世主（そして今は私のメンターです）であるパトリックは、事態を軌道に戻しながら、ステータスという間違った考えについて私に説明してくれました。「完了」を定義するのは顧客なのです。ステータスレポートではないのです。

データベースチームは95% が完了していると報告しましたが、開発したものが実際にユーザーにとって使いものになるかには、何ら関係がありませんでした。たとえステータスレポート上は完璧であるように見えても、私たちは間違ったプロジェクト進捗を見ていたのです。結局のところ、プロジェクトは最初から失敗する運命にあったのです。なぜなら私がプロジェクトの目標をきちんと描けていなかったためです。

私はようやく、なぜフィーチャーを開発したら、それが顧客視点で価値を高めているかをユーザーに評価してもらう必要があるのか理解しました。そうすることで、プロジェクトのステータスレポートはアーンドバリューレポートに変わり、どれだけ仕事が残っているかを示すだけでなく、生み出されたアーンドバリューの真の割合を示すようになります。