Project Definition Document

Project Definition Guide

Purpose

This guide provides assistance for the completion of the Project Definition Document so that all information that defines the project is captured and communicated. It describes the rationale and requirements for the Project Definition Document (PDD) and then gives suggestion for the completion of each key section.

A project definition checklist is included as an appendix.

Rationale

The Project Definition Document is a overall description and estimate of the work to be accomplished and the infrastructure required to plan, staff and control the project effectively.

Initial project boundaries must be established, but may be refined as more information becomes available.

The Project Definition Document is a living document. Actual results and information from completed project work should be incorporated into the document.

The Project Manager uses the Project Definition Document as a communication vehicle to obtain initial Project Review Board support and buy-in and to discuss overall project progress.

An effective Project Definition Document:

• describes goal and success criteria of the project
• outlines the project time-frame, budget and major deliverables
• defines the overall framework and approach for executing the project
• defines the resource staffing levels necessary to perform project work
• defines the project management infrastructure necessary to control the project effectively.

Requirements

As a minimum, a Project Definition Document should include the following elements:

Element	Description
Executive Summary	A one page summary of key information from the Project Definition Document.
Introduction	A high level description of what is to be achieved by the project and why, including the: mission case for change objectives
Scope	A description of the work that is encompassed by the project including: deliverables – what the project will deliver boundaries – what is in and out of scope
Benefits	A statement of the business benefits to be derived from the project, identified as: quantitative financial benefits quantitative non-financial benefits qualitative financial benefits qualitative non-financial benefits
Risks	A summary of events which are external to the project and which have not yet happened but which, if they did happen, would detrimentally impact one or more project deliverable. Each risk should contain indications of likelihood and impact.
Delivery	A description of the way the project will be done in order to achieve the objectives. This explanation should include factors that determine the approach, including: approach critical success factors constraints dependencies assumptions
High Level Milestone plan	A high level plan showing the key milestones, their dates and interdependencies.
Finances Budget categories are: Internal resource costs External resource costs Other expenses Equipment and Material Total	A description of the: budget (capital and revenue) (ie, what money will be spent) funding how this money will be sourced Based on an average full cost per project and location Either actual contract cost or as for internal resources For items such as travel, accommodation, videoconferencing, external training For equipment or project infrastructure such as computers and rental of office space The total project budget for which the project manager is responsible.
Project Organisation	A description of the organisation of the project required to achieve the objectives, including the: roles and responsibilities key resources external suppliers project infrastructure requirements

Each section of the Project Definition Document captures information for a particular element of the project definition.

Developing the Executive Summary

The executive summary is used to communicate the key points of the project definition to senior executives. It should therefore:

• be concise (with a strong target of one page)
• summarise the content of the project definition, not add new material.

Points that are normally included are:

• business imperative, summarising the
  - mission
  - case for change
  - objective
• key benefits
• key milestones
• financial summary.

Other content should be included to cover specific aspects of the project that warrant executive attention due to their strategic relevance or high risk.

The executive summary should be the last section of the Project Definition Document developed and should be able to stand alone.

Constructing the Introduction

The introduction gives a high level overview of what the project is to achieve, how and why.

Much of the information in this section should be an elaboration or extension of information used to obtain project approval. Typical sources include the feasibility study or the business case.

The completeness of this initiation information can be tested with the aid of the checklist (see appendix).

Mission

The Mission of the project should be clearly stated in terms of how the project will provide value to the business.

The suggested format is the:

To

• what

in a way that

• how

so that

• why

Development of the mission would normally involve the sponsor, owner and stakeholders of the project.

Case for Change

The case for change is a statement of why the organisation must change. The case is typically based on two arguments:

• that the consequences of inaction (the do-nothing scenario) are against the interests of the organisation

• that the benefits are derived by changing either the way the organisation works or through what the organisation does.

These are often considered in terms of:

• reducing costs
• increasing revenue from current activity or
• increasing revenue by undertaking new activities

The aim of the case for change is to awaken the organisation's leadership team to the alternative scenarios of the future and generate a climate of urgency in order to act.

Objectives

The project objectives are stated to:

• set the expectations of the Project Sponsor and Stakeholders
• provide a target point to guide the Project Team
• allow determination of when the project is finished

Considerations for project objectives:

• objectives must state "What" not "How"
• objectives should be measurable

Identification of measures for objectives can be aided by considering the question

"How will we see the difference after the project has been successful?"

• the "To... in a way that ... so that ..." statement style may be useful
• using the “So what?” challenge on statements of objectives can help cut thorough unclear statements to expose he real underlying objective.

Defining Project Scope

There are two main elements to defining the scope:

• identifying the project deliverables
• identifying the boundaries via inclusions and exclusions.

Deliverables

All major deliverables for the project should be identified. At the Project Initiation phase, when the project definition is first developed, the deliverable list should:

• be complete, so that no major deliverables are left out of the scope
• be a high-level description of the deliverables, since not all details are known at this stage

Developing a Product Breakdown Structure for deliverables is a useful technique to ensure that deliverables are not overlooked.

Any key feature or characteristic of a deliverable that is apparent or known to be important should be included. It is expected that each deliverable will be specified in detail as part of the Project Planning phase.

Boundaries

A boundary statement for the project helps to define the scope by clearly identifying inclusions and exclusions for the project.

Boundaries can be identified for a number of distinct aspects of the project, including:

• organisation
• geography
• business process
• technology platform.

It is useful to represent boundaries as an inclusion/exclusion table as illustrated below, as it is often the specific note of an exclusion that is important.

Included	Excluded

Documenting the Benefits

Organisations initiate projects in order to realise benefits, which have been identified during business strategy development and, specifically, in the project's business case.

The way in which these benefits are reported depends on the kind of presentation senior managers feel is acceptable and on the scale of the project.

Benefits can be usefully identified as:

• quantitative benefits
  that can be expressed numerically and can ultimately be translated into monetary terms
• qualitative benefits
  that tend to be “softer” and are measured on more subjective criteria such as satisfaction.

Identifying Initial Risks

The Project Definition Document requires an initial identification of major risks. The major business risks that pose a threat to achievement of the benefits or major objectives of the project are the focus of this risk section. The development of a detailed risk register and risk management plan is a subsequent activity. At this stage a management strategy should be identified for each risk.

A table as shown below may be useful for documenting initial risks.

Risk	Impact (H/M/L)	Probability (H/M/L)	Management strategy

Defining the Delivery Strategy

Approach

The approach to be used for delivering the project's end product should be described. This section describes the "how" of the project.

Considerations when developing the approach include:

• obtaining benefits as quickly as possible
• reducing risk
• ensuring business constraints are considered
• establishing "Go/No Go" points for re-evaluating the cost-effectiveness of the project based on updated estimates, technical feasibility and current business environment
• achieving early useful deliverables without putting undue burden on the users; and,
• cost effectiveness

Approaches for technical implementations also need to consider:

• the relative merits of “build versus buy” for systems or parts thereof
• “Big Bang” implementations generally contain significant risk and delay achieving benefits until the end of the project
• “Phased” implementations generally reduce risk and deliver benefits earlier, but may be more costly and longer in duration.

The approach may take considerable time to develop for a large project, and may be refined and modified as more information becomes available during project execution. Input from business and technical personnel is usually required when developing a comprehensive delivery strategy.

Critical Success Factors

Critical success factors identify what the project must excel at in the eyes of the stakeholders. Typical factors to consider include:

• a full and proper understanding of the requirements, with frequent reviews of the requirements and deliverables
• a forward looking risk management and risk minimisation approach
• high user involvement
• high visibility of the progress and issues through a strong reporting procedure and project issue reporting
• efficient use of all resources
• an understanding of the critical dependencies
• understanding and attention to the external interfaces to the project.

The project team must also be mindful of team oriented success factors. These include:

• a co-operative team centred approach
• efficient working practices with a focus on the specific deliverables
• commitment to time targets and budgets
• early and structured communication of problem areas or uncertainties; problems identified are often problems solved
• open communication within the team and with associated third-parties.

Constraints

Constraints are factors that will limit the project manager team options. Predefined budget is a constraint that is highly likely to limit the teams options regarding scope, staffing, and schedule constraints often take the form of:

• dates
• legislation
• money or resources

Ensure that the details under here are true constraints, and not assumptions - which should be specified elsewhere.

Techniques that may be useful in workshops include using a Constraints Matrix to identify the relative importance of scope, cost and time for the project

	Most constrained	Some constraint	Least constrained
Scope			X
Time	X
Cost		X

Dependencies

Define any dependencies known - that this project might be dependent on, and additionally what might be dependent upon this project. Dependencies should, as far as possible, be defined in terms of a deliverable. A useful technique to get an overview of the dependencies is to create an "inter-dependencies matrix" which identifies:

• the receiver of a deliverable transferred from this project to another
• the producer of an external deliverable to this project

Assumptions

Define any assumptions made for the project that would materially affect the project if they were later found to be untrue. For example:

• the network infrastructure is assumed to be adequate to run this increased functionality without upgrade
• the Group application development strategy is to use xxx technology

Documenting the High Level Milestone Plan

The approach to the project should be expressed in terms of the key milestones, which are associated with the major deliverables of the project.

Identify the key project milestones and associated deliverables. The table below is a helpful way to do it.

Milestone	Deliverable(s)	Planned Date
Project Definition Completed	Approved Project Definition Document

The milestone plan may be included here, or as an appendix.

Including Project Finances

Document the budget for the project and how the project will be funded. The initial information for this section will come from the Business Case. Here the Project Manager adds more detail of the cost elements.

The budget needs to be documented so that regular status reports can be linked back to this initial budget. The categories for budget information are included in the requirements section of this guide, and must match those to be reported against.

Describing the Project Organisation

The organisation structure should be appropriate for the project objectives and scope. The initial structure should be geared towards supporting the near term work effort, since the project organisation structure will generally change as the project evolves.

After an appropriate organisation structure has been defined, the position of sponsor and project manager should be reconfirmed. At times, the initial project definition activities are performed by someone other than the permanent project manager. Additionally, the specific boundaries, approach, estimates and organisation structure may reflect the need to change the Project Sponsor and/or the Project Manager.

Roles and Responsibilities

The key roles required for the project, particularly the main management roles should be identified. A table as illustrated below may be effective.

Role	Responsibilities	Name(s)
Project Review Board
Project Sponsor
Project Manager
Project Team

The Project Organisation Chart may be included here or in an Appendix.

A Responsibility Matrix may be included here or in an Appendix.

Key Resources

If there are specific skills, experience or people that have particular significance to the project these should be identified. The resources will often be associated with key constraints, risks or assumptions for the project.

Requirements/ Skills	Name

External Suppliers

External suppliers can be involved with projects in a variety of roles and capacities. Regardless of the role or service provided by the external supplier, specific project management considerations are necessary to minimise the risks associated with reliance on an “outside party” for performance of key project-related tasks. External suppliers need to have specific goals, deliverables and schedules established that are clearly linked into the project plan.

The major considerations for defining the relationship with external suppliers are:

• the role of the external supplier on the project
• deliverables the external supplier will produce.

Project Infrastructure Requirements

Any specific requirements for the project working environment should be identified. The working environment includes:

• facilities for the Project Team – with consideration to central or dispersed location
• equipment – including wide and local area networks, teleconference, videoconference etc
• office supplies
• access to office facilities, as needed.

It may also be necessary to conduct a readiness assessment to ensure the Project Team has the appropriate training in the selected methods, procedures, guides, and tools to start the project. Insufficient training, conflicting priorities and unfamiliarity with the project environment may prevent a team from functioning effectively.

Project administrative details must be considered and addressed, ensuring conformance with internal practices. Administrative details to be considered may include:

• signature authority for the Project Manager and Team Leaders
• purchasing procedures
• systems access
• work day schedules
• secretarial and administrative support
• travel guidelines and expense reimbursement
• communication vehicles, such as access to an electronic mail system.

The Project Manager and Team Leaders should establish the guides and procedures for managing the Project Team. Careful consideration should be given to this step as the results set the atmosphere for how the project will be managed. Providing the Project Team with the right tools, training, communication mechanisms and administrative guidelines for the project reduces resistance which could prohibit cohesive and effective performance.

The Project Definition Document should contain the key features of these infrastructure considerations. The details can be documented in as Project Operation Guides and provided to each team member.

Appendix – Project Definition Checklist

Questions to Consider

Executive Summary

• Can the reader appreciate the whole document if this was the only section they read?
• Does the executive summary include the business imperative (summarising the mission, case for change and objectives), the key benefits, the key milestones and a financial summary?
• Are there any aspects of the project that warrant executive attention because of factors such as strategic relevance or high risk? Are these included?
• Does the Executive Summary fit on one page?

Introduction

Mission

• What is the expected value to the business from of the project?
• What is the business problem to be solved?
• What must the key stakeholders see as results from the project if they are to declare it a success?

Case for Change

• What are the problems and/or requirements that initiated the project?
• What is the background to this project?
• What are the business drivers? Will the project help reduce costs or increase revenue?
• What new business opportunities are created by this project?
• Will this project change existing procedures?
• Is other organisational change likely during the project?

Objectives

• What expectations do the sponsor and other key stakeholders have for the project?
• What must be achieved for the project to be declared complete?
• How will success be measured?

Scope

Boundaries

• Is it clear what the project includes and excludes?
• Are there specific inclusions or exclusions for divisions, geographies, functions, technologies, or other factors?
• Which business functional areas are involved? Which business functional areas are not involved?

Deliverables

• Have all the deliverables for the project been identified?
• Is there a product breakdown structure so the composition of deliverables is clear?
• Is there a definition or description of each deliverable?
• Who will own or use each deliverable after the project is complete?

Benefits

• How will this project improve , costs, revenue, processes or organisation?
• Are the benefits related to the business case for the project?

Quantitative Benefits

• What are the measurable results expected from the project (e.g. cost reduction and revenue enhancement)?

Qualitative Benefits

• What benefit will the project bring that are ”soft”, or subjective, and likely to be measured on the basis of personal opinion?

Risks

• What are the major risks, threats or obstacles to achieving the benefits from the project?
• Are risks assessed for both severity of impact and likelihood of occurrence?
• How will the project management or approach be tailored to mitigate this risk?

Delivery Strategy

• What is the project’s completion criteria?
• Who and what establishes that the project is done?
• How will the project be accomplished?

Critical Success Factors

• What do stakeholders and sponsors expect to be the outcome?
• What things must be achieved for the project to be a success?
• What things must be in place if the project is to work as planned?

Constraints

• Are there any constraints in respect to the project?
• Are there current standards that need to be followed?
• Does the project depend on key resources or resource groups?
• Is the project linked to a particular legislation?
• Is there a genuine deadline date for the project?
• Does a fiscal year or calendar year play a role?

Dependencies

• What other active projects are related to this one?
• What is this project’s priority in relation to other current or proposed projects?
• Are there any external dependencies (out-sourced work packets, regulatory environment)?

Assumptions

• What are the assumptions made about the project (regarding e.g. resources, business processes, technology availability etc.)?

High Level Milestone Plan

• What are the phases into which the work effort will be divided?
• What are the milestones related to the major deliverables?
• When will each milestone be achieved?
• What are the interdependencies between milestones?
• Are there points when the project might be ended, or at least totally re-evaluated (Go/No-Go points)?

Finances

Budget

• What is the financial commitment?
• What are the initial costs?
• What are the expense guidelines?
• What is the summary estimate of the labour and costs of the project—a top-down high-level estimate for phases and activities?
• What is the initial estimate range including contingency?

Funding

• From what budget will the project be funded?
• Who has authority to provide or refuse funding?

Organisation

Roles and Responsibilities

• Is the project organisation represented in an organisation chart?
• Are the key management roles such as sponsor, project review board and project manger identified?
• Are the business managers who are impacted by the project, or who can impact the project, identified as stakeholders?

Project Sponsor:

• Who is the Project Sponsor?
• What is their level in the organisation?
• What is their level of commitment?

Project Review Board Members

• Who are the Project Review Board members?
• Who is making the Go/No-Go decision?

Project Team Members

• What is the time commitment for each Team Member?
• What is the resource-staffing plan?
• What is the organisation chart that depicts the Project Team?

Key Resources

• Is the design of the project dependent on very few people?
• Are the key resources going to be available for the required amount of effort and at the required time to meet project milestones?

External Suppliers

• Is the project dependent upon third parties for resources or deliverables?
• What are their roles?
• What are the deliverables to be provided by the supplier, and what are their prices/fee arrangements?
• What are the deliverable confirmation specifications?
• What is the payment schedule and what are the provisions?

Project Infrastructure Requirements

• What are the infrastructure (technical, hardware and software, work space), resources and project sponsorship requirements?
• Where will the work be done in respect of business unit location and/or the physical presence of the project team members?
• What are the work planning procedures?