PLANNING A PROJECT

5.1 Introduction

This chapter is intended to give some guidance on defining and planning a project; about deciding whether or not to set up a computerised database; and if the answer is yes, what steps to consider during implementation. It needs to be remembered that a computerised database is a tool to serve some specific objectives. Hence the project objectives are the key issue: the more carefully these are evaluated and defined the more successful the project is likely to be.

5.2 Is a computerised database needed?

At the beginning of a project a number of steps can be considered, as presented in a flow diagram (Figure 5.1).

(Figure 5.1 about here)

The first step in any research project is the initial identification of some problem to be investigated or a particular subject to be explored. At this stage the problem or subject is likely to be defined in rather vague terms and it is only after some information has been collected and analysed that a more exact definition of the aims of the project can be made.

The second step might therefore be to begin a literature survey, to consult with relevant people and organisations and to collect some preliminary information.

For instance, a need might be perceived to conduct a research project in a particular region, in order to discover which plants are used for medicinal purposes and which of these are at risk through over-exploitation. A first step here might be to compile from the literature a list of known medicinal plants, and to interview a variety of people involved in both the herbal medicine trade and in plant conservation. Visits might then be made to rural markets, urban herbal shops and to sites where gatherers collect plant material. From these observations it would then be possible to arrive at a more accurate assessment of the project, and a decision could be made as to which data to collect and analyse. The next logical step is a pilot project, as this provides a means of testing how well these ideas work out in practice.

A pilot project is usually of short duration and is carried out as cheaply as possible. A computerised database might be used at this stage, but in many situations it would not be necessary. It is much more important to test the data collection methods. For example, a survey might be conducted on a small number of herbal shops in order to find out if it is possible to measure the quantities of specific plant materials which are sold. Similarly, other surveys might be carried out in forest with local people in order to collect information on the names and uses of plants, or on the damage caused to trees when gatherers collect herbal products.

The data from the pilot project should then be analysed, and the results discussed with relevant people. As regards analysis, it is best to start with simple methods and to proceed to more complex methods only if required. Simple methods include use of tables, plotting one variable against another on a graph, and drawing up bar charts and histograms. Some statistical analysis may be carried out at this stage (see for example Watt, 1993); if in doubt it may be wise to consult a statistician, especially if more complex methods of analysis seem to be needed (for example for multivariate studies).

If the pilot project is carried out well then the next stage will be much easier, namely defining the detailed objectives and data collection methods of the main project. In many situations it will only be at this stage that a decision can be made whether or not to use a computerised database. Several questions have to be considered, for instance:

* Does the anticipated volume of data warrant the use of a database?

* Is a database essential for certain types of analysis and presentation?

* Can a database be afforded and maintained -- both in terms of equipment and the labour costs of data input?

* Is there sufficient time to learn how to use the software?

* Is the project likely to grow larger?

If the answer is no to most of these questions then it may be better to employ other data storage methods such as file cards or, if a computer is available, perhaps a spreadsheet. But if the answer is yes then the next stage is to design and test a database.

5.3 Designing and testing a database

Some of the steps in planning and testing a database can be shown in another flow diagram (Figure 5.2).

(Figure 5.2 about here)

The first essential step is to define your data needs as exactly as possible. Two important questions need to be considered, namely:

(a) What kind of results are expected from the database?

(b) Given this requirement, exactly which data items are needed?

These questions will be easier to answer if a good pilot study has been carried out, but in any case it is important to be as clear as possible about these two points. There is no point, for example, in including superfluous data just because they happen to be available; if at a later stage particular data items are needed then extra fields can always be added to the database.

Data standards also need to be considered and incorporated at this point. Even if you do not need them at first, it may be wise to follow standards in case you want to exchange data at some future date.

You are now at the stage when conceptual models of the database can be made. This is basically a paper and pencil exercise and can precede the acquisition of software and hardware. Data need to be atomised, assigned to fields, and organised into a table -- or tables if a relational database is required. The relationships of the data elements (i.e. fields) need to be carefully considered, taking into account any hierarchies that may be present (e.g. the taxonomic arrangement of plant names).

If a relational database is planned it will often be helpful to think in terms of a main table supported by associated tables (see Figure 5.3). Linking or common fields also need to be identified.

(Figure 5.3 about here)

If possible it would be advisable to discuss your conceptual models with someone experienced in this topic. They may be able to suggest improvements and also advise you about suitable software. It is important that the model chosen is as simple as possible in order to avoid undue complication at the detailed design stage. According to Synge and Heywood (1991) over-complexity is the main reason why some databases become white elephants or, at best, reach a stage of arrested development.

Having worked out a conceptual model you are in a good position to select the right kind of software (and matching hardware). As discussed in Chapter 3, the basic choice is between a general-purpose package and a dedicated package. If you chose a dedicated package then much of the detailed design will have been worked out for you. However, if a general-purpose package is chosen then this detailed design has to be carried out. Depending on the type of software, it would probably be advisable to seek help at this point, especially if you need to build a relational database. Modern general-purpose database packages are very flexible and versatile but are also complex owing to the number of options available. For this reason it can take several months to learn the features of a package, and several years to become really expert in using it. Therefore unless you have the time (or inclination) to learn how to use the software properly it would be better to get an experienced person to help set up the database for you, based on your conceptual model. Once the database is set up you can begin to use it and gradually learn just the operations that apply to your needs. Modern databases can also be "customised" for a specific use and unnecessary options can be removed from the screen.

For many projects data entry forms will be needed and these should be drafted during the design stage (see examples in Chapter 6). As regards keying-in data, it will probably be convenient if the data entry form matches the form (or template) on the computer screen, and forms can in fact be printed from the screen display. Of course, if data are entered directly into the computer, data entry forms will not be needed, although they are very useful to have in case the computerised data are lost or damaged (see below).

Having set up the database on the computer it is then essential to test it once a small set of records has been entered. All the normal operations should be tried -- editing, sorting, selecting, deleting, joining, printing etc. -- and if any problems appear then some of the previous stages may have to be reviewed and altered (as indicated in Figure 5.2).

Even when the database is established, it should be evaluated regularly. For example, ask yourself the following types of questions:

* Is the database providing the right kind of data for the project?

* Is the presentation of results to other parties satisfactory?

* Should certain fields be deleted or changed?

* Are new fields and new features required?

Changes may well have to be made as a result of such questions, but a step-by-step approach of this kind is more likely to give good results than sticking rigidly to a fixed

set of fields, files and outputs.

5.4 Data protection

It is essential to plan the protection of your computerised data. Apart from CDs (Compact Disks), all computerised data are stored on magnetic media -- hard disks, diskettes and tape streamers. None of these magnetic media (with the exception of Magneto-Optical disks) can be relied upon to store data for long periods of time -- and even a very small change on a magnetic surface can make the data unreadable on the computer. In addition, hard disks -- although generally reliable -- can fail for mechanical reasons.

With these points in mind, it is important to protect your data as follows:

(a) Save your work regularly when working at the computer. This means transferring the information onto the hard disk. Some software includes an auto-save feature that will do this for you.

(b) Make regular copies (or backups) of both data files and software on diskettes; then store the diskettes in a safe place (see Box 5.1 ). CDs offer a more reliable form of backup; the equipment needed to copy files onto CDs will probably become less expensive over the next few years and become more generally available.

(c) Keep the original data entry forms (or if these are not used, printouts of data files) and also store them in a safe place.

If you follow these points, then if a disaster does occur -- such as hard disk failure or theft of your computer -- at least you will have copies of all your data and software stowed away. And if for some reason all your diskettes or tapes are damaged, then the data forms and printouts will provide a final backup.

---------------------------

Box 5.1 Saving your work and software on diskettes

Important points to note:

(a) Keep the diskettes in a cool place, out of sunlight and away from magnetic objects and dust.

(b) Don't store all the diskettes in one place; keep one set in a different room - or better, in a different building.

(c) Buy good quality diskettes and remember to budget for these. It is more cost-effective to buy diskettes in bulk from a specialist dealer.

(d) Label the diskettes clearly.

(e) Use the "write-protect tab" on the diskette to prevent accidental overwriting of files.

-----------------(end of Box 5.1)