Project Initiation Document
This document initiates the project and ensures that the project's scope is defined so resources (budget, people and supplies) can be allocated to the project and the correct lines of authority are in place.
Introduction / Project Overview
Describe the background and context for the project and why are we doing this project There should be enough detail so that the rest of the Project Initiation Document makes sense.
Project Objectives
Objectives are statements that describe what this project will achieve and deliver. Objectives should be "SMART" : Specific, Measurable, Achievable, Realistic, and Time-Based. To be specific and concrete, objectives should be deliverable-based. The completion of an objective should be evident through the creation of one or more deliverables. If the statement is at a high level and does not imply the creation of a deliverable, it may be a goal instead. If the statement is too low-level and describes tasks, then it may be a task list instead. Include reference to which Business Plan items and/or Strategies are supported/advanced.
Project Deliverables
All projects have deliverables. In this section, describe what is to be delivered and when. Provide enough detail so that the reader will understand what is being produced.
Project Benefits
List all the tangible benefits in $ terms if possible. State the timeframe for the benefits to be realized.
Project Scope Inclusions
In this section, define the logical boundaries of the project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. Examples of areas that could be examined are data, processes, applications, or business areas. The following types of information can be helpful:
- The types of deliverables that are in scope and out of scope (Business Requirements, Current State Assessment)
- The major life-cycle processes that are in scope and out of scope (analysis, design, testing)
- The types of data that are in scope and out of scope (financial, sales, employee)
- The data sources (or databases) that are in scope and out of scope (Billing, General Ledger, Payroll)
- The organizations that are in scope and out of scope (Human Resources, Manufacturing, vendors)
- The major functionality that is in scope and out of scope (decision support, data entry, management reporting)
- Include a Workbreakdown structure (WBS) of the project scope in the Appendix : this is a hierarchical representation of the project which is deliverable based not time based. Anything not in the WBS is outside the scope of the project.
Scope Exclusions
Detail areas excluded from the scope of the project. The exclusions should support the understanding of what is included. These may cover locations, business areas, business interfaces, systems, processes and interfaces.
Project Approach
Document the proposed project approach; i.e. how the project will be done &8211; facilitation, interviewed, out sourced etc.
Critical Assumptions
Project assumptions are circumstances and events that need to occur for the project to be successful but are outside the control of the project team. They are listed as assumptions if there is a reasonable probability that they will in fact happen
Critical Constraints
Provide details of all factors which must be taken into consideration when deciding how the project is to proceed. These may be timescales, budget, management guidelines, resource availability, and legal requirements.
Dependencies
Describe any dependencies such as deliverables required from other projects or other projects relying on deliverables from this one.
Identified Risks
Project risks are circumstances or events that exist outside of the control of the project team that will have an adverse impact on the project if they occur. (In other words, whereas an issue is a current problem that must be dealt with, a risk is a potential future problem that has not yet occurred .)
All projects contain some risks. It may not be possible to eliminate risks entirely, but they can be anticipated and managed, thereby reducing the probability that they will occur. Where possible define actions that can be taken to mitigate risk.
Funding Source
Indicate funding source(s) for the project and any constraints and assumptions.
