Software_Asset_Managment_-_Performance_Work_Statement_(7-15-19).docx

1. NIH Software Asset Management Performance Work Statement As of JULY 15, 2019 National Institutes of Health (NIH) Office of the Chief Information Officer (OCIO) The professional Information Technology (IT) products and services specified in this Performance Work Statement (PWS) are being acquired from the open market.

2. Agency Background Overview of the National Institutes of Health The National Institutes of Health (NIH), a part of the U.S. Department of Health and Human Services (HHS), is the principal federal agency responsible for biomedical research and the largest biomedical research funding organization in the world. Its mission is to seek fundamental knowledge about the nature and behavior of living systems and the application of that knowledge to enhance health, lengthen life, and reduce illness and disability. It is a federated environment of approximately 36,000 employees and contractors supporting the NIH mission and consists of the Office of the Director (OD) and 27 Institutes and Centers (IC) with specific research agendas, often focusing on particular diseases or body systems. Each of the 27 ICs have their own mission and functions, separate appropriations, and statutory authorities.

The Office of the Chief Information Officer The NIH Office of the Chief Information Officer (OCIO) advises the NIH Director and NIH senior management on strategic directions and management of significant NIH Information Technology (IT) programs and policy. The goals of the Director of the OCIO are to: enable creation and sharing of scientific and business knowledge; enhance business adaptability by ensuring that NIH IT projects are well managed to respond rapidly to business and research needs; ensure a robust, secure NIH infrastructure at or above industry standards; manage integration of external imperatives with NIH needs; lead NIH IT across the Institutes and Centers; and develop an IT capable workforce. The Director of OCIO is also the NIH Chief Information Officer.

The Center for Information Technology The Center for Information Technology (CIT) supports the agency’s mission by delivering high-quality IT services and systems to 36,000 staff in 200+ buildings and facilities. NIH facilities and personnel in the Washington, DC and Maryland metropolitan areas, Arizona, Montana, and North Carolina rely on CIT-managed IT services and supporting infrastructure.

The mission of CIT is to provide, coordinate, and manage information and IT for NIH and to advance computational science to improve NIH’s ability to discover new biomedical knowledge. Additionally, CIT operates a consolidated data center, which provides administrative and computational services to HHS and other federal agencies. As a service organization, CIT is focused on managing NIH’s core IT infrastructure and providing enterprise-level information technology systems, solutions, and services to all NIH ICs and OD. CIT’s services include networking, scientific computing, software and systems engineering, enterprise systems, desktop and mobile device support, data storage, and staff support and training. Modernizing the NIH IT infrastructure, cyber security, and delivering high quality, innovative day-to-day IT services are CIT’s top three priorities.

Some CIT services are discretionary and service use varies by NIH IC. CIT’s intramural research program (IRP), which includes staff scientists and researchers, provides collaborative support and specialized expertise to the NIH intramural scientific community in the areas of computational bioscience, engineering, informatics, and statistics. Most of its collaborations require first-of-a-kind instrumentation design, software development, and innovative laboratory and clinical analytical capabilities. The Director of CIT is also the NIH Chief Information Officer.

3. Legislative Background The federal government is placing increasing emphasis on the accountability of federal programs and projects and alignment of business strategies and technology investments. Recent drivers include the Making Electronic Government Accountable By Yielding Tangible Efficiencies (MEGABYTE) Act, Office of Management and Budget (OMB) Category Management Memorandum 16-12, and the Federal Information Technology Acquisition Reform Act (FITARA).

MEGABYTE Act The MEGABYTE Act of 2016 is a United States federal law that requires each Agency to establish a comprehensive inventory of software licenses. It requires Agencies to track and maintain software licenses and analyze software usage to make cost-effective decisions. It also requires Agencies to provide software license management training, establish goals and objectives for a software license management program, and consider the software license management lifecycle phases to support effective decision-making and incorporate existing standards, processes, and metrics.

Under OMB Directives and the MEGABYTE Act, HHS has specific requirements for software license management, including implementing a software asset management (SAM) tool. The requirements were created by the Enterprise Software Category Team (ESCT), a subgroup of the Category Management Leadership Council. According to the ESCT, the SAM tool should provide the following capabilities (guidance subject to change over time):

Table 1. SAM Tool Capabilities The ESCT compiled a schema that provides guidance on the attributes they identified as necessary for full MEGABYTE Act / OMB M-16-12 compliance. The release of this schema in March of 2017 was meant to define a comprehensive federal standard for the software license management inventory that agencies should work to attain. The current high-level data elements for the SAM tool schema, and the core and reference data objects are listed below. These schemas may change over time, and it is expected that the Contractor will support the schemas as they are revised in future years.

SAM Tool Schema (High Level Data Elements)

User details

Organization data

Location

Asset type (e.g., virtual, hardware, software)

Type of License (e.g., single user, multi-user, concurrent, etc.)

Model and serial numbers

Purchase and leasing costs

Purchase and leasing information

Termination or replacement date

Maintenance, repair, change, and upgrade information

History

Initial Installation Date

Utilization/Usage

Interaction with Acquisition and financial systems

License Key information for re-harvesting

License Terms and Conditions

Expiration (notifications prior to expiration)

Interaction with ticketing system

Definitive Media Library Repository

Table 2: SAM Tool Schema: High Level

Core Data Objects

OS Serial

Agency

Agency_Location

Agency_Org

Is_Virtual

Vendor_Agreement_Ref

Parent_Host

Cost_Center

VM_Mapping

Vendor_Agreement_Status

Processor_Usage

Table 3: Core Data Objects

Reference Data

Reference Data Objects

Agency

Location_Type

Table 4: Reference Data Objects

FITARA

The Federal Information Technology Acquisition Reform Act (FITARA) outlines performance standards for acquisition and inventory management. To oversee and measure the implementation of FITARA, the House Oversight and Government Reform Committee implemented a “FITARA Scorecard” with a grading system (A – F) for FITARA priorities.

Letter grades are assigned to each agency based on self-reported data. The scorecard has been issued every six months, beginning on November 4, 2015. The scorecard has evolved each iteration in response to General Accounting Office (GAO) recommendations and stakeholder feedback. Scorecard 5.0 added a fifth graded category to assess agencies’ management of software licenses.

NIH was able to score an A on the HHS Operating Division (OpDiv) FITARA scorecard based on a partial manual inventory, but OMB’s requirement for an automated inventory will bring NIH’s scores down unless an automated approach is implemented.

Category Management Issued June 2, 2016, OMB Memorandum M-16-12, Improving the Acquisition and Management of Common Information Technology: Software Licensing requires an agency-wide approach to centralizing license management, reducing duplication, and adopting s/w management best practices.

Category Management is an approach the Federal Government is applying to buy smarter and more like a single enterprise. Category Management enables the government to eliminate redundancies, increase efficiency, and deliver more value and savings from the government’s acquisition programs.

The OMB Memorandum 16-12 tells agencies to maintain a continual agency-wide inventory of software licenses, including all licenses purchased, deployed, and in use, as well as spending on subscription services (to include provisional (i.e. cloud) software as a service agreements (SaaS). Agencies must analyze inventory data to ensure compliance with software license agreements, consolidate redundant applications, and identify other cost-saving opportunities.

According to OMB, agencies shall develop automated, repeatable processes to aggregate software license and maintenance requirements and associated funding, as appropriate, for commercial and commercial off-the-shelf (COTS) software acquisitions. Agency CIOs, in coordination with CAOs and CFOs, must use their authority under FITARA to align all components with a centralized acquisition strategy that defines common software license and maintenance requirements across the agency. The processes should include a means to review existing software that is currently in use against the agency-approved list of software. When software is discovered that is not on the agency-approved software list, the process should include provisions for agencies to consider whether to add the product to the approved software list, or identify an approved alternative software product to replace it.

The memorandum also reminds agencies that they should not agree to terms and conditions that prohibit other government entities (including posting said information to the Acquisition Gateway. When terms or conditions are identified that seem to preclude an agency from sharing prices paid with other Federal agencies, the covered agency shall ensure removal of these terms and conditions during the negotiation process for the contract or the option period renewal.

Improving IT commodity acquisition and management practices is a critical step in the implementation of FITARA and providing value to the taxpayers. OMB will monitor savings and the reduction in contract duplication over time.

4. Program Goals In June 2018, NIH OCIO developed a proposal to transform our current and emerging capabilities to improve software asset management for NIH and improve software licensing accuracy and availability to NIH decision makers. OCIO is standing up an Enterprise Software Asset Lifecycle Management Program for NIH. The primary goals for the Program are to:

Develop a comprehensive understanding of NIH’s software needs and usage.

Mature NIH’s software management, tracking, analysis, testing, and negotiation approaches to achieve significant cost savings by reducing duplicative efforts and harnessing the power of volume.

Achieve improvements to the management and distribution of software and updates.

Reduce the risk of vulnerabilities by reducing out-of-date and unsupported software.

Secure better pricing and value for COTS software that are high priority and widely used.

The NIH Enterprise Software Asset Lifecycle Management Program (also referred to as ‘NIH Software Program’ or herein as ‘Program’) will transform NIH’s approach to acquiring, provisioning, licensing, testing, and managing COTS software that is used to accomplish the NIH mission. This will be a new capability that will benefit all ICs and NIH. OCIO and CIT will put in place the infrastructure, tools, processes, people, and policy that addresses the entire software lifecycle, from needs analysis to disposal, for commonly used software. This will allow NIH to reduce risks associated with end-of-life software, acquisition and installation of unsecure software, improper installations and configurations, software audits, and improper use of terms, conditions, and entitlements.

The NIH Software Program will involve three interrelated components: Software Asset Management, Procurement and Governance, and Distribution.

The Program will structure the functions involved in the software lifecycle (budget and finance, enterprise architecture, security, contracting, IT infrastructure, asset managers, and users) into a collaborative body that efficiently works toward the end goal of acquiring and distributing COTS software that is secure and meets business needs at the least possible cost. The initiative’s goal is to implement and staff processes to manage software assets throughout the entire lifecycle, from ordering, purchasing, and renewals to distribution and retirement of software through the following activities:

Software Asset Management: NIH will acquire external subject matter expertise from the Contractor (responding this the Request for Proposal and awarded the subsequent contract) to implement tools and processes that will collect detailed knowledge of NIH software. The data will then be used to develop recommendations for a variety of business decisions related to software. The Contractor will assist government decision makers with recommendations regarding NIH usage, license negotiation, costs, allocation/re-allocation, and technical architecture. The data collected by the Contractor will be passed onto the Procurement and Governance component (external to the Contractor but part of OCIO and CIT) so that contracting officers can negotiate better pricing, which will have the most impact on the balance sheets of those who purchase commonly-used and high cost software.

Procurement and Governance: Software acquisition officials will work with the Contractor which has the business acumen and market knowledge to assist in strategizing an NIH position with regard to license and cost negotiations with vendors. The partnership between the analysis and purchasing functions will strengthen NIH’s ability to save money on software licenses and receive the terms and conditions that work best given NIH needs. The Program will establish an oversight body that includes IC representation so that the business needs perspective is included in all license and cost negotiations with vendors. The IC-staffed oversight body will ensure a streamlined process for identifying software that meets trans-NIH needs is developed and maintained.

Distribution: CIT currently distributes software for several ICs and can expand this capability to all enterprise software that falls within the Software Program. The procurement function within the Program will coordinate with the distribution team to ensure covered entities receive software they are entitled to and that upgrades, maintenance, and troubleshooting are provided. The Program will add resources to the existing CIT software distribution activities to handle this increase in volume and strengthen the infrastructure. The distribution team will also provide a testing lab and services to ICs to allow them to try software before they purchase it to determine if the software meets their needs, satisfies information security requirements, and works as planned in the NIH environment. The testing environment will also allow NIH to test new releases of existing software, together with the new features, to determine if there is an impact due to other environmental variables. This testing of new features within commonly used software is currently being repeated at each IC, when only a single test with wide distribution of results is needed.

The proposed approach appreciably strengthens the NIH infrastructure by making a commitment to service all of NIH with software asset lifecycle management according to best practices. The approach will simplify acquisition activities across ICs, ensure currency of software products in use at NIH, and simplify the approach for updating software on end-user’s computers.

The Contractor is an integral part of the overall Program, but the Contractor’s scope of work will be within the Software Asset Management component of the overall Software Program.

Following is a diagram that shows stakeholders in the NIH Enterprise Lifecycle Management Program and their relationships with the components and with other resources.

NITAAC 14 of 2818 CIO-SP2i QASP Template June 8, 2010

National Institutes of Health 16 of 27 Office of the Chief Information Officer

Figure 1: Lifecycle Relationships

National Institutes of Health 16 of 27 Office of the Chief Information Officer

5. Current Software Environment Software Purchasing NIH uses the Procurement Information System for Management (PRISM) to track software procurements. PRISM is a web-based, commercial off-the-shelf, procurement and contract management system. It provides a streamlined, end-to-end procurement cycle that integrates and tracks information from the initiation of a requirement, through its solicitation and award. PRISM also tracks information on contract administration, contract closeout, and document archive. While PRISM has the capability to provide contract management for COTS software tracking, use of this feature varies significantly by the ICs and should not be considered a reliable data source for contract management information. The ability to extract and use contract information from PRISM is a critical capability that will require additional attention to improve the format, reliability, and accuracy of data within PRISM so that it is meaningful to SAM analysts and tools. It is the responsibility of contracting officers to input contract-related data in PRISM.

Group Purchasing Program CIT currently operates a software group purchasing program: the Information Systems Distribution & Procurement (ISDP) program. The ISDP program works with contracting officers to negotiate discounted software for NIH and HHS personnel by leveraging large volume purchasing agreements. The program is a full-service operation that performs market research, collects software product information, and negotiates directly with vendors to obtain cost savings that are substantially lower than the General Services Administration (GSA) price for COTS products.

The ISDP program generates cost savings and enables software purchasers to maximize their time and resources by:

Conducting negotiations on behalf of the software purchasers.

Streamlining product accounts to manage costs and forecast demand.

The ISDP program supports all the HHS Operating Divisions and Staff Divisions and serves an estimated 100,000 users – 35,000 of whom are with NIH, and 65,000 affiliated with other HHS operating divisions. In FY18, the ISDP program purchased approximately $74M in software.

The ISDP program will change as the Software Program establishes itself. It may or may not continue to service HHS OpDivs. If it does, it is not clear what inventory and usage data HHS OpDivs will be able to supply.

Standard Software Purchasing NIH does not have a required process for the acquisition of COTS software. Software can be purchased using various sources across the government, which include:

1) NIH Information Technology Acquisition and Assessment Center (NITAAC) Chief Information Officer-Commodities and Solutions (CIO-CS)

2) National Aeronautics and Space Administration (NASA) Solutions for Enterprise Wide Procurement (SEWP) V

3) GSA IT Schedule 70 Other sources of COTS software include office supply stores (e.g., Staples) or through the NIH ISDP software resellers. Most of the 27 ICs and OD manage their own software purchases and software inventory differently. However, they rely on one of the ten Offices of Acquisition established within NIH to process their orders. This approach limits NIH’s ability to manage and optimize the purchasing, licensing, deployment, maintenance, utilization, and disposal of commonly used software assets within the NIH.

Software License Inventory Per OMB Memorandum 16-12, NIH is required to report software license inventory on a quarterly basis. OMB expects agencies to maintain a software asset management (SAM) system that will support inventory management, license life cycle management, contract management, internal rules management and software compliance management.

Currently, NIH OCIO does not have the resources to conduct a comprehensive automated inventory of all 27 ICs and OD. To comply with the requirement to maintain an inventory, OCIO collects limited software acquisition information from the ISDP software program. HHS accepts the manually-generated response with the expectation that NIH is working towards acquiring and deploying a SAM tool that will capture the required core data objects.

Software Asset Management Tool The NIH OCIO’s Information Security Awareness Office deployed a Department of Homeland Security (DHS) Continuous Diagnostics and Monitoring (CDM) tool, IBM BigFix with the Inventory Module. It is deployed at the enterprise level by CIT to comply with DHS requirements for software inventory/configuration management and HHS’ directive that all OpDivs standardize on the tool for this purpose. The NIH (and thus the Contractor) must use BigFix and its Inventory Module for SAM.

At NIH, several ICs manage their own instances of BigFix and may continue to do so. They elect to do so for multiple reasons, such as control patch management, which is not currently available at the enterprise level. ICs that do not have a tool installed are required to install the CIT enterprise instance of BigFix. Regardless, of who owns the instance of BigFix, NIH plans to rely on the data collected by the tool to report software inventory/licensing data to HHS. Because NIH must report as one agency, the current landscape of multiple BigFix instances is problematic. As a solution, N IH will use Splunk (managed within OCIO) Info to collect the data from the IC instances of BigFix so that it can be correlated with the data from the enterprise instance and reported upstream to HHS.

The data it’s pulling for inventory, essentially software installed on NIH hosts, is currently being tagged and routed to Splunk to be shared upstream to the federal dashboard. It’s not yet pulling configuration management data and NIH is still using Tenable Security Center for that requirement.

Software Licensing Maturity Based on Gartner’s SAM Maturity Level Descriptors[footnoteRef:2], NIH is at Maturity Level 1: SAM roles and processes are event-driven or transaction-driven (for example, audit). There is little or no SAM guidance available through the organization's policies. There is little control over what IT assets are used or where, and there is a lack of policies, procedures, resources, and tools. [2: Gartner, Market Guide for Software Asset Management Mangaed Service Providers, February 2018]

NIH’s software licensing maturity is presently being analyzed by HHS, as HHS in turn responds to Legislative and Executive oversight. Implementation of the NIH Enterprise Software Asset Lifecycle Management Program will hopefully improve NIH’s maturity level. Subject matter expertise from the Contractor will help the Program achieve its goals.

Microsoft In February 2019, NIH signed an agreement with Dell to provide Microsoft licenses. Dell is to provide an online portal for order planning, fulfillment, tracking, and reporting all enrollments, licenses, and products procured via the ordering procedures in the agreement with Dell. All Microsoft software will be provided electronically via the Microsoft Volume Licensing Service Center.

6. Scope Recent scans performed by OCIO shows that NIH has roughly 25,000 unique software products installed on computer devices across the NIH.[footnoteRef:3] There is a wide variety of software products installed and/or hosted on various platforms (Unix/Linus, Mac, Windows, mobile, as-a-Service, etc.). Major software vendors include IBM, Adobe, Oracle, Microsoft, and MacAfee. Figure 2: NIH Computing Environment Fact Sheet provides insight into NIH’s current operating environment and indicates the variety of software that NIH uses. Currently, all ICs and OD can purchase software from any vendor at any time. Software is used for both administrative and medical/scientific research. This vast landscape provides insight into the broad scope of software and software management at NIH. [3: These numbers are estimates based on software installed on computing devices attached to the NIH network at the time of the scan. These numbers do not reflect the recent uptick in acquisition of software as a services (SaaS), which are cloud-based software products with no installation requirement, and therefore are not visible to software scans.]

The broad requirement for SAM is to provide NIH with a solution that provides external subject matter expertise to implement tools and processes that will collect detailed knowledge of all the unique software installed across NIH. The data will then be used to develop recommendations for a variety of business decisions related to software. This subject matter expertise will assist government decision makers with recommendations regarding NIH usage, license negotiation, costs, allocation/re-allocation, and technical architecture. The data collected by the subject matter experts will be passed onto the Procurement and Governance component so that contracting officers can negotiate better pricing, which will benefit all of NIH by driving down costs for IT and administrative overhead so that more resources can be applied to the scientific and research mission of NIH.

For the purposes of estimating level of effort for this contract, NIH assumes approximately three to five full time equivalents (FTE) will be needed throughout the period of performance (not including optional services) and provisioning of tools and utilities to meet objectives.

Neither the prime vendor, nor any teaming partners for this requirement may be a software reseller, which NIH considers a conflict of interest when providing optimization advice.

Figure 2: NIH Computing Environment Fact Sheet

7. NIH’s Performance Objectives and Expected Outcomes Overall Objectives The overall objective of this acquisition is to acquire SAM-related activities that involve managing and optimizing the purchase, deployment, maintenance, utilization, and disposal of enterprise software applications within the NIH. To achieve this, the contractor must provide services and deliverables as described to meet objectives.

This solicitation for SAM services is a Performance Work Statement, and is primarily concerned with the realization of performance objectives. The Contractor will be asked to provide an approach for best meeting the performance objectives, to include approaches for ramping up services in a prioritized way. Each objective states added constraints or needs that shall be considered requirements that must be met within the Contractor’s approach, whether explicitly addressed by the Contractor, unless the Contractor explicitly states the requirement cannot be met with the Contractor’s solution.

Automated Inventory Objective: An accurate snapshot of all NIH software usage (consumption) on all platforms at any given time exists in an automated NIH software inventory. This includes all software regardless of the ownership status of the software.

The Contractor shall create and maintain a comprehensive inventory of all NIH COTS software.

IBM BigFix is currently installed at NIH and is used by the OCIO Information Security and Awareness Office for continuous diagnostics and monitoring of assets on the NIH network. The Inventory Module is installed on NIH BigFix instances and data is aggregated among the different instances of BigFix using SPLUNK. The Contractor shall use data obtained by the various instances of BigFix and its Inventory Module along with any other Contractor-supplied tool(s) to collect software inventory data among all platforms that deliver or provide COTS software to NIH. Such platforms include but are not limited to: mobile, desktop and server-based (Windows OS, Mac OS, Unix OS, and Linux OS), virtual server-based, -as-a-service, cloud-hosted, and hybrid-hosted COTS software. NIH uses MobileIron for Mobile Device Management and all mobile devices with access to NIH-networked resources have MobileIron installed. CIT manages the MDM function. Contractor and NIH responsibilities are further described as follows:

A. The Contractor shall discover all NIH COTS software usage data, regardless of the platform, using automated tools, including but not limited to:

a. Network-attached physical and virtualized platforms upon which software executes (this ranges from data center to end-user devices).

b. Cloud-based and mobile platforms and services.

B. The Contractor shall ensure inventory information is shared with all ICs across NIH.

C. NIH shall provide to the Contractor access to BigFix Inventory Module and Splunk-aggregated data.

D. The Contractor shall measure database consumption by tracking hardware details and configuration data.

E. The Contractor shall capture software usage for cloud and SaaS applications by reviewing provider portals. Where such portals or similar capabilities do not exist, the Contractor shall provide tools.

F. The Contractor shall capture platform configuration information, and extract all software information residing within those platforms, along with the usage information. This includes metering of usage for subscription or cloud services.

G. The Contractor shall normalize software usage data: consolidate and resolve duplicate or conflicting records to create a single, accurate, organized and categorized inventory of software.

H. The Contractor shall identify software in the NIH inventory according to nomenclature and Stock Keeping Unit (SKU).

I. The Contractor shall evaluate, assess, and report gaps in the inventory tools NIH has in place, (such as BigFix) and implement alternative technologies so that all NIH software assets are inventoried. The gaps are not limited to platform coverage, software title/publisher coverage, incomplete/inaccurate reporting.

J. The Contractor shall provide inventory reports as requested by NIH.

K. NIH shall own all NIH-COTS usage data in this inventory. At the end of the contract period of performance, the Contractor shall transfer all NIH-owned data to NIH or a follow-on contractor team in a commonly used data format, approved by NIH.

Entitlement and Licensing Analysis Objective: An accurate accounting of all NIH enterprise software entitlements at any given time in an NIH software license management database. The term ‘enterprise’ means all those agreements that are managed at the NIH corporate level rather than by ICs for IC use.

HHS has specified a data taxonomy (See Section 3.1) to be used by HHS OpDivs (such as NIH) when managing software assets. HHS expects OpDivs to report software inventory information using the specified taxonomy. HHS then aggregates all Operating Division data and reports it to executive and legislative bodies as required.

The NIH’s contract data resides in a system called PRISM. NIH will work with PRISM administrators to push contract data (per the HHS data taxonomy) to the Contractor’s preferred inventory management tool for visibility into software entitlement data. Since much of PRISM’s current contract data is unstructured, NIH will work with contracting staff to collect future contract data in accordance with the specified HHS taxonomy. Contractor and NIH responsibilities are further described as follows:

A. NIH shall record all contract transactions in NIH’s contract management system of record, PRISM.

B. NIH shall make it possible to push PRISM software license agreement contract data to a license management database of Contractor’s choosing – the database must be able to cope with the complexity of the available license models, as well as with potential changes in technology.

C. The Contractor shall manage entitlement data so that it is complete, accurate, and of sufficient quality to reconcile entitlements against software usage.

D. The Contractor shall harmonize contract, purchase, and entitlement information with normalized inventory data to create an effective license position (ELP).

E. The Contractor shall assist with cleaning up entitlement data for high priority publishers if reconciliation is needed for contract negotiations in advance of automated entitlement pulls from PRISM.

F. The Contractor shall provide entitlement reports as requested by NIH.

G. NIH shall own all NIH-COTS entitlement data in the software license management database. At the end of the contract period of performance, the Contractor shall transfer all NIH-owned data to NIH or a follow-on contractor team in a commonly used data format, approved by NIH.

License Positions and Recommendations Objective: New license agreements and maintenance on existing ‘enterprise’ agreements are optimized so that NIH does not over or under procure licenses and NIH is able to secure the best value for its investment.

NIH requires regular and systematic reconciliation of license agreements for all platforms. NIH will seek Contractor support when generating new agreements and annually when NIH negotiates maintenance agreements for NIH-wide use. The Contractor shall provide subject matter experts on an as-needed basis to assist NIH in negotiating contracts with software vendors. Out of scope for this task will be licenses purchased by ICs for internal IC use rather than enterprise licenses that will be used across NIH. Contractor and NIH responsibilities are further described as follows:

A. The Contractor shall compare assets/license entitlements against installation and/or usage metrics to establish whether the way in which software is deployed and used is compliant with the terms and conditions under which it was provided by the software vendor or licensor.

B. The Contractor shall compare assets/license entitlements against installation and/or usage metrics to establish whether the way in which software is deployed and used is optimal, given the terms and conditions.

C. The Contractor shall provide recommendations for alternative methods of software deployment for those instances for which deployment and licenses agreements are suboptimal.

D. The Contractor shall determine over-licensing of specific products and recommend strategies for alternative distribution or termination.

E. The Contractor shall determine under licensing of specific products and recommend strategies for meeting license demand or negotiating an alternative agreement.

F. The Contractor shall document the limitations of any tools used to carry out the reconciliation process and include manual validation and intervention where necessary.

G. The Contractor shall provide recommendation on the appropriate license type given specific scenarios for any platform.

H. The Contractor shall perform reconciliation of contracts, purchase, and entitlement information with normalized inventory data on all platforms.

I. The Contractor shall identify and communicate risks and opportunities, to include opportunities for contract consolidation.

J. The Contractor shall identify software that is enterprise-wide versus IC-owned, and be able to draw conclusions and make recommendations for consolidation where appropriate.

K. The Contractor shall provide analytics and other information necessary to draw conclusions and make recommendations regarding NIH’s ELP.

L. The Contractor shall model reconciled data to examine software, entitlements, environment and actual usage so that ‘what-if’ scenarios can be analyzed.

M. The Contractor shall provide full support of key enterprise partners including but not limited to Microsoft, Oracle, Adobe, IBM, and McAfee.

N. The Contractor shall provide reconciliation reports as requested by NIH.

NIH Enterprise Software Asset Lifecycle Management Program Support Objective: Contractor participates as a member of the NIH Enterprise Software Asset Lifecycle Management Program as a subject matter expert so that the Program develops, operates, and matures in accordance with NIH needs.

A. The Contractor shall calculate Program cost savings and report the savings along with details about what lead to the savings. Details may include sources of savings such as through license harvesting, software re-deployment, shifts in the mix of fixed versus concurrent licensing or other approaches.

B. The Contractor shall attend and participate in operational or planning meetings at which governance, policy, and process are discussed.

C. The Contractor shall provide recommendations for governance, policy, and process additions or changes related to the NIH Enterprise Software Asset Lifecycle Management Program.

D. The Contractor shall provide reports and information that documents the amounts owed by ICs and OD for enterprise software based on consumption, entitlements and/or, other cost calculation data.

Audit Readiness Objective: Minimize the impact of an audit.

A. The Contractor shall provide continuous management of software licenses to determine NIH’s ‘enterprise’ ELP and protect against potential fines for non-compliance.

B. If a software audit is conducted by a publisher or other party, the Contractor shall provide advice and support to help minimize the financial, performance, and public relations impact.

C. The Contractor shall perform internal audits and share results and recommendations with the NIH Enterprise Software Asset Lifecycle Management Program.

Software Ordering (Optional) Objective: Reduce waste and save money by harvesting software for re-use.

NIH will create an ordering interface (using ServiceNow or SharePoint for example) that includes the titles and cost of software that is maintained by the Software Program. NIH will ensure requests are routed to the Contractor, which will then be responsible for the following:

A. The Contractor shall intake software requests for NIH and determine if request should be fulfilled with existing ‘enterprise’ entitlement, if a new ‘enterprise’ entitlement should be purchased, if the request can be fulfilled via a true-up of an existing entitlement, or if the Software Program should defer the request to the IC for local procurement.

B. The Contractor shall review software requests and determine feasibility of leveraging existing licenses and/or matching requirement to the most appropriate license instance to minimize shelfware and unnecessary expenditures.

C. The Contractor shall re-assign software to minimize waste while at the same time meeting user requirements.

D. The Contractor shall ensure software requesters are notified if the NIH Enterprise Software Asset Lifecycle Management Program is unable to meet their software request.

Transition Out (Optional) Objective: Transition contract performance to another Contractor or to the government without disrupting day-to-day operations of the SAM function.

A Transition Plan shall be completed and agreed to by NIH prior to the transition of knowledge, work-in progress, and/or assets off of this contract. The Contractor shall play a key role in the planning of transitions and the creation of a Transition Plan, and shall comply with transition milestones and schedules of events. A Transition Out Plan shall be delivered 120 days before the expiration of the contract. The Contractor shall be responsible for the implementation of the transition and cutover activities.

The Contractor is responsible for planning and execution of the transition. As part of transition, the Contractor shall (as applicable):

Inventory and transfer all GFE to include devices, software, licenses, Contractor-acquired government property, and Government Furnished Information (GFI).

Transfer all inventory and entitlement data in a format that conforms to an industry standard capable of being transported to other systems to either NIH or another contractor, as instructed.

Transfer relevant completed and in-process documentation.

Transfer all non-proprietary software code in process, such as interfaces to NIH-systems.

Certify that all non-public Health and Human Services (HHS) information has been purged from any Contractor-owned or managed system, as requested.

Exchange accounts for accessing software and hosted infrastructure components.

Participate in knowledge transfer activities in accordance with the Transition Plan.

Provide members and participate in a Transition Management Team (TMT).

The Transition Plan shall:

Document the strategic approach.

Identify devices, hardware, software, licenses, documents and other artifacts that are included in the transition and its phases.

Establish milestones and schedules.

Establish activities.

Identify transition risks and risk mitigation.

Define roles and responsibilities.

Define transition approval authorities and lines of communication.

Define a communications approach.

Define a knowledge transfer approach.

Define a property inventory and transition approach.

Create tri-party agreements.

Provide checklists.

The government is and shall remain owner of all data (to include data discovered and created through the contract) associated with NIH software inventory, software consumption, software entitlements, and NIH’s software license position. In the event of termination for any reason, all Contractor-managed data on behalf of NIH shall be delivered in a format that conforms to an industry standard capable of being transported to other systems.

Period of Performance

The resulting award period of performance is a base period of 12 months with two (2) 12-month option periods, unless the period is extended by modification to this task order. Option periods are subject to availability of funds and may be unilaterally exercised by the government.

Roles and Responsibilities - Key Personnel

The NIH considers the selection of the key personnel who work on this contract to be critical to the success of the Program. Those identified as key personnel must have demonstrable experience in the work areas identified in the proposed solution and their resumes shall be submitted for review and approval by NIH.

Neither the prime vendor, nor any teaming partners for this requirement may be a software reseller, which NIH considers a conflict of interest when providing optimization advice.

The primary roles and responsibilities of key personnel and others vital to the success of the Program are described in Table 5: Roles and Responsibilities

The Contractor has the opportunity to identify the management team and key personnel. Key personnel shall:

A. Have sufficient expertise to address the management, functional, and technical aspects of the Contractor’s solution.

B. Be full-time employees of the prime contractor.

C. Ensure that all work on this contract complies with contract terms and conditions.

D. Have access to Contractor corporate senior leadership when necessary.

E. Be the primary Contractor interface to NIH Enterprise Software Asset Lifecycle Management Program officials.

The Contractor shall:

F. Identify key personnel.

G. Provide statements of qualifications for key personnel.

H. Manage substitutions or additions to key personnel, by:

1. Immediately notifying the Contracting Officer in writing.

2. Presenting the resume of the proposed replacement within 30 days.

3. Proposing replacements that have at least substantially equal ability and qualifications as the outgoing personnel.

4. Submitting requests for key personnel changes in writing via email to the Software Program Manager, contracting officer, and Contracting Officer Representative (COR) and providing a detailed explanation of circumstances necessitating the proposed change.

Contractor Program Manager(s) (Key Personnel)

· Responsible for implementing objectives and adherence to all SLAs.

· Responsible for all performance outcomes.

· Manages the contract and all deliverables.

· Manages cost, quality, and schedule.

· Ensures transitions onto and off contract occur as planned.

· Manages risk so that issues do not occur.

· Performs functions specified in the PWS.

Contracting Officer Representative (COR) (Government)

· Interfaces with the Contracting Officer, Contractor Program Manager(s), Contractor Subject Matter Experts, and other members of the NIH Enterprise Software Asset Lifecycle Management Program to ensure problems, risks, and issues are identified, monitored, tracked, and resolved.

· Validates that SLAs are adhered to by the Contractor.

· Monitors performance and ensures business value is delivered.

· Ensures deliverables meet delivery standards.

· Reviews invoices and raises issues with the Contracting Officer.

· Ensures license data is available for pairing with consumption data.

· Negotiates contracts with software sellers and resellers.

· Signs license agreements with software sellers and resellers.

· Reviews software license invoices.

· Ensures software licenses are appropriately funded.

· Deploys software and updates.

· Removes out-of-compliance and unneeded software.

Table 5: Roles and Responsibilities

Deliverables/Delivery Schedule In order to achieve the objectives described in Section 7, the contractor must propose deliverables and an associated delivery schedule. At a minimum, the following deliverables and delivery schedule must be included. The schedule is expressed in terms of calendar days.

Implementation Project Plan

Draft – 30 days after contract award Final – 60 days after contract award

Table 6. Deliverable Schedule Service Level Agreements and Performance Standards All services delivered will be required to meet contractor-offered Service Level Agreements (SLAs).