I agree that keeping documentation up-to-date is an absolute pain in the arse but when you need it and it isn't there you are in trouble.
I work for a company that specialises in information mapping. Rather than write four sides of A4 prose they try and condense it to a diagram and a set of bullet points. I'd be shot on sight if they heard this over-simplification of it.
The problem with maintaining disaster recovery documentation is one of investment.
- Investment in time.
- Investment in tools to do the job.
- Investment in training.
If I browse around this site there are various scripts to automate the various SQL Server admin tasks and even one to blast DBCC SHOWCONTIG info into a database table.
I believe that it is not beyond the wit and wisdom to develop a tool that will maintain the bulk of the disaster recovery documentation.
I also work with content management systems. Rather than building pages of information they tend to allow authoring of blocks of re-usable text. This tends to have versioning and including localisation facilities.
If the money was invested in such a system for use as a disaster recovery tool then the job of updating the disaster recovery information would be much simpler. Unfortunately the attitude is no-one got a pat on the head for putting in a better admin system.
Oh, rule one of disaster recover. The first machine to recover is the one with the disaster recovery documentation on it.