category #2 bundling and unbundling workgroup september 24, 2007

10
Category #2 Bundling and Unbundling Workgroup September 24, 2007

Upload: gabriella-chase

Post on 03-Jan-2016

215 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Category #2 Bundling and Unbundling Workgroup September 24, 2007

Category #2 Bundling and Unbundling

Workgroup

September 24, 2007

Page 2: Category #2 Bundling and Unbundling Workgroup September 24, 2007

2

Agenda

Objectives Definitions

Bundled Unbundled

Issues Recommendations Appendix

Commercial-Off-The-Shelf (COTS) Definition

Page 3: Category #2 Bundling and Unbundling Workgroup September 24, 2007

3

Objectives

What are the industry issues related to supplying software separately or as part of the systems integration procurement?

Page 4: Category #2 Bundling and Unbundling Workgroup September 24, 2007

4

Definitions

Bundled Solicitation and Contract: The solution to the State’s information technology (IT) public policy and business needs are provided by one primary party, the system integrator, who has contracted with the State for completion of the contract. The system integrator or prime contractor also may have contracted with one or more third-party provider(s) to supply an array of IT goods and/or services necessary to the prime contractor solving the State’s business and/or policy requirements.

Unbundled Solicitation and Contract: The solution to the State’s IT public policy and/or business needs is provided by multiple IT suppliers who have each individually contracted with the State for completion of their contracts.

Page 5: Category #2 Bundling and Unbundling Workgroup September 24, 2007

5

Issues

1. There is a lack of understanding as to the implications of bundling and unbundling hardware and software (COTS) products during the development of the RFP, which can result in increased costs to both the State and Vendor.

2. Once RFP responses have been received, there is a lack of flexibility to negotiate bundling and unbundling of hardware and software (COTS) products, which can result in decreased competition and increased costs to both the State and Vendor.

3. Current contract requirements for bundled software (e.g. terms and conditions for licensing, indemnity and warranty requirements) creates a liability for Vendors that can result in either a “no bid” decision or increased costs that are passed on to the State.

Page 6: Category #2 Bundling and Unbundling Workgroup September 24, 2007

6

Recommendations

1. There is a lack of understanding as to the implications of bundling and unbundling software during the development of the RFP, which can result in increased costs to both the State and Vendor. The ITPP (Information Technology Procurement Plan) is a DGS mandated document that

describes the strategy the project will use in procuring goods and services from a Vendor. The ITPP is prepared in conjunction with the FSR (Feasibility Study Report).

The ITPP process should be modified to require market analysis be performed twice; once in support of the FSR development and then again prior to the development of the RFP. Discussions with Vendors during the RFP development process should specifically explore the implications of bundling and unbundling requirements. It is not reasonable to have this complete of an understanding during the FSR process.

To better align with the market and best practices, stronger consideration should be given to allow the Vendor to propose a contracting approach whereby the State would contract separately with the hardware/software (COTS) providers. This would circumvent the current contracting issues (see 3rd issue below) and allow a direct relationship between the State and Vendors.

Page 7: Category #2 Bundling and Unbundling Workgroup September 24, 2007

7

Recommendations

2. Once RFP responses have been received, there is a lack of flexibility to negotiate bundling and unbundling of hardware and software (COTS) products, which can result in decreased competition and increased costs to both the State and Vendor.

Modify RFP and General Provisions contract language in order to allow the Vendor to propose, and the State to consider, an unbundled contracting approach. This would give the State the flexibility to determine what is in its best interest (at the time of contracting) in regards to bundling and unbundling of hardware and software (COTS) products. Under the current process if the State selects a Vendor on a large complex project it may be years between the original bundling/unbundling decision and system implementation. If at the time of design and implementation the market dictates a different software solution, there is no flexibility to make those changes often resulting in increased costs.

Page 8: Category #2 Bundling and Unbundling Workgroup September 24, 2007

8

Recommendations

3. Current contract requirements for bundled software (e.g. terms and conditions for licensing, indemnity and warranty requirements) creates a liability for Vendors that can result in either a “no bid” decision or increased costs that are passed on to the State. Modify General Provisions that limit/eliminate liability for standard items out of

control of the Vendor.  For example hardware being bid by a SI, when it is the manufacturing vendor that should and often times does, provide warranty services; and COTS software (source code) that has standard license agreements & warranties.

This recommendation should be referred to the General Provisions workgroup. Contract separately with the hardware/software (COTS) provider and systems

integrator whenever possible, thus eliminating the liability and contracting issues for a system integrator and increased costs for the State.

Page 9: Category #2 Bundling and Unbundling Workgroup September 24, 2007

Appendix

Page 10: Category #2 Bundling and Unbundling Workgroup September 24, 2007

10

Commercial-Off-The-Shelf (COTS) Definition COTS (commercial off-the-shelf) product: is one that is used "as-is." COTS products are

designed to be easily installed and to interoperate with existing system components. Almost all software bought by the average computer user fits into the COTS category: operating systems, office product suites, word processing, and e-mail programs are among the myriad examples. Specific to the State, COTS have taken on several levels of complexity: Simple COTS implementation (no customization, few or no interfaces)

State needs to ensure that the solution can be successfully installed, users are trained, and ongoing updates or issues are resolved.

Medium complex COTS implementation (some combination of minor customization, minor interfaces, multiple geographic locations, some configuration, training, ongoing maintenance)

State needs to ensure that the solution is installed correctly.  The work could be implemented by the State, the COTS supplier, or a third party.  The State needs to be comfortable with the risk of the implementation strategy selected.

Complex project involving one or more COTS solutions (includes a combination of COTS customization, multiple COTS or customer software solutions, multiple interfaces, multiple geographic locations, training, ongoing maintenance)

State needs a third party to manage the project, multiple Vendors/suppliers, and project risk.