Here are some notes I made quite awhile ago. The notion is that there are some documents that should always exist for projects and applications. More importantly, which documents belong with projects (which are transitory) and applications (which we hope will be permanent)?
This makes a difference when designing source code repositories, for instance. I don’t want to be moving files from project folder to project folder, when the documents should logically be part of the application.
It’s obvious these notes are geared to web applications.
I may expand (even expound) on this another time.
Project Brief * Mission * Business Purpose * Competitive Info * Top-Level Outcomes * Executive Site Description * Risks * Estimates
Task Backlog and Estimate
Site Brief * Visitor Problem Solved * Mission, goals, etc. * Features * Design Principles * Architecture
Site Map Design Elements (pages as needed) Wireframes/Layouts Schema Issue Tracking
Yet more notes….
Web or Paper Based Documentation
(Customer Brief) * Project Brief * Schedule/Budget * Issue Tracking * User Interface (screens, site map, help/training) * Programming interface (includes architecture overview, class interfaces, basic usage, etc.) * Schema * Supporting documents (mostly discovery) * Environment Info (things like site URL, database locations, user/pass)
Document rule of thumb: 90% of documents are for discovery and have no client value after the project is complete.
What information is needed by someone new to a customer/project? These are the “keeper” documents.
Some documents exist “above” the project. For instance, a site often exists through multiple projects (revisions), so there would probably be a discovery site map for the project, but there should be a current site map at the customer level. * UI * API * Schema