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 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.