ユーザーのストレスを無視したプロジェクトは失敗する

biz think

TechTargetに非常に興味深いタイトルの記事が。。。

プロジェクトの開発経緯を詳細に分析した結果、ユーザーに大きなストレスを与えたことが、失敗の最大原因であることが分かった。ユーザーが受けるストレスの程度は、以下の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。