Have you ever thought if the way you are organizing your documents works for you and your team? Recently I had to sit and think (and research) of a common structure that on one hand is general enough to work (with minor adjustments) for most of the projects I participate in, and on the other hand is logical and self-explanatory.
Here is what I came up with:
- Project Planning
- Brief – an overview of the project setting one's focus on the subject.
- Specification – definition of the scope and work that has to be done.
- Plan – time schedule describing when and what should be done in a sequential manner along with specific milestones.
- Roles & Responsibilities – definition of a person's/team's involvement in the project.
- Technical Documentation
- Network Access – what credentials and software is needed and how to use it.
- Systems and architecture – any specifics about interacting servers or applications.
- Rules & Procedures – description of things such as way of time tracking, question escalation, access requests, etc.
- Guides/Manuals – any documentation such as user manuals, installation guides, or other information regarding environment set-up or usage.
- Project Areas (Modules)
- Area 1
- Requirements – expectations that have to be met by persons/teams involved in this area.
- Processes – description of the steps that are taken for fulfilling the above requirements.
- Issues & Solutions – any issue that is found during the process of work and its corresponding workaround (if no workaround, then it belongs to “Questions & Concerns).
- Area 2
- Questions & Concerns – any open questions that need to be resolved along with obstacles/assumed difficulties or recommendations.
- Meetings & Discussions – description of meetings (discussed topics, decisions taken, responsibilities distributed, deadlines that were set, etc.).
- Contacts – contact information of the persons taking part in the project.
Reader, do share your thoughts or experience on this matter :).