This information should have been gathered during the project. It should be apparent early in the project if the project documentation will be a problem. Documentation writing skills are often not the best among developers. You may need a coach, writing assistant, or technical writer to assist with the task. Having been both a producer and consumer of documentation, I can attest that it is difficult to produce good documentation, and that good documentation wonderful to have.
Ongoing sources of this information includes:
- who owns what should have been specified in the contracts;
- what the contractors delivered should match what was specified in the contract, and delivery recorded in the status documents;
- what the developers have done architecturally should be recorded in design documentation;
- what the developers delivered should have been recorded in status documents; and
- how to support the application should have been documented during development.
This information should be developed as the project develops. On-going management of the contracts and contractors should result in the desired information being available at the end of the contract. A simple document tracking contracted deliverables and there state should enable immediate determination of what the contractors delivered. Be sure to add out-of-scope deliverables.
Recording what the developers delivered may be more difficult as they may not file good status reports. For an agile project, tracking story delivery should give you good documentation. Track equivalent deliverables for other methodologies.
Support documentation has always been problematic. Ongoing hand-offs to a production team can be used to gather this information. The production team should require or generate run-books for the application. This should include how to deal with ongoing support. This documentation may be prone to rot on the shelf, perhaps more so for projects which require less on-going support.
I would consider hand-off of the projects repositories (content management system, bug database, wiki, etc.) a critical concern. This can be an invaluable trove of information. If you haven't contracted ownership of the code this will likely not happen. I would at least want the code in escrow. If you supplied the repositories, it becomes an issue of placing them into maintenance mode.
Documentation on how to setup the environments for development, building, testing, and delivery preparation is important for the maintenance team. This should have been documented early in the project and kept up to date. If your organization does multiple projects, try to standardize this as much as possible.