Tuesday, August 19, 2008

Project Terms of Reference

Tom: I hear that you started working on a new project Dan. How is it coming along?

Dan: It's still at a very early stage and I'm just really getting it off the ground. I've been putting some documentation together following the standards and guidelines that we use in this organization. I really seem to be creating a lot of documents. Are they all really necessary?

Tom: The documents that I would suggest are really quite minimal. Most project methodologies use many more documents than I would recommend and require you to rewrite or reinvent a lot of your work. With the framework we we use in this organization we evolve each of the documents so you never lose anything or have to rewrite anything. Remember, a document is simply a way of gathering together what people are thinking and saying. Without a place to record this our projects would be full of misunderstandings, ambiguities and errors.

Dan: In that case what document should I focus on at the beginning of a project?

Tom: Well after the initial Idea Sheet you should be starting to compile a Project Terms of Reference document. It is called many different names but what it does is provide a place for you to gather together all the initial thoughts about a project. Remember it will evolve.

Here are some notes on the Project Terms of Reference and what to include in it:


The Project Terms of Reference

The purpose of the document is to allow an informed decision on whether or not to start a project. If the project is not worthwhile, it stops immediately and the organization saves the time, money, and effort of starting a project, only to find later on that it is not viable. If the project is worthwhile the document acts as a baseline which is key to effective change management throughout the project. The project’s Sponsor or Project Board agree to more detailed project work by signing off this document. Key sections of the document include:

Background
  • The business reasons for doing the project. May identify problems or difficulties, their effect on the organization, and the reason for doing something about them (or the impact of doing nothing).
  • A statement of the current situation and key historical events, describing the context within which the project is to be done.
  • References to pertinent people, places and events
  • Cross-references to other work being done
  • Cross-references to the business mission, vision and strategic objectives

Objectives
  • A statement of what is expected to be achieved during the project.
  • Multiple objectives should be listed separately in order of priority.
  • The objectives should be: concise, unambiguous, relevant, measurable and realistic

Scope
  • A specification of the boundaries within which the work is to be undertaken
  • What processes, functions and operations the project will cover
  • What areas the project will NOT cover
  • What business areas, jobs and geographical locations will be affected

Constraints
  • To describe any restrictions which could well influence the way in which the project is undertaken.
  • Examples of constraints that may apply are:
  • Timescales: When the assignment should be started and completed. Any critical dates, such as start of financial periods. Target dates for presentation and review of draft report.
  • Budget: In man-days and cost.
  • Resources: Availability of staff undertaking the project.
  • Methods: Refers to standards or procedures that have to be followed
  • Tools: May refer to tools which have to be used to implement or manage the project
Assumptions
  • A list of all assumptions.
Roles and Responsibilities
  • Project organizational structure
  • Key roles and responsibilities (e.g. Sponsor, Project Manager)
  • Use the VICARS Matrix

Key Deliverables
  • This section describes the outputs from the project. These would normally be the physical outputs but could include 'changed state’ outputs (i.e. trained employees). Examples include: Project Terms of Reference, Microsoft Project Plan, Risk Register, Product Specifications, Organizational Structure and Job Descriptions.
I hope you find this useful Dan. Let me know if I can help with anything else.

For more information about this and other management topics please click here.

1 comment:

Anonymous said...

Dude that project like totally ROCKS!

RD
www.decrypt.net.tc