システムの保守はシステムをユーザに引き渡してから保守が始まると考えていませんか？
もちろんそういう考え方も成り立つのですが・・・
実はシステムの保守は開発中から始まっているでのす。
（もっというと、成果物を作成した時点から保守が発生しているのです。）
ある設計書を作成した後、仕様変更が発生すれば、当然その設計書を変更する必要があります。
この変更というのは、まさに保守なのです。
ドキュメントとソースの乖離がよく問題にされますが、これはソースとドキュメントの関係だけではなく、ドキュメントとドキュメントの関係も同じです。
ドキュメント間に整合が保たれていなければいったいどのドキュメントを信用して作業をおこなっちけばいいのでしょうか？
上流工程の成果物に基づいて下流工程の成果物を作成していくわけですから、ドキュメント間に不整合が発生していた場合は、より上流のドキュメントが正とされるべきかもしれません。
しかし、実際に変更が発生するのは作業が行われた後、つまり下流工程で発生するわけです。
その場合、担当者は目先の成果物は更新しますが、それを上流工程までさかのぼって修正するでしょうか？
残念ながら、多くの場合、そのようなことはしません。
そうすると、ドキュメントとドキュメントの不整合が発生し、さらに、より上位工程で作成したドキュメントの方が現状に合っていない（最新ではない）可能性が大きいのです。
したがって、システム開発を行う過程でいかに保守しやすいプロセスとするか、保守しやすい成果物にするかということを常に念頭において作業を行う必要があります。
情報は状況に応じて常に必要最小限の状態を保てることこそ、重要であると考えています。
『情報は少なければ少ないほど、最初の理解及び開発・維持管理が容易になる』と考えて必要最低限の成果物を作成することに限定すべきです。
システムを構築するためだけではなく、保守するためにどのようなドキュメントが必要なのかを合わせて検討すべきでしょう。
システムを構築してしまえば、システム構築プロジェクトは終了ですが、保守はその後何年（何１０年）と続けていかなければならないのです。
システム開発においては、さまざまな成果物が作成されますが、その成果物は本当に必要なのでしょうか？
Q1．何の目的で作成しているのか理解しているでしょうか？
Q2．一度作成した資料（成果物）を後工程で、どのように利用しているでしょうか？
Q3．その成果物は、変更が発生した場合、メンテナンスされているでしょうか？
Q4．上記の質問に、直ちに答えられない成果物は、本当に必要な成果物といえるでしょうか？
不必要な成果物を作ることに、工数を消費し、本来行うべきタスクをないがしろにしていませんか？
必要なものしか作成しない、定義しないということが重要ではないでしょうか？
いや、言われるまま作る訳では無いですよ。
当然、必要無いとかな事はちゃんとお客に伝えるんだけど、なかなか理解されない（欝
まぁ、納品後の管理はお客と割り切ってしまえば、楽なんですけどね。（その後の対応は、全て仕様変更とかｗ）
コメントありがとうございます。
確かに、必要ないものと作れといってくるユーザ客側にも問題はありますね。
実際ユーザ側にも、保守で本当に必要なものは何なのかという明確な考えがないことが多いと思います。
これまで、いろんなプロジェクトに参画してきましたが、開発終了後もきちんとメンテナンスされているドキュメントって以外に少ないものです。
（というか、ほとんどないような気も・・・）
保守段階でメンテされないドキュメントは、実態と乖離してきますので、ドキュメントの信頼性が問題になってきます。
信頼できないドキュメントは当然使われなくなってきますので、そのうち存在自体が忘れられてしまう・・・。
そういう状態にしないためにも、必要最低限のドキュメントを規程し、どんなに苦しくてもメンテしつづけるという覚悟と努力が必要だと思います。
以前、設計書の内容をツールに入力してほしいという案件がありまして、その案件の担当になったことがありました。
ファイル数で数１０００ファイルあったと思いますが、まず最初にやったことは、設計書の整合性の確認です。
整合性の確認といっても、別にたいしたことをやったわけではなく、「＊＊一覧表」という成果物があった場合、各一覧に対応する「＊＊詳細」が存在するかというだけの簡単なチェックです。
惨憺たる結果でした。
あるサブシステムでは２０％程度しか合っていませんでした。
検収を出したユーザ側にも責任はあると思いますが・・・