The History Of The Feasibility Study

Published Date: 02 Nov 2017

The purpose of the feasibility study phase it to identify the main objectives and problems, how they may be solved and the cost and timescale involved. The end of this phase is usually marked by a decision on whether or not to proceed with the research project.

The objective is to allow a properly informed decision to be taken on whether to commit resources to a problem that appears to have a research solution. This is done by examining the feasibility, impact, and potential costs and benefits of the possible research as far as they can be ascertained at this early stage. In all but the most trivial projects, failure to do a feasibility study is a false economy; the work has to be done somewhere, and if omitted is likely to cause problems later on. It is well to note that typically, the cost of changes doubles with each successive research phase.

Within the established environment a number of optional solutions are defined, together with a cost/benefit analysis. One option has to be selected for further investigation. If it is decided to proceed, the Terms of Reference, scope and probable budget should be agreed, and the Project Manual established. The end product of the feasibility study is the Feasibility Report incorporating an environmental impact report and general theoretical considerations. An Abstract sheet summarizing the research should be prepared. These usually form part of a Research proposal.

The feasibility study is carried out by the researcher. The only commitment at the end of the feasibility study is to carry out the model design. Later studies as work progresses could result in the project being abandoned or extended in scope and budget.

The aim is to make students aware of:

� what a feasibility study is and why it is done,

� the skills that are necessary for conducting a feasibility study, and

� the steps that are followed in a feasibility study.

The objective is that the student will be able to:

� carry out a feasibility study, and

� produce a feasibility report.

4.2 Feasibility Study

The aim of the feasibility study is to define a research model whose behaviour is likely to answer the research question in the most effective way. It should:

� Define policy guidelines for future development of the research.

� Demonstrate the financial and technical viability of the proposed research.

There is no single solution to a set of user requirements. For each postulated solution, the factors enabling a decision on the relative merits must be defined in the best possible solution details. This involves:

� The identification of a limited number of possible solutions.

� The expansion of each solution to sufficient detail to enable effective evaluation of the selection to be made.

� Specification of the selected option in sufficient detail to permit the preliminary design phase of the model to begin.

In general, the more effort put into the feasibility study, the less effort is likely to be needed in the later phases. However, the decisions made in a feasibility study may be subject to change as more is discovered as the research is developed and so it is likely that a short feasibility study will be most effective, especially if there is a prospect that the research will be abandoned.

It is essential that the benefits to the user resulting from the research and the application of any recommendations must be identified prior to the research, and a cost benefit analysis should provide clear evidence that such research is worthwhile.

What is acceptable as an intangible or hidden benefit will vary a great deal from one organization to another. It will be governed by that most subjective � but important � of factors, ethos and management style. Researchers must handle the situation on the merits of their own environment � but it is clearly a good idea to consult users. Beware of crystal ball predictions that need to be justified!

4.2.2 Initiate feasibility study

The feasibility study is initiated by creating a feasibility study plan based on the Terms of Reference for the study which should indicate availability of people, time, money, and other resources. If the time allowed for the study is not specified, then the project complexity should be established so that an estimate of the time can be made for each activity.

Constraints, in terms of the availability of time, people, money and other resources, are of particular importance to enable the feasibility study to be conducted and determine the completion date. It is useful to use these to create a feasibility study plan, and the use of an elapsed time schedule will ensure that the study is kept on track. Each activity that needs to be performed in the study should be identified with an estimate of the available effort and resources required.

Quality assurance requirements for the feasibility study need to be identified. The involvement of the supervisor and user throughout the duration of the study should be discussed with each party to ensure that the feasibility study is looking at the right things, and that the product is of the highest standard. The product of the feasibility study is the Feasibility Report and the structure of this can be established.

The initial investigation of the research question established the Terms of Reference which indicated some of the problems likely to be encountered and the requirements of the research. It is a good idea at this stage to create a problems/requirements list that can be added to as the feasibility study progresses. This list will evolve and eventually become part of the specification for the research model.

The tasks to initiate a feasibility study activity include:

? Establish the feasibility study constraints.

Particularly the availability of time, people, money and other resources.

? Create a problem/requirements list

From initial investigation and terms of reference.

? Create a feasibility study plan

Use an elapsed time schedule.

? Estimate the effort required for each activity

? Allocate resources to each task

Proportion of available effort.

? Review the feasibility study plan

Get authorization to proceed.

? Establish feasibility study QA procedures

4.2.3 Overview current behaviour

The research problem does not exist in isolation, and there is a need to look at the problem environment to see whether any previous research has attempted to model the behaviour of the problem. Any shortcomings and limitations should be identified, along with the demands for enhancements or alternatives.

The definition of the problem helps to establish its interactions with its environment and the function of its behaviour. All external interfaces need to be identified, including any interaction that the user may have. Who is going to use the results of the research needs to be identified, and what effect it will have on them.

An understanding of the physical problem behaviour should be represented logically in terms of the processes that will be involved in modelling the behaviour, and the structure of data that the model will produce. This is an initial idea of what sort of model will be required, how it will function and what it will produce. The theoretical basis should also be determined if possible. The model can be regarde asd everything between the problem and the solution.

The tasks to overview the current behaviour activity include:

? Establish current environment.

? Identify user community.

? Determine function of current behaviour.

? Identify external interfaces.

? Identify user interfaces.

? Model logical data structure.

? Model logical processes.

Convert current physical view to logical view.

? Determine theoretical basis.

? Update problems/requirements lists.

Add any problems and requirements identified during investigation of the current behaviour.

4.1.3 Interview users

The key users of the research need to be identified and interviewed in order to create a good working relationship. It is important to establish and maintain these contacts with the users as they should be comfortable with what is going on, and feel that they can make a useful contribution to the research. The key users include representatives of whoever may be providing funding for the project, and any community that may be affected by the research.

The tasks involved in this activity include:

? Identify key users.

? Create interview plan.

? Arrange interviews.

4.1.4 Establish constraints

Constraints for the research project are often imposed in the Terms of Reference, and derived from the problems and requirements list. Where additional staff are required, this is likely to be dictated by the availability of staff freed from other projects. The timing often determines what can be done when, and needs to be established early in the planning. This important activity should not be underestimated as it will govern the whole research project development.

An arbitrary time-scale is often imposed by the need to complete the research by a particular date such as the end of the month, year, financial year, and so on. These should be viewed with suspicion, and all dates

and time periods reviewed before they become inevitable and no longer subject to change. This type of time-fixing cannot usually be justified, and is often fixed on the basis of a perceived amount of work being needed, and if more resources are available it will take less time. Be realistic with all times.

Similarly, cost constraints are often arbitrarily imposed and unrealistically linked to a time-scale. Realistic times and costs should be established, and maximum values stated. The need to use particular equipment and space (e.g. laboratory) at different times in the research should be identified, as the project will have to be defined around availability. Possible alternatives should be investigated.

Any conflicts with concurrent projects, resources, staff, space, and so on, should be identified and good communication established with the other parties. Management often imposes policy constraints in terms of the type of research that can be conducted, and the sensitivity of the project. The researcher should be aware of any moral and ethical constraints that are likely to impact on the research, particularly in areas of human and animal rights, defence, etc.

It is recommended that these constraints be reviewed with users and other affected parties to determine how �firm� they are. Any constraint that simply seemed �a good idea� and has no further justification should be revised.

The tasks involved in establishing constraints activity include:

? Establish human resources constraints.

? Establish time resources constraints.

If there is an arbitrary time-scale, it is desirable to review it and turn it into something more realistic before it becomes sacrosanct and inevitable. Imposed targets coinciding with a year-end should be viewed with especial suspicion. This is often dictated because of an imperfectly perceived �necessity� and lacks real justification on the grounds that X amount of work with Y people involved will take a mathematically determinable time.

? Establish money resources constraints.

The maximum cost of the research should be stated. Beware of the situation where the figure is linked to an imposed, unrealistic time-scale.

? Establish equipment resources constraints.

The need to use particular equipment at different times in the research should be identified, as the project will have to be defined around availability. Possible alternatives should be investigated.

? Establish facilities resources constraints.

? Availability of laboratory and other space should be identified.

? Establish project size constraints.

? Establish conflicting project constraints.

Concurrent projects may have a call on available resources.

? Establish communications constraints.

? Establish policy constraints.

? Establish moral end ethical constraints.

? Establish project sensitivity.

4.1.5 Consolidate problem/requirements list

A unified and consistent set of problems and requirements should be created from items that have been added during the study. Each entry should be reviewed to remove duplication, resolve any contention, combine similar entries and establish priorities.

Each entry should be an accurate statement of the problem or requirement, expressed in the form of clear single objectives. Where others are affected, the priority level should be discussed with other experienced users and researchers.

The tasks to consolidate the problems/requirements list activity include:

? Reconsider all entries on the problems/requirements list.

Identify duplication and contention, resolve any contention with the relevant users, and combine entries where appropriate.

? Review entries with users.

Each entry should be an accurate statement of the problem or requirement, expressed in the form of clear single objectives.

? Allocate a priority level to each entry.

Discussed with experienced users.

4.1.6 Review problem definition

At this stage in the feasibility study it is desirable to review the problem definition to ensure that it is an acceptable representation of the problem and that the continuation to the next step is justified.

A formal review meeting with interested parties is advisable to ensure that the feasibility study is still on course. Up to date documentation should be provided, and amended to incorporate suggested changes. Any outstanding contentious issues should be clarified with the boundaries properly established and agreed. A review of the feasibility study plan may require estimates to be amended if they are off course. It is often useful to get formal authorization to proceed with the study.

The tasks involved in the review activity include:

? Distribute copies of review documents.

? Hold review meeting

? Clarify contentious issues.

? Agree on boundaries.

? Amend documentation to incorporate changes.

? Review the feasibility study plan.

Amend plan if estimates are off course.

? Obtain authorization to proceed.

4.1.7 Define design objectives

Before the research model can be designed, the performance criteria which the model must achieve need to be identified. These will provide the performance targets against which the model can be measured. It is important to specify the data and timing requirement so that data can be safely stored and accessed when needed. Provision should be made for emergency situations such as fire, theft, earthquake, etc. by providing alternative storage facilities. Suitable archiving and recovery requirements need to be specified.

The tasks in this activity include:

? Specify data storage criteria.

? Specify function timing criteria.

Identify the required timing targets for each function and constituent process.

? Specify information accessibility objectives.

? Specify the fallback and recovery requirements.

? Specify the performance objectives.

4.1.8 Establish theoretical basis

The theoretical basis for going from the problem to its solution can be identified from a study of relevant published material, and requirements from any standards and codes of practice. Any preliminary assumptions that seem necessary should be identified, along with possible methods of solution. The validity of the methods should be investigated, and the credentials of their authors established.

The main purpose of establishing the theoretical basis is to obtain an appreciation of the logic and methods of computation used and to form an opinion of the assumptions, scope and limitations of the method, and accuracy and reliability of the numerical results produced. Where preliminary calculations are made as a pilot study, their limitations should be clearly stated, and additional work needed before the method can be approved.

The tasks involved in establishing the theoretical basis include:

? Survey published references.

? Locate relevant standards and codes of practice.

? Identify preliminary assumptions, scope and limitations.

? Describe method of solution.

? Estimate accuracy and reliability of results.

4.1.9 Survey project options

At this stage there should be several means of getting from the problem to the solution, however far-fetched some of them may be. It is important to consider as many alternatives as possible as these may trigger further possible solutions. This is where inspiration and lateral thinking are invaluable, and provide that spark of genius that has so often eluded researchers.

The aim of this activity is to produce from three to six outlines of possible research solutions. Creating project outlines is likely to be fairly subjective and it is unnecessary to become too technical. It is often a good idea to solicit the knowledge and experience of other researchers in brainstorming sessions.

Broad outlines for each possible option should be produced in the form of project outlines. Constraints and requirements need to be identified, along with the technical and physical environment, reference material, method of development, cost and time impact, and so on. It becomes obvious in this process that some options can be eliminated early in the process, but that particular facets of the approach may usefully be incorporated into another option. Eventually, in discussions with users and other experienced researchers, the options are reduced to two or three possible contenders.

The tasks involved for the activity producing a broad outline for each possible option include:

? Identify constraints and requirements.

? Create project outlines.

Technical environment � physical, hardware, etc.

Method of development.

Reference material.

Informal impact of each option in terms of cost.

? Review options informally with users.

Reduce to three possible contenders.

4.1.10 Specify outline project requirements

The project outlines for each of the remaining options should be expanded to produce enough information to enable those selecting an option to make a sound business/engineering decision. As a general rule, the level of detail explored should be that which will allow acceptable estimates of costs and benefits to be made. Where possible, common parts of the specification should be utilized.

Outline data descriptions for each option should include estimates of data size and volumes as an approximate basis for estimating the data storage and processing requirements. The main events should

include those events which produce a basis for estimating the data collection and processing requirements.

Any equipment, hardware, software, processing, communications, other facilities should be described as part of the technical environment. The project development plan for each option should be elaborated upon. The advantages and disadvantages should be listed along with an outline of the cost/benefit analysis for comparative evaluation at this stage. Each remaining option should be reviewed for consistency, and the outline documented.

The tasks involved in specifying each outline project include:

? Create outline data descriptions.

Include estimates of data size and volumes as an approximate basis for estimating the data storage and processing requirements.

? Overview main events.

Include those events which produce a basis for estimating the data collection and processing requirements.

? Describe the technical environment.

Equipment, hardware, software, processing, communications, other facilities.

? Elaborate on the project development plan.

? Carry out an impact analysis.

Only outline analysis required at this stage.

? Carry out cost/benefit analysis.

Only skeletal for comparative evaluation.

? Review the outline specification for consistency.

4.1.11 Determine impact

The impact analysis is a vital component of each option specification. It will normally consist of a list of advantages and disadvantages of significance to the user. Every attempt must be made to attach a value to each point. The impact analysis is elaborated upon after a final choice has been made.

The tasks involved in the impact analysis activity include:

? List advantages.

? List disadvantages.

4.1.12 Evaluate benefits

The cost/benefit analysis is derived from the previous work and will be used as the basis for comparative judgement of the options. The confidence in the analysis is heavily dependent on the amount of effort put into it and the quality of the estimates.

The tasks involved in the cost/benefit analysis activity include:

? List costs.

? List benefits.

4.1.13 Select best research option for development

This activity requires the users to evaluate the options created and select a suitable option for further development if possible. It is the researchers responsibility to ensure that the users are aware of the issues involved in making the selection. Once the formal presentation has been given, the research team must be prepared to help users who will have to deal with documents that are almost certainly limited in scope.

It is important to keep the users involved in this process, and they may also need a cover note explaining the requirements for selection. It is a good idea to make a formal presentation of each option, identifying significant features and comparing strengths and weaknesses. Insufficiently defined areas will need clarification and amplification. The researcher should be prepared to make a recommendation if necessary, although by this stage the selection is usually obvious. One suitable option should be agreed, noting reasons for selection and rejection.

The chosen solution may be a hybrid or a subset of the options. This is likely to be a minimal, low-cost solution. On the other hand, the discussions and deliberations leading up to the evaluation process may lead to the conclusion that something much more comprehensive is needed and can be afforded, leading to a more elaborate solution.

The tasks involved in selecting the research option for further development include:

? Distribute copies of the outline options.

May also need a cover note explaining the requirements for selection.

? Make formal presentation of each option.

Identify significant features and compare strengths and weaknesses.

? Clarify and amplify insufficiently defined areas.

Make a recommendation if necessary.

? Agree on a suitable option.

? Note reasons for selection and rejection.

4.1.14 Estimate resource requirements

The resource estimate turns a research option into a proposed research project. It forms the basis for approval for work on the research project to commence.

In preparing the resource estimates, the researcher (project manager) should take into account the implications of the requirements specification, acceptance testing, and other project time-scales through discussion with the respective managers. The level of detail and planning required before an accurate estimate of resources can be made will depend upon individual circumstances, and an accuracy of �20% should be the aim for the projected completion date. A useful rule of thumb for estimating research time is:

35% model design

15% model build and test

25% modelling and results processing

25% acceptance and report

Note that model design does not include research or any exploration of totally new techniques. Model building and testing is the easy part and therefore easiest to estimate provided that there is a good design. Modelling is normally done in conjunction with results processing and good estimates can usually be made. Acceptance takes a long time and as it tends to come at the end of the project, any errors found can cause havoc with schedules.

When scheduling, it is well to remember that the number of months of a project depends upon its sequential constraints. The maximum number of people depends upon the number of independent tasks. From these two quantities one can derive schedules using fewer people and more months. One cannot, however, get workable schedules using more people and fewer months. If the research runs behind schedule, throwing more people onto the task will not reduce the schedule, but usually make it worse. The solutions are:

� Reschedule, that is, allow enough time in the new schedule to ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.

� Trim the task. In practice, this tends to happen anyway, once slippage is observed. Where the secondary costs of delay are high, this is the only feasible action and should be done formally, rather than just let it happen.

Scheduling the completion of a project to match the users requirements does not necessarily govern the actual completion. There is clearly a lack of information on research productivity, estimating rules, etc.

It is important that one does not estimate the model building portion and extrapolate using the given ratios to get an estimate for the whole project, as a small error here can only be magnified. Also, it should be realized that only about 50% of the working week is actually productive research time. Higher priority short unrelated jobs, meetings, reading, training, paperwork, other business, leave, sickness, personal time, etc. account for the rest.

The research project is established on the basis of identifiable research products. For this research procedure, these products are in the form of defined documentation. Each of these products or events, called milestones, has a date. Picking the dates is an estimating problem, and crucially dependent on experience.

Costs vary as the product of the number of people and the number of months or weeks. Progress, however, does not.

The tasks involved in estimating resource requirements and completion include:

? Estimating.

A useful rule of thumb for estimating research time is:

35% model design

15% model build and test

25% modeling and results processing

25% acceptance and report

? Scheduling

When scheduling, it is well to remember that the number of months of a project depends upon its sequential constraints. The maximum number of people depends upon the number of independent tasks. From these two quantities one can derive schedules using fewer people and more months.

4.1.15 Recommend research strategy

The research project plan must show the strategy for development and give an estimate of the resources that will be needed and the time-scale that might be achieved.

If resources have been allocated and are known, then a detailed plan can be prepared. Otherwise, a provisional plan will identify significant intended milestones.

The tasks involved in this activity include:

? Consider research options.

? Recommend research strategy.

4.1.16 Establish quality assurance (QA)

Tangible products should be identified to which QA techniques can be applied to assess quality, completeness, and hence progress. QA must ensure that the proposed research strategy does not distort the research procedure so as to lose any of its inherent strengths. The procedure must always contain:

� A structured, planned way of working.

� Techniques that cross-check each other and therefore test the assumptions made.

� Formal QA checkpoints.

The tasks involved include:

? Establish formal QA checkpoints.

4.1.17 Formalize Feasibility Report

The Feasibility Report is intended to serve two purposes:

� It provides a formal record for management, users and researchers of the work done and the decisions taken. It is used as the basis for formal approval to carry out further research.

� It provides the researchers starting point for the model preliminary design phase.

As a minimum the feasibility study report must contain:

The problem definition.

Outline research project option specifications.

Selected project specification.

Statement of reasons for selection.

Detailed plan for the model preliminary design phase.

Authorization document for the model preliminary design phase.

The Feasibility Report includes the products of the feasibility study and acts as the specification against which further research is carried out and requires a complete research project specification. This should reflect the selected research option, update the outline cost/benefit analysis and the outline impact analysis. Detailed costs for the model preliminary design phase should be calculated and a model preliminary design phase schedule created. Resources, including time and money, should be allocated and the Feasibility Report completed.

The report includes the products of the study and acts as the specification against which further research is carried out and requires the following tasks:

? Complete the research project specification.

This should reflect the selected research option.

? Update the outline cost/benefit analysis.

? Update the outline impact analysis.

? Prepare the tasking estimates.

Calculate detailed costs for the model preliminary design phase.

? Create a model preliminary design phase schedule.

Allocation of resources.

Time requirements.

Milestones.

? Complete the feasibility report.

4.1.18 Prepare Abstract sheet

An updated Abstract sheet should be produced at this stage. The proposed research should be summarized on a single page, with diagrams illustrating the modelling on the reverse where applicable.

The tasks involved in preparing the Abstract sheet include:

? Prepare Abstract sheet.

4.1.19 Seek approval

There is no commitment at this stage to the whole research project � only to proceed to the model preliminary design phase. Full records of this phase should be stored in the appropriate section of the Project manual.

The tasks involved in seeking approval include:

? Seek approval to proceed..

4.2 Feasibility Report

The Feasibility Report covers the products of the feasibility study. It acts as the specification against which further research is done, that is, it becomes the preliminary design requirements for the model. The report is intended to serve two purposes

� It provides a formal record for management, users and researchers of the work done and the decisions taken.

� It is used as the basis for formal approval to carry out further work.

It provides the researcher�s starting point for the preliminary design of the model.

The Feasibility Report includes project identification, problem/requirements list, functional specification of the research requirements, theoretical basis, resource constraints, cost/benefit analysis, impact analysis, safety, ethical and code requirements, management plan and elapsed time schedule with tasking estimates. It should conclude with an option for future consideration.

Maximum use should be made of the products created during the study, all of which should be included as annexes or enclosures to the report. Original text should be kept to a minimum. The study of a large complex research problem may produce a report of several volumes, of which the first should be a management summary.

4.2.1 Feasibility Report specification

The Feasibility Report should include:

Title Page Institution

Research Title

Feasibility Report

Author/Researcher

Date

User

Introduction Problem definition.

Scope of the research.

Overview of the proposed research.

Background to the needs for the research.

Outline of the user requirements, the essential and desirable features as well as constraints including time scales and costs.

Description of the physical, social, political, economic and organizational environment into which the research is to investigate.

Guide to other documents.

Structure of the Report.

Current Existing models and solutions.

Ability to cope with current behaviour.

Demands for enhancements or alternatives.

Shortcomings and limitations.

User Characteristics of the users who will interact with the research/solution, particularly those that might affect the modelling.

Wants and needs.

Requirements Summary of the main functional requirements of the model and their interrelationships, including all major functions, inputs and outputs.

Outline the way the research model is expected to operate, normally, failure, etc.

Overview of the way the model is developed, used and maintained during its life, and the way this will be controlled.

Performance requirements of the model in terms of static and dynamic capacity and response and delivery times.

Constraints Theoretical, modelling and user constraints.

Financial, time, resource and human constraints.

Research standards, codes of practice, language, and procedures for report formats, data naming, audit, ethical and quality requirements.

Compatibility requirements for internal and external interfaces.

Use of specific computer hardware and software packages

Communication standards and interfaces.

Specific data base and data handling requirements.

Tolerances, margins and contingency constraints on model size, performance, expansion, etc.

Compliance with standards and codes of practice.

Tolerances and margins for capacity, performance, contingency, etc.

Identification of user and model operator constraints and features that may be needed.

Component and integration testing.

Any assumptions that will be necessary.

Theory Description of, or reference to, theoretical and/or empirical method of solution.

Assumptions on which method of solution depends.

Limits within which assumptions are valid.

References to experimental justification and assumptions.

Empirical data used in method of solution.

References to sources of empirical data.

References to full-scale tests.

Correlation between results predicted and results of tests.

Mathematical idealization, mathematical and numerical algorithms and techniques, etc.

Specification Functional requirements of the model.

Description of overall functional structure listing separate component functions and their interrelationships.

Data framework needed to support the functional structure and appropriate cross-referencing, listing all model inputs and outputs, interfaces, data ranges, formats, etc.

Overall requirements for both normal and failure operations of the model, including modes of control, performance requirements, built-in tests and safeguards, availability, start up and close down, security and safety aspects, error reporting and recovery, etc.

Hardware and equipment requirements, environment, reliability, physical, electronic and mechanical constraints, etc.

Options Outline research option specifications.

Impact analysis summary consisting of advantages and disadvantages of significance to the user and the environment.

Cost/benefit analysis summary as the basis for comparison, with estimates of research, development and operating costs.

Project research plan showing the strategy for research and an estimate of resources needed and timescale envisaged.

Selection Statement of reasons for selection.

Selected research project specification.

List of expected deliverables.

Documentation format and standards required.

Version and document control.

Operational life of research products.

Cost/benefit Development costs.

Operating costs.

Current costs that will disappear.

Intangible benefits.

Impact The effect on the research environment.

Significant changes in user and community procedures.

Effect on organization and staffing levels.

Consequent organizational changes.

Major advantages to the organization.

Major disadvantages.

Moral and ethical considerations.

Implementation considerations for

� installation

� staffing requirements

� training requirements

� effects of inexperienced staff

� service levels

Assurance Research acceptance requirements.

Arrangements for quality management and acceptance testing.

Detailed research plan.

Arrangements for control and progress reporting.

Conclusions Approval for resource and financial expenditure.

Approval to proceed to next phase.

4.3 Report writing

Reports, like letters, are written for their readers. This obvious fact is often overlooked, at the report writer�s peril. Most reports convey information about a given subject, such as a research project, an accident, tests on equipment or a visit. Many reports are also requests: the writer wants more time, more money, or more cooperation to complete the research or sell the product or idea. Both language, which is formal, and format must work to the benefit of the reader, who is the most important person. They will then also bring the �right� response from the point of view of the writer.

The reader and the purpose of the report must both be clearly identified. This will help the writer to use the correct �language�, ie the appropriate level of technicality, with explanation and backup as required. Reports, like letters, tend towards the pompous (�initiate� rather than �start�) and to the imprecise (�in due course�). The English language should be used formally but in an easy, fluent way, and as precisely and unambiguously as possible. Technical language should be chosen for the reader and for the subject matter, preferably in that order.

The purpose (objective) of the report should also be well defined in the writer�s mind, so that all the information given is relevant to the subject and builds up a clear, uncluttered picture of the situation and what should be done about it. This clarification also helps to make the writing concise; report readers are usually busy people who prefer a short report to a long report. There is a tendency among engineers to ramble, often repeating the same information several times, or introducing unnecessary details or wandering away from the point.

Although some reports are read in order from start to finish, far more reports are used, with the reader picking and choosing sections which are helpful, of particular interest or needed urgently. The structure of the whole document must be apparent from the contents list (Table of Contents), although convention is also a useful guide. A technical report might follow a standard format such as:

Introduction (with the reason for the investigation)

Summary (including the main conclusions and recommendations)

Procedure (how the investigation was carried out)

Results (the facts which emerged from the investigation)

Discussion (the implications of the results)

Conclusions (what is or is not satisfactory)

Recommendations (what should be done as a result of the conclusions)

A long report such as a dissertation or thesis might have even more sections:

Abstract (a brief one page summary, including the main conclusions and recommendations � consider as a separate document)

Title page

Acknowledgements

Table of Contents (section or chapter numbers, headings, page numbers)

Introduction (putting the reader in the picture)

Background (include a review of the relevant literature)

Procedure (methodology of how the research is carried out and the findings discovered � result must be able to be repeated)

Findings (what has been discovered � the data)

Analysis (turning data into results)

Conclusions (turning results into information � implications of what has been discovered)

Recommendations (what should be done in the future)