Required Elements of Project Definition document 1

Required elements

Here are 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—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—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—Clearly indicates the high-level work items that are related (or associated) to this initiative but that are not part of this project to better communicate what is considered to be “in scope.”
• Assumptions—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—Lists any business event, schedule, budgetary, resource, or technical factor that will limit the options available to the project.
• Risks—Lists any uncertain event or condition (risk) that, if it occurs, could have a negative effect 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 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. 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.

Apart from the above mentioned elements, there are informational elements that might not always apply, but if appropriate, are recommended additions to the Project Definition document. These are:

• 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 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.
• 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.

Project Definition Checklist

A project definition checklist can help you to determine whether your project is defined properly and whether you are ready to proceed to the next iteration of detailed planning. If you find that your project is not properly defined, you have the following options available:

• Resolve any gaps with appropriate stakeholders before moving on to the next phase.
• If the project has already been defined, work to resolve these gaps during the detail planning phase.
• If gaps cannot be resolved, then handle as project risks or issues (whichever is appropriate for the specific gap).

General

• Is it clear why this is project is being undertaken?
• Is there a clear picture of the desired results of this project?
• Is there a clear picture of how this project fits within the organizational landscape?
• Is there a gap between available and needed funds?
• Have the success factors been identified? Are they complete? Are they SMART?
• Have any future state performance targets been defined as success factors? Are they SMART?
• Is the gap between the current state and the desired future state clearly documented and understood?
• Has the expected “change” impact on existing business processes, customers, systems, and staff been clearly documented?
• Do you understand who is funding the project initiative?

We'll cover some more required elements in our next post.