多くの失敗が起こる工程
以上のウォーターフォール型の開発手法を踏まえて、文化シヤッター対IBMの事例を見ると、プラットフォームの利用というのは住宅の建築でいえば建売住宅を購入することであり、既製品をベースに内装や間取りを少しカスタマイズする想定でスタートしていたものが、なぜか早々に建売住宅の壁を一度壊して配置を全部変えるなどの大改造を行い、最終的にその大改造に失敗したというものである。
そのほかのシステム開発に関する裁判例もいくつか分析すると、プロジェクト失敗の傾向が見て取れる。それは、上流工程において失敗の原因が発生し、それが下流工程で顕在化して失敗に至るという点である。
失敗の原因が下流工程に発生するのであれば手戻りが少なく、まだリカバリーが容易である。例えば最後から二番目の開発フェーズでプログラミングを失敗して、それが次のテストフェーズで発覚したのであれば、一つ前の開発フェーズに戻って修正するだけなので、工期や費用が追加されるとしても限定的となり、何とか完成まで辿り着くことができる。プロジェクトが失敗に終わることは少ない。
しかしながら、失敗の原因が上流工程に内在すると、そもそもスタートから間違った方向にプロジェクトが進行していたことになるので、それが下流工程で発覚した場合にはもはやリカバリーは容易ではなく、そのシステム開発は失敗する可能性が高まる。
責任の所在
多くの失敗事例を引き起こす上流工程における原因は、ユーザー側とベンダー側のどちらに責任があるか。
実際の紛争においては、ユーザー側からは「ベンダーが丁寧に説明してくれなかったから、プロジェクトの方向性や進め方を十分に理解できていない状態で誤った方向にスタートを切ってしまい、我が社のビジネスに合わない/使えないシステムになった」という旨の主張がなされ、ベンダー側からは「ユーザーがプロジェクトで実現したい要望を社内で取りまとめてくれなかったり、着手した後から次から次へと要望を出してきたりして、収拾がつかなくなった」という旨の主張がなされることが多い。
上流工程においては、ベンダー側として、システム開発に不慣れなユーザーに対して、どのようなシステムが用意されているか、導入候補となるシステムによって何が実現でき何が実現できないか、納期や予算はどれくらいになるかといった点をユーザー側に分かりやすく説明する義務がある。これを裁判例ではプロジェクトマネジメント義務と表現されている。
他方で、ユーザー側としても、システム開発によって実現したい要望や自らの業態（例えば製造業、コンサル業、金融業など）の特徴を期限内に取りまとめた上で、必ずしもユーザーの業務内容に明るくないベンダーに伝える必要があるし、導入するシステムによって自社の業務フローに変更が生ずる場合には事業部を説得する必要が生ずる。これを裁判例ではユーザーの協力義務と表現されている。
