B.1 BASE YEAR
Contract Line Item No. (CLIN) given in table below refers to the RFP document where sufficient details for each requirement and its context can be found. Vendor shall review the RFP document in its entirety to understand each requirement and provide Total Price against each CLIN listed in table below. In case Vendor believes there is any other cost component which has not been captured in table below but which could affect the total cost of this project or any of its deliverables then Vendor must bring it to Customer’s attention.
Serial No.
Contract Line Item No. (CLIN)
Item Description Total Price
1 B.2.2 Manage Grants Program
2 B.2.3 Manage Investment Justification Category (IJC) 3 B.2.4 Manage Project Concept
4 B.2.5 Manage Project Plan (MPP)
5 B.2.6 Manage Quarterly Status Report (QSR) 6 B.2.7 Manage Reimbursement Requests 7 B.2.8 Manage Project Finance Restraints 8 B.2.9 Manage Authorized Expense Items (AEI) 9 C.1.1 Manage Dynamic Views
10 C.1.1.1 Create View 11 C.1.1.2 Create Search View 12 C.1.1.3 Update View 13 C.1.1.4 Authorize View Access 14 C.1.1.5 Click through Hyperlinks 15 C.1.1.6 Select Data 16 C.1.1.7 Import Data 17 C.1.1.8 Export Data 18 C.1.1.9 Filter 19 C.1.1.10 Sort 20 C.1.1.11 Group 21 C.1.1.12 Print 22 C.1.2 Manage Database 23 C.1.3 Manage Groups 24 C.1.4 Manage Roles 25 C.1.5 Manage Users 26 C.1.6 Manage Dashboard
27 C.1.7 Application GUI and Content Management 28 C.1.7.1 Manage Application Logic Formulas 29 C.1.7.2 Manage Text on Application Home Page 30 C.1.7.3 Manage Look and Feel
31 C.1.7.4 Manage Template 32 C.1.7.5 Manage Template Attributes 33 D.1 Electronic Signature 34 E.1 Email Notification System 35 E.1.1 Manage Email Notifications 36 E.1.2 Email Notification Log
37 F.1 Data Migration
38 G.1 Business Process Workflows 39 I.1 Support and Maintenance
40 I.1.1 Application and System Support – Help Desk 41 I.1.3 Application Documentation
42 I.1.4 User Training
43 J.8 Data and Database Security Management
Grand Total for B.1 $_______
M.2 TECHNICAL RATING
M.2.1 The Technical Rating Scale is as follows:
Numeric Rating Adjective Description
0 Unacceptable Fails to meet minimum
requirements; e.g., no
demonstrated capacity, major deficiencies which are not correctable; offeror did not address the factor.
1 Poor Marginally meets minimum
requirements; major deficiencies which may be correctable.
2 Minimally Acceptable
Marginally meets minimum requirements; minor deficiencies which may be correctable.
3 Acceptable Meets requirements; no
deficiencies.
4 Good Meets requirements and exceeds
some requirements; no deficiencies.
5 Excellent Exceeds most, if not all
requirements; no deficiencies.
M.2.2 The technical rating is a weighting mechanism that will be applied to the point value for each evaluation factor to determine the offeror’s score for each factor. The offeror’s total technical score will be determined by adding the offeror’s score in each evaluation factor. For example, if an evaluation factor has a point value range of zero (0) to forty (40) points, using the Technical Rating Scale above, if the District evaluates the offeror’s response as “Good,” then the score for that evaluation factor is 4/5 of 40 or 32.
If subfactors are applied, the offeror’s total technical score will be determined by adding the offeror’s score for each subfactor. For example, if an evaluation factor has a point value range of zero (0) to forty (40) points, with two subfactors of twenty (20) points each, using the Technical Rating Scale above, if the District evaluates the offeror’s response as “Good” for the first subfactor and “Poor” for the second subfactor, then the total score for that evaluation factor is 4/5 of 20 or 16 for the first subfactor plus 1/5 of 20 or 4 for the second subfactor, for a total of 20 for the entire factor.
M.3 EVALUATION CRITERIA
Proposals will be evaluated based on the following evaluation factors in the manner described below.
Based on Vendor’s response:
1. Each Vendor will receive ‘Vendor’s Technical Score’ points for each ‘EVALUATION CRITERIA’ as per Technical Rating Scale table given in Section M.2.1 of this document.
2. Technical Score achieved by Vendor will be multiplied by corresponding ‘WEIGHT’ given in table below to calculate ‘Vendor’s Weighted Score’ for subject ‘EVALUATION CRITERIA’.
3. Total of ‘Vendor’s Weighted Score’ will be used to calculate ‘Average Weighted Score’ for the Vendor.
Sl. No.
EVALUATION CRITERIA WEIGHT Vendor's
Score
Vendor's Weighted Score
1 Functional Requirements 5 0
2 Business Process Workflows 5 0
3 Data / Table Driven Business Rules 5 0
4 Configurable Business Logic 5 0
5 Search Capabilities 5 0
6 Reporting Capabilities 5 0
7 Data Import / Export Capabilities 5 0
8 Configurable GUI / Views 5 0
9 Permissions Based Data Access 5 0
10 Administrative Capabilities 5 0
11 Functionally Flexible / Expandable 5 0
12 Secure 4 0
13 Reliable 5 0
14 Open Source Technologies 4 0
15 Scalable 3 0
16 Data Migration Capabilities 5 0
17 Rollout Timeline / Modules already available to deploy 7 0 18 Experience with similar systems and Customer
Satisfaction
5 0
19 Execution Team, Development and Delivery Model 5 0
20 SLA, Maintenance and Support Model 4 0
21 Company Strength 3 0
Total 100 0 0
Given below is a brief high level description of some of the evaluation criteria listed above. Since most of these are generic IT terms their complete intent must be interpreted as what is widely understood in the IT industry. Statements herein are for general very high level guidance only.
1 Functional Requirements: Functional Requirements for the system as listed in CGMS SOW document.
2 Business Process Workflows: Business Process Workflows listed in CGMS SOW document and any other that may be provided by customer as part of the RFP process.
3 Data / Table Driven Business Rules: Business rules which can be changed dynamically using data in database tables.
4 Configurable Business Logic: Business Logic which can be configured at run time in production without having any adverse or intended impact.
5 Search Capabilities: Techniques, methods and options available in system to perform quality/meaningful search on any data within the system.
6 Reporting Capabilities: Techniques, methods and options available in system to produce quality/meaningful reports on any data within the system.
7 Data Import / Export Capabilities: Techniques, methods and options available in system to produce import/export any data into/from the system.
8 Configurable GUI / Views: Graphical User Interface which can be easily configured as per changing needs for different roles/users in the system.
9 Permissions Based Data Access: Access to data in system is restricted based on access level granted.
10 Administrative Capabilities: Administrative functions and capabilities available in the system to manage it without requiring any code changes or redeployments. 11 Functionally Flexible / Expandable: Ability to add new functionalities or
expand existing functionalities easily in the system.
12 Secure: System’s ability to protect property and information from unauthorized access, theft, corruption, or natural disaster, while allowing the information and property to remain accessible and productive to its intended users.
13 Reliable: As defined with examples in CGMS SOW Section K.1.4 ‘Reliable’ 14 Open Source Technologies: Technologies used in the system for which their
source code is available for free sharing and potential future enhancements and usage.
15 Scalable: Ability of system, network, or process, to handle growing amounts of work in a graceful manner or its ability to be enlarged to accommodate that growth.
16 Data Migration Capabilities: Ability of vendor to perform data migration from existing system/s to the new system without loss of any data or data quality.
17 Rollout Timeline / Modules already available to deploy: Ability of vendor to deploy system with various functionalities as stated in the requirements within a specific timeframe as per configurations sought by customer.
18 Experience with similar systems and Customer Satisfaction: Vendor’s experience with similar systems in the recent past and its approval rating from its customers and users.
19 Execution Team, Development and Delivery Model: Quality of vendor’s team and execution strategy which will be working on this system to develop, customize, support and deliver it.
20 SLA, Maintenance and Support Model: Quality and reliability of vendor’s SLA Terms and Conditions (how close or better they are than those provided in requirements document), quality of its Maintenance and Support team and their execution strategy for the system.
21 Company Strength: Vendor’s experience and strength in the domain specific to the kind of requirements sought by customer, it’s financial strength and stake in this kind of market to have strategic interest in supporting customers over several years from now.
Cost To Value Criterion
Cost to Value will be determined using below formula:
Cost to Value of Evaluated Proposal = (Lowest Proposal Price / Evaluated Proposal Price) x Weighted Score of Evaluated Proposal