Below is a pro forma RFP:
1.0 Confidential Information
Prior to receiving this Request for Tender (RFT), a duly authorised representative of your company signed a Confidentiality Agreement. This Confidentiality Agreement documents the obligations of your company and Organisation to maintain the confidentiality of information. All of the information contained in this RFT shall be deemed to be "Confidential Information" within the meaning of the Confidentiality Agreement and shall be treated accordingly. Such information may not be copied, disclosed or distributed to any other person without the prior written consent of Organisation.
2.0 Acknowledgment Form
This form acknowledges receipt of this RFT and states whether the vendor intends to submit or not submit a tender.
Request For Tender No: Number
Closing date for receipt of tenders:Date2 before 5:00 p.m, at the location set forth below:
RETURN THIS FORM BY:Date3 before 5:00 p.m., to:
Organisation
Attention:
We,
Vendor name
Address
(Check one of the following)
Intend to submit a tender
Do NOT intend to submit a tender and have returned all Organisation documentation, including the RFT.
Please indicate your reasons for declining to submit a tender:
Signature
Title
Date
3.0 Project Introduction
This document is a request for tender (RFT) to obtain certain [SPECIFY] Information Technology (IT) products/services. The IT services within the scope of this RFT include [insert a brief description of the scope of the requirement, e.g., hardware; data processing services; communication services; applications development and maintenance; applications maintenance; distributed processing; hardware, packaged software, consumables, other]. Organisation anticipates that the provision of these IT products/IT services will provide ………… [insert a brief description of expectations and the current environment, e.g., consolidation approach; in-house approach to application development and maintenance; other]. While Organisation foresees a [insert a brief description of the key objective, e.g., Systems integration contract, application maintenance contract covering the corporate headquarters location; other], it is essential that [insert a phrase describing what the essentials of the contract are, e.g., the service levels and support provided under any agreement be responsive to local needs and exceed current levels being provided; other]. [Insert a sentence describing the scope of the contract, e.g., Storage hardware, data processing services include the provision of hardware, system software, platform operations and support services but exclude business application maintenance; other]
This introductory section describes the background to the RFT, Organisation's objectives, the scope of the RFT and an overview of the current environment.
3.1 Background
The Organisation is Describe Organisation in one paragraph.
A wide range of information and facts about Organisation is available at the website, www.Organisation.com.
The IT needs of Organisation's business are supported by a diverse support organisation, including, but not limited to:
• Mainframe data centres
• Multiple midrange computing locations
• Distributed/desktop systems at all Organisation locations
• Wide area data network, connecting (partial list)
• Video network, connecting (partial list)
• Voice network
• Applications development and support
• Applications maintenance
• Database administration
• Training
3.2 Tender Objectives
Organisation's primary objectives in Tendering the [IT Requirement] are as follows: [Insert statements of key objective(s), e.g.,
• achieve costs that are minimal and predictable
• ensure flexibility in terms of storage usage and costs
• continue to provide and improve upon high quality service levels to the end-customers
• enable existing Organisation programming staff to focus on new application development
• reduce the amount of discretionary functional enhancements in existing applications
• improve equipment total cost of ownership ]
3.3 Current Environment
[Relevant Description – e.g., Applications Architecture, Hardware Architecture, etc]
4.0 Instructions to Vendors
This is a Request for Tender (RFT), not an order. This document shall not be construed as a request or authorisation to perform work at Organisation's expense. Any work performed by a vendor in connection with evaluating and responding to the RFT and, if selected, negotiating a definitive agreement will be at the vendor's own discretion and expense. This RFT does not represent a commitment to purchase or lease. Organisation reserves the right to reject any and all tenders at its sole and absolute discretion. Submission of a bid constitutes acknowledgement that the vendor has read and agrees to be bound by such terms.
The information in this document will enable the recipient to formulate a tender to meet the workload requirements as described in this RFT. The information in this RFT is accurate to the best of the author's knowledge but is not guaranteed to be correct.
4.1 Point of Contact
All communication with Organisation regarding this document (seeking clarification only) must be directed by e-mail to the single Point of Contact for this project, as follows:
Point of Contact
Although telephone queries will not be taken regarding this document, contingency contact details are:
Point Of Contact
Organisation
Address
Telephone:
Email:
Tenderers must not contact or discuss the RFT with any other persons in the Organisation. Organisation will respond to all queries with the unattributed questions/clarifications and related answers being posted on the Organisation website at: pointer
4.2 Submission of Tenders
Tender must be received by Date4 by 5:00 PM. Extensions to this date cannot be granted.
Vendors MUST submit tenders complete and in writing. Tenders MUST be organised according to the format described in Appendix B. Vendors MUST submit an electronic copy of the tender in response to this RFT will constitute an offer to develop a contract based on the terms stated in this RFT and in the vendor tender, if vendor is invited by Organisation to do so. Organisation wishes to see cost-effective, quality solutions that meet all of the mandatory requirements in this document. Partial solutions may not be considered. Vendor responses will be assumed to be their best and final offers.
Tenders MUST include a statement that indicates that the vendor understands the requirements of the RFT and accepts the terms and conditions under which the RFT was issued to the vendor. The original tender and (x) complete copies MUST be signed by a duly authorised officer. If any subcontractors or partners will be providing services under the tender, all subcontractors and/or partners MUST sign the tender. In signing, all subcontractors and/or partners are responsible for carrying out the work called for in the tender attributed to such contractors and/or partners. The vendor submitting the tender shall be primarily responsible for carrying out the work called for in the tender. All pages and sections in the tender must be clearly numbered.
The original and all copies, including all supplementary literature, must be submitted to the Contact identified in Section 4.1 of this RFT.
This RFT remains the property of Organisation at all times, and must be returned by the vendor upon request. Vendors not submitting a tender MUST immediately return all printed, graphic and electronic documentation to the Contact. Once a vendor has been advised of a contract award, the unsuccessful vendors MUST return all RFT and related printed, graphic and electronic documents to the Contact.
All tenders (and related materials), once delivered, become the property of Organisation.
TenderVendors will comply with any and all requirements as specified in the RFT document. Any stipulation or qualification made by vendors contrary to the RFT requirements in or accompanying tenders as a condition for the acceptance of the contract by the vendor may not be considered in the award of the contract and may cause the rejection of the entire tender.s which are delivered late will not be considered and will be returned unopened.
4.2.1 Exceptions and Alternatives
Vendors may, however, submit one or more alternative tenders in addition to a response conforming to the requirements specified in this RFT. Any alternatives must be clearly identified and segregated from the original tender. Any alternatives must be prepared using the same format specified in this RFT. The vendor will assume full responsibility to demonstrate that the alternative will meet or exceed Organisation's requirements. Vendor will bear all costs required to obtain Organisation's acceptance of the alternative solutions(s). Organisation reserves all the same rights for alternatives as otherwise specified in this RFT.
|
Date: |
|
|
Time: |
[insert time of meeting start - end] |
|
Place: |
Organisation |
|
|
|
|
|
|
|
|
|
4.5 Competitive Dialogue
Following submission of the tender, the number of vendors being considered may be reduced to a "finalist list". Vendors may be asked to participate in a competitive dialogue [state the likely form of the dialogue] with Organisation management. Final vendor selection will be based on the vendor's responsiveness to Organisation's project objectives.
4.6 Requests for Additional Information
Questions regarding clarification to the contents of the RFT will be accepted from time of receipt by vendor until 5:00 PM Date6. Organisation cannot guarantee that responses will be issued in time for vendors to incorporate into vendor tenders.
Inquiries MUST be made IN WRITING to the Contact. Answers to vendor inquiries will be distributed in writing to all vendors if it is determined that this clarifies the Organisation requirements to all vendors. Any verbal statements regarding this RFT by any persons other than the Contact, previous to vendor selection, shall be deemed unauthorised and may not be relied upon.
All requests for information which would be supplemental to the information contained in the RFT should be made in writing, addressed to the Contact. Whenever responses to these requests would constitute a modification or addition to the original RFT, the reply will be made in the form of an addendum to the RFT, a copy of which will be forwarded to all vendors. All questions must include:
• The submitting company's name, company address and phone number
• A clear and concise question
• References to specific points within this RFT
4.7 Site Visits
For vendors that so desire, a visit to the Organisation [insert appropriate Organisation facility, e.g., data processing centres or programming centre] may be arranged by appointment. Requests for visits should be addressed to the Contact.
Organisation may request a visit to the vendor's proposed [insert appropriate vendor facility, e.g., data processing site(s), programming and maintenance centre(s)].
4.8 Tender Format
To facilitate a timely and comprehensive evaluation of all submitted materials, tenders MUST be submitted using the format defined in Appendix B [and use the Template provided]. Any deviation from this format may lead to the rejection of the tender. Alternative tenders, if offered, are to be prepared using the same format and will be considered as part of the evaluation process.
5.0 RFT Principal Requirements
Full details of the Organisation requirements for the tender are given Appendix C the following section sets out the principal general requirements.
5.1 Procurement Process
• Organisation reserves the right to amend or otherwise change the process or to terminate the process. This RFT does not represent a commitment to enter into any contract. Organisation is not bound to accept the lowest cost offering.
• Tenderers shall bear all costs associated with the preparation and submission of their tender and Organisation shall not be responsible or liable for any costs or expenses regardless of the conduct or outcome of the procurement process.
• All propositions in the response will be treated as contractually binding. Organisation reserves the right to update or alter any details in this document at any time and will post such changes on the Organisation website at pointer.
• All material provided to Organisation is treated in strict confidence. It is required that tenderers will treat all information provided by Organisation in a similar way.
5.2 Licensing Policy and Source Code [applicable for S/W, SI and Outsourcing]
The following must be provided:
5.2.1. Software Ownership
A clear statement in relation to ownership of all software supplied and any third party licensing which may be involved.
5.2.2. Licence Policy
A statement outlining the licence policy, if any, in relation to the solution as adapted for Organisation. This should address whether a 'site licence' is provided, or whether more restrictive approaches are proposed e.g. a concurrent or named user arrangement or a platform related licence.
5.2.3 Escrow
Details of Escrow arrangements for source code, including verification procedures, and detailing any cost to Organisation. If source code cannot be provided (e.g. third party package software) as part of the contract, a suitable escrow agreement may be required to protect the interests of Organisation.
5.2.4 Guarantees and Warranty
Details of Guarantees/Warranties. These should cover error correction, upgrades and enhancements to the basic solution.
5.2.5 Resale
Tenderers should identify any issues arising from the possible re-sale by Organisation in the future of all or parts of the solution.
5.6 Pricing
5.6.1. Quote on Fixed Price
Tenderers should quote for the supply of a [product/service/solution] at a fixed price in respect of all [products and] components being offered. Each category of cost (as defined below) must be priced separately. Prices must be quoted in Currancy, and it must be clearly specified whether applicable taxes are included.
5.6.2 Maintenance Cost
Tenderers should quote, and clearly identify, for annual maintenance and support of the supplied components, and state on what basis the quote is calculated.
5.6.3 Training Requirements
Tenderers should clearly identify what training is included in the price, and what required training is not included.
5.6.4 Product Dependancies
Where parts of the solution will be met by standard office products, or any other dependent products, these should be identified (particularly in relation to versions) but not included in the cost.
5.6.5 Special Requiremants
Costs for any other specialised hardware and software, or any other products or services essential to the installation, use or maintenance of the system, should be described and confirmation given as to whether they are included in the quoted price.
5.6.6 Cost Breakdown
The costings must be broken down into the following categories, giving both initial cost and any recurring costs:
• Hardware
• System Software/Middleware
• Application Software
• Licensing costs
• Customisation
• Project Management
• Consultancy
• Implementation
• Maintenance and Support
• Testing.
• Training.
• Any third-party or other product costs.
• Other Costs.
5.6.7 Recurring Costs
Tenderers should separately and clearly identify any recurring costs (such as licences, maintenance etc.) that will occur beyond handover of the system.
5.6.8 Term of Offer
In consideration of receiving the tender documents, the tenderer agrees that the tender shall remain open for acceptance for a minimum of six (6) months from the date of submission.
5.7 Overall Governance Procedures
The Organisation project board has been appointed to manage the project. This board consists of senior business and ICT managers. The proposed lines of contact and liaison must be set out, including escalation procedures.
5.8 Project Management
Details of the Project Management methodology proposed must be provided, giving examples which demonstrate proven competence in this area.
5.9 Project Risks
Tenderers should describe the methodology they use for identifying and managing project risks, giving examples of the successful use of the methodology on previous projects.
5.10 Documentation
Tenderers should include in their response, details of the documentation they will
provide, including the format(s) available, and details of how it is to be kept up-to-date. It should be clearly identified what documentation is included in the pricing.
5.11 Testing
The proposals must include adequate provision for the proper testing at all stages of the project, including unit, integration, public-facing functionality, system and user acceptance testing. The tenderer will have full responsibility for testing the technical and functional aspects of components provided. Organisation testing staff will be involved in conducting system test and will be responsible for user acceptance testing. Representative members of public users of the system may also be involved in user acceptance testing.
Organisation will conduct user acceptance testing at three levels:
1. Public Interfaces.
2. System functionality, including in particular interfaces with other Organisation systems.
3. Performance.
It is envisaged that the user acceptance testing will take a minimum of six months to complete.
5.12 Handover
On termination of the agreed maintenance period if any, it is envisaged that Organisation will take over full responsibility for the maintenance and support of the system. To facilitate this it is essential that the tenderer achieves a meaningful skills transfer during the build and implementation.
The response should identify the minimum level of essential training to achieve successful handover. It must also specify what skills and training are required to operate the system going forward. Details of the tools, competencies and skills required to maintain the system should be provided together with recommended training requirements for each user class and technology specialist area, detailing the provider options, training medium, duration and expected cost of such training. (As specified in 4.7, tenderers should clearly state what training is included in the quoted price).
The response should set out a proposed plan for the handover, and identify any costs, potential difficulties or risks associated with the handover.
5.13 Reference sites
Tenderers should provide details of three reference sites preferably in country where they have completed projects that are similar in scale and nature.
Details should include:
• Organisation.
• Contact.
• Period of contract.
• Outline of solution implemented.
• Tools/Technologies/Methodologies used.
• Volumes of data.
Organisation, at its discretion, may contact or visit reference sites as nominated by the tenderer at any time during the evaluation process. Tenderers are therefore advised to secure referee's consent before using their names.
5.14 Consortia Tendering and Identification of Prime Contractor
If consortia are making proposals, they should appoint a prime contractor, to be agreed with Organisation, who will assume overall responsibility for the signing of the contract, if awarded, and delivery of the project.
5.15 Copyright
This document and its appendices remain the property of Organisation.
5.16 Copies of this document
Notification of this RFT is posted on the following web sites:
List
5.17 Freedom of Information
Organisation undertakes to hold confidential, any information provided in response to this RFT subject to obligations under law. Should the tenderer wish that any of the information supplied in the tender not be disclosed because of its sensitivity, the tenderer must, when providing the information, identify it and specify the reasons for its sensitivity. Organisation will consult with the tenderer about this sensitive information before making a decision on any request that may be received.
If a tenderer considers that none of the information supplied is sensitive, a statement to that effect should be made. Such information may be released in response to a request under the Freedom of Information Act.
Decisions of Organisation in relation to any Freedom of Information request are subject to appeal to the courts by the person who made the request.
Appendix A – Organisation Applications Architecture
Provides relevant background detail of current or desired architecture, framework, model, etc
Appendix B – Layout of Tender – Evaluation Criteria
Basic information
• Name, address and fax number of tenderer(s).
• Name, telephone number and email address of person(s) dealing with tender.
Required Statements
The following statements, as identified in the RFT, are required:
• Statement as at 5.2 on Licensing Policy and Source.
• Statement as at 5.3 on Source Code and Software Ownership, and as at 4.3.5 on re-sale.
• Statement as at 5.5 on Product Development.
• Statement on documentation (Section 5.10).
• Attention is also drawn to Section 5.17 – Freedom of Information.
Mandatory Requirements
All tenders must be formatted in the following way, [describe required format see below or include the use of a response Template for large-scale complex tenders]. Organisation reserves the right to reject any tenders not structured in the way prescribed.
Management Summary
The management summary must contain the following:
• General overview of the proposed [product/services/solution].
• Implementation approach and time-scales.
• System costs.
Functionality
Product Description
Full description of the [products/services/solution] proposed must be provided including detailed specifications of all configured items, (or if described elsewhere, clear references must be given to where the descriptions appear).
Functional Requirements
Tenderers should provide an outline description of their understanding of the requirements.
Tenderers must address the individual requirements on a point-by-point basis. Evidence and proof, and examples, are expected in responses where compliance with a requirement is being claimed. Where compliance with a requirement is dependent on customisation/ configuration, the scale of modification should be clearly indicated.
Tenderers must ensure that the response covers all aspects of the proposed solution and supporting procedures, including:
• Hardware inventory
• Overview of system and software.
• Detailed description of all system functions.
• Detailed description of all required procedures.
• Testing, training and hand-over.
• Any security and recovery procedures proposed.
• System flow charts that clearly describe the action of the system from both the user’s and operator’s perspective.
• Help features and documentation.
• Detailed specification of all configured products]
Capability
Technical Capability
Tenderers should provide evidence of technical ability, including evidence in relation to Section 4.2. The response should include:
• Details of [similar] systems, if any, provided to other administrations.
• Details of any relevant projects implemented in the past three years.
• Details of any relevant bodies or organisations (i.e., Standards bodies, best practice, etc.) to which the tendering company or companies belong or participate in.
• Any other evidence of the tenderer’s technical capacity to deliver this project should also be included.
Company profile
A brief description of the tendering company or companies must be given together with an overview of its product portfolio, customer base, current market focus and strategic direction.
Details of Reference Sites
At least ‘n’ references sites must be provided with all relevant contact details see section 5.13.
Financial details
A financial profile for the last three financial years must be provided to include independently audited certified accounts.
Quality certification
Tenderers and sub-contractors who have obtained formal quality certification should provide details of their certification.
Service and Support
Delivery and Implementation Schedule
FULL DETAILS SET OUT AS REQUESTED IN SECTION 5.4.
Project Management
Full details of Project Management approach, (see Section 5.8), Governance (See Section 5.7) and Project Risks (see Section 5.9) must be provided.
Identification of prime contractor
If proposals are being made by consortia, they must appoint a prime contractor who will assume overall responsibility for the delivery of the system and the signing of the contract (see 5.14), if awarded.
Sub-contracting
An indication of which portion, (if any), of the tender the company may intend to sub-contract is also required.
Vision
Evolution of Service/Solution
An indication of how your [product/service/solution] might evolve over time to support Organisation as demanded by its business strategy and change plans.
Roadmap
What are the key milestones for your proposed implementation and what will be the key determinants of how these will be achieved.
Costs
Cost Breakdown
Provide full details set out as requested in Section 5.6.
Total Cost of Ownership Estimate
Provide a detailed TCO analysis for you’re proposed solution giving a price [per seat/per processor/per transaction].
Appendix C: [See individual summary sheets]
Appendix D: Glossary