Project Definition Document

We’ve referred to “gaining consensus” and “getting agreement” as 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. This section reviews 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.

I use Project Definition because this term best describes the purpose of the document.

 Tip

Whenever you define what is in scope, it’s a good idea to note what related work is out of scope. This helps clarify understanding and expectations regarding project scope.

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

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.
• Success Criteria—Closely related to Goals and Objectives, this section should list the measurable, verifiable results that determine the success level of this project. This section is often referred to as Critical Success Factors.
• Project Context—This section documents how this project relates to other projects within the product program and 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 affect the results or success factors of this project.
• Scope Specifications—This section clearly designates the organizational, process, systems, and functional specification boundaries for the project. This section should be a high-level breakdown of the Goals and Objectives.
• Out-of-Scope Specifications—This section clearly indicates the high-level work items that are related to (or associated with) this initiative but that are not part of this project, to better communicate what is considered to be in scope. NoteTo 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 helps facilitate the discussions, negotiations, and modifications that need to occur among the stakeholders.
• Assumptions—This section clearly communicates the underlying basis or things to be considered true in regard to any other aspect of this document. In most cases, the Scope, Out-of-Scope, Assumptions, and Constraints sections combine to clearly define what work will be performed by this project.
• 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 lists any uncertain event or condition (risk) that, if it occurs, could have a negative effect on one or more project success criteria (schedule, budget, quality, and so on). For each risk, it is good to list the related causes, the perceived negative effects, the likelihood it will occur, and the planned response strategy and action items.
• Stakeholders—Lists all 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. Including a project organization chart and a stakeholder-role description table is highly recommended here.
• Recommended Project Approach—Highlights the recommended approach to getting the work of the project done and why it is selected over any other options as a way to better describe the intent of the initiative. This section should note any key strategies, methodologies, and technologies to be used. TipAn agile project approach should be considered when the requirement details are not well understood, when there is a lack of consensus on the product vision, or when there is high risk involved.

Additional Elements to Consider

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

 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.

• Alternative Project Approaches—This section lists the approach details for any alternatives that were considered.
• Organizational Change Issues—Because 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 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. TipUse a visual project scope summary to gain a clearer picture of project purpose, context, goals, and change impact among key 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.
• Visual Scope Summary—For most projects, a visual summary of the project scope can be an invaluable tool for communicating the objectives, boundaries, and change elements of the project. It can help validate the definition of the project, identify potential risks, and greatly improve the common understanding of the project stakeholders. Especially for any project that is introducing significant change, the effort to create this visual summary is one of the best investments you’ll make. The creation of a visual scope summary definitely falls into the “art” part of project management—there is not a single way to do this. The specific tool or medium used can vary depending on skill set and tools available. The specific approach depends on the nature of the project. For product and construction projects, a prototype or visual drawing of the target can be used. For projects impacting business processes, a variant of a flow diagram (process, data, system) showing current state and proposed future state can be very effective. There is no right answer—you just need to be effective. TipFor anyone who has not attended a Goal Setting 101 course, let’s do a quick review of SMART goals.Actually, I’ve seen three different definitions of SMART goals, and they all apply. In each, the first two parts and the last part are consistentDefinition #1—SMART goals are Specific, Measurable, Achievable, Rewarding, and Time-based.Definition #2—SMART goals are Specific, Measurable, Attainable, Relevant, and Time-based.Definition #3—SMART goals are Specific, Measurable, Agreed-To, Realistic, and Time-based.Perhaps the acronym should be SMAAARRRT. For projects, the third definition is more important due to the “Agreed-To” element.