features from fastrak consulting

click here for the features menu

Managing the TBT projectpixel.gif (807 bytes)

pixel.gif (807 bytes) Getting off to the right start
pixel.gif (807 bytes)
A HIGH PROPORTION of the problems experienced with TBT projects are caused by rushing, or avoiding altogether, the project definition stage. Without a clear understanding of exactly what the client wants and what you’re prepared to deliver, there’s far too much room for disagreement later. You know how clients always seem so nice at the start of a project? In the rosy glow of optimism, it hardly seems necessary to pin down the details, to dot the i’s and cross the t’s - after all, there’s plenty of time to work that out as you go along. For now, a statement of general intent will do. Oh no it won’t.

The project definition makes it absolutely clear what the project is setting out to achieve. And as the saying goes, if you don’t know where you’re going … you’ll end up somewhere else. Here’s what you need to sort out at this stage:

Problem or need
A concise statement of why the project is required at the current time.

Objectives
These describe what has to be achieved if the project is to satisfy the underlying need or solve the underlying problem. To be of use, objectives need to be specific, achievable and measurable.

Scope
Scope defines the magnitude of the project in terms of variables such as content, audiences, geographic regions and learning objectives.

Constraints
Most projects operate under some constraints, which limit your flexibility to some extent. These might include budget limits, critical delivery dates, maximum training times, established style guides, delivery platforms, limitations on recruiting and so on.

Deliverables
Deliverables are the outputs of the project, not only in terms of the end product, but also what is to be delivered at each key milestone (prototypes, documents, etc.). Be careful to avoid subjective statements of quality for deliverables - quality guidelines need to be specific and measurable. And remember that quality does not necessarily mean high production values - what is important is that the end product is ‘fit for purpose’.

The project definition is the result of a negotiation between customer and supplier, one in which both sides win. It pays to remember that it is the client who is paying the bills and that, in return, they acquire a number of rights …

Customer’s bill of rights
I have the right
  • to set objectives for the project and have them followed
  • to know how long the project will take and how much it will cost
  • to decide which features are in and which features are out
  • to make reasonable changes to the requirements throughout the course of the project and to know the cost of making those changes
  • to know the project’s status clearly and confidently
  • to be appraised regularly of risks that could affect cost, schedule or quality and to be provided with options for addressing potential problems
  • to have ready access to project deliverables throughout the project

From the Software Project Survival Guide by Steve McConnell 1

footer2.gif (845 bytes)
                                                     Fastrak Consulting Ltd, 1999. All rights reserved.                                Last revised 21/2/99