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:
|
| Scope |
A description of the work that is
encompassed by the project including:
|
| Benefits |
A statement of the business benefits
to be derived from the project, identified as:
|
| 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:
|
| High Level Milestone plan | A high level plan showing the key milestones, their dates and interdependencies. |
Finances
Budget categories are:
|
A description of the:
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:
|
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 ScopeXTimeXCostX
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?
