筆者はこの半年の間に、2人のCIOから販売、注文処理、顧客サービスなどに関連した5つのプロジェクトが失敗した原因の分析を依頼された。これらのプロジェクトの予算規模は50万～100万ドルで、開発期間は7～11カ月だった。プロジェクトマネジャーたちにインタビューをして明らかになったのは、プロジェクト管理の面で多くの問題があったにもかかわらず、5つのプロジェクトのうち4つは開発の最終段階までほぼ順調に進行していたということだ。しかしこれらのプロジェクトが、ユーザーによるテスト、ユーザーのトレーニング、配備というサイクルに入ったところで問題が発生した。結局、3つのプロジェクトが配備の前に中止になり、2つのプロジェクトが運用段階に入ってから3カ月後に中止された。これらのプロジェクトの開発経緯を詳細に分析した結果、ユーザーに大きなストレスを与えたことが、失敗の最大原因であることが分かった。ユーザーが受けるストレスの程度は、以下の5つの要因で決定される。

1. ユーザーの日常業務の時間が奪われる：これらのプロジェクトでは、要件定義、デザインレビュー、導入時のトレーニングのために、ユーザーの業務時間の大きな比率（40％に達したケースも多かった）を割り当てる必要があった。従業員の報酬は業務遂行実績をベースとしていたにもかかわらず、日常業務の分量を減らす措置は取られなかった。その結果、多くのユーザーが、新プロジェクトに必要な時間を割こうとしなかった。日常業務の時間が奪われることによるユーザーのストレス度は、5段階評価（5が最大）で4.0だった。
2. 変化の程度：5つのプロジェクトはいずれも、技術、業務手順、ユーザーの説明責任のレベルにおいて大幅な変化を伴うものであった。プロジェクトマネジャーたちは、ユーザーが新しい技術（特に新しい操作手順）を学ぶのに苦労を強いられるという点を見落としていた。プロジェクトのスポンサーたち（すべてIT部門のメンバーだった）の間で支配的だった考え方は、「ユーザーが新しいプロセスに適応すればよいのだ」というものだった。しかしユーザーは適応できず、彼らのストレス度は3.5～4.5であった。
3. 変化を受け入れる姿勢：筆者の経験では、ユーザーが新しいプロセスを受け入れる姿勢は、プロジェクトチームがユーザーとどれだけ友好的な関係を築くかと直接的な相関関係がある。この点において、プロジェクトスポンサーおよび主要ステークホルダーの持続的努力が不可欠である。調査した5つのプロジェクトではいずれも、経営者が最低限の関与しかしておらず、主要ステークホルダーがプロジェクトを十分にサポートしていなかった。ユーザーのストレス度は3.0～4.0だった。
4. 変化に適応する能力：これは、ユーザーのトレーニングとサポートと直接関係する。3つのプロジェクトでは、行き当たりばったりのトレーニングしか行われなかった。その理由は、スケジュールの遅れが何度も生じた結果、講習会が直前になって延期されたためである。また、ほとんどのトレーニング用教材はオンラインで提供されるだけで、ユーザーにとっては使いづらいものだった。プロジェクト配備後の最初の数週間は、多くのユーザーが定型業務で古いシステムを運用した結果、大量の残業が発生した。ユーザーのストレス度は3.0～4.5。
5. 変化のタイミング：注文処理プロイジェクトと顧客サポートプロジェクトは、1年間の販売サイクルで最も忙しい時期に配備されたため、大量の残業が発生した。まずいタイミングとなった最大の原因は、スケジュールの遅れだった。残業した従業員に休暇を与えないことを経営者が決めたことも、問題をさらにこじらせた。ユーザーのストレス度は4.0～4.5。

　5つのプロジェクトのユーザーの総合ストレス度は17.5～21.5と、非常に高いものになった。これらのプロジェクトが崩壊したのも無理はない。

　CIOは、プロジェクトマネジャーがユーザーのストレス要因をプロジェクト計画プロセスの一部として評価し、この重要な指標を注意深く監視してプロジェクトスポンサーに報告していることを確認しなければならない。本稿で紹介したような失敗プロジェクトを筆者は数多く見てきたが、ほとんどのプロジェクト管理手法において、この重要な指標が無視されているのだ。

本稿筆者のゴーパル・K・カプール氏は、カリフォルニア州サンラモンにあるセンター・フォー・プロジェクトマネジメントの所長を務める。著書には「Project Management for Information, Technology, Business and Certification」がある。