Terms of Reference (ToR) Template: Free Word Download + Writing Guide

A Terms of Reference (ToR) template gives you a ready-made structure for the document that spells out a project’s background, purpose, and objectives. It includes a range of criteria necessary for strategic project management decision-making, and it defines the activities, risks, budget, and expertise related to the project.

This guide covers what a Terms of Reference document is, what belongs in each section, and how to use it. It also includes a free, ready-to-fill Word template, a short interactive quiz, and a downloadable practice exercise. No email required.

Note: committees and boards also use the term “terms of reference” for their own governing mandate. This guide covers ToR as it applies to a specific project.

Terms of Reference: Definition and Purpose

In project management, the Terms of Reference is a strategy-level document that describes the expected deliverables, who is responsible for each deliverable, and the timeline in which they should be completed. The ToR states the planned activities, typical inputs and outputs, project budget, working schedules, and job descriptions. It is used to evaluate the performance of the project team, contractors, consultants, experts, and other project stakeholders.

The purpose of the ToR is to specify the amount and type of work to accomplish the project. In addition, it is a governance document that establishes and determines the relationships between all project stakeholders. The Terms of Reference document is developed once a project has been identified, defined, and planned.

The ToR of a project provides a clear description of the following critical information:

• The rationale behind undertaking the project.
• The proposed methodology of project management, along with work plans and activity schedules.
• The expected resource requirements, primarily regarding personnel.
• Reporting rules and requirements.

What’s Included in the ToR?

The development of Project Terms of Reference is required for making the decision on whether or not to allocate necessary funds to a proposed project. It is the result of the project proposal process, and TOR serves as the primary report of this process.

TOR is usually required for:

• Pre-feasibility and feasibility analyses
• Appraisal activity
• Implementation contracts designing and monitoring
• Evaluation studies
• Reporting and audit
• Other advisory work required at any project stage

Considering the listed items, the content of Project Terms of Reference should include business-critical information necessary for starting, implementing and monitoring project activities. Meanwhile, the exact content of TOR varies from project to project and significantly depends upon the scope of a proposed project.

A generic content format of Project Terms of Reference is suggested below, 7 components:

1. Project Background
2. Project Objectives
3. Issues to be explored and analyzed against certain criteria
4. Implementation Methodology to be applied
5. Expertise required
6. Reporting requirements
7. Work plan, including activity schedules

Please note these are the common sections of a TOR template. They can be changed or omitted, depending on the scope of a particular project. The following description of the TOR sections is general and provided as an overview for guidance purposes. A particular project will require a deeper analysis of the content to be included in a TOR template. When you plan for your project, you must first analyze and define the work that needs to be contracted out, and then proceed with the development of Project Terms of Reference.

1. Background

The background of a project provides an overview of the history behind the project. It should clearly state why perform the project and refer to a programming context. The purpose is to provide the reader with a brief explanation of the need behind the project.

The Background section of a ToR template usually includes several paragraphs which address the following issues:

• Describe the project in the context of a related business need
• State the general role of stakeholders in doing project activities
• Highlight a brief overview of the project to date

2. Objectives

The objectives of a project are those desired accomplishments that can be reasonably delivered upon project completion, with consumption of available resources and within an expected timeframe. They should clearly identify and define what is expected from the project and who the target audience is.

The Objectives section of a Terms of Reference template should describe desired achievements at different stages of project lifecycle. It should also state the primary objectives of the project, which must be achieved upon successful project completion. Here’s an example of how it should look:

Work Type / Project Stage	Generic Objective
Project Completion	To increase sales of product “A” by 15% over a 3-month period
Feasibility study	To provide decision makers with sufficient information necessary for acceptance or rejection of the proposed project
Monitoring	To provide decision makers with sufficient information necessary to make informed judgment regarding the performance of the project
Audit	To ensure the project remains relevant and reasonable in legal, economical and technical terms

Want to see these objectives in a complete, filled-in document? Skip ahead to the worked example below: it shows a full sample ToR for a real-style project, from background through work plan.

3. Issues

Any project involves a number of issues and problematic areas that must be addressed in order for the project to be implemented smoothly. The issues are the points of discussion or dispute throughout the project lifecycle. They cover any concern, query, request for change, or anything else that requires a resolution during the project. Unresolved issues may cause project failure.

The Issues section of a TOR template should highlight key issues to be tracked and resolved at every stage of the project lifecycle. Most teams triage issues against a short set of criteria:

• Impact: how much the issue affects schedule, budget, quality, or scope if it isn’t resolved
• Urgency: how soon a decision is needed before the issue blocks other work
• Ownership: who is responsible for investigating and resolving it
• Status: open, in progress, resolved, or escalated to the sponsor

4. Methodology

The implementation methodology of a project provides a set of broad principles and rules from which specific procedures will be derived in order to define how to carry out the project in a cost-effective way. It describes the main methods of project implementation.

The Methodology section of a Project Terms of Reference template should therefore include a description of the following items:

• Key phases of the project implementation process
• The required level of stakeholder involvement that ensures smooth implementation
• The content and duration of project activities and tasks
• The information collection tools to be used throughout the project for monitoring purposes
• Data analysis rules

5. Expertise

The expertise needed for doing a project defines a set of professional requirements for the individuals and teams involved in project implementation. It will be the basis for team building, including training and skill assessment.

The Expertise section of a Project Terms of Reference template should identify the following:

• The type of work involved in the project
• The type of skills and abilities required to do project work
• The exact number of individuals involved, including a description of their qualifications, experience, and other professional attributes
• The period of engagement of each team member
• A description of the duties and responsibility per teammate
• The relationship between the team members, including leadership roles

6. Reporting

Reports provide valued information about project performance over a certain period. Reporting is a process that starts once a project is launched and continues until the project is completed and its product is handed over. Reporting requirements will define how to write and submit project reports and what information to include.

The Reporting Requirements section of a Terms of Reference template should clearly specify the requirements for the reporting process, and might include the details of:

• Table of contents for project reports
• Rules for composing annexes
• Report templates
• The language to be used in reports
• Computer software programmes to be used
• Submission dates
• People responsible for reporting and approving
• Other sufficient information, such as number of copies to be created, responsibilities for report production and presentation, etc.

7. Work Plan

A work plan is a kind of strategy that aims to help solve problems throughout a project and boost employee drive and focus. It determines what actions need to be taken to start, implement, and complete the project within a specified time period and under defined budget. It is often used as a general guide for developing a project implementation plan.

The Work Plan section of a Project Terms of Reference template should set out the activities and necessary resources required for achieving the project’s results and purpose. It should therefore include a summary of the anticipated work and time schedule, which are based upon the following:

• An analysis of the issues, in terms of the evaluation criteria
• The proposed implementation methodology
• The reporting requirements
• The finance resources allocated to the project

Want an ongoing, updatable version of the Work Plan and Issue Log to keep using after the ToR is signed off? Grab the companion Work Plan & Issue Log Tracker (Excel) too.

How a Terms of Reference Gets Created

The sections above describe what a ToR contains. In practice, it’s rarely written in one sitting by one person. It moves through a short, fairly predictable process:

Step	Stage	What happens	Typically involves
1	Scope identified	A specific piece of work (a consultancy engagement, a feasibility study, a contracted deliverable) is identified within an already-authorized project.	Sponsor, PM
2	Draft	A first version is written covering background, objectives, methodology, expertise, reporting and work plan, the sections above.	PM or the person commissioning the work
3	Stakeholder review	The draft goes to whoever will rely on it: the contracted party, plus anyone accountable for the outcome, for comments and questions.	PM, contracted party, key stakeholders
4	Revise	The draft is updated based on feedback. Scope, budget, or timeline assumptions often shift at this point.	PM
5	Sign-off	The ToR is formally approved, usually alongside or right after contract/engagement paperwork.	Sponsor or approving authority
6	In use	The signed ToR becomes the reference document for evaluating the work for as long as the engagement runs.	Everyone involved in the engagement

What counts as “smaller” here is really about team size and budget, not calendar time. A one- or two-person engagement with an informally approved budget can usually compress steps 2-4 into a single conversation. Once the work involves a dedicated budget line, an external contract, or several people across different teams, skipping a real review round is the most common reason a ToR needs rework after sign-off.

Sample Terms of Reference (Filled-In Example)

To show how the sections above come together, here’s a simplified example ToR for a mid-sized internal project: launching a customer feedback portal.

Background: the company currently collects customer feedback through scattered email threads and support tickets, with no central way to track sentiment or trends. The Customer Success and Product teams have jointly requested a self-service portal where customers can submit, rate, and track feedback, feeding directly into the product roadmap.

Objectives:

• Launch a working feedback portal within one fiscal quarter.
• Reduce average feedback-response time from 5 business days to 1.
• Give Product and Customer Success shared visibility into feedback trends via a shared dashboard.

Scope & methodology: the project follows an agile approach, delivered in two-week sprints, with a soft internal launch to the Customer Success team in week 6 and a full customer-facing launch in week 12.

Expertise required: 1 project manager, 2 backend developers, 1 frontend developer, 1 UX designer (part-time), 1 QA engineer.

Reporting: weekly sprint status reports to the Product Director; a go/no-go readiness review before the week-12 launch.

Work plan (high level):

Phase	Weeks	Key deliverable
Discovery & design	1-2	Approved UX wireframes
Build	3-8	Working portal (internal)
Internal pilot	9-10	Feedback from Customer Success team
Hardening & launch prep	11-12	Public launch

This is simplified on purpose: a real ToR for a project this size would go into more depth on risk, budget, and reporting format, following the same structure covered above. It’s also a composite illustration, not a real client engagement. Actual ToRs are confidential business documents, so a guide like this one has to build a representative example rather than publish one.

Real-World Examples: What Happens Without a Frozen Scope

The example above shows the format. These two show the stakes: both are real, extensively documented project failures, and both trace back to the same root cause. nobody ever locked down a written scope that the whole team was held to.

FBI Virtual Case File (2000-2005)

The FBI’s case-management system replacement never had a frozen scope. The specification document ballooned to over 800 pages and, according to a security engineer on the project, described implementation details (“there will be a page with a button that says e-mail on it”) rather than requirements. Between December 2002 and December 2003 alone, the contractor logged roughly 400 change requests. Agents would see working code and ask for changes on the spot; one official called it a “death spiral.” The FBI scrapped the project in April 2005 after spending $170 million, discarding $105 million worth of already-written code.

Source: IEEE Spectrum, “Who Killed the Virtual Case File?” (spectrum.ieee.org/who-killed-the-virtual-case-file)

Denver International Airport Baggage Handling System (1992-1995)

Denver committed to building “the world’s largest and most efficient” automated baggage system on an aggressive schedule, with the underlying plan and strategy continuing to shift after that commitment was already made public. The system’s failure to work as promised held up the opening of an otherwise-finished airport by 16 months and added over $1 billion in combined delay and rework costs. Large sections of it were eventually torn out in favor of ordinary trolley carts and manual handling.

Source: Calleam Consulting, “Denver Airport: Baggage Handling System, Why Do Projects Fail?” (calleam.com/WTPF/?page_id=2086)

Neither project failed for lack of a ToR specifically. A Scope Statement, a frozen requirements baseline, or a well-run ToR would all address the same gap. The point that carries over to this article: the sections above (Objectives, Methodology, Work Plan) aren’t paperwork for its own sake. They’re what a written, signed-off scope looks like, and both of these cases show what tends to happen without one.

Practice: Test Yourself

Quick knowledge check

10 questions based on this guide: definitions, the ToR vs. Charter vs. Scope Statement distinction, when to use one, and a question on the FBI case above. Multiple choice, instant feedback per question, retakeable, ends with a link to the free template.

Write your own ToR

A separate downloadable exercise: a realistic scenario (an external agency engagement, different from both the Sample ToR walkthrough above and the template’s own filled example, so nothing here just repeats content already on the page), guiding questions under each of the 7 sections, then a model answer on the following page for self-check after you’ve had a go.

When (and When Not) to Use a Terms of Reference

A ToR is worth writing when:

• You’re engaging an external consultant, contractor, or vendor for a defined piece of work inside a larger project: the ToR spells out exactly what they’re delivering and how their work will be judged.
• A specific workstream or deliverable needs its own scope definition, separate from the overall project (a feasibility study, an audit, an evaluation).
• A formal procurement or tendering process requires documented evaluation criteria.
• Several stakeholders need a shared written reference for what a piece of work covers, so expectations don’t drift over time.

It’s usually overkill, or the wrong tool, when:

• The work is small enough that a one-page task brief, or a few lines in the project plan, covers it just as well. A full ToR for a two-day task is paperwork, not clarity.
• The project already has a complete Project Charter and Scope Statement covering the same ground: a second document repeating that structure doesn’t add information.
• The work is still exploratory and the team doesn’t yet know what “done” looks like. A ToR needs a defined scope to write against; that definition has to come first.
• What’s actually needed is a governing mandate for a committee or board, not a scope of work for a deliverable, which is a different use of the term (see the note near the top of this guide).

ToR vs. Project Charter vs. Scope Statement

All three get written early in a project and all define scope at some level, which is exactly why they get confused. The difference is what each one actually authorizes or answers:

Document	Answers	Who writes / approves it	When it’s created
Project Charter	Should this project happen, and who’s in charge?	Sponsor approves; names the PM	Project start, before detailed planning
Scope Statement	What’s in and out of scope for the whole project?	PM drafts; sponsor approves	Early planning, right after the charter
Terms of Reference	Exactly what does this specific piece of work involve, and how will it be judged?	PM or work owner drafts; sponsor/approver signs off	Whenever a specific deliverable or engagement is defined, at any point in the project

The charter clears the whole project to exist, the scope statement draws its outer boundary, and the ToR fills in the detail for one specific piece of work inside that boundary. Most projects that use a charter end up writing a ToR too.

Which term you’ll encounter often comes down to the methodology tradition your organization follows, more than the type of work itself:

• Terms of Reference is the standard vocabulary in government and public-sector contracting, international development and donor-funded work (World Bank, EU, UN, and similar procurement processes), and professional consulting engagements: anywhere a specific piece of work needs a documented scope for an external party or contractor.
• Project Charter is the standard vocabulary in PMI/PMBOK-aligned organizations, more common in US corporate, IT, and product-development environments. PMBOK defines the charter as its project-authorization artifact and doesn’t use the term “Terms of Reference” at all.
• PRINCE2 (common in UK, EU, and Commonwealth organizations) sits in between: it authorizes a project with a “Project Brief,” not a charter, but it does use “Terms of Reference” for specific board, assurance, or work-package mandates.

None of this is a hard rule, plenty of organizations mix terminology regardless of methodology, but it explains why you’ll see both terms depending on where you’ve worked.

Frequently Asked Questions