It's really about trying to balance the documentation as the needs of the users/process change. Your team and functional staff need to determine what documentation is absolutely essential and it should be minimal due to the nature of change in the world we live in today. Documentation is good provided that it is correct, but a working product has more value to your organization.

For one conversion project (COBOL to ASP.NET), our documentation had 6 major revisions (4 before release) and hundreds of minor revisions. Most of the documentation versions in the earlier phases no longer matches the final product. There were new compliance requirements, changes in the enterprise systems and payment process. There was a concrete date that the legacy app would be shut down. If we didn't hit that target date it would cost us substantially to continue the legacy application and we would have to re-write some sub programs within

COBOL to meet our requirements.

So we had thousands of pages of documents, flows, UML, specs, compiled code, unit tests, etc. that were done over 5 years by various staff/consultants (most gone) that no longer apply to the final product.

We couldn't go fully agile, but we finally convinced the CIO, the functional staff and management to go along that route and we salvaged 1/3 of the code and got the project out in time with less staff. Was it perfect when we went live? Nope, but it worked and bugs were triaged quickly. The second phase which was scheduled for a year was released incrementally in under 4 months.

Our source control repository is the documentation. We have standards for check-ins,tasks, bugs, release cycles and comments in the code to tie back to the source control system. We can now extract information from the source control system to build any needed documentation AFTER release. It does require programmers to follow the documentation standards and it isn't perfect by no means, but it works for us.