失敗したプロジェクトから学んだ3つの教訓 - (page 2)

＃2：プロジェクトの三角形からは責任者でも逃れられない

　プロジェクトマネジメントの講習で、時間とコスト、スコープという3つの制約について学んだはずだ。そして、プロジェクトの三角形を構成するこれら3つの辺は自由に変更できないということを答える講習最後のテストにも正解しているはずだ。実際のところ、三角形の1辺の長さは、他の2辺に影響を及ぼさずに変更できないのである。

　こうした事実があるにもかかわらず、前述した人材採用プロジェクトの責任者は、コストや時間に影響を及ぼさずにスコープを追加できると考えていた。この責任者はウェブサイトの稼働開始予定日の2週間前に、応募者が複数の職種に応募できるよう、「iPod」のようなルック＆フィールを人材募集サイトに追加したいと言ってきたのである。

　このスコープ変更が行われた時、チームはユーザー受け入れテストの真っ最中だった。しかし、プロジェクトへの影響について誰も異議を唱えず、その責任者はとにかく作業を完了させてほしいと考えていた。最終的に予算が大幅に超過し、チームは長時間にわたる残業を強いられ、業務的な価値がほとんど得られない部分で多大な労力が無駄に費やされる結果となった。

　責任者がこういった新たな要件を持ち込んできたこととは関係なく、要求されていた機能は納期までに完全に実装できなかった。このため、そのウェブサイトはごく一部しかリリースできないという結果に終わった。

教訓：利害関係者全員が従う変更管理プロセスを、プロジェクトの初期段階で採用する。

＃3：英雄的行為からは失敗しか生まれない

　ヒーローが格好良く見えるのは映画の中だけだ。成果物に機能を追加するために英雄的行為を要求することや、特定の個人によってプロジェクトが成し遂げられると考えることからは、失敗しか生まれない。

　前述した人材採用システム開発プロジェクトにおいて、チームは開発者のリーダーとして外部からコンサルタントを雇い入れていた。このリーダーはプロジェクトにおける実際の成果物を作成していたため、プロジェクト責任者に対してもある種の影響力を有していたし、プロジェクト責任者からも信頼を寄せられていた。しかしこのリーダーは日中、要求をまとめるための会議に忙殺され、開発はほとんど行えていなかった。そのため彼は、夜中の2時まで8時間の残業をこなし、コードを記述するという日々を送っていた。また彼は、社内のIT要員とコードベースを共有していなかった。日々の進捗報告の場において彼は、「他の人にわずらわされることなく1人で働けるようにしてくれれば」、自らが担当するコードは納期までに用意できるとかたくなに主張していた。しかし結局のところ、動作するコードは納期までに完成しなかった。

　一方、プロジェクトの特定部分に責任を持っていた社内のITチームは、チームとして働いたおかげで納期までに成果物を用意できた。チームはバグ修正とエンドユーザーテストのサポートのために連日深夜まで残業した。誰もプロジェクトのヒーローになろうとはしなかった。このプロジェクトは、1人の開発者の英雄的行為で完成させるにはあまりにも大きすぎたのだ。

教訓：効率的なチームを作り上げ、彼らを信頼する。

まとめ

　プロジェクトの進捗におけるさまざまな局面で成功、あるいは失敗が生じる。これこそが問題管理プロセスやリスク管理プロセスを実施する理由なのだ。プロジェクトを成功させる鍵は、過去のプロジェクトにおける失敗から学び、学んだ教訓を実践することなのである。