Project Definition Document

We've referred to "gaining consensus" and "getting agreement" on the answers to the important project defining questions several times. How do you do this? You write them down and get everyone to formally sign off on this document. We will refer to this document as the Project Definition document. In this section, we will review both the "must-have" elements and "good to have" elements of the Project Definition document.

caution

There are many different names for the Project Definition document. Some of the most common alternative names are Project Brief, Project Charter, Project Initiation, Scope Statement, and Statement of Work.

We are using Project Definition, because this term best describes the purpose of the document.

 

Required Elements

First, let's review the must-have informational elements that should be included in your project definition document.

• Purpose This section should answer the "Why?" question and clearly communicate the expected business value. It should reference the organizational objective being supported, the business problem being solved, and its relative priority level.
• Goals and Objectives This section is derived from the Purpose and communicates the targeted outcomes for the project. It should answer the "What are you going to accomplish?" question.

  tip

  

  Whenever you are defining what is "in scope", it's a good idea to note what related work is "out of scope."

  This will help clarify understanding and expectations regarding project scope.

  As a rule, any work item that is related to your defined scope that someone could assume is included, but is not, should be listed as "out-of-scope."

• Success Criteria Closely related to Goals and Objectives, this section should list the measurable, verifiable results that will determine the success level of this project. This section is often referred to as Critical Success Factors too.
• Project Context Documents how this project relates to other projects within the product program and/or within the organization as a whole. This section should also describe how the project fits within the organization and business process flow.
• Project Dependencies Closely related to Project Context, this section clearly documents any dependencies that could impact the results or success factors of this project.
• Scope Specifications Clearly designates the organizational, process, systems, and functional specification boundaries for the project. Should be high-level breakdown of the Goals and Objectives.
• Out-of-Scope Specifications To better communicate what is considered to be "in scope," it is recommended that you clearly indicate the high level work items that are related (or associated) to this initiative, but that are not of this project
• Assumptions This section clearly communicates the underlying basis or things to be considered true in regards to any other aspect of this document. In most cases, the Scope, Out-of-Scope, Assumptions, and Constraints section combine to clearly define what work will be performed by this project.

  

  To expedite the process of getting agreement on the project definition document, walk through an initial draft that you develop with the stakeholder group rather than starting with a blank slate.

  The process of project definition and project planning is a process of iterative refinement (or what PMI refers to as progressive elaboration), so your draft will help facilitate the discussions, negotiations, and modifications that need to occur amongst the stakeholders.

• Constraints This section lists any business event, schedule, budgetary, resource, or technical factor that will limit the options available to the project.
• Risks This section will list any uncertain event or condition (risk) that, if it occurs, could have a negative impact on one or more project success criterion (schedule, budget, quality, and so on). For each risk, it is good to list the related causes, the perceived negative impacts, the likelihood it will occur, and the planned response strategy and action items. See Chapter 14, "Managing Project Risks," for more details.
• Stakeholders This section lists all of the individuals, business units and organizations involved in the project, the role(s) each is expected to play, and an indication of how they relate to one another. A Project Organization chart and a Stakeholder-Role Description Table is highly recommended here.
• Recommended Project Approach To better describe the intent of the initiative, this section highlights the recommended approach to getting the work of the project done and why it was selected over any other options. This section should note any key strategies, methodologies, and technologies to be used.

Additional Elements to Consider

These are informational elements that may not always apply, but if appropriate, are recommended additions to Project Definition document.

• Alternative Project Approaches This section lists the approach details for any alternatives that were considered.
• Organizational Change Issues Since most projects result in a change to the status quo, and the most common oversight in projects is not adequately realizing, planning, and preparing for the "change" impact to current customers, business processes, and personnel, it is highly recommended that this area be a focus from the start of the project.
• Policies and Standards Given the priority that standardization, compliance, process improvement, security and quality have in most organizations, it is highly recommended that any policy, regulation, or standard that will be applied to the project or the results of the project be identified from the start of the project.
• Preliminary Cost, Schedule and Resource Estimates Generally, there is some preliminary "ballpark" expectation for the cost, timing, and resource needs of this project. In many cases, these will be noted as either project objectives or as project constraints. The most valuable information here is not necessarily the date or the dollar amount, but an explanation for what is driving the figures presented.

  caution

  

  The Project Definition document is a "living" document and should be updated to reflect the evolving circumstances, issues, and needs surrounding the project.

  Changes are okay. The changes just need to be announced, reviewed, and approved by the relevant stakeholders.

• References to Supporting Documents For any situation, where the results of a preliminary or related project served to define the need or details for this project, always include a reference to those supporting documents. Common examples would be a Business Case, Cost-Benefit Analysis, Assessment Results, Requirements Document, and Business Process Engineering Studies.