Previous PageTable Of ContentsNext Page

DLAD PART 39 – ACQUISITION OF INFORMATION TECHNOLOGY (IT)



PART 39 – ACQUISITION OF INFORMATION TECHNOLOGY (IT)

(Revised December 20, 2013 through PROCLTR 2014-54)

TABLE OF CONTENTS

SUBPART 39.2 – ELECTRONIC AND INFORMATION TECHNOLOGY

39.201 Scope.

SUBPART 39.74 – TELECOMMUNICATIONS SERVICES

39.7402 Policy.

SUBPART 39.90 – PROCEDURES, APPROVALS AND TOOLS

39.9001 Procedures for IT Procurement.

39.9002 Documentation Requirements for IT Procurement.

SUBPART 39.2 – ELECTRONIC AND INFORMATION TECHNOLOGY (E & IT)

39.201 Scope.

(a) General Service Administration (GSA) requires all contracts and purchase requests for E&IT, regardless of cost, to include Section 508 requirements as well as the 508 technical standards for each category of E&IT products and services being obtained. However, note that the GSA IT-70 solicitation contains Section 508 requirements.

(b) Further information on Section 508 is available via the internet and on the intranet in eWorkplace under J6.

39.204 Exceptions. Consult with the procuring organization’s office of counsel when seeking an exception to having the acquisition of E&IT supplies and/or services meet the applicable accessibility standards at 36 CFR Part 1194, E&IT Accessibility Standards.

SUBPART 39.74 – TELECOMMUNICATIONS SERVICES

39.7402 Policy

(b)(4) Process recommendations to provide property pursuant to DFARS 239.7402 (b)(4) through the DLA Acquisition Operations Division, who will coordinate with the Director, DLA Acquisition (J7) for the necessary authorization.

SUBPART 39.90 – PROCEDURES, APPROVALS AND TOOLS

39.9001 Procedures for IT procurement.

(a) All mid-tier requirements must be coordinated with J6 and other business offices as needed, e.g., J8, prior to submission to the contracting office. Mid-tier refers to equipment that is in the range between individual work stations and mainframe computers. Mid-tier uses include client servers, network controllers, process controllers, and dedicated single application processors.

(b) DLA Document Services is the single office with authority to procure office document devices and their associated maintenance support and consumables (and is an optional source for paper). These devices include network and stand-alone copiers, printers, multi-functional devices, scanners, fax machines, and related support services. Upon request to the DLA Document Services CCO, waivers to this mandate will be reviewed for approval by DLA Document Services.

(c) The DLA Contracting Services Office (DCSO) is responsible for acquiring IT services, supplies, equipment (other than office document devices procured by DLA Document Services), training, and/or subscriptions for DLA. Non-DCSO procuring organizations may award contracts or orders for IT if the total value of the contract or order (including options) does not exceed $500,000.

(d) Requirements with a value exceeding the threshold of $500,000 shall be procured by DCSO, unless approval of the DCSO CCO is obtained. Non-DCSO procuring organizations shall request this procurement authority in writing to the DCSO CCO who will determine whether the procurement action will be performed by the non-DCSO procuring organization or DCSO based on the facts presented.

(e) Proposed use of the Defense Information Systems Agency defense enterprise integration services contracts shall be submitted to the DLA CIO, through the DCSO, unless otherwise authorized in writing by the DLA CIO.

(f) All requirements to be acquired using the GSA federal systems integration and management program shall be staffed through the DCSO to the DLA CIO for informational purposes and investment accountability by the DLA CIO.

(g) Refer to section 4.1302 when acquiring personal identity verification products and services.

(h) Prior to acquiring commercial software or software maintenance the contracting officer shall review DFARS Subparts 208.74 and 227.72, the DLA Issuance, Smartbuy and Enterprise Software Initiative (ESI) Enterprise Service Agreements (ESA), which is accessible through eWorkplace, and the DLA Information Technology Solutions Document. Requests for waiver in accordance with DFARS PGI 208.7403 and DFARS 227.72 shall be submitted to J6 (see DLA Issuance, Smartbuy and Enterprise Software Initiative (ESI) Enterprise Service Agreements (ESA), 4.6.3.2). .

(i) Any requirements that require the contractor to develop, store, process, display or transmit information that is used in any DLA business process must be coordinated with J-6 in the acquisition planning stage.

(j) Consult the DLA Information Technology Solutions Document in DLA eworkplace under J6 to ensure that there are no existing IT solutions that can meet the acquisition requirement.

(1) Though this document provides Agency IT solutions, the contracting officer must ensure that all necessary procurement requirements are followed when using sources listed therein. Some areas to consider include the competitive process (see FAR 6.1), sole source and limited source justifications (see FAR Subpart 6.3 and FAR 8.405-6), including brand name situations, economies of scale and scope of the listed source(s).

(2) Contact J-6 to request the addition of a new solution to the document.

(k) For telecommunications equipment and services:

(1) The contracting officer shall ensure that, for capital investment requirements $250,000 or greater, capital investment funding shall be used.

(2) Communication Services Authorities or other communications services orders or agreements shall be signed by the contracting officer.

(l) Internal Use Software (IUS).

(1) As defined in Statement of Federal Financial Accounting Standards (SFFAS) Number 10, Accounting for IUS, “IUS” is software used to operate a federal entity’s programs (e.g., financial, administrative and project management software), and to produce the entity’s goods and services.

(2) Requiring activity program managers are responsible for: classifying a software procurement as IUS, structuring software requirement deliverables in accordance with the IUS CLIN classification guidelines stated in paragraph (m)(4) below, and preparing the IUS classification and acknowledgement certification form identified in paragraph (m)(4) below.

(3) Contracting officers are responsible for validating that the CLINs have been properly assigned in accordance with paragraph (m)(4) (i) below, signing the certification in paragraph (m)(4)(ii) below ( Internal Use Software Acknowledgment Certification) ensuring contractors submit invoices in accordance with the CLIN structure, and ensuring contracting officer representatives (COR) accept contractor deliverables and invoices consistently with the invoiced CLINs. A copy of the signed certification shall be placed in the contract file. Validating the CLINs can be delegated to CORs but must be certified by the contracting officer.

(4) Contract Line Item Number Capitalization Table and Software Acknowledgement Certification.

(i) CLIN Capitalization Table for Internal Use Software (IUS).

Table 1

Contract Line Item Number (CLIN) Capitalization Table for Internal Use Software (IUS)

CLIN

Title

Description

Work Products, Deliverables, and Major Reviews

Example Costs

Capitalized or Expensed?

CLIN 0001

Acquisition/

Design

This phase includes all actions leading to source selection of a commercial off the shelf (COTS) or other commercial source. For internally developed software, this phase includes all actions prior to system requirements specification (SRS).

•Determination of existence of needed technology

•Conceptual formulation of alternatives

•Evaluation and testing of alternatives

•Final selection of alternatives

Labor

Travel

Expensed

CLIN 0002

Program Management

Program management activities include developing budgets, monitoring cost and schedule, forming the project team, and monitoring technical performance of the project. Additional critical functions include risk and issue management, schedule management, earned value management (EVM) metrics and documentation, performance management, and configuration management. It includes identifying all necessary activities required for production readiness and assisting in the development and deployment of the plan. Project management activities are performed across the entire project life-cycle.

Business Case Analysis (BCA)

Governance Charter

Performance Measurement Plan (PMP)

Scope Document

Formulation Authorization Document (FAD)

System Concept Document

Memorandums of Understanding (MOUs) 

Project Schedule (resource loaded)

Acquisition Plan and Documents

Risk Management Plan

Framework Agreement Document

PMC Formulation Request

Budget Documentation

Risk Reviews

Business Impact Assessment

Workforce Analysis

Transition Management Plan

Service Level Agreement

• Operations Level Agreement

Labor

Travel

Program manage-ment office (PMO) indirect costs shall be expensed or capitalized, depending on: 1) their materiality to overall cost of individual software develop-ment projects and 2) in which phase the costs were incurred.

CLIN 0003

Software Development

Perform preliminary and detailed design. (This is

specific to an implementation). Conduct unit testing. Develop supplemental materials such as end user procedures and job aids.

Design Documents

Software

configuration and

interfaces

Software Coding

Technical system

documentation

Unit testing plans and

results

Software

functionality

Development of end

user procedures, user

manuals and/or job

aids

Process flows

Training

development

Labor

Travel

Capitalized

CLIN 0004

Data Conversion

Data conversion plans developed identifying conversion source systems and the data conversion strategy. The data conversion plan will document the source data layout, business rules requirements, mapping requirements, security requirements, and reporting requirements for each conversion. Mock data conversion tests are conducted and data conversion system requirements specifications developed.

Data Conversion

Plan

Data conversion

mapping

documentation

Mock data

conversions

Migrated data

Labor

Travel

Expensed

CLIN 0005

Technical Architecture

Technical architecture focuses on the system concept documentation as well as the development of the system environments for design and modeling. Technical architecture develops all system environments for the development and production of the system including: development environment, systems integration testing environments, performance testing environment, training environment, and production environment.

Operations Plan

Performance Test

Plan

Systems Architecture

Test Plan

System Integration

Test (SIT) -1 Environment

SIT-2 Environment

SIT-3 Environment

Performance Test Environment

Training Environment

Production Environment

Labor

Travel

Capitalized

CLIN 0006

Security

Focuses on security requirements for the life-cycle of the project. Initial tasks include the identification of the project security categorization, assessment of security risks, and the documentation of contingency plans. A security business impact assessment is conducted along with security planning, risk mitigation planning, and privacy impact assessments for personal identifiable information (PII) and sensitive data (SD).

Preventative Controls

Recovery Strategy

Privacy Impact

Assessment (PIA)

Sensitive Data

Review (SDR)

Security Risk

Assessment

Security Risk

Mitigation Plan

Security Functional Requirements Analysis Report

Security Assurance Requirements Analysis Report

Cost Considerations and Reporting

Security Controls

Security Test and Evaluation Process

Functional Validation Report 

System Integration Rpt

Security Certification and Accreditation Rpt

IT Contingency Plan

Contingency Testing, Training and Exercise Plan

PII / SD Report

Configuration Management and Control Plan

Labor

Travel

Capitalized

CLIN 0007

Testing

Testing tracks and documents participation in systems integration testing iterations. The test plans and test scripts will be developed and documented to verify and validate the system design.

SIT plan

System Integration

Test Scripts

Regression Testing

Parallel processing

Labor

Travel

Capitalized

CLIN 0008

Deployment

Deployment comprises all tasks completed to prepare the module for production, Go-Live, and stabilization activities. Procedures are developed in support of system transition as well as post “go-live” procedures for the end users and support staff. Interface programs are executed and validated, and volume and stress tests are performed. Also, the project works closely with the users to develop clear performance, service, and business measurements for the system, as well as expectations for metric data collection, evaluation, and reporting. Readiness reviews and operational readiness review (ORR) are conducted and documented within this deployment. Go-live includes the formal handover of the module from a preproduction environment to the support staff operating the production environment. Project team members help execute the transition plan and document lessons learned. The module is put into production. System and business performance metrics may be collected and evaluated.

Operational Readiness Review (ORR)

Project Completion

Review (PCR)

Labor

Travel

Expensed

CLIN 0009

User

Implementa-tion

User implementation focuses on the work and costs associated with the rollout of the software solution to the individual users. This includes activities conducted to aid in identifying user requirements, interfaces, or data migration efforts. It also includes activities associated with actual implementation at specific locations, communication, process redesign, &data cleanup.

Project Plan

Risk Management Plan

Transition (Cutover) Plan

Operations Plan

Operational Readiness Review (CORR)

Labor

Travel

Expensed

CLIN0010

Post-Implementa-tion/Opera-tional Phase

Post-implementation includes all operational testing and evaluation, as well as other functional testing conducted after technical acceptance and includes costs incurred to make customer ease of use changes.

•Application maintenance

•Implementation assistance (trouble- shooting, systems analysis, producing/ printing user manuals and similar support to project customers)

Labor

Travel

Expensed

(ii) IUS Software Acknowledgment Certification.

IUS Software Acknowedgement Certification is required to ensure all costs associated with IUS[*] activities received the proper accounting treatment. The Project Manager must include the attached CLIN structure in all IUS requests for proposals (RFP), statement of objectives (SOO), and/or performance work statements (PWS) along with the instructions for invoicing.

Table 2

Internal Use Software Acknowledgment Certification

Certification:
I certify the following information was included in the:

Document:

CLIN structure included:

If not, state reason:

RFP

   

SOO

   

and/or

   

PWS

   

Project Name:

 

Project Manager:

 

Phone:

 

E-mail:

 

Contracting Officer:

 

Phone:

 

E-mail:

 

Project Manager Signature _____________________________________Date____________

Contracting Officer Signature____________________________________Date____________

All originals must be filed, scanned, and available upon request.

Copies should be provided to the appropriate contracting officer, contracting officer’s representative, program manager, APO, and FSA.

*Software includes the application and operating system programs, procedures, rules, and any associated documentation pertaining to the operation of a computer system or program. “Internal use software” means software that is purchased from commercial vendors “off-the-shelf,” internally developed, or contractor-developed solely to meet the entity’s internal or operational needs. Normally software is an integral part of an overall system(s) having interrelationships between software, hardware, personnel, procedures, controls, and data.

Reference: Federal Accounting Standards Advisory Board, Accounting for Internal Use Software, Number 10, June 1998; Definitions 8, 9; Page 3.

39.9002 Documentation requirements for IT procurement.

(a) The requiring activity shall provide the following documentation to the contracting office to be included in the contract file:

(1) A statement clearly describing why the IT is needed and the program/project/Automated Information System being supported by the IT procurement;

(2) A description of what is being acquired. Identify the product (including its intended purpose, if that is not clear from the name of the product), manufacturer and model number, version number, quantity, unit cost and any other attributes such as essential physical characteristics. For support services include a Statement of Work;

(3) Include the exact location and point of contact with commercial and DSN telephone numbers.

(4) A copy of the market survey for each recommended source (see FAR Part 10);

(5) A copy of the funding documentation;

(6) For sole source (e.g., only one source, specific make or model, or compatibility-limited) provide the contracting office documentation that can be used to support a justification for other than full and open competition or limited source justification (see FAR 6.3 and 8.405-6), and brand name situations (see FAR 11.105).

(7) Attach a copy of any miscellaneous information and/or supportive documentation necessary.

(b) Additional documentation and/or Business Case Analysis (BCA) shall also be prepared as part of the contract file for an acquisition as needed.

(1) Acquisitions valued below $50,000 shall be submitted in accordance with local procedures, or as appropriate for the complexity of the requirement.

(2) For acquisitions greater than or equal to $50,000 and less than $250,000 outline and compare the status quo method of business with three alternatives.

(3) For acquisitions greater than or equal to $250,000 and less than $1,000,000, in addition to the requirements of (b)(2) above, provide a detailed comparison of the expected costs, benefits, impacts and risks that would result from implementing alternative IT investments.

(4) For acquisitions greater than or equal to $1,000,000 and/or having a significant impact on DoD logistics operations, in addition to the requirements of (b)(2) and (b)(3) above, the analysis must be more in-depth. The analysis requires a study of the impact on DLA as a whole, as well as the quantitative and qualitative ramifications of the alternatives described within the investment. It considers the broad implications of the implementation of each alternative, including local and global implications, as well as immediate and future costs and savings.

(5) Refer to the DLA Issuance, Acquisition Business Case Analysis Process, for guidance on acquisition BCAs. Note explanation of exemptions provided at paragraph 3.a.

Previous PageTop Of PageTable Of ContentsNext Page