Supplement 1: Salesforce Platform Managed Service
Supplement 2
Enterprise and Agency Salesforce Projects & Enhancements
Multi-Award Opportunity
Table of Contents
1.0 Enterprise and Agency Salesforce Major Projects & Enhancements 3
1.1. Background and Overview 3
1.2. Conceptual Organization of Requirements and Scope of this Supplement 3
1.3. Use of as a Development and Business Platform for Selected State Enterprise and Agency Applications 3
1.4. State and Contractor Project Team Organization 4
2.0 Offeror Demonstration of Capabilities, Experience and Personnel 6
2.1. Offeror Capabilities and Salesforce Experience (as a Firm) 6
2.2. Offeror Example Personnel Resumes (Available for State Work) and Capability 6
2.3. Offeror-Specific Salesforce Methods, Tools and Development Accelerators 7
2.4. Enterprise Integration (ESB) Based Experience/Expertise 7
2.5. Offeror Case Studies (up to 3) Designed to Showcase Offeror Salesforce Capabilities and Eminence 8
2.6. Other Pertinent Offeror Details (optional) 8
3.0 Mandatory Project Requirements – Applies to Any Work Arising from this Supplement 9
3.1. Project Management Responsibilities 9
3.2. Document Convention: Deliverable Identification 9
3.3. Create and Maintain Project Plan 9
3.4. Meeting Attendance and Reporting Requirements. 10
3.5. Develop, Submit, and Update Detailed Activity Plans. 11
3.6. Utilize OIT’s Document Sharing/Collaboration Capability 11
3.7. Project Management Methodology, State Minimum Standards 12
3.8. Software Development Design Phase Deliverables and Responsibilities 13
3.9. Software Development Build Phase Deliverables and Responsibilities 13
3.10. Software Development Testing Phase Requirements and Deliverables 15
3.11. Software Development: Retirement of Legacy Functionality and Data Migration, Decommissioning 16
3.12. System and Acceptance Testing Requirements 18
3.13. Performance and Reliability Testing Requirements 18
3.14. Support the State’s Performance of User Acceptance Test (UAT) 19
3.15. Pre-Production / Production Deployment Phase 19
4.0 Contracting Methods and Standards 20
4.1. Future Project Services Objectives 20
4.2. Future Salesforce Projects and Deployments: Contractor Support Requirements 21
4.3. Development Life Cycle Proposals associated with Development and Enhancement Projects 21
4.4. Future Project Services Pricing Response and Rate Card 21
4.5. Submission and Acceptance of the Proposed Contractor Offer and Statement of Work associated with a Future Project 22
4.6. Design, Configuration and Implementation Responsibilities 22
4.7. Guiding Principles and Requirements: Configuration and Customization of Salesforce Objects 23
4.8. Change Management/Communications and User Training (Minimum Requirements) 24
4.9. Project Completion Activities and Final Documentation 25
4.10. Salesforce Data Archive and Purge 26
4.11. Non-Production Environment Data Masking 27
4.12. Monitoring Enhancements, Evolutions and Updates to the State’s Salesforce Platform: Information Sharing 28
4.13. Project Delivery Environments and Production System Technical Requirements 28
4.14. Cooperation with State and State Contractors 30
4.15. Project Review Check Point 30
5.0 Offeror Assumptions and Other Considerations 31
5.1. Assumptions 31
5.2. Pre-Existing Materials 31
5.3. Commercial Materials 31
6.0 Project Performance Measures and Service Levels 32
6.1. Service Level Specific Performance Credits 32
6.2. Monthly Service Level Report 32
6.3. Service Level Commitments – Project Implementation Services 33
6.4. Defect Resolution – Mean Time to Repair/Resolve (Severity 1 Items) 34
6.5. Defect Resolution – Mean Time to Repair/Resolve (Severity 2 Items) 35
6.6. Defect Resolution – Mean Time to Repair/Resolve (Severity 3 Items) 36
6.7. Service Levels – System Test Execution Exit Quality Rate 37
6.8. Blocking Issues – Identification and Removal 38
6.9. Regression Testing Performance – Issue Find/Fix Rate 39
6.10. Service Levels – Project Performance, Milestone Attainment 40
6.11. Deliverable Acceptance 41
6.12. Service Levels – Development Methodology Compliance 42
6.13. Service Levels – Phase Completion – Issues Detected and Resolved in Production 43
1. Enterprise and Agency Salesforce Projects & Enhancements
Offeror Note: This Section is repeated in its entirety from Supplement 1 for purposes of Offeror understanding and relationship to the overall Goals and Strategy of the State on this opportunity. The Scope of this RFP is to seek to qualify additional Salesforce Project firms under Supplement 2 of RFP 0A1194 as originally released. Supplement 1 of the original issuance of 0A1194 contained requirements for Supplement 1, which in general was designed to obtain a managed service vendor for the State’s enterprise Salesforce platform which was awarded in July of 2017 and not scheduled for renewal at this time. The State, via this reissue of RFP 0A1194 does not seek, nor will accept, responses pertaining to Supplement 1. Supplement 1 references in this solicitation are for informational purposes only.
1. Background and Overview
The Department of Administrative Services (DAS), Office of Information Technology (OIT), is charged with the design, deployment, operation and maintenance of critical Enterprise Services that include the provision, operation, support and ongoing evolutions to Enterprise and Agency-specific systems that operate utilizing the platform and ancillary Salesforce AppExchange Applications, developed extensions and Enterprise integrations via an enterprise service bus (ESB) and file-based methods.
The State has developed and deployed a variety of public-facing and State internal use applications using the Salesforce platform and has recently commissioned a variety of development projects that are anticipated to go-live in the Fiscal Year 17-18 period as well as continued interest by State Agencies in migration of legacy applications to modern Software-as-a-Service and Platform-as-a-Service architectures for the foreseeable future.
This Supplement is to establish a pool of pre-qualified Contractors that are capable of performing Projects and Enhancements to both existing and new Salesforce-based Applications for the State.
In addition, this Supplement includes provisions for development of enhancements, evolutions and optimizations to these State applications deployed on top of the Salesforce platform.
State developed applications use a variety of similar architectural principles and common services, but each have their own unique collection of implementation-specific considerations (e.g., AppExchange elements, extensions, integration methods etc) that must be factored by Offerors in their development of Proposals to this Supplement.
2. Conceptual Organization of Requirements and Scope of this Supplement
This Supplement is designed to identify, via a competitive process as outlined in the RFP documents a pre-qualified pool of qualified Salesforce development firms. Offerors proposing responses to this Supplement are encouraged to review the following conceptual organization of requirements pertaining to the scope of this Supplement:
Conceptual Organization of Requirements and Scope of this Supplement
[pic]
3. Use of as a Development and Business Platform for Selected State Enterprise and Agency Applications
The State has successfully deployed a number of applications to the Public (citizens, businesses and workers) throughout a number of State Agencies that (in general) have similar core attributes including: time to market, ease of deployment, enablement of State workers, financial and regulatory compliance, cost of ownership and other factors. Based on these successes utilizing the platform, AppExchange applications and extensions, the State has determined that the use of the Salesforce platform is a prudent strategy to serve at the core of the State Enterprise and Agency application development due to the State’s strategy to:
▪ Adopt an Enterprise Approach – including a structured and repeatable development methodology, framework, and solution for implementing Customer Relationship Management, Filing, Reporting, Compliance and Payment processing functions at their core is based on an enterprise-approach on a modern, cloud-based configurable platform.
▪ Reduce Reliance of Programming Oriented Skillsets and Tools – developing applications to a more “configuration driven” and “modular” approach that allows OIT, and Agencies, to more efficiently design and deploy new Agency Applications, Services and Business Transactions while migrating from the legacy application set and programming languages to a more robust and integrated development paradigm that is commonly available in the marketplace.
▪ Enablement of State IT Professionals – Enabling State self-reliance through the use of a cloud platform is fundamental to the State’s evolution to retiring legacy applications across all Agencies through the creation of centers of excellence/interest and enablement of State IT professionals with modern methodologies such as Agile including processes, and tools to become more effective in conceiving, designing and implementing systems across the State.
▪ Utilize of Existing Investments, Standards and Conventions – Part of the State’s evolution is to put more reliance upon including pre-existing licenses and cloud agreements, governance structures and standards, methods and conventions to help drive consistency, long-term success and a skill evolution opportunity for State IT professionals;
▪ Drive Incremental Delivery, Value and Risk Management over the Duration of any Project – through following an iterative, Agile-based approach that helps accelerate time to market, agility in responding to new or changing requirements, addressing the needs of State and Agency customers in a controllable fashion as opposed to traditional “waterfall” implementation methods that generally don’t align with the needs of the State stakeholder community.
▪ Use Salesforce Platform, Accelerators, Enablers, Middleware – rather than developing “from the ground up” or adapting generalized development frameworks and tools, the State has determined that a significant portion of the requirements could be realized through out-of-the-box Salesforce, utilizing extensions through AppExchange providers, use of existing State integration service bus and limiting development to truly “State specific” functions around a common set of conventions and standards will not only help simplify any projects, but yield dividends in adding future Agencies and Services on Salesforce as well as reducing the overall operations and maintenance total cost of operations.
4. State and Contractor Project Team Organization
Work contained within this Supplement will (at the State’s discretion) be performed for Enterprise Projects within the DAS/OIT Enterprise Applications Group or in collaboration with State Agencies. For Agency projects arising from this Supplement, Agencies may implement their own Project development and teaming arrangements with Contractors as applicable based on the needs of the Agency. For any project that will be deployed on the State’s Enterprise Salesforce platform, the requirements of Sections 3.0, 4.0, and 6.0 of this Supplement, in their entirety, shall apply.
Conceptual State Team Organization
[pic]
2. Offeror Demonstration of Capabilities, Experience and Personnel
Offerors, as part of their response to this RFP are required to provide responses to each of the following Sections of this Supplement as to demonstrate and highlight: the capabilities of its firm; its personnel; and Salesforce methods, tools and accelerators.
Importantly, Offerors are to provide the State up to three (3) brief case studies that illustrate the experience and expertise of the firm in providing Salesforce-based Project development and implementation expertise to be applied to State projects that are based upon the Salesforce platform, AppExchange and 3rd party applications as well as development of Salesforce RICEFW elements. In formulation of proposals to this Supplement, Offerors are encouraged to review the Evaluation Criteria included in the RFP Documents that are pertinent to this Supplement.
1. Offeror Capabilities and Salesforce Experience (as a Firm)
The State encourages Offerors to provide brief overviews of their capabilities, core competencies, and market differentiators in the following areas:
▪ Salesforce Relationships, Alliances or Awards that demonstrate a commitment to Salesforce and a long-standing track record of successful deliveries and customer experiences;
▪ Access to Best Practices that the Offeror has developed with customers that result in rapid, high quality and low cost development of Salesforce applications and extensions while mitigating needs to customize the system;
▪ Commitment to Scalable, Upgradeable Solutions to ensure the State has access to current features/functionality and can pursue migrations and new service implementation in a timely and cost effective manner;
▪ Commitment to Minimize Customization and maximize the value provided by the standard off-the-shelf Salesforce modules, given the various requirements of the State;
▪ Salesforce Center of Excellence or “laboratory” type of environment where best practices and methodologies are designed and refined in the context of new Salesforce capabilities, releases, versions or modules;
▪ Development of long-term partnerships working with public sector and government entities, establishing mutually beneficial, long term relationships.
▪ Additional Salesforce module implementation services; and
▪ Related Salesforce application configuration, deployment and management services that may include reporting databases, performance tuning and management, operational/ongoing cost reduction projects, end-user rollout/training and other Salesforce related activities.
2. Offeror Example Personnel Resumes (Available for State Work) and Capability
The State acknowledges that the actual work to be performed and the team members required is highly situational, such as any remediation services required by the State. However, the State seeks to understand the Offeror’s capabilities and knowledge, skills and experience of potential team members and by extension the capabilities of the firm in performing the work.
The Offeror’s proposal must identify such Project Personnel who may provide services as part of the resulting Contract. Sample resumes for the candidates should align with the work requirements contained in this RFP and clearly demonstrate the Offeror’s capabilities and experience. Representative resumes are not preferred. The resumes will be used to supplement the descriptive narrative provided by the Offeror regarding their proposed project team.
The resume (2-page limit per resume) of the sample Project Personnel should include:
▪ Proposed Candidate’s Name
▪ Proposed role on similar Salesforce-based Projects
▪ Listings of competed projects (a minimum of two references for each resume) that are comparable to the Work or required similar skills based on the person’s assigned role/responsibility on similar Projects. Each project listed should include at a minimum the beginning and ending dates, client/company name for which the work was performed, project description, and a detailed description of the person’s role/responsibility on the project.
▪ Education
▪ Professional Licenses/Certifications/Memberships
▪ Relationship to the Offeror Firm (e.g., Employee, Contractor, Sub-Contractor)
▪ Salesforce Certifications and Project Experience
▪ Relevant Employment History (as applicable to the proposed role(s) in Salesforce Projects)
In addition, Offerors are required to present their Salesforce and Related Services (e.g., data conversion, integration, testing, RICEFW development etc) capabilities as a firm as to:
▪ Demonstrate the full-spectrum of Salesforce (and related) development expertise; and
▪ Demonstrate the capability to either perform multiple projects and serve the full needs of the State in consideration of development of new capabilities leveraging Salesforce as a development platform; or replace State legacy applications with modern, Salesforce-based solutions that are easier for the State to develop and operate as well as more cost effective and efficient.
3. Offeror-Specific Salesforce Methods, Tools and Development Accelerators
The State encourages Offerors to provide brief overviews of their capabilities, core competencies, and market differentiators in the following areas:
▪ Innovative Practices and Development Methodologies provided by the Offeror that are market proven and help drive successful migrations, implementations and enhancements while mitigating Project risk wherever possible;
▪ Rapid Implementation and Quality Methodologies designed to help ensure that migrations and implementations go as quickly as possible, are reviewed at each major step against quality requirements, and result in minimal business interruptions, auditable performance, and a lasting operational capability that the State can build on; and
▪ Offeror-specific Development Accelerators inclusive of pre-built templates, project delivery/execution frameworks, SDLC aids, version control tools, requirements traceability, automated testing; defect management/resolution and other elements that are designed to deliver rapid, high-quality Software development projects utilizing the Salesforce platform.
4. Enterprise Integration (ESB) Based Experience/Expertise
State Enterprise Service Bus (ESB) – Agency systems and systems architectures have been built over the years with a variety of middleware or service bus architectures. For purposes of any Agency project and general Enterprise use across the State, Offerors shall base their proposals on the assumption that use of the State’s ESB to perform SOA functions, Web Services (in general) as well as required Agency integrations to the extent possible.
Oracle Enterprise Bus® is the service bus architecture standard for the State for this project. Any proposed application that requires interoperability and integration to the Enterprise platform are the required unifying technologies for any project.
Offerors are to note that many Agencies over the years have developed their core systems utilizing a variety of ESB and file-based integration methods and (in general) products from Oracle, IBM and other middleware vendors exist in the State’s application portfolio. Further, the State utilizes MuleSoft ESB within the Salesforce platform for the eLicensing application.
The State encourages Offerors to provide brief overviews of their capabilities, core competencies, and market differentiators in the following areas:
▪ Oracle-specific integration capabilities inclusive of: utilizing “off-the-shelf” commercial software adapters;
▪ Custom SOA/Web-Service based integration methods;
▪ Cross ESB integrations and ESB managed file transfers; and
▪ ESB migration to an Enterprise Standard (in the State’s case: Oracle).
5. Offeror Case Studies (up to 3) Designed to Showcase Offeror Salesforce Capabilities and Eminence
The State encourages Offerors to provide up to three (3) brief Case Studies of their capabilities, experience, core competencies, and market differentiators in the following areas:
▪ Customer Information (e.g., Customer Name, reference information, dates of Service)
▪ Customer Business Problem & Objectives
▪ Offeror Role(s) in the Project (in as descriptive terms as possible)
▪ Team Size
▪ Development Approach, Methodology and Tools
▪ Customer Realized Outcomes (inclusive of return on investment, business outcome, revenue driven, costs avoided, system(s) developed/retired)
▪ Public/Internal User Counts, Transaction Volumes/Volumetric information (estimates are acceptable)
▪ Customer Business Processes (e.g., procure-to-pay, customer relationship management) covered by Solution
▪ Representative Static Demonstration (if available) inclusive of Screen Captures, Narrative, Processing Highlights and other information as to convey the scope, quality, sophistication and overall merits of the developed Salesforce-based solution;
▪ Major Integrations and Integration Methods (e.g., Salesforce to Customer ERP, Payment Gateway, CRM etc)
▪ Significant Customer Testimonials that highlight the strength of partnership between the Offeror and their customers that have resulted in achieving the strategic goals of your customers, specifically with respect to large government or corporate entities
▪ Industry/3rd Party Awards and Citations (if applicable)
6. Other Pertinent Offeror Details (optional)
The State encourages Offerors to provide any additional information that highlights to the State their capabilities, core competencies, and market differentiators not otherwise addressed in this Section.
3. Mandatory Project Requirements – Applies to Any Work Arising from this Supplement
1. Project Management Responsibilities
For any work arising from this Supplement, the Contractor will have responsibility to provide overall project management.
The Contractor will:
▪ Be responsible for overall Project completion;
▪ Maintain the overall Project Workplan;
▪ Ensure deliverables have a detailed project sub plan as required by the State to ensure timely delivery and appropriate quality;
▪ Ensure that all efforts have an effective version control mechanism for all documents within the project document library that will be maintained on a State provided Microsoft SharePoint site;
▪ Ensure that an appropriate “Project Kickoff” occurs and that all integrated work plans are agreed to by the State from project commencement;
▪ Complete status reporting adhering to the PMO policies;
▪ Work with the State leadership to ensure that the Project is staffed appropriately;
▪ Ensure that required testing activities across both technical and operational components are completed to minimize Project risk; and
▪ Collaborate with the task areas to ensure appropriate cross-team communication and delivery.
2. Document Convention: Deliverable Identification
All items in this Supplement that are marked with the term Deliverable and numbered sequentially (e.g., 000) shall be considered formal deliverables and be subject to the State’s deliverable acceptance process described in Attachment 4 of this RFP. Offerors to note that this numbering is sequential as the deliverables appear in the text of this Supplement and may be reordered based on the actual work that is mutually agreed by the State and Contractor under a State Authorized Statement of Work.
3. Create and Maintain Project Plan
The Contractor must produce a detailed Project Plan, in electronic and paper form, to the Project Representative for approval within twenty business days after the State issues a purchase order or other written payment obligation under the Contract. The Contractor must lead a planning session which ensures the following:
▪ A common understanding of the work plan has been established;
▪ A common vision of all deliverables has been established;
▪ Contains a critical path that identifies all major milestones, dependences (both internal and external to the project), resources by name and resource assignments and is complete and inclusive of the entire work effort from commencement until conclusion of all contracted activities;
▪ Clarity on scope of overall project and the responsibilities of the Contractor has been defined and agreed to by the State.
Thereafter, the Contractor must:
▪ Formally update the Project Plan, including work breakdown structure and schedule, and provide the updated Project plan as part of its reporting requirements during the Project; and
▪ Ensure the Project Plan allows adequate time and process for the development for the State’s review, commentary, and approval. The State will determine the number of business days it needs for such reviews and provide that information to the Contractor after award and early in the development of the Project Plan. Should the State reject the plan or associated deliverables, the Contractor must correct all deficiencies and resubmit it for the State’s review and approval until the State accepts the Deliverable at no additional cost to the State.
4. Meeting Attendance and Reporting Requirements.
The Contractor’s project management approach must adhere to the following meeting and reporting requirements:
▪ Immediate Reporting - The Project Manager or a designee must immediately report any Project staffing changes to the State Project Representative.
▪ Attend Weekly Status Meetings - The State and Contractor Project Managers and other Project team members must attend weekly status meetings with the Project Representative and other members of the Project teams deemed necessary to discuss Project issues. These weekly meetings must follow an agreed upon agenda and allow the Contractor and the State to discuss any issues that concern them.
▪ Provide Weekly Status Reports - The Contractor must provide written status reports to the Project Representative at least one full business day before each weekly status meeting.
▪ At a minimum, weekly status reports must contain the items identified below:
← Updated GANTT chart, along with a copy of the corresponding Project Plan files (i.e. MS Project) on electronic media acceptable to the State;
← Status of currently planned tasks, specifically identifying tasks not on schedule and a resolution plan to return to the planned schedule;
← Issues encountered, proposed resolutions, and actual resolutions;
← The results of any tests;
← A Problem Tracking Report must be attached;
← Anticipated tasks to be completed in the next week;
← Task and Deliverable status, with percentage of completion and time ahead or behind schedule for tasks and milestones;
← Proposed changes to the Project work breakdown structure and Project schedule, if any;
← Identification of Contractor staff assigned to specific activities;
← Planned absence of Contractor staff and the expected return date;
← Modification of any known staffing changes; and
← System integration/interface activities.
▪ The Contractor's proposed format and level of detail for the status report is subject to the State’s approval.
▪ Prepare Monthly Status Reports – During the Project, the Contractor must submit a written monthly status report to the Project Representative by the fifth business day following the end of each month. At a minimum, monthly status reports must contain the following:
← A description of the overall completion status of the Project in terms of the approved Project Plan (schedule and cost, if applicable);
← Updated Project work breakdown structure and Project schedule;
← The plans for activities scheduled for the next month;
← The status of all Deliverables, with percentage of completion;
← Time ahead or behind schedule for applicable tasks;
← A risk analysis of actual and perceived problems;
← Testing status and test results; and
← Strategic changes to the Project Plan, if any.
5. Develop, Submit, and Update Detailed Activity Plans.
As part of the Project and no later than twenty business days following the commencement of the effort, the Contractor must develop a Project Management Plan (Project Plan). The Contractor also must update the plans with more detail throughout subsequent Project phases coincident with Project Status reports or upon reasonable request of the State Project Manager to address, at a minimum, the following subjects:
1. Project Plan
including (at a minimum):
← Project Integration;
← Project Scope;
← Project Time;
← Project Quality;
← Project Staffing;
← Project Communications;
← Project Risks/Issues; and
← Project Procurement elements (if required).
The Offeror must develop these plans from information that the State’s Project personnel provide. These State personnel have varying percentages of time to devote to this Project, and the Offeror must consider (and specify) time commitment expectations to the Project in creating the Project schedule and when obtaining information from State staff to create the above plans.
6. Utilize OIT’s Document Sharing/Collaboration Capability
In conjunction with the delivery of any Project, coincident with the start of the project through its conclusion, the Contractor must use the State provided and hosted document management and team collaboration capability (Microsoft® SharePoint™) to provide access through internal state networks and secure external connections to all project team members, approved project stakeholders and participants. In conjunction with the utilization of this tool, the Contractor must:
▪ Structure the document management and collaboration pages and data structures in such a manner as to support the overall requirements of the Project;
▪ Be responsible for the maintenance and general upkeep of the designer configurations of the tool in keeping with commercially reasonable considerations and industry best practices as to not adversely impact the project delivery efforts performed by the Contractor and State; and
▪ At the conclusion of the project, or upon request of the State, ensure that the State is provided a machine readable and comprehensive backup of the SharePoint™ database(s) contained within the tool that is owned by the State and not proprietary to the Contractor or otherwise required by the State to maintain ongoing project documentation and artifacts (i.e., Contractor is to remove all Contractor proprietary or non-State owned or licensed materials from the tool).
7. Project Management Methodology, State Minimum Standards
The State maintains a project management and reporting methodology that is used at varying levels for complex, transformational Information Technology projects. This methodology is designed to provide a substantive and objective framework for the reporting and review of projects to impacted stakeholders and, should the need arise, identify the need for corrective action for one or many of the participants in a project (e.g., State, Contractor, Customer, Stakeholder).
The State acknowledges that various contractors that may do business with the State may maintain unique or proprietary project management methodologies, but seeks to ensure that the overall project is delivered to the State as contracted. Therefore, a minimum standard project management reporting standard has been created to serve the State’s project management and oversight needs while not adversely impacting or influencing Contractor provided delivery methodologies. The State accepts traditional “waterfall” and Agile-based as well as hybridized variations such as conference-room pilots, iterative-prototyping, Agile development within Phased Releases and the like and will work with Contractors to identify the most appropriate development methodology in consideration of the work. Regardless of the final, mutually agreed methodology, Contractors must adhere to and provide all contracted delivery artifacts that effectively segment, control and memorialize the work in the form of contracted responsibilities, activities, milestones, and deliverables within their proposed methodology.
The Contractor must provide a summary Project Plan as requested by the State. For purposes of a summary project plan specific phase and gate dates, effort and costs are a sufficient minimum.
Following the award of this Contract, and during the project mobilization phase Contractors must include all contracted activities, deliverables and milestones within their detailed project plans and methodologies at a minimum upon commencement of the project:
State Development Methodology, Minimum Activities, Work Products, Deliverables and Milestones
|1. Project Set-Up ( |2. Requirements Confirmation and Project Management|3. Design Phase Elements (System and Process) ( |
| |( | |
|Establish Steering Committee/Oversight |Create/Maintain Refined Project Plan |Follow/Track Final Project Plan |
|Create Summary Plan |Establish Implementation Strategy |Establish Final Cost & Time Estimate |
|Establish Key Milestones |Assess Internal/External Project Dependencies |Outline Phase/Release Schedule |
|Establish Key Deliverables |Assess Internal/External Risks |Create Detailed Design Documents - Functional |
|Establish High Level Project Plan |Create Detailed Project Plan |Create Detailed Design Documents - Technical |
|Create Cost/Time Analysis (Budget) |Create Stakeholder/Customer Communications Plan |Establish Performance Requirements |
|Establish High Level Dependencies |Create Detailed Resource Plan |Establish Support Requirements |
|Create High Level Project Schedule |Establish Level 0 System Design |Establish Operating Requirements |
|Establish Scope/Statement of Work & Methodology |Model End-User Characteristics |Obtain System Application Software, Tools |
| |Determine Existing Process Change Model |Create Process Flows with Key Inputs/Outputs |
| |Identify New/Enhanced Business Processes |Create Interface Control Documents |
| |Finalize Implementation Strategy |Create Conversion/Migration Plan |
| |Analyze Impact to Enterprise Architecture/Data |Create Integration Plan |
| |Model |Develop Stakeholder Communications Materials |
| |Develop Deployment Strategy |Establish Technical Requirements |
| |Finalize Development Tools and Production |Create Solution System Architecture Documents |
| |Requirements |Update Enterprise Architecture Documents |
| |Validate Customer Adoption Assumptions |Create System(s) Sizing Requirements |
| |Establish SDLC Environments |Establish Test Plan |
| | |Brief/Update User Stakeholders/Customers |
|4. Development Phase Elements |5. System, Process & Acceptance Testing ( |6. Production and Operational Readiness ( |
|(Systems and Process) ( | | |
|Follow/Track Final Project Plan |Develop/Execute Overall Test Plan |Perform User Training/Change Management |
|Establish Final Cost & Time Estimate |Establish Final Processes |Document/Publish Final Policies & Procedures |
|Outline Next Phase Schedule |Establish Q/A Metrics |Publish Final Procedures |
|Create Detailed Design Documents - Process |Develop UAT Plan, Scripts and Cases |Create System Technical Documentation |
|Create Detailed Design Documents - Functional |Complete Final Sizing Analysis |Publish Version / Release Document |
|Create Detailed Design Documents - Technical |Establish Operational Performance Baseline |Develop Training Scripts |
|Establish Performance Requirements |Publish Committed Capacity Plan |Develop Training Guide |
|Establish Operating Requirements |Prepare Component Test Analysis Report |Create Operational Documents |
|Finalize Process Flows with Key Inputs/Outputs |Develop Training Materials |Create User Job Aids |
|Finalize Interface Control Documents |Execute Component Test |Update User Stakeholders / Communications |
|Finalize Conversion/Migration Plan |Collect Performance Metrics |Update Job Schedules and Dependencies |
|Create Integration Plan |Create Component Technical Documentation | |
|Develop Stakeholder Communications Materials |Perform User Acceptance Test | |
|Create Solution System Architecture Documents |Document/Prioritize/Publish Issue/Bug List | |
|Update Enterprise Architecture Documents |Remediate Launch Critical Issues/Bugs | |
|Create System(s) Sizing Requirements |Create Remediation Effort/Schedule for Outstanding | |
|Establish Test Plans (Unit, System, Acceptance) |Defects | |
|Change Management Stakeholders/Users (Prep) |Perform Final Performance Testing | |
|Establish System Test Expected Results |Collect Performance Metrics | |
|Establish UAT Expected Results |Produce System Test Report | |
|Establish Test Plan & Procedures |Create System Operational Documentation | |
|7. Production Deployment / Closeout |
|Compile Release Checklist |
|Update Business Contingency / Continuity Plan |
|Transition Operational Procedures |
|Publish Job/Control Schedule |
|Establish SLA Parameters |
|Assemble Audit Impacts (integrity, security, privacy) |
|Create Release Verification Checklist |
|Execute Operations Training |
|Perform Release Verification |
|Update Enterprise Architecture and Data Model |
|Update Data Center Environments |
|Perform User Training |
|Disseminate Documentation and Procedures |
|Remediate Go-Live Issues |
|Perform Post-Production Support Period (P1, P2) |
|Seek/Provide Final Acceptance |
8. Software Development Design Phase Deliverables and Responsibilities
During any software development phase, the Contractor will:
▪ Conduct a Joint Application Design session to define and document detailed functional design for Contractor Solution Components
▪ Define foundational capabilities and application functionalities to enable efficient processes and processing for all user groups and implement standardized application approach across Agency and Enterprise requirement areas
▪ Validate requirements for in-scope capabilities and compliance areas and review as-is business processes as applicable to the scope
▪ Design to-be business processes (inventory and process mappings) as applicable to the scope
▪ Create Functional Design Document (FDD) for Application & Application Components, Integration Components, and Data Conversion & other related components as applicable to the scope
▪ Create Technical Design Document (TDD) for Application & Application Components, Integration Components, and Data Conversion & other related components as applicable to the scope
▪ Complete Middleware Design & Architecture as applicable to the scope
▪ Meet requirements related to System Environments defined in this document
2. Phase Design Document (( Repeats for Each Release, Phase / Cycle)
← Inclusive of all functionality contained in the phase (business, functional, technical, integration, operational or otherwise)
← User Interface and Customer Management Requirements
← Transaction Routing and Processing Requirements
← Agency Interfaces, Integration and Reporting
9. Software Development Build Phase Deliverables and Responsibilities
During any Build Phase the Contractor will:
▪ Build foundational and advanced solution capabilities as applicable to the phase;
▪ Build new solution requirements as applicable to the phase;
▪ Leverage, augment, configure or extend pre-built requirements as applicable to the phase;
▪ Complete data conversion design and build, as applicable to the phase;
▪ Meet requirements related to Project and Phase Completion defined in this document;
▪ Meet requirements related to System Environments defined in this document; and
▪ Meet requirements related to Version Control defined in this document.
For any system code, scripts, job schedules, objects, rules, metadata, database, scripts or other programming artifacts (collectively “Development Items”) that lend themselves to documentation that the Contractor develops, modifies, enhances or replaces, the Contractor will, during the project, fully document any Development Items in a manner as to comply with the following standards:
▪ Documentation of Development Items comply with Salesforce (and if applicable 3rd party software) OEM best practice guidance for adding comments to code (in general);
▪ Documentation will be sufficient for a capable third party to assume, adjust, alter, maintain, support, update or upgrade the system in the future without the involvement of the Contractor;
▪ Comments will additionally follow the project specific requirements below:
▪ The Contractor will use comments to describe the intent, algorithmic overview, and logical flow.
▪ The Contractor will include comments so that someone other than the original developer can understand the intent, behavior and purpose of the code.
▪ The Contractor will use comments liberally for all State specific functionality on Development Items and where State specific functionality integrates with core or unmodified Salesforce functions.
▪ The Contractor will include comments that indicate who made the changes, when the changes were made, why the changes were made and what the changes accomplish and (if appropriate) what phase, release or version number of the system the Development Item was developed for.
The Contractor must ensure that:
▪ Complex Blocks of Code are properly commented
▪ Comments must not be used to serve as inline translations of the code; instead they should focus on the intent and function of the code.
▪ Comments must be used to classify the modification type.
▪ Reasons must be given if any base layer code is commented.
▪ Unnecessary or inaccurate comments are removed.
▪ The Contractor will identify all methods that are missing XML header documentation that outlines the summary, parameters, return values and remarks for the method. For these items, the Contractor will add proper documentation for each method.
▪ The Contractor will ensure that the system label dictionary contains all standard and customized labels and that all tables, extended data types and base enums contain a valid label id assigned to the label and help text properties. As part of this work the Contractor will replace all static text with valid label code for extended data types, tables, table fields, views, view fields and maps in the system model store.
▪ The Contractor will ensure that all custom objects follow a proper naming convention and will rename custom objects in accordance with the naming conventions that other objects appear to follow and adhere to industry best practices.
3. Build Completion Document (( Repeats for Each Release, Phase / Cycle)
← Completion of the build phase and all requirements contained in a phase
← Other delivery artifacts as well as documentation as required in this Supplement
← Environments Accepted- State approval that represents that all SLDC, operational and disaster recovery environments have been established as required.
← Version control mechanisms are installed and functional and that all development activities that are subject to version control are managed by the environment prior to any promotion of development objects to User Acceptance and Production environments.
10. Software Development Testing Phase Requirements and Deliverables
The Contractor will:
▪ Create Solution Testing and Acceptance Strategy as applicable to scope of the phase, release or cycle;
▪ Update test plans, scripts, functional matrix, schedule, scenarios, and processes that will be used for the system integration test;
▪ Build performance test plan for the scope elements;
▪ Execute application and integration Performance Testing approach and plan;
▪ Address any issues identified during performance test, publish performance testing results;
▪ Complete Systems Testing integrated with the Application and other State and Participating Agency system software components;
▪ Support State User Acceptance testing plan based on in-scope business processes and business scenarios (as defined in Business Requirements Document(s) and the Functional Design Document(s)) that will be used for User Acceptance Testing;
▪ Identify build, test and deploy defect fixes identified during all testing which includes Contractor and State testing and deploy code fixes to all relevant environments; and
▪ Meet requirements related to Test Phase Exit, Production Deployment, and Production Transfer as required in this Supplement.
A Test Readiness Review Checkpoint must be successfully completed prior to beginning the Test phase. This includes the State’s acceptance of all deliverables due to date per the project schedule. A validation of the scope and schedule for the remainder of the Project will also be completed at the Test Readiness Review Checkpoint.
For avoidance of doubt with respect to testing activities, the Contractor is responsible for all activities associated with System Test. The State is responsible for UAT Test execution while Contractor will be responsible for UAT support, which includes at a minimum, test preparation, management and tracking of UAT activities. The Contractor Team will plan, lead and execute System Test, User Acceptance Test (“UAT”) Support, and Operational Readiness Test (“ORT”) and include the State Project Team and Participating Agency Team(s) in the effort. The State will provide SMEs knowledgeable in test execution and as mutually agreed to with the Contractor to support test execution.
Following are the testing focus areas and the State’s expectation for each of the test cycles:
▪ System Test focuses on the customizations, configurations, workflow and integrations. Test conditions and test scenarios to be included in the System Test will be mutually agreed upon by the Contractor and the State. These scenarios will be based on an analysis of the requirements, changes, and modifications that are approved for implementation. System Test includes integration and regression testing.
▪ Performance Test establishes a baseline of acceptable performance for a sample of online transactions. The tests are conducted under a practical proportion of expected transaction and user volumes to mimic real-world usability. The number, frequency, and concurrency of online user transaction load will be defined using the most recent Contractor team estimates of activity available at the time of test preparation. The estimates will be based on enterprise-wide usage.
▪ User Acceptance Test (UAT) verifies the usability of the new processes and ensures that the system meets the needs of the organization and the end user. UAT leverages System Test Scripts and is executed by State resources. A key objective of UAT is to facilitate an understanding of the technology and the business change being implemented.
▪ Operational Readiness Test (ORT) must include end-to-end testing of business processes, all delivered system functions, interfaces and reports and the underlying technologies that support the solution and will be planned, led and executed by the Contractor and include the Contractor Personnel responsible for the design, construction and system testing of the system, State Project team and Participating Agency Team(s) in the effort. ORT will be conducted during a specific time period before Go-Live as a final business readiness test prior to live commercial use of the system.
▪ Security and Vulnerability Test must allow the State to conduct a test with the support of the Contractor that includes an application scan, manual testing of the system using client-side code analysis, and loading maliciously formatted inbound interface files.
The Contractor Team will develop and prepare weekly status reports to monitor the progress of each test phase. The status reports will contain sections for condition creation, script creation, script execution, issue identification and resolution, and defect identification and resolution
The Contractor will provide and follow a Test Moves to Production strategy and plan as appropriate for their solution’s environment(s). The Contractor will demonstrate to the State that the strategy allows for the development and testing of a migration process and checklist, as well as an assessment of timing and any mitigation or resolution of any issues related to timing.
Throughout the Project duration, if a testing or production incident is due to errors, omissions, documentation inconsistencies, or defects in a software element licensed by a Salesforce or a Third Party to the State, the Contractor will assist the State by referring such incident to the appropriate entity for resolution and coordinating with the Contractor, as appropriate, to help minimize the State role in problem management.
The Contractor will implement measures to help avoid unnecessary recurrence of incidents, by performing root cause analysis and event correlation for items discovered during testing/validation activities.
4. Contractor System Test Phase Completion (( Repeats for Each Release, Phase / Cycle)
← State acceptance of completion of the System test phase and all Contractor requirements and delivery artifacts as well as documentation as required in this Supplement.
5. State Acceptance Test Phase Completion (( Repeats for Each Release, Phase / Cycle)
← State acceptance of completion of the Acceptance test phase and all Contractor requirements and delivery artifacts
← Testing must be sufficient to validate the overall completeness, accuracy and quality of the solution inclusive of all system development activities and as applicable to live production use within the State.
6. Disaster Recovery/Data Backup (DR, DBK) Plan (( Repeats for Each Release, Phase / Cycle)
← Completion of DR testing sufficient to ensure that the system contains features and capabilities as required to meet the State’s disaster recovery requirements, at a minimum as to replicate all technical elements of the system inclusive of code, data and configuration values to an alternate location as to resume operations in the event of an unanticipated disaster.
11. Software Development: Retirement of Legacy Functionality and Data Migration, Decommissioning
As part of transition / migration / decommissioning of any legacy Agency business functions and data associated with a deployment of an Agency Application to Salesforce, the Contractor will be required to design and execute a comprehensive transition and migration plan for each release phase of any proposed solution.
These requirements must be delivered with a seamless migration of business transactions and the conversion of data and business functions from the Agency solution as to create a consistent and coherent user experience for users that may be transacting business utilizing Salesforce functionality until such time as the Agency application is fully replaced. The Contractor will ensure that reconciliation reports and controls are in place to validate no data, transactions or revenue is lost in transition or migration.
The Contractor will ensure that:
▪ User experience is seamless with single sign-on;
▪ Users must be able to complete end-to-end business transaction in single operating environment (User Experience);
▪ Users must have access to complete historical, current and in-progress data in single operating environment;
▪ Reconciliation processes and reports must be in place to ensure the new system is processing the same volume and revenue of transactional data as the legacy application and no data is lost in transition; and
▪ The new Salesforce-based system is covered under a proven and tested Disaster recovery and Data Backup/Recovery as part of a State business continuity plan.
As part of migrating functionality or data from an Agency system to a Salesforce-based system, for each functionality area or data group that is intended for live production, the Contractor will:
▪ Identify, with State assistance, all data records in the list of conversions detailed in this document subsequent to this identification. The Contractor will develop data extraction and data conversion reports to validate, extract, transform (if required) and load the records identified into the Salesforce system;
▪ The State is responsible for any data extraction from legacy Agency systems and loading it into staging tables;
▪ The State will either remediate these records or determine alternate methods to process (or if necessary exclude) records that require remediation;
▪ Work with the State to ensure that, prior to any decommissioning of functionality or data from the legacy environment (once the data and business functions are in production in the Salesforce environment), the State has successfully archived the then current legacy system and data in a retrievable fashion;
▪ Develop, test and maintain a reversibility plan such that should (for any reason) the State elects to revert back to legacy functions migrated in a release cycle in a period immediately following go-live, it can do so through re-application of legacy functions and data;
▪ Perform a data assessment and identify any records that require State remediation prior to loading in the Salesforce environment;
▪ Following State remediation (if appropriate) and for those records that do not require State remediation, load all records into the Salesforce system and provide control reporting sufficient that all records were loaded, fields mapped, no data was altered or lost, and the records are as a group and uniquely accessible in the new system;
▪ Design, build and migration and decommissioning test reports, while ensuring all the necessary security and privacy controls are in place;
▪ Work with the State, agencies and external system (e.g. CBOSS, Banking/Payment Processing/ESB integration) teams, to identify the scope, required data elements, frequency, security and controls of reconciliation reports;
▪ Work with agencies and external system teams, to design, build and test reconciliation reports; and
▪ Contractor must design, build, end-to-end test and deploy Salesforce and middleware integrations up until the Agency hand-off.
7. Legacy Function and Data Decommissioning Report (( Repeats for Each Release, Phase / Cycle)
← Plan to decommission application functionality and compliance areas
← Decommission and shut down of legacy system service areas as Salesforce-based functions, data and service areas come online, as applicable to the release, phase / cycle;
← Decommission of redundant functionality in instances where capabilities will be enabled on Salesforce (e.g., logon, account management and user registration)
← Deployment plan to migrate Agency system changes to Salesforce Production as required, given other decommissioned functionality
12. System and Acceptance Testing Requirements
For any Salesforce technical implementation, all software and code-based deliverables, development, upgrade / update or elements will be subject to a formal testing and acceptance process that uses objective and thorough test criteria established by the Parties that will allow the Parties to verify that each build meets the specified functional, technical and where appropriate, performance requirements. The testing and acceptance process will be developed for each build as soon as possible after establishing the business and user requirements. The testing and acceptance process will include sufficient audit trails and documentation as required to track and correct issues. The tasks and activities that the Contractor will perform as part of the testing and acceptance process include the following:
▪ Develop and maintain test data repositories as agreed appropriate;
▪ Develop test plans, scripts, cases and schedules as agreed appropriate;
▪ Perform the following testing activities for solution components and assess quality and completeness of results including:
← System Test / Assembly;
← Integration/interface testing and regression testing for new releases of existing applications; and
← Performance Test including regression testing new releases of existing applications as well as the potential performance impacts to current production environments where a risk of impacting performance may be introduced as a result of these elements;
▪ Provide test environments populated with quasi production data as required to perform the system and user acceptance testing work, and where appropriate performance testing. The test environments will be designed and maintained by Contractor so that test activities will not adversely affect the production environment.
▪ Contractor ensure that all developed software is not constrained by and executes within agreed performance parameters on the Salesforce platform or State provided infrastructure; and
▪ Perform technical architecture build/configuration testing (e.g. batch scheduling, interfaces, operations architecture, etc.).
8. System and Performance Test Results
← All Functionality Contracted by the State in each Phase/Release/Cycle/Sprint as applicable
← All RICEFW elements Contracted by the State in each Phase/Release/Cycle/Sprint as applicable
← Documented system and performance test results for State review and acceptance prior to the State’s commencement of acceptance testing.
13. Performance and Reliability Testing Requirements
For any effort that involves the development of software code, custom configuration, scripts, batch processes, interfaces, data extractions, extensions to Salesforce, changes/alterations (collectively Contractor Developed Elements) to Salesforce and Salesforce Application provided data structures and the like, the Contractor will work with the State to develop an overall approach to performance testing of the impacted State and Salesforce elements as a result of the work described in this supplement.
▪ The Contractor will specify the appropriate performance testing approach that includes the design and execution of processes designed to demonstrate to the State that performance for any Contractor Developed Elements adheres to the agreed upon performance parameters and does not diminish the performance of Salesforce and State Applications beyond agreed values as a result of introducing the Contractor Developed Element into a State environment.
▪ The Contractor will specify test environments as required to perform the appropriate performance testing. The test environments will be designed, implemented and maintained by Contractor so that test activities will not adversely affect any production environment.
▪ Contractor will expand capacity if testing requirements are constrained by the hardware or environments.
The Contractor is to provide best practices in conjunction with the overall performance testing effort. To facilitate rapid and quality testing, with a high degree of code coverage, the Contractor will employ automated testing tools and techniques where possible to test core scenarios, scenario variations, and regression testing of performance testing items.
14. Support the State’s Performance of User Acceptance Test (UAT)
The Contractor will support the State’s user acceptance testing for solution components as follows:
▪ Develop with the State agreed upon UAT test plans, scripts, cases and applicable acceptance criteria;
▪ Coordinate UAT execution and acceptance procedures with the appropriate the State participants;
▪ Record and report UAT results;
▪ Review changes, fixes and enhancements with the participants in the UAT testing;
▪ Correct identified defects and nonconformities in accordance with the acceptance process;
▪ Compile and maintain solution issue lists;
▪ Conduct quality and progress reviews with appropriate the State personnel;
▪ Coordinate and confirm the State approval of solution components and verification of applicable acceptance criteria for transition into deployment and production use;
▪ Provide the State with reports on a weekly basis tracking the progress of Contractor’s performance of testing work, or in the case of user acceptance testing, support of the State activities;
▪ Contractor will provide timely responses to the State’s requests for information and reports necessary to provide updates to the State business units and stakeholders; and
▪ Contractor will also provide the State with a database extract from the database that tracks progress of Contractor’s performance of testing work, all documented defects, defect prioritization and defect find/fix/retest activities (particularly those required for launch as well as all Severity 1 and 2 Defects).
9. State User Acceptance Testing Completion
15. Pre-Production / Production Deployment Phase
The Contractor will be responsible for working with the State and its 3rd party contractors, and executing the production deployment and roll-out of any Salesforce Implementation to the Production Environment provided by the State.
Should the deployment include any software deployment to the end-user desktop equipment, State infrastructure inclusive of file servers, networks, database servers or related elements (if applicable), identification of interfaces and any required conversions/migrations, installation and testing of any required middleware products, installation of server software, and any required testing to achieve the proper roll-out of the Application software.
Contractor will comply with the State required implementation and deployment procedures. This may include, network laboratory testing, migration procedures, the use of any pre-production or pseudo-production environment prior to production migration. Contractor will be responsible for business user support required during the initial weeks of a production deployment as determined by the affected State business units and will maintain the capability to provide enhanced levels of support during the term of the Contract. Contractor will submit to the State, for the State’s approval, a written deployment plan describing Contractor’s plan to manage each such implementation, including working with the State’s Infrastructure Services Division, if applicable. The tasks and activities to be performed by Contractor as part of the Deployment Services also include the following:
▪ Execute required data conversions or migrations including, but not limited to, baseline Salesforce configuration tables and parameters, and ancillary supporting data as required by the system to function successfully in the production environment;
▪ Establish data to be used with the new solution by producing new data and reconciling and mapping different data and database representations;
▪ If required, convert electronic data into a format to be used by the new solution using the data conversion program;
▪ Perform required data matching activities and error reporting;
▪ Document data issues and provide to the State for resolution;
▪ Coordinate and confirm the State approval of data conversion results;
▪ Conduct production pilot(s) (including “day in the life” simulations) and fine tune solution as agreed appropriate;
▪ Compile and maintain solution issue lists;
▪ End to end final validation of the operational architecture for the system; and
▪ Develop, and thereafter maintain and make available to the State, a knowledge base of documentation gathered throughout the Project's life and allow for re-use of such documentation for future Projects.
10. Final State Acceptance and Handoff to State Salesforce Managed Service Provider
▪ Completion of all items documented in the State’s Production Acceptance Checklist;
▪ Resolution of all Severity 1 and 2 Defects and other defects as mutually agreed with the State;
▪ Transition solution support responsibility to the State Salesforce Managed Service as appropriate;
▪ Conduct a post-implementation review process upon the completion of the Project which will include an analysis of how the business system(s) resulting from the Project compare to the post-deployment performance requirements established for such Project; and
▪ Establish a performance baseline for the Project business systems, and where appropriate document requirements for future performance enhancement of the business systems implemented as part of the Project.
4. Contracting Methods and Standards
The State may from time to time request proposals in the form of Statements of Work (SOW) e.g., Change Request/Amendments under the contract arising from this RFP for the design, development, testing and deployment of new applications or significant application enhancements (“Application Development Projects”). Upon completion of a Project Services implementation, the completed application, once meeting the State’s acceptance criteria, will, in most cases, be managed by the State on an ongoing basis as an Enterprise DAS/OIT service. Such projects will be governed by and provided by the Contractor under the standards and requirements contained in Supplements 2 and 3 of this RFP.
The State may also request staff augmentation services from the Contractor. When staff augmentation services are provided by the Contractor that do not involve full lifecycle development or implementation responsibilities, the Project Requirements described in Supplement 2 may not apply (determined at the sole discretion of the State). The State acknowledges that it is responsible for the management of these types of projects and of the work being provided by any Contractor staff providing services under a staff augmentation-type engagement.
1. Future Project Services Objectives
The Future Project Services are defined to achieve the following:
▪ Standardize the Delivery Model for new application development using the Enterprise Salesforce Platform;
▪ Facilitate smooth, well-defined transitions of new Projects to steady-state/production support;
▪ Utilize the Contractor’s rate card to better control overall development costs across the State;
▪ Improve delivery through clearly defined development standards, conventions and guiding principles;
▪ Implement a standards based governance structure to drive process improvements and consistency across the State;
▪ Speed up the development lifecycle by reducing the procurement timeline; and
▪ Identify, design and develop Agency specific Security and Data privacy requirements that follow State standards included in Supplement 2 as well as any Agency specific requirements based on Agency use of the Salesforce platform.
2. Future Salesforce Projects and Deployments: Contractor Support Requirements
The State has invested in the creation and ongoing operation of the Salesforce platform and related Enterprise and Agency applications. As a result of ongoing Salesforce and Application releases, stabilization and extension into new lines of business and services as well as current IT Optimization efforts underway State-wide, the State has identified several opportunities for Agencies leverage Salesforce-based applications in support of the State’s overall, and Agency-specific missions.
The Contractor will support DAS/OIT in:
▪ The development and refinement of ongoing Salesforce Business Roadmaps for State identified Salesforce opportunities;
▪ Creation of business case, change programs and Salesforce adoption/extension budgets, timelines and investment models that are pragmatic and grounded in the realities of budgets, implementation efforts and Salesforce capabilities;
▪ Development and delivery of exploratory workshops with new Agency customer groups from the above;
▪ Leading of “change agent” type communications designed to encourage Agency and Statewide adoption of Salesforce service offerings; and
▪ Support DAS/OIT management in bridging: business, functional and technical and organizational changes to propose, design, implement and extend Salesforce offerings Statewide.
3. Development Life Cycle Proposals associated with Development and Enhancement Projects
The Contractor will provide a disciplined Systems Development Life Cycle (SDLC) methodology for use on Application Development Projects and will adhere to such methodology during the performance of Application Development Projects. The Contractor will adapt this methodology as required to meet the State’s needs. The Contractor will provide the State with a comprehensive description of the methodology, the formal training available if required, the development tools and templates used with the methodology, the project management tools to be used with the methodology, and the plan for implementing the methodology within the State environment. For large changes and releases the Production/Version Control and Release Management requirements in Section 4.3 above must be followed.
4. Future Project Services Pricing Response and Rate Card
Offerors must utilize the Rate Card, by project personnel role and experience level as well as Business, Functional and Technical role and experience level that is binding over the Contract term. The Contractor may not propose rates in any Project SOW that exceed from this rate card as allowed under any contract arising from this RFP.
5. Submission and Acceptance of the Proposed Contractor Offer and Statement of Work associated with a Future Project
At the State’s request, the Contractor may provide any proposals to the State that addresses the State’s requirements for an Application Development Project. The Contractor’s offer must incorporate the SDLC described above (or as agreed to by the State) and as appropriate, be in accordance with all the requirements included in both of Supplements 2 and 3. At a minimum, the Contractor’s offer must include a list of activities to be executed and deliverables to be created, organized by SDLC Phase (e.g., design, build, test and implement).
The Contractor’s offer must be priced based on the either the Rate Card (for time based projects) or Fixed Price Deliverables/Milestones included in the Cost Summary for the completion of the deliverables required by the State’s requirements and as contained in a mutually agreeable Statement of Work (SOW).
The State will review the Contractor’s offer and provide feedback as needed to the Contractor within thirty (30) days of receipt of the offer. Under no circumstances will work be started without State approval, and the State will have no financial obligation for services performed without State approval.
Upon State acceptance of a Contractor Proposal, all standards, conventions and general Project Management requirements contained in this Supplements 2 and 3 of this RFP shall apply unless otherwise agreed to in writing by the State.
6. Design, Configuration and Implementation Responsibilities
The Contractor will validate and refine the current technical and functional designs for the any Salesforce Implementation for the support of the State. The Project design validation services will also include the following:
▪ Validate the current environment and refine the designs which will include, where applicable based on the size, complexity and requirements of the Project, design of forms, user interfaces, reports, security, audit trails of the transactions processed, provision for parallel testing, development of fallback procedures, provision for recovery procedures from production outages, provision for process considerations designed to minimize the time required to address, prioritize and resolve Salesforce issues and maximize end-user experience through prompt and accurate resolution of Application issues.
▪ Update Salesforce system and process designs, inclusive of State and Managed Services roles as necessary to properly address issues in respective areas of expertise and responsibility.
As part of the design / configuration process, Contractor will also:
▪ Validate/refine State Salesforce solution designs to support solution requirements;
▪ Validate/refine user interaction model which defines applicable standards, solution prototypes, and visual designs;
▪ Validate/refine technical design of required user interfaces, reports and forms;
▪ Validate/refine technical design of integrated solution components and interfaces to external systems (if applicable);
▪ Compile and maintain solution issue lists;
▪ Validate/refine document design specifications and work with State to create applicable acceptance criteria;
▪ Conduct quality and progress reviews with appropriate State personnel; and
▪ Develop testing plans for the solution.
11. Design, Configuration, Reporting and Integration Document
← Present the final designs and configuration specifications that, at a minimum, include: key processes and workflows, user interaction and user interfaces, user input edit/validation, reporting, and any required interfaces to State systems to the State for approval.
← These will be considered completed when they are approved by the State.
The Contractor will, in its implementation, incorporate the use of configuration standards, reviews, and audit trails, including release control. User walk-through(s) of the system will be provided upon request.
Contractor’s configuration will include the creation and testing of test and production procedures and job schedule, as appropriate.
Contractor will also perform the following tasks and activities in connection with developing the applications:
▪ Configure solution components to support approved design inclusive of: configuration and customize the solution requirements; configuration and customization of solution user interfaces; configuration and customization of solution reports and forms;
▪ Configure and customize integrated solution components and interfaces to external systems;
▪ Utilize build, prototyping and test environments as required to perform the development work. The build environments will be designed and maintained by the Contractor so that build activities will not adversely affect the production environment and otherwise be representative of the production environment as to minimize issues associated with production release of the developed application software and integrations;
▪ Perform unit test for solution components and assess quality and completeness of results;
▪ Document solution and refine applicable acceptance criteria;
▪ Make use of applicable Contractor practices to enhance code reusability;
▪ Compile and maintain issue lists;
▪ Develop the Application in accordance with the State’s strategies, principles, and standards relating to technical, data and Applications architectures as communicated to Contractor. Contractor will contribute to the ongoing development of such strategies, principles and standards through, at a minimum, advising the State of developments in technology which may be applicable to the State’s business requirements;
▪ Conduct Build progress reviews with appropriate State personnel; and
▪ Obtain State approval of solution components and verification of applicable acceptance criteria for transition into Test activities.
7. Guiding Principles and Requirements: Configuration and Customization of Salesforce Objects
Contractors are required to follow these guiding principles in the performance of the work contained in this Supplement and any resultant contract.
The State seeks to maintain Salesforce implementations, inclusive of AppExchange, 3rd Party applications and extensions and Enterprise Integrations to as close to “as delivered” and, as part of this work to the extent possible, avoid all customizations in lieu of “as delivered” Salesforce functionality under the following conventions (emphasis intentional):
1. No customization may introduce a systems performance issue, bottleneck or processing delay in consideration of the current operating state of the Salesforce platform. The current performance of any Salesforce application (or Applications developed by the Contractor in light of as delivered Salesforce functions), unless otherwise noted, shall be the performance baseline by which Contractor performance, system performance testing and State acceptance of same is measured.
2. No customization may invalidate, negate or minimize any warranty or maintenance requirement as agreed to between the State and Salesforce and other Salesforce provided infrastructure elements that support Salesforce.
3. No customization may be constructed in such a manner as to confound, add complexity to, or technical burdens that would impact a future upgrade by the State to future versions or releases of Salesforce.
The State acknowledges that due to the nature of its business, and the various integration demands of a multi-Agency Salesforce environment that certain existing customizations and extensions may still be required as part of an Agency implementation. Therefore, all RICEFW (Reports, Interfaces, Conversions, Extensions, Forms, and Workflows) objects must be designed, constructed, configured and deployed that adhere to these conventions unless one of the following two criteria are met (emphasis intentional):
1. The Contractor shall analyze and design existing RICEFW customizations and objects, and for those identified as State specific with no viable alternatives if still required by the State, the Contractor will obtain written State approval to continue these RICEFW customizations and objects as part of Salesforce.
4. For any new customizations that are identified as part of the development of an Application, technical upgrade or other parts of the work described in this RFP, that contravene the aforementioned conventions and explicitly do not lend themselves to an “as delivered” or “configurable” approach, the Contractor will obtain written State approval to design, develop and implement these customizations prior to proceeding.
For the avoidance of doubt, the Contractor shall not introduce any new customizations without written State approval. The Contractor shall identify all existing customizations and seek to implement these customizations in a supportable, upgradeable and State-wide consistent manner and seek State approval for the continuance of existing customizations.
In consideration of the customizations as contained herein, State approval will require the approval of the Office of the State CIO or a designate.
8. Change Management/Communications and User Training (Minimum Requirements)
Over the course of any implementation, the Contractor will have the following responsibilities with regard to the effort which are additive to the general responsibilities contained in this Supplement as they pertain to Change Management and User Training. Each will be discussed in turn:
Agency/User Change Management/Communications
▪ Contractor will work with the State to develop general communications materials regarding the scope, anticipated impact of change with regard to the change from an existing application (should one exist) to the new Application based on Salesforce;
▪ These communications documents must be focused (at a minimum) on general communique to all State users;
▪ For Agency Expert Users, the Contractor will develop progress and design summaries to be shared by the State with these users;
▪ For the OIT Managed Service management function, OIT help desks that support Salesforce, OIT and Agency Business support functions, the Contractor will develop targeted presentations that highlight specific Application support processes, workflows, job aids and updates arising from the Salesforce implementation
Enterprise Salesforce Platform Service Delivery Functions User Training
▪ For Statewide and Agency Expert Users, the Contractor will develop for the State to publish general guides containing FAQ, one-page “how to” and help pages for the Application website on utilizing the new system for Agency functions;
▪ For the OIT Managed Service management function, OIT help desks that support Salesforce, OIT and Agency Business support functions, the Contractor will develop targeted training sessions to be delivered that highlight the implementation, use, changes, workflow, reporting and other use considerations in such a manner as to facilitate the migration of Agency support functions to the new Salesforce system.
It is the Contractor’s responsibility to establish and maintain data sets within each environment that are sufficient to support the training development and delivery requirements outlined above. As part of this activity set, the Contractor will document data set organization, integration across functions, location of source information, and any other information required to understand how data sets were built and conduct knowledge transfer to the State.
Based on current support staff sizes, there are between 10-20 people (in addition to selected (2-3) State Managed Services personnel) that would require this form of training.
Offerors are informed that OIT service delivery personnel have been operating under (and most have completed training) in ITIL v3 and should be assumed conversant with modern ITIL techniques and methods.
9. Project Completion Activities and Final Documentation
Following forty-five (45) days of successful execution by the Contractor Managed Service in the State’s Salesforce production environment, the Contractor shall be relieved of Project requirements contained herein.
During this period the Contractor will:
▪ Provide personnel with the requisite skills and experience levels in development of the Salesforce Application to answer questions and address issues that the State or Managed Services Provider personnel may have;
▪ Address any software defects, gaps, omissions or errors that are discovered in the Contractor’s work as they pertain to operation in a production environment;
▪ Resolve any configuration, performance, compatibility or configuration issues that arise as a result of migration of the Contractor’s work to a production environment;
▪ Document any relevant changes to operational, configuration, training, installation, commentary or other documentation as a result of migration to the Contractor’s work to a production environment;
▪ Assist either the State or Salesforce Managed Services personnel with production issue triage, root cause and remedy analysis and wherever possible propose work-arounds, fixes, patches or remedies (code-based, procedural or environmental) required to successfully transfer and operate the Contractor’s work to a production environment.
During the 45-day period immediately following the introduction of any Contractor developed Enhancement or Application to production the Contractor must:
▪ Ensure adequate staffing from the Contractor Project Team is on hand (or available remotely) to ensure that during this 45-day period all Service Level Agreements committed to by the Contractor in this RFP are adhered to, specifically:
← Prompt isolation, triage and repair of any Severity 1 or 2 issues;
← Performance Monitoring of the System to ensure that there are no statistically significant (i.e., +5%) deviations from actual production performance as compared to the results of the upgrade performance test(s);
← All interfaces, ETLs and RICEW objects perform and function as specified;
← Work with the OIT Application Management to review system and database performance statistics that may indicate either or both of infrastructure configuration or Salesforce configuration issues and work with the State to remediate these issues;
← Monitor job schedules and job execution inclusive of results to ensure that the job scheduling system is performing and functioning correctly
← Compile all final versions of the upgrade documentation, work products and delivery materials and locate / organize them as ‘FINAL’ on the State provided Project SharePoint site.
12. Final Acceptance
← Obtain a final acceptance document from the State and the State Managed Service Team confirming that all of the above has been delivered and accepted as final.
If, during the 45-day period immediately following the introduction to Production, a Severity 1 or Severity 2 issue occurs that can be directly attributable to the efforts of the Contractor, and not the State, the Contractor Managed Service Team or other non-Project parties, the 45 day period will, at the sole discretion of the State, be reset for additional 45 day periods until such time as the system can perform without Severity 1 and Severity 2 issues.
10. Salesforce Data Archive and Purge
Based on the State’s experience running the Salesforce environments since the implementation of several Agency Applications, the State has determined that there is a requirement for accommodating the archive and purge of historical or obsolete data from the production environments.
At a high level, the rationale for implementing archive and purge functionality is to ensure that: the data in Salesforce is contemporary and follows State and Federal regulatory retention requirements, that extraneous data is not maintained by the State that could pose a liability, the overall performance characteristics of the system are not compromised by processing or accommodating historical data; the overall costs associated with storage, backup and maintenance of historical data are cost effective; and requirements for creating subsets of data to support the development, testing and training of projects.
Based on the high level objectives outlined above, the State has evaluated various methods to accomplish the archive and purge functionality including: the development of customized scripts to facilitate the extraction and migration of data to online, offline or purge data stores; and the purchase and subsequent implementation of commercial packages available on the marketplace.
The State believes that a combination of Salesforce Backup and Data Purge techniques (for transactional tables) and Salesforce system purge tools for system, report and log objects may be appropriate to suit the State’s needs. For non-Salesforce objects (e.g., file transfers, interfaces, ETLs etc., the Contractor shall develop a set of scripts to be run periodically to remove these files from online storage.
In the event that Offerors have opposing or complimentary approaches, the State requests that Offerors propose their preferred method(s) for managing general archive and purge requirements in their Salesforce environments. Offerors are required to include a high level description of capabilities, features, configuration and limitations of their provided toolset, any underlying assumptions as to the basis for provision of these functions, and any incremental pricing associated with the delivery and implementation of these capabilities.
Notwithstanding the final tool or implementation approach the Contractor will:
▪ Review State identified tools and approaches and, if necessary, marketplace offerings and approaches and work with the State to determine the best possible solution to achieving Archive and Purge Requirements
▪ Provide an analysis of all data maintained in their proposed Salesforce Application(s) and perform a gap analysis based on State provided data retention requirements to identify archive/purge-able data elements maintained in the Salesforce environment
▪ Determine the schedule frequency to perform archive and purge operations (e.g., annually, quarterly etc.)
▪ Determine windows in the annual production schedule to perform these operations while not impacting other routine scheduled jobs and affording appropriate backup and recovery windows in the event that the State needs to reverse the archive / purge process as a result of unintended job outcomes.
13. Salesforce Archive/Purge Elements
← Create a design document for State approval based on the above and the agreed solution to be configured and implemented in the Salesforce environments for all data that meets the agreed archive and purge criterion
← Develop the solution inclusive of system and performance testing requirements contained herein
← Provide the State with a build completion summary that includes the results of performance and system tests using a replica of Salesforce at full production volumes
← Support the State in conducting pre-production acceptance testing for final approval prior to implementing to the production environment
← Establish run parameters and job schedules, operational documentation and developer/maintenance notes and procedures prior to remanding the system to the Managed Services team for ongoing operation as per the agreed and established schedule.
11. Non-Production Environment Data Masking
Data Masking and Information Privacy in Non-Production Environments the State has a requirement for all non-production environments (e.g., development, testing, training) that require production data refresh from time to time as outlined in the table in. Elements of production data that require protection under information privacy regulations such as Social Security numbers, bank account information and other sensitive data must be protected in these environments.
As a result of these requirements, the State has conducted a review and vendor driven proof-of concepts and demonstrations as part of the formulating a strategy to achieve these requirements including a preliminary review of the available marketplace packages from as well as features available in Salesforce.
In the event that Offerors have alternative or complimentary tools, techniques or methods, the State requests that Offerors propose their preferred method for achieving data masking or private data in their Salesforce managed services environments. For alternate or complimentary approaches, Offerors are required to include a high level description of capabilities, features, configuration and limitations of their provided toolset or approach, any underlying assumptions as to the basis for provision of these functions, and any incremental pricing associated with the delivery and implementation of these capabilities.
The State will work with the Contractor to develop a listing of all personally identifying, confidential or private information during the implementation of a Data Masking tool. The Contractor will utilize this listing in the implementation of the Data Masking tool and provide an inventory of this information for nonproduction environments and employ commercially reasonable steps to safeguard this information and promptly report any access to this information.
14. State Sensitive / Personally Sensitive / Business Sensitive Data Masking Design
← Conduct a review of non-Production environments, intended and actual use and develop an impact matrix of key data elements maintained in these systems (whether PII, HIPPA or financially sensitive or otherwise) that require the implementation of data masking
← Identify, by environment, requirements for data masking and refresh periodicity (no less frequently than annually) of data to serve the non-production environment’s intended purpose
← Present a final requirements document for State approval prior to implementation
Following the State’s approval of the requirements the Contractor will assemble a design / configuration document using the agreed tool(s) that that includes (at a minimum):
▪ Environment data refresh periodicity
▪ Database(s), Table(s) or Field(s) that require data masking
▪ Continuance of Salesforce data masking referential integrity so that the underlying system continues to perform as designed with masked data
▪ Performance and Job Scheduling considerations to perform data refresh of non-production environments as per the required periodicity without adversely impacting other scheduled jobs or processes
▪ Present a final design document for State approval prior to implementation
Following the State’s approval of the design/configuration document, the Contractor will implement the system and conduct testing as follows:
▪ Configure or construct the system to comply with the agreed State requirements
▪ Perform system testing functions and provide results to the State for review that demonstrate that data masking requirements, by environment are performing as required
▪ Perform system performance testing functions on a full replica of production and appropriately sized data in non-production environments by intended use to ensure that timing and performance parameters are understood and factored prior to production migration
▪ Test the non-production systems based on intended use to demonstrate that all identified data is both masked and that these systems continue to be useable based on their required uses (e.g., demo, testing, training etc.)
▪ Produce an implementation and testing summary (inclusive of performance testing) for State review and approval.
Thereafter, the Contractor will support State acceptance testing as required by this Supplement
▪ Following State acceptance of the system, the Contractor will develop appropriate job schedules as to ensure that data refresh periodicity requirements are met as well as to not conflict with or adversely impact existing Salesforce production schedules and promote the system to the Salesforce production environment for ongoing operation and maintenance by the Managed Services team.
12. Monitoring Enhancements, Evolutions and Updates to the State’s Salesforce Platform: Information Sharing
Enterprise and Agency application systems (in general) operate in a highly integrated and dependent manner. Any Contractor led project must maintain functional integrity of existing systems and introduce enhancements from an overall Salesforce platform perspective.
As any project is delivered, the Contractor will ensure that configuration values and customizations made in any aspect of their Application that may impact on the Enterprise or an Agency are coordinated across the system environment and consider the broader impact on existing Salesforce capabilities and other modules. Contractor project teams must coordinate the major decisions with the State that need to be made to ensure that any design considerations and implementation phasing are well understood, agreed to and coordinated.
The State’s Salesforce platform is a going concern with a defined roadmaps and Agency development pipelines. The Contractor will periodically schedule and conduct meetings with the State Salesforce team(s) that are designed to mutually share information as to ensure that development progress, enhancements and backlog items are understood and factored as the Contractor’s application and the State’s Salesforce platform relate to and are dependent upon one another as to not conflict, contradict or (to the extent possible) result in duplicative efforts. These meetings shall be conducted prior to the start of any Application development cycle, phase or release.
13. Project Delivery Environments and Production System Technical Requirements
The State will be responsible for the initial provisioning of existing State environments (should they exist) for Contractor use. Contractors will be responsible for maintaining these all Project environments and regular updates based on the evolution of the project until such time as they are no longer pertinent or required for the Contractor work.
The Contractor will provision, and thereafter maintain for the duration of the Project, a current Salesforce environment replica utilizing State provided machine instances (for State premise based applications) and Salesforce development environments as required to perform the project under their proposed methodology. The Contractor is responsible for the replication of production data or production data subsets using applicable data masking procedures for Sensitive or Personal data as required herein.
State suggested, environments include demo, Conference Room Pilot (CRP), proof-of-concept, Agile design, development, testing, pre-production implementation and migration staging, production or disaster recovery validation, additional processing requirements for peak or seasonal requirements or infrastructures for performance testing as required in this RFP. Offerors are to review the following table and, based on their development methodology and requirements to deliver the project using an Agile-based approach, propose the number of, configuration and use of environments over the duration of the Project (as part of their Proposal to this RFP).
State Suggested Minimum Environment Requirements
|Environment Summary Description |Env. |Conditions and Sizing Considerations |
| |Count | |
|Production Use |
|Production |1 |Full Production Volume |
| | |Current Production Code Base |
|Disaster Recovery |1 |Full Production Volume |
| | |Current Production Code Base |
|Production Replica (QA, Performance Testing, Replication of Production |1 |Full Production Volume |
|Issues) | |Current Production Code Base |
|Production Support Environments |
|Development - Production Support |2 |1 x Enhancements, 1 x Hot Fix |
| | |Current Production Code Base |
|Testing - Production Support |2 |1 x System, 1 x UAT |
| | |Current Production Code Base |
|Training - Development and Delivery |1 |Representative Data Volume, Participating Agencies |
| | |Current Production Code Base |
|Systems Development Lifecycle (SDLC) Support |
|Demonstration, Reference, Proof-of-Concept, CRP |1 |Representative Data Volume, Participating Agencies |
| | |Current Production Code Base |
|Agile Development (Support of Multi-Phase Development) |1+ |Representative Data Volume, Participating Agencies |
| | |Current Production Code Base |
|System and Acceptance Testing |3 |All Agencies, most current 13 months of Data |
| | |Current Production Code Base |
| | |1 x System, 1 x UAT, 1 x Performance Test |
|Deployment/Dry Runs |1 |Representative Data Volume, Participating Agencies |
| | |Current Production Code Base |
|Configuration Management Testing |1 |Representative Data Volume, Participating Agencies |
| | |Current Production Code Base |
The State will be responsible for the provision and operation of State networks and any State-owned on premise hardware as a service to the Contractor, inclusive of firewall and intrusion detection from the physical data center, through the network, to the operating system prompt. All security requirements (as addressed in Supplement 2) beyond this that are application, database, service bus or otherwise Salesforce related (i.e., above the operating system prompt) will be the responsibility of the Contractor.
Any instances required by the Contractor to support development, pre-production implementation and migration staging, production or disaster recovery validation, additional processing requirements for peak or seasonal requirements or infrastructures for performance testing will be the responsibility of the Contractor to specify, provision and provide using State provided equipment as required by their operations in keeping with contemporary high availability/resilient fault-tolerant configurations.
14. Cooperation with State and State Contractors
The State may hold other contracts for additional or related work for the Salesforce platform and Agency application development. The Contractor must fully cooperate with all other contractors and State employees and coordinate its work with such other contractors and State employees as may be required for the smooth and efficient operation of all related or additional work. The Contractor may not act in any way that may unreasonably interfere with the work of any other contractors or the State’s employees. Additionally, the Contractor must include the obligations of this provision in all its contracts with its subcontractors that work on any Project.
Contractor will cooperate with the State in its attempts at transferring, replacing or augmenting the services responsibilities to another provider in a manner in keeping with not adversely affecting the provision of ongoing services and other projects being performed concurrent with this project.
15. Project Review Check Point
Upon completion of the baselined Project Plan and on a quarterly basis throughout the Project, the Contractor, in conjunction with State Project team staff, must deliver a presentation to the State. At a minimum, the presentation must address any known State or Contractor issues or concerns, including but not limited to the following:
▪ Project scope, budget and schedule;
▪ Any changes to Key named resources assigned to the Project;
▪ Project readiness including key issues and risk from their current status;
▪ Project Status including variance from baseline for key milestones, tasks, deliverables (Significant work products) and project closure;
▪ Methodology, approach, and tools to achieve the Project goals (inventory and status of completeness and agreement for documented project management and implementation approaches. I.e., Project management plan, communication plan, requirements traceability, implementation approach and methodology); and
▪ Roles, responsibilities, and team expectations.
Upon completion of the presentation, the State will immediately assess the health of the project and determine next steps for moving forward with the Project, within one week of the meeting, which may include the following:
▪ Continue the Project;
▪ Terminate the Contract; or
▪ Suspend the Contract.
See Suspension and Termination language in Attachment Four for remedies for failure to deliver the proposed work.
Note: There may be additional Project Reviews conducted by the State on an as needed basis throughout the term of the Contract to assess Project health and ensure the Project is progressing successfully.
5. Offeror Assumptions and Other Considerations
1. Assumptions
The Offeror must list all the assumptions the Offeror made in preparing the Proposal. If any assumption is unacceptable to the State, the State may at its sole discretion request that the Offeror remove the assumption or choose to reject the Proposal. No assumptions may be included regarding the outcomes of negotiation, terms and conditions, or requirements. Assumptions should be provided as part of the Offeror response as a stand-alone response section that is inclusive of all assumptions with reference(s) to the Section(s) of the RFP that the assumption is applicable to. Offerors should not include assumptions elsewhere in their response.
2. Pre-Existing Materials
The Offeror must list any Pre-Existing Materials it owns that will be included in a Project or Deliverable if the Offeror wants a proprietary notice on copies that the State distributes. For example, the Offeror may have standard user interfaces or standard shells that it incorporates in what is otherwise custom software. (See the Ownership of Deliverables Section of the General Terms and Conditions.) The State may reject any Proposal that includes existing materials for a custom solution, if the State believes that such is not appropriate or desirable for the Project.
3. Commercial Materials
The Offeror must list any commercial and proprietary materials that the Offeror will deliver that are easily copied (e.g., software) and in which the State will have less than full ownership (“Commercial Materials”). Generally, these will be from third parties and readily available in the open market. The Offeror need not list patented parts of equipment, since they are not readily copied.
6. Project Performance Measures and Service Levels
The State’s specifications pertaining to project performance based on Service Level Agreements (SLA) to be established between the Contractor and the State are applicable to any work associated with the development, configuration, extension or implementation of any software (asset or cloud-based) associated with this Supplement.
These requirements comprise the State’s minimum expectations framework pertaining to project delivery factors, requirements relating to service level commitments, and the implications of meeting versus failing to meet the requirements and objectives, as applicable. These SLAs pertain to any Project Implementation Project and to all subsequent Project related services and phases that are contracted under future Statements of Work between the State and the Contractor related to this RFP.
The mechanism set out herein will be implemented to manage the Contractor’s performance against each Service Level, in order to monitor the overall performance of the Contractor.
1. Service Level Specific Performance Credits
Each Service Level (SL) will be measured using a “Green-Yellow-Red” traffic light mechanism (the “Individual SL GYR State”), with “Green” representing the highest level of performance and “Red” representing the lowest level of performance. A Performance Credit will be due to the State in the event a specific Individual SLA GYR State falls in the “Yellow “or “Red” state. The amount of the Performance Credit for each SLA will be based on the Individual SLA GYR State. Further, the amounts of the Performance Credits will, in certain cases, increase where they are imposed in consecutive months. No Service Level Performance Credit will be payable for the Contractor’s failure to meet a Service Level Objective.
The Contractor agrees that in each month of the Contract, 12% of the monthly project charges (MPC) associated with an 3Implementation Project arising from this RFP will be at risk. MPCs are the charges for the deliverables required by the State in such a project that are presented to the State for acceptance during a given month. The MPC for the Project Implementation will be at risk for failure to meet the Service Levels set forth in the Contract. The Contractor will not be required to provide Performance Credits for multiple Performance Specifications for the same event; the highest Performance Credit available to the State for that particular event will apply.
On a quarterly basis, there will be a “true-up” at which time the total amount of the Performance Credits will be calculated (the “Net Amount”), and such Net Amount will be set off against any fees owed by the State to the Contractor.
The Contractor will not be liable for any failed Service Level caused by circumstances beyond its control, and that could not be avoided or mitigated through the exercise of prudence and ordinary care, provided that the Contractor immediately notifies the State in writing and takes all steps necessary to minimize the effect of such circumstances and resumes its performance of the Services in accordance with the SLAs as soon as possible.
The total of any weighting factors may not exceed 100% of the total At-Risk Amount. To further clarify, the Performance Credits available to the State will not constitute the State’s exclusive remedy to resolving issues related to the Contractor’s performance. Service Levels will commence with Project initiation for any Implementation Project.
2. Monthly Service Level Report
On a State accounting monthly basis, the Contractor will provide a written report (the “Monthly Service Level Report”) to the State which includes the following information: (i) the Contractor’s quantitative performance for each Service Level; (ii) each Individual SL GYR State and the Overall SL Score; (iii) the amount of any monthly Performance Credit for each Service Level (iv) the year-to-date total Performance Credit balance for each Service Level and all the Service Levels; (v) a “Root-Cause Analysis” and corrective action plan with respect to any Service Levels where the Individual SL GYR State was not “Green” during the preceding month; and (vi) trend or statistical analysis with respect to each Service Level as requested by the State. The Monthly Service Level Report will be due no later than the tenth (10th) accounting day of the following month.
Failure to report any SLA, SLA performance in a given month, or for any non-Green (i.e., performing to Standard) SLA a detailed root cause analysis that substantiates cause will result in the State considering the performance of the Contractor for that period as performing in a Red State.
3. Service Level Commitments – Project Implementation Services
The Contractor will meet the Service Level Commitment for each Service Level set forth in the tables and descriptions below:
|No |Service Level Agreement |Support |Required |
| | |Hours | |
| | | |Response |Resolution |
|1 |Defect Resolution – Severity 1 Items |7x24 |Every 4 hours until resolution | ................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- salesforce platform app builder questions
- salesforce platform developer 2 certificati
- salesforce platform starter
- salesforce platform basics
- salesforce platform license
- salesforce platform license cost
- salesforce platform vs full license
- salesforce vs salesforce platform license
- salesforce platform pricing
- salesforce platform 1 certification
- salesforce platform license limitations
- salesforce platform developer 1 exam