Participation, presentation and review - Introduction to Environmental Impact Assessment - page 178

Appendix 5 of Environmental impact assessment: guide to the procedures (ODPM
2003a): see Table 3.5. Table 1.1 provides an example of a good EIS outline.
An EIS should explain why some impacts are not dealt with . It should include a
“finding of no significant impact” section to explain why some impacts may be
considered insignificant. If, for instance, the development is unlikely to affect the climate,
a reason should be given explaining this conclusion. An EIS should emphasize key points .
These should have been identified during the scoping exercise, but additional issues may
arise during the course of the EIA. The EIS should set the context of the issues. The
names of the developer, relevant consultants, relevant LPAs and consultees should be
listed, along with a contact person for further information. The main relevant planning
issues and legislation should be explained. The EIS should also indicate any references
used, and give a bibliography at the end. Ideally, the cost of the EIS should be given.
The preparation of a non-technical summary is particularly important in an EIS, as this
is often the only part of the document that the public and decision-makers will read. It
should thus briefly cover all relevant impacts and emphasize the most important, and
should ideally contain a list or a table that allows readers to identify them at a glance.
Chapter 4 gave examples of a number of techniques for identifying and summarizing
impacts.
An EIS should ideally be one unified document, with perhaps a second volume for
appendices. A common problem with the organization of EISs stems from how
environmental impacts are assessed. The developer (or the consultants coordinating the
EIA) often subcontracts parts of the EIA to consultancies which specialize in those fields
(e.g. ecological specialists, landscape consultants). These in turn prepare reports of
varying lengths and styles, making a number of (possibly different) assumptions about
the project and likely future environmental conditions, and proposing different and
possibly conflicting mitigation measures. One way developers have attempted to
circumvent this problem has been to summarize the impact predictions in a main text, and
add the full reports as appendices to the main body of the EIS. Another has been to put a
“company cover” on each report and present the EIS as a multi-volume document, each
volume discussing a single type of impact. Both of these methods are problematic: the
appendix method in essence discounts the great majority of findings, and the multi-
volume method is cumbersome to read and carry. Neither method attempts to present
findings in a cohesive manner, emphasizes crucial impacts or proposes a coherent
package of mitigation and monitoring measures. A good EIS would incorporate the
information from the subcontractors' reports into one coherent document which uses
consistent assumptions and proposes consistent mitigation measures.
The EIS should be kept as brief as possible while still presenting the necessary
information. The main text should include all the relevant discussion about impacts, and
appendices should present only additional data and documentation. In the US, the length
of an EIS is generally expected to be less than 150 pages. In the UK, the DoE (1995)
recommends:
For projects which involve a single site and relatively few areas of
significant impact, it should be possible to produce a robust ES of around
50 pages. Where more complex issues arise, the main body of the
statement may extend to 100 pages or so. If it exceeds 150 pages it is