In one of the companies that i worked, we had this whole process oriented approach with lots of documents (most of which were asked to be filled in by Project Manager). However, in spite of the length and explanations, i realized that it hardly used to help people -the real developers.
So i decided to pull on of myself with a specific objective of "helping the developers". The most important thing i started is to collect most basic questions - the real FAQs.
What i learned is that following matters to most people when they want to adopt certain process, and many things that they may not have prior idea but would appreciate right away if they understand the logic.
Here are the key topics that such a documentation should help:
The process of development to deployment -
How should the code be organized, compiled, published (in the form of DLLs, libraries, executables, installers, web pages and how will they be deployed and tested)?
How should we do version control? (and why if there are newbies).
Understand how the structure of the repository, the code of conduct - when a check-in acceptable and when not, when a version/tag is announced, how the patch, merges will be applied, and what are the cleanliness expectations when a patch or release is declared done
Executing the Methodology -
are we agile, do we do up-front design, which methodology we use? Now given this, it might be a fixed for a given company. Now, for most people, they want to know how we are going to implement it for the given project. This is very specific about the project that will allow people to visualize different milestones and what is potentially important. In a research oriented project - we would want indicate "always validate critical algorithms before building on top of it" in a shrink wrap I would focus on the correctness and importance of features.
Communication responsibilities -
Defining how do you make formal communication - this is not done with whether specific people can talk to each other - but people must have a sense as to what is important enough (problems, design decisions, feature freeze) to be either announce or even debated before proceeding on implementation.
Finally, we must all have a common understanding of code-quality, coding standard and in general what we think is ok or below hygiene level.
I wish I would start off every project with such documents - however, it's not quite easy. But important thing is to address all issues that relate to day-to-day behavior and choices of developers. This goes long way when multiple releases to market needs to be delivered.
Finally, I would also suggest that try to be informal as possible. Usually, the process oriented guys don't quite like informal documents which can potentially be misunderstood outside the context. However, it should be done such a way that it connects the developers.