Project Definition for [ PROJECT NAME]

[Project Name]

Definition Document

Document Overview
Prepared By: / Author’s Name
Prepared For: / Department Name
Date Created: / Month, Day, Year
Last Updated: / Month, Day, Year
Revision Log
Revision / Date / Initials / Description of Revision
1.0 / MM/DD/YYYY / Initial Draft

DOCUMENT EXPLANATION

The purpose of the Project Definition document is to identify the boundaries of a project. It provides a framework for the project team to start, manage and end the project successfully.

Gaining agreement on answers to the following question is a strong foundation.

•who is the customer?

what, exactly, does that customer want?

•who will be working on the project?

•how much time will it take?

•what technology is involved?

•how much will it cost?

•who pays for it?

Sponsor: / The Sponsor(s) has the ultimate authority, accountability, and responsibility for the project. The Sponsor is normally a part of the leadership team (Director level or higher), who is responsible for the major operational area affected by the project. S/he is involved in project definition, particularly specifying deliverables and benefits/results from the project.
Customer(s) / Internal and External: / Generally, the customer is the end user(s) of the product or service created by the project. However, sometimes the customer(s) can be difficult to determine precisely. In such cases, the project manager must ask the following questions to narrow the candidates: who has final authority over the project's requirements, i.e., who establishes the final acceptance criteria? who asked for the project's end product or service? whose money is building it?
Stakeholders / Internal and External: / Persons and organizations such as customers, sponsors, and the public, that are actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project. They may also exert influence over the project and its deliverables
Business need or project trigger / What is the issue / problem that this project will solve? Be succinct and specific, thinking about the statement in terms of “the problem is X,” and this project will produce Y” to fix that problem.
Strategic or Operational? / Describe whether / how the project falls within an ITS Strategic Initiative or is required for ongoing Ops / Maintenance work.
Description and goals / Scope: / High-level description of the project approach and goals. (Will the implementation be staged in phases? or is it a single cutover approach? etc.)
Decision to make or buy: / Explain (succinctly) why we are either building or buying the solution(s)
Funding: / Who is paying for this project? what is the estimated budget?
Schedule estimate: / High-level statement of milestones, with seasonal / academic calendar notations as necessary.
Quality objectives / Success Criteria: / Specific quality improvements over the current situation, or issues we must be careful not to create. Examples:
  • Customers should be able to manage their own sites without causing performance issues for other users.
  • Functionality should improve
  • The service should have fewer single points of failure.

Other objectives
Assumptions / Critical Success Factors: / Provide specific descriptions of the assumptions being made for this project. Examples:
  • funding is available
  • resources are available
  • our infrastructure can support the new app
  • our building can support the new hardware
  • we can cutover in X month
  • etc.

Out of Scope / What is not included in this projects - functionality, services, customer base, etc.
Constraints / What is limiting the scope of this project? why can’t you do something?
Cconstraints are usually funding, time (pre-determined deadlines, academic calendar restrictions, etc.), resource availability and/or skillsets (your own or other groups’), available technology release schedules, etc.
Dependencies / Integrations: / What other projects (active or pending), technology / systems, etc are interrelated / affected by this project?
Risks/Trade-offs
- / This is a high-level statement of the risks. Risks most often are an extension of Assumptions, Constraints and Dependencies, with a probability factor added.
Risks can be weighted by the likelihood of happening and the downside impact if they do happen.
Resources / Key IT departments to check with regarding human and technical resources, administrative and other support requiremens:
  • Technical Architecture Group (TAC)
  • Data Center Services
  • Communications Infrastructure
  • Network Engineering
  • VOIP Services
  • Security, Firewalls, VPN
  • Help Desk
  • Desktop Support
  • Training
  • ITS Communications

PROJECT DEFINITION SIGN-OFF PAGE

PHASE: DISCOVERY

This Project Definition document [ Version x.x] has been reviewed and found to be consistent with the specifications and/or documented project requirements. The signature(s) below confirm acceptance of this document and/or work product by the signing authority /ies.

Organization: University of Chicago______Contractor______
Approved by:
Name:: ______
Signature:______
Title: / Dept:
Date:
Organization: University of Chicago______Contractor______
Approved by:
Name:: ______
Signature:______
Title: / Dept:
Date:

This document is a copy, effective only on the downloadeddate. The official,updated template always resides on the PM101 site.

Document: PM101-Project Definition Page 1 of 5

Last saved: 10/15/18