Skip to Content

Project Documentation Templates

Project Charter

The Project Charter is the initiation document for any proposal/project. The information in the charter should clearly articulate the scope of the project, as well as provide any associated information that should be considered when defining the requirements and potential timeline for the project. Project charters for TR work should be submitted to the appropriate TR Director once prioritized by the user’s department/division.

Charter Template (DOCX, 111 KB)

Project High Level Estimate Worksheet

The Project High Level Estimate Worksheet is a brainstorming tool and guide for the project teams to organize the high-level estimate of work for the high-level requirements of the project.


Project Requirements

The Requirements document is used to describe the requirements of the project in sufficient detail to satisfy the project goals and desired results. Initially, high level requirements should be identified when defining the proposal. Once the proposal becomes an active project, the requirements should be expanded to the detail needed to produce the desired project results. Other types of requirements documentation may be used in addition to, or in place of, the template. Requirements should be in enough detail that any necessary test plans and testing can be created.


Activity Diagram

The Activity Diagram is used to give a visual representation of the activities (process flow) of the business process being addressed by the project. It should show the activities within the functional areas and their relationships as they relate to this proposal or project. The activity diagram supplements the requirements documentation to assist in understanding the business problem being resolved.

NOTE: Activity Diagrams do not describe the project steps to be taken to produce the solution.


Communication Plan

A Communication Plan is developed to describe what information should be communicated, and to whom, as well as how and when the communications will occur. Initially, you will determine which Stakeholders should receive communications and what type of communications they should receive.  

Projects may be comprised of many different groups of stakeholders (e.g., executives, sponsors, customers, developers). Each of the stakeholders may have unique requirements for information relating to the project, including progress, issues, and change (both business changes as well as project changes).  

Stakeholder perception of project success is largely influenced by the quality of the project information made available to them at the appropriate time. From the assessment of project stakeholders and their communication needs, the initial communication plan should be updated with detailed information and periodically reviewed throughout the project.


Report Requirements

The project Report Requirements document is used to provide enough detail about the specific report request to allow the developer to produce the desired report. Many projects involve the creation or modification of one or more reports. This template is designed to assist in capturing the necessary requirements for each of the reports to be produced by a project.


Work Breakdown Structure (WBS)

A WBS is a visual representation of the tasks (in increasing detail) necessary to complete a project. It resembles an organizational chart in structure, with the highest level representing high level project components or phases. In increasing detail under the highest level, work is progressively broken down into smaller components until at the lowest level of the WBS work tasks can be described.  These lowest level tasks can then be scheduled and assigned to individuals and entered into a Project Tracking and Management System for tracking.


Project Closure Report

The Project Closure Report is intended to capture what you have learned during the course of a project, what you might do again, and what you might change in the future. Much can be learned from the delivery of a project. While many things worked well, some may have worked better a different way. 

For an organization to improve its ability to successfully deliver projects, and therefore products, we must learn from each other’s successes and mistakes. This template provides a guide to capturing this important information for documenting and sharing among the project’s Stakeholders and TR staff. 

Those who ignore history are doomed to repeat it. – George Santayana