A Terms Of Reference Howto

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

thelist 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
   be:

   • 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
   suffers..?

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 evolt.org'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
   disproportionately.

10. Strategy
    
    
    This is the high-level guidance for the project team, and is
    also useful for reassuring your stakeholders. You're likely to
    include:

    • 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
    ones)? 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.