6．教訓をつかむ
どんなにダメなプロジェクトにも見るべきところはある。それは、将来別の仕事に流用できる、ビジネスルールのオブジェクトコードかもしれないし、今後に生かすことができる、あるスタッフが新しい役割で発揮した素晴らしい才能かもしれない。失敗分析の一部として、チームの中の「よかったこと」を見つけ出し、プロジェクトが提供した価値を見いだすことは、たとえ本来の目的が失敗した場合でも有益だ。
7．関係者のレビュー
プロジェクトマネージャーは、自分自身（およびほかのメンバー）がプロジェクトで発揮したパフォーマンスを評価すべきだ。その焦点はプロジェクトの目的に当てられるべきだが、多くのプロジェクトマネージャーは政治も一定の役割を果たすことを知っている。ユーザーが非協力的であったり、ITスタッフの間で内紛やいがみ合いがあったり、社外ベンダーが役割を果たしていなかったなどの要素は、すべてプロジェクトの失敗に影響を与える可能性がある。この理由から、すべてのプロジェクトマネージャーは、関係者のレビューと、政治（内部および外部）についてのレビューを行うべきだ。
8．出口を設定する
失敗しつつあるプロジェクトの処理は、空中戦のようなものだ。常に緊急脱出の方法を把握し、パラシュートを身に着けておく必要がある。こういった出口は、プロジェクトが始まる前にチームや利害関係者と共にあらかじめ設定したチェックポイントであるべきだ。通常、これらの出口はプロジェクトのライフサイクル中に時々設定された評価ポイントの形を取り、プロジェクトチームと利害関係者が、プロジェクトが正当化できないと感じたときに、中止するチャンスとなる。プロジェクトにこういったチェックポイントを設定することで、プロジェクトの評価に関して開かれたコミュニケーションと参加を確保し、望ましくない不意打ちに襲われる可能性を減らすことができる。
9．代替手段を準備しておく
ほかに代替手段がないプロジェクトを中止したい者はいない。プランBを用意しておけば、プロジェクトの成果を別の形で引き継ぐことができる。例えば、最初の目標はプライベートクラウドの構築だったが、何らかの理由で上手くいかなくなった場合、代わりにIaaSプロバイダにクラウド環境を構築してもらう方法もあるかも知れない。
10．プロジェクトと予算をフェーズに分割する
プロジェクトとそれに伴う予算をフェーズに分割し、定期的にチェックポイントを作るべきだ。プロジェクトをより小さく、管理可能なフェーズと予算に分割しておけば、数百万ドルを投資し、スタッフを1年間稼働させた後よりは中止しやすい。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
