Documentation is often left for last in software projects. One of the most visible aspects of the project from the perspective of users being trained, the management review, and client or customer experience, great documentation should be considered a critical part of your software project.
Documentation?
Waiting too long produces rushed, poor documentation. If hours are short at the end of the project, and the documentation remains to be completed, either the project might go over budget just because of the documentation effort, or the documentation may not get done or be done poorly. Any of these things reflects badly on the project team and on you as a project manager. Here are some tips for ensuring high quality, useful documentation that is on time.
Developer Traits
Developers can see documentation as a chore and will delay doing it. Others may use excuses and rationalizations here, like "the code is changing; I don't want to have to rewrite, etc". These are all attempts to avoid the work. Other team members may have other reasons and rationalizations for not completing the documentation. Perhaps the excuses are interface changes, incomplete code or even just that they are waiting on something else. A few process and work habit changes and you can have your team seeing the light on the value of working on documentation sooner rather than later, and why great documentation makes them look great.
Creating Great Documentation
Development environments and programming tools have come a long way. It's far simpler now to integrate documentation for standard components and APIs into your project and its custom code. In line comments convert to documentation automatically now in some development environments. You do have to work on the comments. Good comments can make the difference between excellent, maintainable, troubleshoot-able code and a huge PITA. Microsoft's development environments allow for the creation of the help menus from in line comments and documentation in the code.
Developers may not want to spend the time as they code including thorough, clear comments and documentation, but tell them to consider: if they do it now, they won't have to do it later! It may take some retraining and development process changes to get comment and document as-you-go into practice, but it's worth it.
If user guides and documentation are being developed by others as well as coders, be sure that they work closely with the coders to describe accurately what the product does and what its capabilities are. Documentation written by someone that didn't write the code can be good of course, but true understanding of the product is in the minds of its creators.
Getting Started
Set a policy and project guideline for documenting in line and as-you-go. Stress that documentation is not an afterthought or something that is a necessary evil. Have developers and architects work with design and training team members to ensure that there is time and pride put into the documentation. Long after you are gone and the team members are on to other projects, the documentation as a testament to your work will be around. Be proud of it.