次に既存システムの改修です。通常システム開発は企画、要件定義、基本設計、開発、テスト、運用というステップを踏んでいきますが、その際重要な事は「ユーザーは急激な変化を好まない」という前提で改修に臨むことでした。意外に思われるかもしれませんがエンドユーザーはリアルな道具は新しいものを求めますが、ソフトウエア（目の前の画面）の新しさは望みません。例えば通常使っているアプリケーションのアイコンの位置が移動しただけでも「使いにくくなった」といいます。

さらに「使いにくくなったのでExcelで作り変えて自分のファイルに入れた」とIT担当者と上司以外に自慢げに話し、その使いやすさから皆がそのファイルをコピーして使い出し、そのファイルが事実上の標準（デファクトスタンダード）となる一方で、新システムは大して使われないのに、毎年の保守/運用費が湯水のごとく流れ出て行きます。組織の誰にとっても避けたい現象です。

つまり、システム改修（開発）する上で最も重要なことは「最も影響力のあるユーザーを設計の段階から巻き込む」ことです。作ってからでは手遅れです。やはり、現場をよく観察して表面的な人間関係だけでなくインフォーマルな人間関係を把握し、中心人物を特定して企画の段階から巻き込むことがツボといえます。自分が関わったものであれば愛着も生まれますし、必ず現場で使われるシステムになるのです。