You are here: Home Blogs Tips for Writing Project Definitions
Tuesday, 20 October 2009 12:29

Tips for Writing Project Definitions

Written by 
Rate this item
(0 votes)

The following information will assist a Project Manager in completing a Project Definition. This information should be used to supplement the detailed information provided in the Project Definition template itself.


  • Make sure that you are working with the most current project definition template.
  • Make sure that you scale the Project Definition for the size of the project you are working on. For smaller projects, you may not need all the sections, or the information in the sections can be much briefer.
  • If a definition section does not appear to apply to your project, mark the section as ‘Not Applicable’, rather than deleting the entire section. This will show that the section was considered, and that it was not just ignored.
  • The overall flow of the Project Definition should tie together as follows. If this chain cannot be followed, more definition work is required to make it all tie together.
  1. Business goals are contributed to, or completely satisfied by project goals.
  2. Project goals are satisfied by the completion of project objectives.
  3. Project objectives are satisfied by the completion of one or more deliverables.
  4. Completion of project deliverables is accomplished by activities in the Project Workplan.

Approval Page

The Project Definition should be signed by the appropriate managers, sponsors, project manager and any applicable team members.


This section should describe the background that has lead to the project being undertaken. It should state the overall business goal that this project will help to achieve.

Executive Summary

Describes the Project Definition document. This is not a high-level overview of the project.

Goals and Objectives

  • Complete this section first. If you cannot clearly state the project goals and objectives, you are probably not ready to complete the rest of the definition
  • The completion of the project goals should directly contribute to the success of the overall business goals. Goals are stated at a higher level than objectives.
  • Objectives should contribute to the achievement of the project goals. All objectives should be completed within the scope of the project. If the project is successful, all project objectives should be completed successfully.
  • Objectives must be SMART - specific, measurable, assignable, realistic and timebound. Each objective should be satisfied by the completion of one or more deliverables.


Project Assumptions communicate the circumstances and factors used to develop the Project Definition and Workplan. Decisions are made based on the belief that these statements are correct and will occur.  (If a necessary condition is not likely to occur, it should be stated as a risk.)


  • All major deliverables should satisfy, or contribute to the satisfaction, of a project objective. Ask yourself “If all the deliverables were completed right now, would all the objectives have been satisfied?”
  • If you can only describe one major project deliverable, break it into several smaller deliverables which represent interim stages of the final deliverable.


  • Document the business processes, data requirements and/or system requirements that will be affected by the project.
  • Just as important as what is in-scope is to state what is out of scope. Documenting what is out of scope is important when trying to manage scope creep.

Project Approach

This is an important section. Review the directions for how to complete this section so that the overall approach is clearly communicated to the reader.


Project risks are characteristics, circumstances or features of the project environment that may have an adverse effect on the project or the quality of its deliverables. If a condition is required for the project to be successful, and you feel the condition is not likely to occur, it should be stated as a risk. A plan must be put into place to ensure that the conditions described as risks do not occur.

Project Management Procedures

Think about how these procedures will occur on your project. Do not just use any standard procedures set up for all projects.

Read 4531 times Last modified on Friday, 11 December 2009 02:03
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Parse error: syntax error, unexpected end of file in /home/spektmedia/public_html/wp-content/plugins/ccode.php on line 82

Who's Online

We have 586 guests and no members online

Got something to say?