A-6-Guideline For Technical Specification
A-6-Guideline For Technical Specification
A-6-Guideline For Technical Specification
CONTENTS
1
INTRODUCTION..................................................................................................2
1.1 PERSONNEL.........................................................................................................2
1.2 PROCEDURES......................................................................................................2
1.3 SPECIFICATIONS................................................................................................2
1.4 OBJECTIVITY & CONFIDENTIALITY.............................................................2
1.5 MARKET RESEARCH.........................................................................................3
2
CONTENT OF TECHNICAL SPECIFICATIONSError! Bookmark not defined.
2.1 GENERAL REQUIREMENTS.............................................................................3
2.2 SPECIFIC BRAND...............................................................................................4
2.3 ORIGIN..................................................................................................................4
2.4 FUNCTIONALITY................................................................................................4
2.5 ACCEPTANCE CRITERIA..................................................................................4
2.6 COMPLETENESS.................................................................................................4
2.7 OVER-SPECIFICATION......................................................................................5
2.8 DUPLICATION.....................................................................................................5
2.9 SCHEDULING......................................................................................................5
2.10 INTEGRATION.....................................................................................................6
2.11 CUSTOM DEVELOPED ITEMS.........................................................................6
2.12 SPECIAL CONSIDERATIONS FOR CUSTOMISED SOFTWARE.................6
Page 1 of 7
INTRODUCTION
1.1
PERSONNEL
The Contracting Authority is responsible for drawing up Technical Specifications for supply
contracts. It is helpful to consult all parties involved in the proposed project in preparing
Technical Specifications. This should improve both the quality of the project as well as the
commitment of the Contracting Authority and beneficiaries. Given the technical complexity of
many contracts, the preparation of the tender dossier - particularly the Technical Specifications may require the assistance of one or more external technical specialist(s).
1.2
PROCEDURES
The Technical Specifications must be drawn up in accordance with the Practical Guide to
Contract Procedures for European Commission External Actions (PRAG). This document
summarises the relevant information given in PRAG. For those preparing the technical
specifications, the responsibility begins with understanding the purpose intended by the
Contracting Authority, continues through defining the characteristics required of the products,
services, materials and/or work (the supplies) to satisfy the purpose, and ends with the
Contracting Authoritys approval of the specifications. Throughout this process those involved
must be totally committed to the task.
1.3
SPECIFICATIONS
environmental performance
safety or dimensions, including, for supplies, the sales name and user instructions, and, for
all contracts, terminology, symbols, testing and test methods, packaging, marking and
labelling, production procedures and methods.
The purpose of the specifications is to give instructions and guidance to contractors at the
tendering stage about the nature of the tender they will need to submit and to serve as the
contractor's mandate during project implementation. The Technical Specifications will be
included in the tender dossier and will become an annex of the eventual contract awarded as a
result of the tender.
Thorough preparation of the Technical Specifications is crucial for the ultimate success of the
project but it is also vitally important to ensure clarity and conciseness in drafting them.
1.4
Strict objectivity and confidentiality must be maintained throughout by observing the following:
Each beneficiarys representative or technical specialist must sign a Declaration of
Objectivity and Confidentiality
All information or documents must be held in confidence and used only for the purposes of
preparing the Technical Specifications and not disclosed to any third party unless that person
has also signed a Declaration of Objectivity and Confidentiality
All contributions to preparing Technical Specifications must be objective and must fully
respect the principles of fair competition and impartiality, in particular by avoiding terms or
conditions favouring any one product, manufacturer or service provider
Market research
Market research is required to ensure that:
At least three different examples of each item can be obtained that meet the PRAG
nationality rule.
All the required supplies can be obtained within the proposed budget.
Guidelines for carrying out this market research are given at:
http://www.cfcu.gov.tr/files/kaynaklar/market_research.pdf.
2.
CONTENTOFTECHNICALSPECIFICATIONS
The Technical Specifications indicate - where applicable, lot by lot - the exact nature and
performance characteristics of the supplies. Where applicable, they also specify delivery
conditions and installation, training and after-sales service.
It is essential that the performance characteristics correspond to the intended purpose. If there
needs to be an information meeting or site visit to clarify technical requirements at the site
where supplies are to be installed, this should be specified in the instructions to tenderers,
together with details of the arrangements.
2.1
GENERAL REQUIREMENTS
As well as the technical specifications of the supplies, various other requirements will need to
be specified, such as:
maximum delivery period
warranty
after-sales service
documentation
training
acceptance procedure.
recommended consumables
delivery address
background information
equipment layout
spare parts
2.2
SPECIFIC BRAND
It is not normally allowed to mention or describe products of a given brand (e.g. IBM
computer) as this would favour or exclude certain products. However, where products cannot
be described in a sufficiently clear or intelligible manner any other way, they may be named as
long as they are followed by the words "or equivalent" (e.g. Processor - One Intel Celeron 2.4
GHz with 400MHz FSB and 256KB L2 cache or equivalent).
2.3
ORIGIN
All supplies must satisfy the PRAG rules on origin. This can present problems if:
The only known suitable product does not meet the rules on origin, or
A particular product is needed (e.g. for compatibility with beneficiarys existing equipment)
Understand that PRAG states the country of origin is deemed to be the country in which the
goods have undergone their last, economically justified, substantial transformation. For
example, it is necessary to procure a computer with the Microsoft Windows XP operating
system. The computer hardware meets the rules of origin, but the operating system does not
and so if the operating system is supplied separately the rules of origin will be broken.
However, if the operating system is installed by the manufacturer before delivery then the
rules can be met. In this case the computer specification could include the item:
Specification
Minimum required
Operating system
Preloaded Microsoft Windows
(must be pre-installed in the hardware before
Professional or equivalent
delivery)
2.4
XP
FUNCTIONALITY
Wherever possible the required supplies should be described in terms of their functionality,
rather than their internal characteristics. The required functions of the system need to be
described in a way that will allow acceptance criteria to be derived.
2.5
ACCEPTANCE CRITERIA
There should be clear acceptance criteria for all components of the supply, particularly parts that
are customised.
2.6
COMPLETENESS
Ensure that all the required features of each item are specified including such things as:
software licenses
2.7
OVER-SPECIFICATION
Unnecessarily high specification
There is a temptation to specify items to a very high level, offering complex functionality which
may not be necessary for the beneficiary and which they are unlikely to use. Such needlessly
high level of specification could result in tenderers having to make offers of unnecessarily
expensive supplies. For example, regarding a computer communications switch, the
specifications may require support for at least 32,000 addresses as is commonly found on
equipment generally available. However, the real requirement may be for less than 1,000 and so
this over-specification could rule out cheaper equipment that would be perfectly adequate for
the required system.
Redundant specification
Another fault is where part of the technical requirement is redundant. For example, the general
specification for a Relational Database Management System might state that it must be MS SQL
Server 2005 Enterprise Edition Processor license or equivalent. Following this may be
numerous individual detailed requirements that are redundant as any software that satisfies the
general requirement will automatically meet all of these other requirements. In this case the
tenderers will have to respond to all these detailed requirements and the evaluators will have to
judge their compliance unnecessarily.
Unnecessary items
All the items in the Technical Specifications should contribute to meeting the overall purpose of
the procurement. Items that do not contribute to achieving the purpose should not be included.
2.8
DUPLICATION
No items should be specified more than once. This may seem obvious, but it does happen. For
example, regarding a computer system a section General Hardware Requirements may give
some specifications that are duplicated later under the individual hardware items.
In the most extreme cases, the requirement itself is duplicated so that two of a particular item
will be procured unnecessarily. For example a corporate anti-virus solution that will protect the
entire computer network might be specified in Lot 1 while individual anti-virus programs are
specified separately in Lot 2 for workstation computers.
2.9
SCHEDULING
If the required delivery, implementation and training schedule is specified it should take into
account:
Sufficient time must be allowed for setting up, any custom development and testing.
Any practical training should be scheduled to take place after the supplies can be expected to
be fully tested and functional.
Sufficient time must be allowed for training so that all personnel are not trained at once and
that no individual will be absent from his/her duties for such long periods as to adversely
affect the work.
2.10
INTEGRATION
Where the supplies are the subject of multiple lots, e.g. one Lot 1 for a central computer system
and Lot 2 for a network of workstations, it must be clear whose responsibility it will be to
connect the components and integrate them into a single cohesive system.
2.11
The structure of a supply contract is designed to provide goods and direct services to the
beneficiary in their objective to establish operational facilities. In the technical evaluation of a
supply tender each item is deemed either compliant or non-compliant; there is no assessment of
the quality of the supply. However, custom developed items, such as special software, will vary
in quality, usability and fitness for purpose dependent on the capacity, organisation and
methodology of the contractor. A service contract would be needed in order to evaluate these.
Therefore, if equipment and custom developed items are needed it is best to have two tenders or
one tender with two components:
a global price service tender or component for the customised software, and
2.12
If, nevertheless, customised software is included in a supply tender the following items should
be considered for inclusion in the Technical Specifications:
language
scope
users
user roles
data entry
plausibility tests
data access
architecture
database structure
audit trail
data volumes
interfacing
system adaptation
list of functions
description of functions
reports
security
help function
implementation schedule