| IT Document Names | What is it | When do you need it |
| Project Proposal or Project Business Case Document | Explains the “need” for the project and to gain a project sponsor. It is really the kick-off document that explains why the project is taking place; the goals, objectives, and outcomes being sought. This document will provide the justification for investing in the project. | This document answer the "Why" this project should start and worked on, an the reason behind the strategic goals that have not being met in the past, or where mission performance needs to be improved. |
| Project charter Document | A project charter includes high-level planning components of a project, laying the foundation for the project. It acts as an anchor, holding you to the project's objectives and guiding you as a navigator through the milestones. it explains the scope, objectives and roles and authority with regard to the project. It is a formal approval of the project.
Project Charter Document lays out the high-level scope of work to be completed; the requirements; timeline; investment (resources and budget) required; the definition of done, and project success factors.
This is created by a project sponsor. | For complex projects, this document is usually needed if a project has an in depth approval process. |
| Project feasibility Document | Iwe could say, this document is the foundation of the project. Explains the intended results of the project. This document outlines the specific team being pulled together for the project. | This document is always needed because it lays out the foundation of the project. |
| Project Management Plan | Project Management Plan Document facilitate communication among stakeholders, the planning assumptions and decisions, , document approved scope, cost, and schedule baselines. | Depending on the project it can be very detailed or it can be very simple or any degree between. We could say that a Project Management Plan document is “blueprint” for the project that most project managers and project ownerwould like to have. |
| Work Breakdown Structure (WBS) | Decomposes a project into individual activities. The WBS is used to organize the work into manageable sections, often measured in time. A work breakdown structure is the core of project planning, resource management and avoiding project scope creep. | All projects should have a WBS that outlines each activity, resource assigned and time frame to complete. |
| Risk Management Plan | This document provides information on all risks and issues the project may incounter, and estimate impacts and define responses to issues.
| This document is recommended in order to help mitigate issues before they arise. It can be included in the Project Management Plan. |
| Issue Tracker Document | An issue tracker document manages and maintains a list of issues. It is used for assigning issues to people, and track the status and current responsibilities. | This document must be part of any project developmnet. |
| Change Management Plan | This document is used to layout a process for any changes to a project’s scope that may or may not impact the schedule. It is used to record all changes made to a system. | This is document is recommended for all projects so all stakeholders understand the process if a change is necessary in order for the project to be successful. This also helps to alleviate scope creep. |
| Communications Management Plan Document | This will ensure effective communications amongst the project team and stakeholders. Outlines types of communication (email, cell phone etc.) and who needs to be contacted and when he/she should be contacted. For large and complex projects require document policies; status meetings and automated status reporting; work, status, risks and issues. | Most projects should include this information. |
| Staffing Management Plan Document | Outlines the roles and can include specific personnel needed to complete the project, and in most companies this document is in the form of a table that defines and assigns the responsibilities. The document provides information on who is responsible, who is accountable, who is consulted, and who should be Informed. Mapping the information helps to reduce confusion, shows how the workload is distributed and efficiency can be balanced. | In most projects this is recommended document. |
| Project Schedule Document | The project schedule determines what work needs to be done and when. It is a good idea to document the planned schedule and the current schedule so that late tasks can be flagged and properly addressed. | Most often Microsoft Schedule is used for managing schedule and tasks. There are other tools in the market also. |
| Quality Assurance (QA) Plan Document | Outlines how the final product has been vetted and tested before delivery to ensure it meets the project requirements and/or customer’s expectation.
| Recommended for most projects, in some project this document is very detail with test plan, test cases, testing approach. |
| Cost Management Plan Document | In this document covers detail cost information in managing the budget and costs of a project. | Most projects should include this information. |
| Procurement Management Plan Document | This document shows how items necessary for the project (hardware/software etc.) will be purchased, by whom and when, and sometimes the total cost is included. This plan can also outline the procurement process. | This document is only needed for more complex projects where multiple items are purchased and there is a need to track those purchase. Not recommended for smaller projects. |
| Business Process Document | Details the business process flow associated with the project. | This document can be the basis for a scope of work. It can even be the basis for training materials. |
| System Requirements Document (SRD) | Lists in detail all the requirements needed for the developers to deliver a system that meets the customer’s needs. | This document is always needed for IT projects. |
| Requirements Traceability Matrix (RTM) Document | This document includes all requirements have properly been tested. | This document is needed whenever a System Design Specification Document and a Test Plan are developed. |
| Work Plan/Estimate Document | This document provides information about the work involve in completing the project and estimate the work needed.
| It is recommended for all size projects. |
| System Design Specification Document | The design document showcases the high- or low-level design components of the system. This document describes the architectural strategies of the system. | This document is needed for designing any project. The inputs from all related teams involve in the project incorporated in this document. |
| End-User Documentation | This can be one or multiple documents to show how users will intract with the project. | It is recommended for all project. |
| Closure and Lessons Learned Document | Thisdocument helps in many cases: can be used if there is a repeat or a similar project in the future; helps fast track the next project. Recording findings at different intervals of a project will produce better quality. The entire project team should contribute and agree on the lessons learned. There should be clear takeaways and the final step is to share it with the wider team and recorded for the future use. | Highly recommended for any size project. |
Johnjack
ProjectDocumentsGlossary.xlsx
