After completing your project successfully you have to convey to those who were not present "how it has been" and how successfully you have worked. A documentation can accomplish this.
It is indeed astonishing: Although, after the project, the documentation is the only thing that proves at all that the project took place, innumerable documentations merely convey the following: I am writing this documentation because I have to. But what about the issue of appreciation if a supporter senses that the other side only accomplishes this out of a feeling of perceived coercion? And if the supporter even has to chase after someone because important information is lacking?
But there are also other examples: Documentations that are very elaborate, extensive, affectionate and hand-made. In this case it may happen that the project team does not feel appreciated by the addressee. Some empathy can help here: Your project is something original for you and something that moves you personally. If somebody supports a lot of projects, then he may not find your project as unique as you do. Furthermore, he may be running low on time and capacities. Thus it might suit him if you hand him things that are presented in a condensed manner: Less material, emphasizing the distinctive features of the project (which can indeed also be hand-made!), presented in such a manner that one can also use it for other purposes.
 Different target groups
Documentations are aimed at different persons, both involved and non-involved. It is therefore recommended to consider which kind of information should reach whom. Also the style depends on the target group: Stakeholders and target groups. Since supporters often have a specific idea of what they expect from the supported persons, there are often standardized templates.