ITsourcing

RFP Example Section 5.9 - 5.13

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.

RFP Example Section 5.6 - 5.8

Example pro forma material:

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.

RFP Example Section 5.3 - 5.5

This is pro forma sections for an example RFP:

5.3 Ownership

The tenderer must clearly indicate the ownership of all source code, including procedural source code, and must indicate whether the source code will be provided to Organisation and any conditions that will apply. 

Where bespoke software is written specifically for, and paid for by Organisation, sole ownership of such software will reside with Organisation.  All quoted costs will be assumed to be on this basis unless explicitly stated otherwise.

5.4 Delivery and Implementation Schedule

Full details of the proposed time scale for [delivery]/[implementation] must be provided including earliest start date, and what phasing options are available.  It should be noted that Organisation is committed to timely live implementation of the new system currently scheduled for Date11.  A delivery schedule should be provided confirming the achievement of this deadline, including;

• Delivery schedule of software.
• Installation of Software (indicating who is responsible for installation).
• Customisation.
• Testing.
• Training and handover.

5.5 Product Development

Clear statements as regards product development must be included in the response, including development plans for the product in the short and long term, with particular reference to the developer’s commitment to keeping the product(s) current with advances in technology and legislation.

RFP Example Section 5.0-5.2

This is an example section from a pro forma RFP:

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.

Ian Richmond

Email: 'About' and 'Email Me' link