Article Overview
Terms of Reference or ToR is a formal document that is used to describe a project before a full project charter is produced, or it can be used for a worksteam. Read the article to find out more about ToR.
Table of Contents
- Background
- Objectives
- Scope
- Constraints
- Assumptions
- Roles and Responsibilities
- Deliverables
- Format
- Other Uses for a Terms of Reference
You may have heard of ToR, or Terms of Reference, and wondered how this fits into the project management process. After all, we have lots of documents already in project management, such as a project charter (or project initiation document) which seem as if they do a similar thing. For some projects, a ToR can be very useful and in this article, we will look at why. A ToR is a formal document, but it is typically not very long. It can be used to describe a project before a full project charter is produced, or it can be used for a workstream. In my experience, it is more typically used to set out the terms of reference for a particular workstream or sub-project and is written by the project manager with input from the functional lead who is managing that section of the work.
You could also produce one for a phase of the project, for example, the initial scoping phase. In short, a ToR can cover many things but generally sets out the scope of what needs to be done on a particular piece of work.
The ToR document includes:
The context for the work, the overall aims of the work and any references to other pieces of work that the team should take into account when commencing the work.
What is this piece of work going to achieve? What problem is it going to solve? These should be set out in a way that everyone can understand, avoiding jargon.
This section briefly covers what is in scope and out of the scope of the work. It is easiest to list this in bullet point format, as if more detail is required this can be produced in a full requirements document. Bullet points in this section should cover areas like:
- The technical systems involved or that are required
- The business processes that will be affected by this work
- What hardware and software is required (or specifically out of scope)
- Where the project will take place, what locations are affected and what locations will be out of scope for the purpose of this work
- What third parties will be involved
- Who will be affected, and which teams or individuals will specifically be out of scope.
You will probably think of other things to include in the scope. A good tip is to bring the team together (if you don't have a full team together at this point bring together some colleagues) and use a tool like iMindQ to mindmap some options for the scope. You could include a screenshot of your mindmap in the document if this is easier to do than listing the scope items as bullet points.
This short section documents any project constraints, such as timescales, the available budget, the resources available or any legislative or regulatory frameworks that have to be considered.
Include any assumptions in the ToR. These are the things that you don't yet know for certain but that will have an impact on the piece of work later on. If you are updating your ToR later you can update this section as you may well have been able to ratify your assumptions by then.
Who is on the team? In this section document the names and roles of the people who will be carrying out the work. You can also include their availability, such as if they are only available to work on the project two days a week.
Also, include details of who is sponsoring the work. If it is a full project, this will be the project sponsor. If it is a workstream or part of an existing project, the person to whom the workstream lead reports (probably you, the project manager) is the right person to mention here.
What is the work going to deliver? Make a list - it doesn't have to be too detailed at this point as all you really need is a high-level description of the outputs of the work. You could include a screenshot of the high-level milestones from your project plan here too.
Ideally, you should aim to get your ToR on a couple of pages. There is no need for a fancy cover page or appendices. Put a header and footer on the document and get started! You can always include version control information in a short table at the beginning or end.
You can also set out a ToR for meetings, so your Project Board or Steering Group may have a ToR that explains what they are there to do and how they will go about conducting the business of governance or oversight on the project. You could also have one for other types of meetings, such as terms of reference for risk management meetings. As long as the ToR clearly sets out the scope of activity and explains what is also out of scope, then it will do its job.
Do you use ToR for your projects? Let us know what else you include in them in the comments.