yes DR is an interesting exercise. below are some some points from my own experience.
o management do not understand time constraints for items such as bandwidth limitations, data volumes, restore times, etc. explain these things in their language and back them up with understandable metrics.
o we were fortunate enough to have separate funding for this project. hence we were able to hire an independent consultant to prepare initial architectural recommendations. specifically, this addressed required bandwidth and the choice of replication technology, i.e. backup only [full/diff], log shipping, replication, mirroring.
o engage a project manager, at least for the initial exercise.
o document everything and keep it safe and accessible.
o test your documented procedures using alternative staff, if possible. i.e. the person writing the failover guides should not be the person testing the failover capability.
o time each task in your test sequence and communicate the results.
o script everything and keep these scripts under version control. our log shipping is set up entirely from scripts. this is much faster than 'point and click' and can be easily automated or transferred to other DBA staff.
o keep things up to date. new customers/applications come on board. don't assume that someone has added their databases to the DR site or updated the documentation. have an appropriate person in charge of this, preferably with a backup.
i'm sure there are others. i'll add anything else that comes to mind.