A collection of common documents for managing design and development projects for small studios and freelancers. The intention is to create a framework (in the conceptual sense) for project documents to make sure that the right questions are asked at each step of the process, and the right information is gathered from the client.

For the sake of organization, documents are organized by the typical chronological phases of a project. Of course, no project is typical, so no doubt some documents will be used out of order.

The suggested use of these documents is to have the individual make copies of these files, and replace their own information and project details when needed. Most document will be a series of prompts to help guide the creation of documents that would be sent to a client and approved.

Throughout the documents, any instance of [OWNER] should be replaced by the name of the individual or business that will be doing the work. Any instance of [CLIENT] should be replaced by the name of the client's business that will be commissioning the work.

Note: These documents are by no means comprehensive, nor are they intended to replace legal counsel. Especially for contracts, you should consult a legal professional to assure that documents fit both your business and local laws.

Below are the typical project phases:

After making contact with the prospective client, it's a good idea to learn more about the project, the client, and their business. Beyond the objective of determining the fit for the project, one of the main goals of this phase to start to put some parameters in place around the project.

Following the conversation that took place in Phase 1, this phase looks to define the project in very concrete terms. In addition, other details are also agreed upon, such as schedule and payment. The outcome of this phase should be a contract that both parties agree on, and sometimes a S.O.W. or M.S.A. It is also helpful to define logistically details that relate to the implementation of the project (e.g. technical requirements, production details). Finally, the most critical but difficult document to create is the Brief, which is essential to quality work.

Once work begins, it's essential to keep tabs on the progression of the project. This includes regular checkins with the clients and a means of keeping track of who is responsible for which components.

Following the formal structure of the project, it's extremely beneficial to do a post mortem. Even if the project will roll on to another iteration, it's best to assess successes and failures within the previous cycle. Ideally, this is done with the client, but internal post mortems can be beneficial.

Common terms used throughout these documents, in lou of a glossary within each document.

Further external resources for project documents.