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,

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:

    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

    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:

  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.