ではなぜ、ITプロジェクト管理者と事業寄り幹部のやり方だと違いが出るのだろう。わたしに言わせれば、プロジェクトが常にゴタついて直前の変更要求とそれに伴う急場しのぎが日常茶飯事になり、それを言い訳に事前の計画を立てない状況に、プロジェクト管理者が慣れてしまっていることが問題だ。「計画は必要ない」派の管理者と幹部の多くが見過ごしているのは、計画の深さと広さは直接的に、プロジェクトの複雑さと関係するという点だ。プロジェクトが複雑になるほど、綿密な計画が必要になる。計画立案のための時間と予算が限られている場合、プロジェクトの成功を保証するためにリソースを拡大すべき最も重要な分野は以下の通りだ。

1. 開発と導入

　これには完成品の設計、製作、導入のための成果物とタスクが含まれる。ここで止まってしまうプロジェクト計画はあまりに多い。行き着く結果は、導入時の大混乱だ。

2. 組織変更管理

　すべてのプロジェクトにはある程度の変化が伴う。変化が大きいほど、成果物とタスクの数も多くなる。新プロジェクトで何をするかに焦点を当てるのではなく、どうやるかに焦点を当てること。新しい人間工学インタフェース、プロセス、専門用語はすべて、変更管理の取り組みにおいて考慮すべき要因だ。

3. チーム教育と研修

　中程度から高度の複雑性を持ったプロジェクトでは、新しい技術とビジネスプロセスについてチームメンバーの教育が必要だ。プロジェクトの時間と経費がかさむことから、この過程は飛ばされてしまうことも多い。

4. 顧客トレーニング

　これは見過ごされがちだ。「問題のある」（導入されたが使われないなど）プロジェクトの大きな一因は、タイムリーで適切な顧客トレーニングができていないことだ。また、顧客トレーニングは一般的に集中トレーニングが始まる導入後ではなく、計画の初期段階で実施されるべきだ。

5. 法令遵守

　セキュリティ問題と不正会計のリスクが増す中、多くのプロジェクトで堅牢なファイアウォールと、サーベンス・オクスリー法（SOX法）などの法令遵守が求められる。

6. 次善の策

　失敗した場合に備え、リスクの高いプロジェクトは第2の計画を立てておくといい。

7. 旧システムのリタイア計画

　新プロジェクトが現行システムに入れ替わるものなら（ハード、ソフトなど）、旧システムのリタイア計画を立てておくこと。そうしないと顧客がそれを利用し続け、結果として労力が2倍かかりデータ破損につながるかもしれない。

　「うっとうしい計画などいらない」という態度は大切なものを失うことにつながり、高い確率でプロジェクトの弊害や失敗を招いている。

本稿筆者のゴパル・K・カプール氏はカリフォルニア州サンラモンにあるプロジェクト管理センターの代表で、著書に「Project Management for Information, Technology, Business and Certification」がある。