How to write a terms of reference with template & examples
Why use a Terms of Reference document?
A Terms of Reference document is a really versatile document. I use it mainly for two things:
First, putting down in writing what my Steering Group are actually supposed to do to set the ‘ground rules’ for that group and their meetings. This helps them keep a focus on the job at hand, not get too much into the detail and helps them and others take the project seriously.
Second, to define what a particular workstream on a project is supposed to do.
I find a ToR is helpful when there’s a technical stream of work being led by someone, and then other strands being picked up by other people.
You could use the free terms of reference template (it’s a Word .docx that you can download from the template library) to define almost anything: the remit of your school parent teacher association, the terms for a client project.
Anything where you need to quickly summarize the high level deliverables, objectives, people, cost and time commitments without going into pages of detail that might not be relevant to them.
If you are starting to write one, and want some sample text for inclusion in your own, I’ve shared loads of tips and examples below.
What is a Terms of Reference document?
Just in case you need a refresher on what a ToR is, let’s make sure we’re on the same page.
A Terms of Reference is a short document that sets out the scope, boundaries, resources, objectives and constraints for a particular activity.
A ToR provides the context, purpose and structure for something. The ‘something’ could be a meeting, a committee, a project, an initiative or anything else.
Terms of reference vs charter: which one should you use?
A Charter tends to be longer, more formal and it serves a particular purpose in project management land which is to confer authority on the project manager.
A ToR has a much broader application as you can create them for committees, regular repeating meetings, the board, hiring groups, particular roles like risk champions and so on. It can be as formal as you like.
A ToR is almost a cut-down version of the Project Initiation Document or Project Charter, as it relates to a particular set of individuals and tasks. I like it because it helps them and me see what their particular role is and the responsibilities that fall within their remit.
What’s included in a Terms of Reference
What goes into a Terms of Reference document? I’m glad you asked.
Read on to see what I include.
General info
As with so many project documents, start with some general stuff. Put in the project’s name, title or ID code. Add today’s date. Put the version number so the versioning is clear.
That’s your meta data done. While we’re doing those kind of updates, be sure to also add the project name and the document file name into the footer. You can also add the version number there too if it makes sense to do so (and if the version number isn’t already in the file name).
I use the ‘Insert field’ option in Word to enter the file name, but if it comes out looking too long or weird I’ll abbreviate it to a name we’ll all understand.
Project introduction
Start the ToR document for your project with some brief introductory text about what the project is all about.
Summarize what this Terms of Reference covers. This is likely to be either the remit of a single group i.e. your Steering Group or a workstream of work. Explain what this involves.
For example:
This workstream covers the technical elements of the xxx project including software and hardware elements, technical design and testing.
Note down any principles that this Terms of Reference will operate within e.g. the Steering Group will work according to the principles of PRINCE2®.
Objectives and deliverables
State the objectives and deliverables of this particular workstream, project, group etc. Here are some sample project objectives that you can adapt for your ToR.
- Ensure that all deliverables are completed on time, within cost and to quality
- Ensure the work is adequately resourced against the overall project/resource plan
- Assess risks and ensure appropriate mitigating actions are in place
- Resolve all high level project issues, escalating for resolution to relevant management teams as appropriate
- Raise and analyze changes impacting the project including major milestones, scope of deliverables, costs and benefits
- Ensure compliance to corporate policies and protocols impacting the project
- Manage project dependencies
- Take responsibility for local project communications
- Make/input to critical Implementation go/no go decisions
- Formulate plans for the workstream including deliverables, development, testing, implementation, and communications.
You can see how the work is described to make it clear what the outcomes are expected to be, and we spell it out in really obvious terms.
You’ll also have some specific deliverable information in there too, relating to the outputs that the project team are creating.
Sounds like a lot to spell out? Yes. But successful project managers make sure that the team understands exactly what is expected of them and this is one way to achieve that.
Scope
Outline the scope of work.
For a committee this could be:
Our scope is to review pay and benefits on an annual basis and make a recommendation to the board.
For a project it could be a list of the key scope items included.
Some people get confused about terms of reference vs scope. Project scope is all about what you will do: the tasks or deliverables that will be completed by the team.
A ToR covers more than that. And it’s high level-ish. A scope document could be many pages, and include a full work breakdown structure for a project. In your ToR’s scope section you’re just going to put the big deliverables.
Key resources/roles and responsibilities
List the key names and what they are responsible for. This is easy to do in table format.
If you use a roles and responsibilities template, you can reference that one instead, to save you duplicating effort and writing it all out twice.
In this section, I would also add some information about how often the team is expected to meet.
For example:
Meetings of the team will take place monthly or less frequently as required. Deputies will only be allowed by agreement of the Chair. The standing agenda will include:
- Review of project progress, milestones, risks and issues
- Deliverables for approval or decisions to be made
- Spotlight on special items for discussion or escalation
- AOB
Workstream organization structure
The next section in your terms of reference should be an org chart. This helps people understand how this workstream/team/group etc fits into the overall project (or company).
It makes it clear how their actions feed into the bigger picture.
Approach
Add a paragraph or some bullets that explain the approach that is going to be followed for this. This is an explanation of how you are going to achieve the deliverables above.
For example:
We’re going to be following
Milestones
You don’t need to provide a complete project schedule, but it is helpful to include a table with the major milestones or a visual high-level project timeline.
List out the milestones and the dates they are expected to be completed.
No one is going to use this list as their main project plan, but it exists in the document as part of the expectation setting. It’s a discussion point for your agreement of the ToR, and the team’s opportunity to commit to realistic dates before you put too much effort into building a proper schedule.
Budget
If this work or group has a specific ring-fenced budget, then mention it so they know what they have to work with.
Include a statement like:
The indicative budget for this workstream/group is xxx. This covers xxx. The budget assumptions are included in the PID and the full figures are detailed in the project business case.
Other notes
Finally, add in anything else. Create new headings that are relevant to this particular project, or the ways of working that are appropriate for your organization.
Keep the document as short as possible (2 pages is great), but if you do need to add additional information for the team’s benefit, then do so.
For example, use this space to record any other information for your project closure, such as supplier contact information for ongoing contracts or the location of project’s archived files.
How often should the ToR be updated?
I add a note to the bottom of the ToR document to say when the next revision date is due.
You’d normally agree this with the individuals concerned, and you may have a document update schedule that you would need to abide by.
Most ToR wouldn’t get updated unless something changes in the responsibilities of the group.
You can do an annual review as a minimum to make sure that the ToR still reflects what you are doing and that it feels fit for purpose.
How to get the template
Access the Resource Library here to get the Terms of Reference template. You will get an email with the special link to access to my free Resource Library with all of my templates, checklists, and guides.
There you will able to download the Terms of Reference template. It’s a Microsoft Word document, and as always you’ll have to edit it to take out my notes and put in your text (and don’t forget to update the headers and footers too).
I don’t mind you using my free project management templates for your work purposes but please don’t sell them!
Pin for later reading:
