Skip to page content or Skip to Accesskey List.


Main Page Content

A Terms Of Reference Howto

Rated 3.96 (Ratings: 7)

Want more?

Picture of MartinB

Martin Burns

Member info

User since: 26 Apr 1999

Articles written: 143

If you're launching a project, say to develop a <tips>

database for a webdevelopers site, you'll need some way of

monitoring what you're doing, why you're doing it, who you're

doing for and who's doing what. Or, in Project Manager-speak,

  • Setting objectives

  • Defining the scope

  • Establishing the strategy

  • Deriving the work breakdown structure

The most important tool for defining and monitoring this is the Terms

of Reference (TOR). This is the Project Manager's contract with the

users and with the project sponsor. It's the first point where the

project is given size, shape and direction out of the haze of

hey, wouldn't it be cool to catalogue the <tips> from

to a place where you can actually start working. Some

organisations (particularly larger ones) will make it impossible for

you to get anything done without one - it can be an essential part of

the business case required to get staff time, cash and system resources

to get your project underway.

So what would you put in your TOR? It will vary, depending on your

project, but the typical sections you'd get in most TORs are:

  1. Authority and project sponsor

    This is as simple as who has asked that the project has been

    carried out. In a business setting, this would be whoever is

    providing the money to do the work.

  2. Customer

    Usually the final user of the product.

  3. Objectives

    It's important that the objectives you set for the project are

    in line with whatever your organisation's objectives are (or at

    least those of the project sponsor... don't you just

    love political games?). Your objectives should also


    • Specific

    • Measurable in terms of quality, quantity, time & cost.

    • Achievable

    • Readily understandable

    • Consistent

    • Few in number

    • Supported fully by senior management, project sponsor and

      users (the three constituencies of stakeholder).

    Of course, some of these are going to cause you problems. You

    will need to make tradeoffs between time, cost

    and quality (the usual dictum is pick two, but smarter

    compromises are usually better), working out which are the

    vital ones. In this industry, time to market is nearly always

    the key one, with cost coming in second. Guess what usually


  4. Scope

    This is the biggie. Get this wrong and you'll either end up

    with something which doesn't satisfy your stakeholders, solves

    the wrong problems, or misses the budget/launch date. Project

    Management is all about managing change, so a useful way to

    approach this is in terms of what/who you'll affect by the

    change. A possible outline scope for the

    <tips> project might be:

    A system to extract and publish <tips> from thelist.

    Content delivery will be to thesite, other XML-accepting sites

    and non-PC devices. Users will be able to search for

    <tips> and rate them on their usefulness.

    This is the start of a comprehensive requirements document,

    which could (and often should) be developed in tandem.

  5. Constraints

    Very similar to Scope except that it defines what's outside the

    remit, and what boundaries you may not cross. These may be the

    result of external forces which you can't control, such as the

    development platform you're running on.

  6. Costs/budget

    This section may be 100% guesstimate, but you would usually be

    working within a budget, so cut your cloth accordingly.

  7. Resources

    This may also be guesstimate, but you should have an outline

    idea of who you'll need, and what tools. You can then look at

    the gaps in who and what you already have, and start looking

    for sources to plug the gaps & changing your budget

    accordingly. For the <tips> project, we very clearly need

    database expertise, sysadmin expertise, WAP knowledge and HTML

    skill; we'll also need a database, a web application framework,

    a web server and a system to run it on. Fortunately, in our

    assembled team, we have (amongst others), Rudy, Dean, Dan, and

    Steve with access to the system's running on

    (ColdFusion & Oracle on Linux).

  8. Deliverables

    These should be explicitly defined using your requirements

    document, so the stakeholders have no doubt as to what's

    expected. "A tips database" is not enough; we will be

    delivering a database (or probably an extension to the existing

    one), publishing tools, management tools and documentation.

    There are likely to be additional interim deliverables -

    prototypes, designs, this TOR, requirements document, etc.

  9. Project phases and timescales

    Planning project phases and timescales lets you see the project

    in more understandable components. At the stage of the 1st

    iteration of the TOR, these may be as simple as

    • Initiation

    • Specification

    • Design

    • Build

    • Installation

    • Operation and review

    However, this will keep your mind, the minds of your team, and

    those of your stakeholders on the progress you're making,

    rather than the distant horizon of project completion.

    As far as dates are concerned, you'll probably only commit to a

    date for the next phase - the further away a phase is, the less

    knowledge you'll have of it, and it's a weather-forecasting job

    where Chaotic processes affect later events quite


  10. Strategy

    This is the high-level guidance for the project team, and is

    also useful for reassuring your stakeholders. You're likely to


    • Use of any particular techniques or methodologies

    • The adoption of any recognised standards

    • Relationships with other parts of the organisation


  11. Risks

    This is where you get to be worried about the impact of what

    you're doing. What are the potential major problems

    (particularly the target='_blank' title='Expect the unexpected'>unexpected

    )? What are the chances of them happening? What are

    their impact? What can be done to reduce their likelihood? What

    are the contingency plans? A risk we might consider for

    <tips> is what if CF for Linux doesn't get launched?

    You'll really want to think about your assumptions, as these

    are very clearly elements of risk.

  12. Roles and responsibilities

    Most projects will have natural roles for internal and external

    team members. However, the key thing to tie down is

    decision-making responsibility. Most evolt decisions are made

    by the team (with a loose email '+1' voting system), rather

    than a single individual. Your project may vary from this,

    however, and is sure to need some input from your stakeholders.

So there you are - that's the TOR in outline. Remember that this is

an iterative process - your TOR will be refined as you go through

the process as more information becomes available.

Martin Burns has been doing this stuff since Netscape 1.0 days. Starting with the communication ends that online media support, he moved back through design, HTML and server-side code. Then he got into running the whole show. These days he's working for these people as a Project Manager, and still thinks (nearly 6 years on) it's a hell of a lot better than working for a dot-com. In his Copious Free Time™, he helps out running a Cloth Nappies online store.

Amongst his favourite things is ZopeDrupal, which he uses to run his personal site. He's starting to (re)gain a sneaking regard for ECMAscript since the arrival of unobtrusive scripting.

He's been a member of since the very early days, a board member, a president, a writer and even contributed a modest amount of template code for the current site. Above all, he likes to do things because it knowingly chooses to do so, rather than randomly stumbling into them. He's also one of the boys and girls who beervolts in the UK, although the arrival of small children in his life have knocked the frequency for 6.

Most likely to ask: Why would a client pay you to do that?

Least likely to ask: Why isn't that navigation frame in Flash?

The access keys for this page are: ALT (Control on a Mac) plus: is an all-volunteer resource for web developers made up of a discussion list, a browser archive, and member-submitted articles. This article is the property of its author, please do not redistribute or use elsewhere without checking with the author.