A Statement of Work (SOW) is typically used when the task is well-known and can be described in specific terms.
Statement of Objective (SOO) and Performance Work Statement (PWS) emphasize performance-based concepts
such as desired service outcomes and performance standards. Whereas PWS/SOO's establish high-level outcomes
and objectives for performance and PWS's emphasize outcomes, desired results and objectives at a more detailed
and measurable level, SOW's provide explicit statements of work direction for the contractor to follow. However,
SOW's can also be found to contain references to desired performance outcomes, performance standards, and
metrics, which is a preferred approach.
The Table of
Co
ntent below
is
informational only
and
is
provided
to
you
for
purposes
of
outlining
the
PWS/SOO/SOW.
This
sample is
not all inclusive,
therefore the reader
is
cautioned
to
use professional judgment
and
include agency
specific references
to
their
own
PWS/SOO/SOW.
Soft
ware Application and Web-based Service Interface Page 1 of 36
B.1 GENERAL DESCRIPTION ............................................................................................................................... 3
B.2 SERVICES AND PRICES/COSTS .................................................................................................................... 3
B.3 INDIRECT / MATERIAL HANDLING RATE .................................................................................................
3
B.4 INCREMENTAL FUNDING LIMITATION OF GOVERNMENT’S OBLIGATION ..................................... 4
B.5 CONTRACT ACCESS FEE ............................................................................................................................... 5
C.1 PURPOSE ........................................................................................................................................................... 5
C.2 BACKGROUND................................................................................................................................................. 5
C.2.1 AGENCY MISSION........................................................................................................................................... 6
C.2.2 CURRENT ENVIRONMENT ............................................................................................................................ 7
C.3 SCOPE ................................................................................................................................................................ 7
C.4 OBJECTIVE........................................................................................................................................................ 7
C.5 TASKS ................................................................................................................................................................ 8
C.5.1 TASK 1 - DEVELOPMENT, MODERNIZATION AND ENHANCEMENT (DME) ...................................... 8
C.5.2 TASK 2 – STEADY-STATE CORRECTIVE MAINTENANCE .................................................................... 13
C.5.3 TASK 3 – MONTHLY STEADY-STATE OPERATIONAL SUPPORT ........................................................ 17
C.5.4 TASK 4 – TRANSITION SERVICES.............................................................................................................. 20
C.6 SECTION 508 COMPLIANCE ........................................................................................................................ 20
D.1 DELIVERABLES MEDIA ............................................................................................................................... 21
E.1 PLACE OF INSPECTION AND ACCEPTANCE ........................................................................................... 21
E.2 SCOPE OF INSPECTION ................................................................................................................................ 22
E.3 BASIS OF ACCEPTANCE .............................................................................................................................. 22
E.4 INITIAL DELIVERABLES.............................................................................................................................. 22
E.5 WRITTEN ACCEPTANCE/REJECTION BY THE GOVERNMENT............................................................ 22
E.6 NON-CONFORMING PRODUCTS OR SERVICES ...................................................................................... 22
F.1 PLACE OF PERFORMANCE.......................................................................................................................... 23
F.2 PERIOD OF PERFORMANCE........................................................................................................................ 23
F.3 TASK ORDER SCHEDULE AND MILESTONE DATES ............................................................................. 23
F.4 PLACE(S) OF DELIVERY .............................................................................................................................. 27
F.5 NOTICE REGARDING LATE DELIVERY.................................................................................................... 27
G.1 INVOICE SUBMISSION ................................................................................................................................. 28
G.2 INVOICE REQUIREMENTS........................................................................................................................... 28
G.2.1 INVOICING INSTRUCTIONS ........................................................................................................................ 28
G.2.2 TRAVEL........................................................................................................................................................... 29
G.3 LIMITATION OF COSTS................................................................................................................................ 29
H.1 GOVERNMENT FURNISHED PROPERTY (GFP) ....................................................................................... 29
H.2 GOVERNMENT FURNISHED INFORMATION........................................................................................... 29
H.3 TRAVEL........................................................................................................................................................... 30
H.3.1 TRAVEL REGULATIONS .............................................................................................................................. 30
H.5 SECURITY REQUIREMENTS........................................................................................................................ 30
H.5.1 SECURITY POLICY........................................................................................................................................ 30
H.5.2 SECURITY AND OTHER COMPLIANCE CONCERNS .............................................................................. 30
H.6 KEY PERSONNEL........................................................................................................................................... 31
H.7 ORGANIZATIONAL CONFLICT OF INTEREST AND NON-DISCLOSURE REQUIREMENTS ............ 31
H.7.1
ORGANIZATIONAL CONFLICT OF INTEREST ......................................................................................... 31
H.8 TRANSFER OF HARDWARE/SOFTWARE MAINTENANCE AGREEMENTS TO FOLLOW-ON
CONTRACTORS.............................................................................................................................................. 32
H.9 EARNED VALUE MANAGEMENT CRITERIA ........................................................................................... 32
I.1
FEDERAL ACQUISITION REGULATION (48 CFR CHAPTER 1).............................................................. 33
I.2
FAR 52.217-8 OPTION TO EXTEND SERVICES (NOV 1999) .................................................................... 33
I.3
FAR 52.217-9 OPTION TO EXTEND THE TERM OF THE CONTRACT (MAR 2000).............................. 33
J.1
LIST OF ATTACHMENTS.............................................................................................................................. 33
Sof
tware Application and Web-based Service Interface Page 2 of 36
STATEMENT OF WORK
Project Name & ID: ______________
May 1, 2011
NOTE: Paragraphs B.1 through B.3 of the offeror’s awarded Alliant GWAC are applicable to this Task Order
Request (TOR) and are hereby incorporated by reference. In addition, the following applies:
B.1 GENERAL DESCRIPTION
Consistent with Agency and Federal goals of enterprise, shared-solution, and service-based approaches to
information technology: services may include a new systems, consolidate and/or integrate systems, develop
interfaces with other systems/services, and expand the existing systems to also support other program areas, and,
potentially, support data and requirements from other Federal Government agencies.
The Contractor shall perform the effort required by this task order on a Labor Hour and Firm Fixed Price (hybrid)
basis. The work shall be performed in accordance with all sections of this task order and the offeror’s Alliant
GWAC, under which the resulting task order will be placed. The Contractor must propose labor categories and
hourly rates that are contained within its Alliant contract, at fully burdened rates that do not exceed the benchmark
rates established for each particular labor category in its Alliant contract. Therefore, for the purposes of this task
order, the labor rates shall not exceed the benchmark rates unless the Contractor proposes a specialized or rare labor
category not explicitly defined by any established labor category description in the Alliant GWAC. If a highly
specialized or rare labor category is proposed, the Contractor must provide the appropriate support rationale. Please
reference Section L.7(c) Price Supporting Documentation (Tab C).
B.2 SERVICES AND PRICES/COSTS
The following abbreviations are used in this Task Order Request:
(CLIN) Contract Line Item Number
(FFP) Firm Fixed Price
(LH) Labor Hour
(NSP) Not Separately Priced
(NTE) Not to Exceed
Note: An Indirect Handling Rate Or Other Overhead Charges (Such As G&A) Shall Only Be Included If The
Underlying Contract Allows The Application Of Such A Charge And Includes The Negotiated Rate/Charge.
The Nte Ceiling Amount Represents The Maximum Amount Of The Government’s Liability. The Contractor
Exceeds The Ceiling At Its Own Risk.
*Transition-In Services (Clin 0004) Applicable To Base Year Only
Transition-In Services Are Not Anticipated For The Incumbent. Therefore, These Services Should Not Be Proposed
By The Incumbent.
All Other Offerors Shall Price Transition-In Services Separately From The Total Price Of The Base Year.
B.3 INDIRECT / MATERIAL HANDLING RATE
Travel will be reimbursed at actual cost in accordance with the limitations set forth in FAR 31.205-46.
Software Application and Web-based Service Interface Page 3 of 36
Profit shall not be applied to travel costs. Contractors may apply indirect costs to travel in accordance with the
Contractor’s usual accounting practices consistent with FAR 31.2.
B.4 INCREMENTAL FUNDING LIMITATION OF GOVERNMENT’S OBLIGATION
(a) Contract line item(s) (CLINs) * through * are incrementally funded. For these item(s), the sum
of $ * of the total ceiling is presently available for payment and allotted to this task order. An allotment
schedule is set forth in paragraph (j) of this clause.
* To be inserted at time of award - after negotiation.
(b) For item(s) identified in paragraph (a), the Contractor agrees to perform up to the point at which the
total amount payable by the Government, including reimbursement in the event of termination of those
item(s) for the Government’s convenience, approximates the total amount currently allotted to the contract.
The Contractor is not authorized to continue work on those item(s) beyond that point. The Government
will not be obligated in any event to reimburse the Contractor in excess of the amount allotted to the task
order for those item(s) regardless of anything to the contrary in the clause entitled “Termination for
Convenience of the Government.” As used in this clause, the total amount payable by the Government in
the event of termination of applicable contract line item(s) for convenience includes costs, profit, and
estimated termination settlement costs for those item(s).
(c) The Contractor will notify the Contracting Officer in writing at least ninety days prior to the date when,
in the Contractor’s best judgment, the work will reach the point at which the total amount payable by the
Government, including any cost for termination for convenience, will approximate 85 percent of the total
amount then allotted to the task order for performance of the applicable item(s). The notification will state
(1) the estimated date when that point will be reached and (2) an estimate of additional funding, if any,
needed to continue performance of applicable line items up to the next allotment of funds. The notification
will also advise the Contracting Officer of the estimated amount of additional funds that will be required
for the timely performance of the item(s) funded pursuant to this clause, for a subsequent period as may be
specified in the allotment schedule in paragraph (i) of this clause or otherwise agreed to by the parties. If
after such notification additional funds are not allotted by the date identified in the Contractor’s
notification, or by an agreed substitute date, the Contracting Officer will terminate any item(s) for which
additional funds have not been allotted, pursuant to the clause of this contract entitled “Termination for
Convenience of the Government.”
(d) When additional funds are allotted for continued performance of the contract line item(s) identified in
paragraph (a) of this clause, the parties will agree as to the period of task order performance which will be
covered by the funds. The provisions of paragraphs (b) through (d) of this clause will apply in like manner
to the additional allotted funds and any agreed to substitute date, and the task order will be modified
accordingly.
(e) If, solely by reason of failure of the Government to allot additional funds, by the dates indicated below,
in amounts sufficient for timely performance of the contract line item(s) identified in paragraph (a) of this
clause, the Contractor incurs additional costs or is delayed in the performance of the work under this task
order and if additional funds are allotted, an equitable adjustment will be made in the price or prices
(including appropriate target, billing, firm fixed price, and ceiling prices where applicable) of the item(s),
or in the time of delivery, or both. Failure to agree to any such equitable adjustment hereunder will be a
dispute concerning a question of fact within the meaning of the clause entitled “Disputes.”
(f) The Government may at any time prior to termination allot additional funds for the performance of the
contract line item(s) identified in paragraph (a) of this clause.
(g) The termination provisions of this clause do not limit the rights of the Government under the clause
entitled “Default.” The provisions of this clause are limited to the work and allotment of the contract line
item(s) identified in paragraph (a) of this clause. This clause no longer applies once the contract line
item(s) identified in paragraph (a) of this clause are fully funded except with regard to the rights or
Software Application and Web-based Service Interface Page 4 of 36
obligations of the parties concerning equitable adjustments negotiated under paragraphs (d) and (e) of this
clause.
(h) Nothing in this clause affects the right of the Government to terminate this task order pursuant to the
clause of the underlying contract entitled “Termination for Convenience of the Government.”
Nothing in this clause shall be construed as authorization of voluntary services whose acceptance is
otherwise prohibited under 31 U.S.C. 1342.
(j) The Government has allotted funds to this task order in accordance with the following table:
CLIN
DATE FUNDING
OBLIGATED
TOTAL TASK
ORDER
ESTIMATED
CEILING PRICE
AMOUNT OF
FUNDING
OBLIGATED
TOTAL FUNDED
ESTIMATED
CEILING PRICE
0001, 0002, 1001,
1002, 2001, 2002,
3001, 3002, 4001,
4002
month/day/year
$
$
$
Total
$
$
$
B.5 CONTRACT ACCESS FEE
The Contract Access Fee (CAF) is ¾ of a percent (i.e., 0.0075) to be applied to the total price/cost for contractor
performance as billed to the Government.
The formula is: Total CAF = Total Price or Costs * CAF Percentage.
On all Orders, regardless of Order type, Contractors must estimate CAF in their proposals and OCOs may fund CAF
as a separate Contract Line Item Number (CLIN).
The Contractor remits the CAF to GSA in accordance with Alliant GWAC Section G.9.5.
C.1 PURPOSE
The purpose of this task order is to obtain services related to the Operations, Corrective Maintenance, and
Development/Modernization/Enhancement (DME), of the Agency’s electronic grants management (eGrants) and
other related Information Technology (IT) systems. These systems primarily support program offices.
The current IT systems within scope of this task order include Integrated Disbursement and Information System
Online (IDIS OnLine), Performance Measurement System (PERMS), and the Title V system. Consistent with
Agency and Federal goals of enterprise, shared-solution, and service-based approaches to information technology:
services may also be required to develop new systems, consolidate and/or integrate systems, develop interfaces with
other systems/services, and expand the existing systems to also support other program areas, and, potentially,
support data and requirements from other Federal Government agencies.
C.2 BACKGROUND
Offices under the Office of the Chief Information Officer (OCIO) monitor most IT functions in the Agency.
Systems (applications) work is currently performed under the OCIO Office of Systems Integration and Efficiency
(OSIE). Additionally, staff in the division serves as the focal point in coordinating the technical activities involved
with other OCIO organizations including the Chief Information Officer and Deputies, Investment Management,
Enterprise Architecture (EA), Policy and e-Gov, IT Operations, and IT Security offices.
The Agency serves as the focal point for coordinating efforts with external stakeholders including grantees, public
interest groups, citizens, White House Office of Management and Budget (OMB), and Congress.
Software Application and Web-based Service Interface Page 5 of 36
For purposes of this task order there is one clear distinction that is validated by the Department’s organizational
structure. The people who work in OCIO respond to and effectively manage all technical aspects of this task order.
The people who work in CPD respond to and effectively manage all business aspects of this task order.
The business processes covered under this procurement include, but are not necessarily limited to, the general
aspects of the Grants Management Lifecycle.
This Grants Management Lifecycle is consistent and compatible with the benchmarks identified in the Federal e-
Grants initiative and the Grants Management Line of Business. The IT systems within scope of this task order each
support one or multiple functions of the Grants Management Lifecycle.
CPD’s vision for Electronic Grants Management is to:
Automate or increase efficiency of grant management and administrative processes
Retire manual and/or paper-based processes
Increase use of single-sign-on so grantees have fewer points-of-entry to grants systems
Increase integration among grants systems
Reduce reliance on stove-piped, single-purpose solutions
Streamline database design to increase performance and reliability
Centralize data where feasible (single-source) and share via services
Reduce overall data footprint
Increase accuracy and standardization of data
Reduce data entry burden for grantees and staff
Better utilize existing data for improved analysis, reporting, and decision-making
Improve system design, interface, usability, and user-friendliness
Reduce reliance on manual data corrections to reduce overall operational costs
Improve quality of system releases to minimize need for corrective maintenance
Enable additional grant programs to leverage the eGrants systems for cost savings
Further enhance systems with stronger financial controls for improved accountability
Develop public-facing interfaces for improved transparency
Utilize innovative web technologies for integrated and cost-effective solutions
Rapidly and efficiently respond to legislative mandates requiring system changes
Reduce overall costs to operate/maintain eGrants systems
CPD believes this vision will lead to more rapid award and disbursement of funds to grantees, better execution of
grants, greater capacity of grantees, and better on-the-ground performance of grants. Most importantly, the Agency
believes an improved and integrated spectrum of IT systems will directly lead to improved access to affordable
housing, better neighborhood conditions, job creation, and more targeted services to better meet the needs of low-
income families, the homeless, HIV/AIDS patients, and other key beneficiaries of Agency’s grant programs. In
times of limited Federal dollars for grant programs, optimizing use of IT systems can directly lead to improved
outcomes, i.e., reduced grantee time spent on administrative paperwork frees up staff time to directly execute and
oversee grant activities.
Additionally, CPD believes that grant programs in other program offices could benefit in terms of significant
efficiency gains and administrative cost savings if they leveraged CPD’s grants management systems to administer
their grants, and abandoned existing stove-piped, legacy, and/or paper-based solutions. CPD’s grants management
systems are poised to begin servicing other grant programs around the Department.
C.2.1 AGENCY MISSION
The Agency seeks to develop viable communities by promoting integrated approaches that provide decent housing,
a suitable living environment, and expand economic opportunities for low and moderate income persons. The
primary means towards this end is the development of partnerships among all levels of government and the private
sector, including for-profit and non-profit organizations.
Software Application and Web-based Service Interface Page 6 of 36
The Agency
seeks
to
empower
local residents
by
helping
to
give them
a voice in
the future
of
their
neighborhoods;
stimulate the creation
of
community
based
organizations; and
enhance
the management skills
of
existing
organizations
so
they
can
achieve greater
production
capacity.
Housing
and
community
development are not viewed
as separate programs,
but rather
as among
the myriad
elements
that make up
a comprehensive vision
of
community
development. These groups
are at the heart of
a bottom-up
housing
and
community
development strategy.
The IT
systems
identified
in
this
task
order
request are dedicated
to
supporting
this
mission.
Work
outlined
in
this
task
order
request is
directly
related
to
the following
Strategic Goals:
The Contractor
shall provide innovative,
integrated,
EA-compliant, and
cost-effective IT
solutions
that increase
efficiency,
reduce
data entry,
reduce
IT
system
operations
costs,
and
reduce
manual/paper-based
administrative
burdens
for
staff
and
grantees in
order
to
meet this
mission.
C.2.2
CURRENT
ENVIRONMENT
The Technical Environment for
each
of
the existing
IT
systems
is
defined
in
Attachment 1
to
this
solicitation.
The Agency
currently
uses
the
following
desktop
business
applications: Microsoft Windows
XP,
Microsoft Access
version
2007,
Microsoft Excel
version
2007,
Microsoft PowerPoint version
2007,
Microsoft Word
version
2007,
Microsoft Project version
2007
and
Microsoft Visio
version
2007,
but regularly
upgrades the environment.
The
current Technical Reference
Model (TRM)
can
be found
on
the website.
All deliverables
will be in
a format
compatible with
standards
listed.
C.3
SCOPE
The milestones
and
deliverables in
the following
requirements
will be implemented
and
thoroughly
discussed
with
the GSA
Contracting
Officer’s
Representative (COR)
and
the Agency
Technical Points
of
Contact (TPOCs)
(Government Technical Representative [GTR]/Government Technical Monitor
[GTM]).
This
task
order
will be
performed
for
a five-year
period
with
one base period,
and
four
option
years.
The Contractor
shall support the following
functions:
IT
System
Steady-State Operational Support services necessary
to
continue on-going
operations
of
existing
IT
systems.
IT
System
Steady-State Corrective Maintenance
services, including
application
bug
fixes,
fixes to
reports
that are inaccurate,
correcting
business
rules that contain
bad
logic,
and/or
assistance
in
completion
of
scheduled
Enterprise Architecture (EA)
and
infrastructure or
software upgrades as
identified
by
OCIO.
Systems
Development, Modernization
and
Enhancement (DME)
services for
each
of
the eGrants
systems
and
subsystems
as budgets permit.
DME
typically
includes requirements
analysis,
design,
development,
testing,
and
deployment of
changes
and
enhancements
to
existing
systems
to
engender
new
or
modified
functionality
in
response to
regulatory
and
statutory
changes.
DME
may
also
include development of
future
systems,
consolidation
of
systems,
integration
of
systems
for
improved
data sharing,
and/or
the expansion
of
the existing
systems
to
support other
grant-making
program
areas
in
the Agency
or
potentially
from
other
Federal Government agencies. All of
these services will include coordination
with
the
infrastructure
support vendor(s)
and,
from
the Contractor’s
side,
effective project management in
alignment with
Project
Planning
and
Management (PPM)
process.
C.4
OBJECTIVE
The Contractor
shall be responsible for
providing
substantial value to
the Agency in
the form
of
technical services
to
ensure successful business
operations,
maintenance,
and
enhancement of
the systems
supporting
CPD and
other
grant-making
offices
within
the Agency.
This
work
includes
assisting
staff
and
infrastructure contractors
to
complete scheduled
Enterprise
Architecture (EA)
and
software upgrades as
identified
by
OCIO.
The effort includes
ensuring
that the systems
are fully
compatible and
integrated
with
current software programs
and
hardware and
fully
Soft
ware Application and Web-based Service Interface Page 7 of 36
functional in relation to existing operating environments within the Agency and to the greatest extent possible with
the external users and business partners outside of Agency.
Contractor personnel assigned to this task order will perform their work at the Contractor’s facility. The
Government will not furnish office space or equipment for Contractor staff. However, all project review meetings
with the Government and Contractor staffs will be held at the Agency Headquarters unless instructed otherwise by
the GTR/GTM.
C.5 TASKS
The purpose of this task order is to have the Contractor perform services related to the Operations, Corrective
Maintenance, and Development/Modernization/Enhancement (DME) of electronic grants management (eGrants)
and other related Information Technology (IT) systems. Due to the complexity of the task, the offeror should have
knowledge of grants management business processes, have the ability to analyze those processes in a holistic and
integrated context, and recommend viable cost-effective technical and data solutions that improve program
operations, reduce costs, and lower administrative burdens for grantees and staff.
The Contractor shall provide support for the tasks as described below.
C.5.1 TASK 1 - DEVELOPMENT, MODERNIZATION AND ENHANCEMENT (DME)
Development/Modernization/Enhancement (DME) means the program cost for new investments, changes or
modifications to existing systems to improve capability or performance, changes mandated by the Congress or
agency leadership, personnel costs for investment management, and direct support.
DME includes introduction of new or modified functionality or scope that requires the re-engineering and/or
enhancement of an existing system, the re-platforming of a system to a new technical architecture, or the
development of a new system.
The Contractor shall practice rigorous requirements management, project management, change control management
and testing during DME efforts to ensure:
Deployment Of High-Quality Code That Accurately Meets The Requirements
Successful Releases Without Introduction Of Unexpected Problems
Minimal Need For Emergency/Corrective Maintenance
Minimal Need To Fix The Same Issue Multiple Times
Maximum Value Out Of Limited It Budget Resources
C.5.1.1 DME AND THE PPM PROCESS
All DME projects shall be initiated via a Work Request and will follow the Project Planning and Management
(PPM) process.
Some or all of the project phases defined by PPM will be included in the Project Plan:
Need/Concept
Definition
Design
Execution of Solution
Deployment
Operate and Maintain
Decommission
The project plan will identify the phases above as milestones. It will also include milestones for requirements
gathering/business process analysis meetings, agile development design sessions, prototype demonstrations, regular
Software Application and Web-based Service Interface Page 8 of 36
status meetings, and other meetings as necessary where the Contractor needs input from the Government or staff
requests demonstration of functionality. The project plan will also provide a schedule for all PPM and other
deliverables identified in the Work Request as well as any of the following based on the scope of the change or the
Level of Effort (LOE), as required by the Government:
Concept of Operations
Business Process Models
Proof of Concept
Prototype
Pilot
Work Requests will cover one or multiple phases of the PPM process. The PPM process is a general guideline for
all DME projects. Not all deliverables are required for all projects. During the Need/Concept phase, CPD/OCIO
will develop a Project Process Agreement which essentially determines which PPM artifacts are required for the
project. CPD/OCIO will tailor Work Requests to include or exclude PPM artifacts. The Contractor shall develop
new documents, or update existing documents, as specified in the Work Request. Examples of standard PPM
documents that will be created or updated include:
Requirements Definition Document
Solution Architecture Document
Technical Design Document
Interface Control Document and/or Interconnection Security Agreement
Test Plan
Release Plan
Communication Plan
Staffing Management Plan
Capacity Plan
Data Conversion Plan
Test Report
Operations and Maintenance Manual
Project Completion Report
Post Deployment Report
Decommission Plan
Post Decommission Report
As part of the need/concept or definition phases of the PPM, and based on scope and complexity of work, the project
plan may also include either or both of the following activities as required by the Government:
Business Analysis
Business Process Re-engineering
The PPM process requires Gate Reviews as projects progress through the phases. The contactor shall participate in
OCIO Gate Reviews or other technical project reviews as requested by the GTM.
C.5.1.2 PROJECT MANAGEMENT
Project management shall be required for DME efforts to ensure software developers and other technical staff follow
project plans established in each Work Request. The Agency will closely monitor the cost and schedule of DME
Work Requests to minimize potential for cost and/or schedule variance.
The Government encourages the Contractor to follow the work process flow, methodology, procedures, deliverables
and best practices that conform to the standards dictated by the Project Management Body of Knowledge (PMBOK)
Guide, Project Management Life Cycle defined and published by the Project Management Institute (PMI).
Software Application and Web-based Service Interface Page 9 of 36
DME projects shall follow HUD’s Project Planning and Management (PPM) process. Details about the PPM
process can be found at this Government website:
C.5.1.3 CONFIGURATION MANAGEMENT PLAN
The Contractor shall update the existing Configuration Management (CM) Plan or create the CM Plan if it does not
exist. The plan shall address the following:
Configuration management: Configuration management is a set of processes and procedures to identify
configuration items, baseline configuration items and control changes to the configuration baseline. All
changes must be evaluated and approved by the Change Control Board (CCB) in accordance with the
procedures. The CCB constitutes staff and are responsible for determining priority and sequencing for
releasing fixes and enhancements.
Change management: Change management identifies and defines steps for initiating software changes that
may alter the current system or current requirements. The Contractor will maintain a Change Control
Register (CCR) for each system to log and track all change requests and requests to implement new
requirements.
Release management: Release management consists of specific processes that manage the risks associated
with each release. The processes address the coordination and responsibilities of all functional areas
affected by a release.
Problem tracking: Issues are thoroughly tracked and are sometimes submitted to the CCB for evaluation
and approval of the proposed resolutions.
CM tools: The Contractor will use standard CM tools as part of the CM process. Serena Dimensions is
currently the tool in use at the Agency.
C.5.1.4 QUALITY ASSURANCE PLAN
The Contractor shall provide a Quality Assurance (QA) Plan (QAP) that conforms to the minimum standards as
identified in the Quality Assurance guidelines identified in the PPM. The Contractor shall identify a team that is
dedicated to Quality Assurance and ensure that only high quality products and services are delivered to the
Government.
The Contractor shall maintain a Lessons Learned document, updating it subsequent to each release, and as required
by PPM process. The Contractor shall disseminate lessons learned to the team after each release, and make
recommendations as appropriate to the Government to increase the quality of future deliverables and improve
reliability and efficiency of systems.
The Government will use a Quality Assurance Surveillance Plan (QASP) as part of the Government’s efforts to
monitor contractor performance. See Attachment 2.
C.5.1.5 RISK MANAGEMENT
The PPM process emphasizes the importance of identifying, monitoring, managing, and mitigating risks for DME
efforts. The Contractor shall, with input from the GTM, develop a Risk Management Plan and a Risk Register for
each DME project. Monthly updates to the Risk Register will be identified as tasks in each Project Work Plan
(PWP). When the Contractor believes a technical project risk is on a path to be realized in the future, or already has
been realized, they must notify the GTR/GTM.
C.5.1.6 EARNED VALUE ANALYSIS AND REPORTING
The Contractor shall use Earned Value Management (See Section H.9) as per requirements of PPM process for
Steady-State Corrective Maintenance (Task 2) and DME (Task 1) Work Requests.
The Contractor shall not use Earned Value Management for Task 3 (fixed-price Steady-State Operational Support).
Software Application and Web-based Service Interface Page 10 of 36
C.5.1.7 SECURITY PACKAGES
The Contractor shall assist staff in developing or updating the “Security Package” for each system prior to major
system releases. Staff shall maintain responsibility for these documents but the Contractor shall provide technical
input. Updates in conjunction to major releases shall be covered under Task 2 (Steady-State Corrective
Maintenance) or Task 1 (DME) tasks only if the system fixes/enhancements being released cause a significant
change in the security of the system. All PWPs under Task 2 or Task 1 shall contain a task identifying each IT
Security document update requested in the Work Request, as well as a task or tasks identifying IT security-related
coding or system modification. The Security Package includes the following documents:
Risk Assessment
System Security Plan
Contingency Plan
Other IT security documents may be required, and will be identified in the Work Request. The Contractor shall
provide technical input to HUD in responding to Plan of Action and Milestones (POA&M) items by identifying the
system changes that may be required to correct and address security weaknesses.
C.5.1.8 REQUIREMENTS TRACEABILITY MATRIX (RTM)
A Requirements Traceability Matrix (RTM) shall be created or updated as required as part of the Definition phase of
all DME projects. The RTM is typically a direct input to the Requirements Definition Document. The RTM shall
clearly link the new and/or changed requirements to where and how they have been implemented in the system. The
RTM shall provide backwards and forward traceability, meaning the RTM documents each requirement from its
source through definition, analysis, design, testing, acceptance, and deployment.
C.5.1.9 TESTING
The Contractor shall conduct functional, unit, system/integration, regression, smoke, load/performance and/or
stability tests as applicable as part of their quality assurance plan for each system release. Each applicable test shall
be identified as a milestone in the Work Breakdown Structure (WBS). Use of industry-standard automated testing
software is strongly encouraged. The software shall be flexible to be able to handle changes and requirements of
any complexity; allow for the recording and playback of scripts, along with the ability to maintain an ongoing test
data suite; thus ensuring 100% of the requirements are met and that regression testing will fully test all previous
functionality. The amount and type of testing shall be commensurate with the size, scope, and risk of the specific
release as mutually agreed upon by the Contractor and the GTR/GTM.
User Acceptance Testing (UAT) is the critical step for identifying whether a product is ready to be deployed. The
process for UAT will be consistent with Section C.5.1.10 of this Task Order Request (TOR). Acceptance of all other
deliverables will be consistent with Section F of this TOR.
System performance load and stress testing will begin as early as feasible in the Execution of Solution phase and
shall be conducted at appropriate intervals prior to the submission of the request for the system release to ensure
acceptable performance in production.
C.5.1.10 USER ACCEPTANCE TESTING (UAT)
The Government will perform acceptance testing of the new or modified CPD systems’ code and/or database
changes/additions after successful completion of Contractor testing. The Contractor shall prepare or update a User
Acceptance Test (UAT) plan and test scenarios/scripts for users to follow during the initial structured portion of the
UAT (following structured testing the users are encouraged to conduct their own free-form testing). The Contractor
shall assist the Government during the preparation and execution of the acceptance test by establishing test data and
maintaining the test environment. The Contractor shall provide the draft version of all documentation, including the
Requirements Traceability Matrix (RTM), which shall be delivered with the final product at the time of the initiation
of the UAT period. The RTM shall clearly link the new and/or changed requirements to where and how they have
Software Application and Web-based Service Interface Page 11 of 36
been
implemented
in
the system,
to
assist the users
during
testing.
The Contractor
shall correct any
errors
identified
by
the User
Acceptance
Test team.
The Contractor
shall document the results
of
the testing
in
the Test Report.
Upon
receipt of
the report, the Government
will examine the
test
results
and
make a determination
as
to
the
readiness
of
the new
or
modified
CPD systems’
code and/or
database changes/additions
to
be released
into
the
production
environment.
The Government
will certify
the planned
release under
one of
the
following
categories:
It is virtually error free and should be released into production.
Errors still exist that should be addressed, however, a decision could be made that either:
o
the release can
proceed
intact and
the errors
will be corrected
and
implemented
through
a
subsequent release or,
o
the release can
proceed
but the portions
determined
defective will be removed
from
it and
errors
will be corrected
and
implemented
through
a subsequent release.
It has major
shortcomings
and
should
not be released
into
production
at this
time.
Instead,
it should
be
returned
for
further
development and
re-testing.
C.5.1.11
RELEASES
Once
the Government
has
performed
UAT
and
final system
performance
load
and
stress
testing
has been
completed,
the product shall be submitted
as an
Application
Release Tracking
System
(HARTS) release request, along
with
all
associated
documentation
required
for
the HARTS release.
This
shall include the preparation
of
the system
release
request in
HARTS system,
as well as
the provision
of
test ID(s)
and
Password(s)
and
the necessary
software code.
The Contractor
shall prepare and
manage Release Notes
to
document the fixes/changes/enhancements
included
in
each
system
release and
support the release process
using
standard
CM tools.
When
the GTR/GTM verifies that UAT
is
successfully
complete,
the Contractor
shall prepare and
submit a
HARTS
release package,
which
includes the technical release instructions,
scripts,
schedule,
and
other
documentation.
The GTR/GTM shall determine if
the release is
categorized
as a
“regular” or
“emergency” release.
Current policy
specifies
a lead-time of
10
business
days
for
“regular” releases and
4
business
days
for
“emergency” releases.
The
Contractor
shall be responsible for
coordinating
release testing
with
the Test Center,
including
copying
all relevant
files
into
the Test Center
“realignment” testing
environment used
to
simulate each
release.
The Contractor
shall
support the Test Center
staff,
OCIO staff,
and/or
infrastructure contractors
during
the installation
and
configuration
of
software upgrades and
application
system
releases
as required.
The Contractor
shall also
follow-up
to
provide
Verification
and
Validation
of
the intended
results
within
two
business
hours
after
the release installation
has
been
completed,
to
verify
that the installation
was
completed
correctly.
The Contractor
shall update all PPM and
other
system
documentation
to
reflect all changes
implemented
to
production
under
DME
work.
The Contractor
shall update the IT
Security
Plan
and
other
documents
if
required.
These documentation
tasks
will be identified
in
the
project plan
and
PWP
for
each
Work
Request.
C.5.1.12
CONCEPT
OF OPERATIONS
The Concept of
Operations
shall be based
upon
the templates
and
checklists
outlined
in
the PPM
methodology.
This
document is commonly
referred
to
as a
ConOps.
A
ConOps
is
not usually
necessary
for
routine work
on
existing
systems.
The ConOps
shall be
required
for
deployment of
new
systems; major
re-engineering
or
modernization
of
existing
systems; or
development of
new
system
Modules
or
“paths” to
meet substantially
revised
or
new
business
requirements.
As
directed
by
the GTR/GTM,
the Contractor
shall develop
a ConOps
or
update an
existing
ConOps
for
Definition
and
Design
phases in
the PPM.
The ConOps
shall be delivered
first, before the Requirements
Definition
documents,
and
then
refined
and
delivered
again
before the Technical Design
document.
So
ftware Application and Web-based Service Interface Page 12 of 36
C.5.1.13 BUSINESS PROCESS MODELS
Business process models may include any of the following:
Flow Charts
Use Cases Including Diagrams
Activity Diagrams
Work Process Simulations
Other Models As Required By The Government
C.5.1.14 PROOF OF CONCEPT
A Proof of Concept is a non-operational representation of the proposed functionality. If the Project Plan calls for a
Proof of Concept, it will include a graphical representation of the flow of screens or the progression through the
logic of the system by the typical user.
C.5.1.15 PROTOTYPE
A Prototype is an incomplete project/product that is tested to verify the development that has been completed to
date. Thus, for the functionality that has been completely developed, the prototype shall be considered to be
completely demonstrating those unit functions. If the project plan calls for the prototype, it shall be deployed using
the development language of the final product delivery as well as the database of the final product delivery. The
prototype shall be tested to verify the efficiency of the code as well as the performance of the database. All
subsystem dependencies that have not been identified to be included in the Prototype shall be identified in writing
before the delivery of the prototype. Additionally, a Requirements Traceability Matrix (RTM) of the requirements
that are included in the prototype shall be delivered with the prototype delivery. The RTM shall include the
verification criteria for each requirement for testing purposes.
C.5.1.16 PILOT
A Pilot is a deployment of the final product for a limited group or subset of users. The pilot is intended to decrease
the overall risk of the project by only placing a limited number of users at risk of product failure in the deployment
phase. If the Pilot is deemed to be acceptable, then the Release Plan and Data Conversion Plan continue as
scheduled. The Contractor shall identify and document contingency plans prior to pilot deployment in the event that
the pilot is not successful, outlining corrective action plans for the project, if necessary.
C.5.2 TASK 2 – STEADY-STATE CORRECTIVE MAINTENANCE
Steady-State Corrective Maintenance encompasses modifications that fix application problems caused by design,
logic, or coding errors. This type of maintenance is often triggered by an explicit service desk ticket and often
involves errors that must be addressed immediately. Examples of issues that require corrective maintenance include
the following:
Calculations that generate incorrect totals
Data screens that omit a required entry or store an entry in the improper location
Improper logic in business rules
Aborted programs
Error messages
Interfaces that are not functioning as designed
Application configuration issues
C.5.2.1 PROJECT MANAGEMENT
Project management shall be required for Steady-State Corrective Maintenance efforts to ensure software developers
and other technical staff follow project plans established in each Work Request. The Government will closely
Software Application and Web-based Service Interface Page 13 of 36
monitor the cost and schedule of Corrective Maintenance work requests to minimize potential for cost and/or
schedule variance.
The Government encourages the Contractor to follow the work process flow, methodology, procedures, deliverables
and best practices that conform to the standards dictated by the Project Management Body of Knowledge (PMBOK)
Guide, Project Management Life Cycle defined and published by the Project Management Institute (PMI).
Steady-State Corrective Maintenance projects shall follow Project Planning and Management (PPM) process.
C.5.2.2 CONFIGURATION MANAGEMENT PLAN
The Contractor shall update the existing Configuration Management (CM) Plan. The plan shall address the
following:
Configuration management: Configuration management is a set of processes and procedures to identify
configuration items, baseline configuration items and control changes to the configuration baseline. All
changes must be evaluated and approved by the Change Control Board (CCB) in accordance with the
procedures. The CCB constitutes staff and staff are responsible for determining priority and sequencing for
releasing fixes and enhancements.
Change management: Change management identifies and defines steps for initiating software changes that
may alter the current system or current requirements. The Contractor shall maintain a Change Control
Register (CCR) for each system to log and track all change requests and requests to implement new
requirements.
Release management: Release management consists of specific processes that manage the risks associated
with each release. The processes address the coordination and responsibilities of all functional areas
affected by a release.
Problem tracking: Issues are thoroughly tracked and are sometimes submitted to the CCB for evaluation
and approval of the proposed resolutions.
CM tools: The Contractor will use standard CM tools as part of the CM process. Serena Dimensions is
currently the tool in use at the Agency.
C.5.2.3 QUALITY ASSURANCE PLAN
The Contractor shall provide a Quality Assurance (QA) Plan (QAP) that conforms to the minimum standards as
identified in the Quality Assurance guidelines identified in the PPM. The Contractor shall identify a team that is
dedicated to Quality Assurance and ensure that only high quality products and services are delivered to the
Government.
The Contractor shall maintain a Lessons Learned document, updating it subsequent to each release, and as required
by PPM process. The Contractor shall disseminate lessons learned to the team after each release, and make
recommendations as appropriate to the Government to increase the quality of future deliverables and improve
reliability and efficiency of systems.
HUD will use a Quality Assurance Surveillance Plan (QASP) as part of the Government’s efforts to monitor
contractor performance. See Attachment 2.
C.5.2.4 EARNED VALUE ANALYSIS AND REPORTING
Contractor shall use Earned Value Management (See Section H.9) as per requirements of PPM process for Steady-
State Corrective Maintenance (Task 2) and DME (Task 1) work requests.
Contractor shall not use Earned Value Management for Task 3 (fixed-price Steady-State Operational Support).
Software Application and Web-based Service Interface Page 14 of 36
C.5.2.5 SECURITY PACKAGES
The Contractor shall assist staff in developing or updating the “Security Package” for each system prior to major
system releases. Staff shall maintain responsibility for these documents but the Contractor shall provide technical
input. Updates in conjunction to major releases shall be covered under Task 2 (Steady-State Corrective
Maintenance) or Task 1 (DME) tasks only if the system fixes/enhancements being released cause a significant
change in the security of the system. All PWPs under Task 2 or Task 1 shall contain a task identifying each IT
Security document requested in the Work Request, as well as a task or tasks identifying IT security-related coding or
system modification. The Security Package includes the following documents:
Risk Assessment
System Security Plan
Contingency Plan
Other IT security documents may be required, and will be identified in the Work Request. The Contractor shall
provide technical input in responding to Plan of Action and Milestones (POA&M) items by identifying the system
changes that may be required to correct and address security weaknesses.
C.5.2.6 STEADY-STATE CORRECTIVE MAINTENANCE
The Contractor shall perform Steady-State Corrective Maintenance actions that encompass modifications to fix
application problems caused by design, logic, coding, development, and/or infrastructure errors. This type of
maintenance will be triggered by an explicit trouble ticket, problem report, or trouble call and involves errors that
must be investigated immediately as indicated in Task 3, Monthly Steady-State Operational Support. The Contractor
shall perform all project phases and activities required to build, test and deploy all Steady-State Corrective
Maintenance changes as necessary to fix the application problems.
Steady-State Corrective Maintenance consists of the action(s) taken to restore a failed system to operational status.
This usually involves replacing or repairing the software component that is responsible for the failure in the system.
Corrective maintenance is performed at unpredictable intervals. The objective of corrective maintenance is to restore
the system to satisfactory operation within the shortest possible time.
Code changes or other fixes conducted under a Steady-State Corrective Maintenance Work Request are of the nature
that require a HARTS release or application configuration change to implement into Production, e.g., cannot be
accomplished via data correction scripts.
Corrective maintenance is also undertaken to ensure continuing operations for software
version/platform/infrastructure changes (e.g. operating system upgrades, Microstrategy upgrades, or Oracle
upgrades) when the impacted business application/system would otherwise not work as a direct result of that
version/platform/infrastructure change. For instance, if OCIO determines all systems must upgrade from Oracle
v.11 to Oracle v.12, and that change requires code changes that cannot be implemented without a HARTS release or
application configuration changes, then the work is categorized as Corrective Maintenance. However,
version/platform/infrastructure changes that can be accommodated without a HARTS release or application
configuration change are considered Task 3 Monthly Steady-State Operational Support.
C.5.2.7 WEB CALCULATORS
The Contractor shall provide corrective fixes as requested by the GTR/GTM in a Work Request for the following
web calculators. These tools are used by grantees in coordination with activities undertaken in the HOME and
Environmental Review modules in IDIS OnLine. Web calculators and may require full HARTS releases to deploy
or modify.
C.5.2.8 REQUIREMENTS TRACEABILITY MATRIX (RTM)
A Requirements Traceability Matrix (RTM) shall be created and/or updated as required as part of a Corrective
Maintenance Work Request. The RTM is typically a direct input to the Requirements Definition Document. The
Software Application and Web-based Service Interface Page 15 of 36
RTM shall clearly link the new and/or changed requirements to where and how they have been implemented in the
system. The RTM shall provide backwards and forward traceability, meaning the RTM documents each requirement
from its source through definition, analysis, design, testing, acceptance, and deployment. The size and level of
detail of the RTM for a Corrective Maintenance work request shall be commensurate with the size, scope, and risk
of the corrective maintenance issues being fixed for each corrective release.
C.5.2.9
TESTING
The Contractor
shall conduct functional,
unit, system/integration,
regression,
smoke,
load/performance,
and/or
stability
tests
as applicable as part of
their
quality
assurance
plan
for
each
system
release.
Each
applicable test
will
be identified
as a
milestone in
the project plan.
Use of
industry-standard
automated
testing
software is
strongly
encouraged.
The software will be flexible to
be able to
handle changes and
requirements
of
any
complexity; allow
for
the recording
and
playback
scripts,
along
with
the ability
to
maintain
an
ongoing
test
data suite; thus
ensuring
100% of
the requirements
are met and
that regression
testing
will fully
test
all previous
functionality.
The amount
and
type of
testing
will be commensurate with
the size,
scope,
and
risk
of
the specific release as mutually
agreed
upon
by
the Contractor
and
the GTR/GTM.
The Contractor
shall assist staff
in
coordinating
User
Acceptance
Testing
(UAT)
with
impacted
stakeholders,
as per
section
C.5.2.10
below.
C.5.2.10
USER ACCEPTANCE
TESTING (UAT)
The Government
will perform
acceptance
testing
of
the new
or
modified
CPD systems’
code and/or
database
changes/additions
after
successful completion
of
Contractor
testing.
The Contractor
shall prepare or
update a User
Acceptance
Test (UAT)
plan
and
test
scenarios/scripts
for
users
to
follow
during
the initial structured
portion
of
the
UAT
(following
structured
testing
the users
are encouraged
to
conduct their
own
free-form
testing).
The Contractor
shall assist HUD during
the preparation
and
execution
of
the
acceptance
test
by
establishing
test
data and
maintaining
the test
environment.
The Contractor
shall provide the draft version
of
all documentation,
including
the
Requirements
Traceability
Matrix
(RTM),
which
shall be delivered
with
the final product at the time of
the initiation
of
the UAT
period.
The RTM
shall clearly
link
the new
and/or
changed
requirements
to
where and
how
they
have
been
implemented
in
the system,
to
assist the users
during
testing.
The Contractor
shall correct any
errors
identified
by
the User
Acceptance
Test team.
The Contractor
shall document the results
of
the testing
in
the Test Report.
Upon
receipt of
the report, the Government
will examine the
test
results
and
make a determination
as
to
the
readiness
of
the new
or
modified
CPD systems’
code and/or
database changes/additions
to
be released
into
the
production
environment.
The Government
will certify
the planned
release under
one of
the
following
categories:
It is virtually
error
free
and
should
be released
into
production.
Errors
still
exist that should
be addressed,
however,
a decision
could
be made that either;
o
the release can
proceed
intact and
the errors
will be corrected
and
implemented
through
a
subsequent release or,
o
the release can
proceed
but the portions
determined
defective will be removed
from
it and
errors
will be corrected
and
implemented
through
a subsequent release.
It has major
shortcomings
and
should
not be released
into
production
at this
time.
Instead,
it should
be
returned
for
further
development and
re-testing.
C.5.2.11
RELEASES
Once
the Government
has
performed
UAT
and
final system
performance
load
and
stress
testing
has been
completed,
the product shall be submitted
as an
Application
Release Tracking
System
(HARTS) release request, along
with
all
associated
documentation
required
for
the HARTS release.
This
shall include the preparation
of
the system
release
request in
HARTS system,
as well as
the provision
of
test ID(s)
and
Password(s)
and
the necessary
software code.
The Contractor
shall prepare and
manage Release Notes
to
document the fixes/changes/enhancements
included
in
each
system
release and
support the release process
using
standard
CM tools.
Sof
tware Application and Web-based Service Interface Page 16 of 36
When the GTR/GTM verifies that UAT is successfully complete, the Contractor shall prepare and submit a HARTS
release package, which includes the technical release instructions, scripts, schedule, and other documentation.
The GTR/GTM shall determine if the release is categorized as a “regular” or “emergency” release. Current policy
specifies a lead-time of 10 business days for “regular” releases and 4 business days for “emergency” releases. The
Contractor shall be responsible for coordinating release testing with the Test Center, including copying all relevant
files into the Test Center “realignment” testing environment used to simulate each release. The Contractor shall
support the Test Center staff, OCIO staff, and/or infrastructure contractors during the installation and configuration
of software upgrades and application system releases as required. The Contractor shall also follow-up to provide
Verification and Validation of the intended results within two business hours after the release installation has been
completed, to verify that the installation was completed correctly.
The Contractor shall update all PPM and other system documentation to reflect all changes implemented to
production under Corrective Maintenance work. The Contractor shall update the IT Security Plan and other
documents if required. These documentation tasks will be identified in the project plan and PWP for each Work
Request.
C.5.3 TASK 3 – MONTHLY STEADY-STATE OPERATIONAL SUPPORT
Consistent with OMB Circular A-11 and Capital Planning and Budget processes the objective of Operational
Support is to ensure complete, continuous and successful business operations for all of the CPD eGrants systems.
Steady-State Operations (SS) means maintenance and operation of current IT systems at current capability and
performance level including costs for personnel, maintenance of existing information systems, configuration, data
communications maintenance, and replacement of broken IT equipment. Project Management support should be a
minimal portion of Task 3 Monthly Steady-State Operational Support since no Work Requests are anticipated.
C.5.3.1 The Contractor shall create Operational Verification Checklist for elements within each system that will be
verified to ensure normal business operations and submit the checklist to the Government for revision or updates on
a quarterly basis.
C.5.3.2 The Contractor shall use the Operational Verification Checklist to conduct a daily check on all systems
covered by this task order to verify that they are operational. Send a status report to the GTM and project managers
daily by 9:00am each Federal business day. Identify each failure/issue and escalate as needed. Identify items in
which the performance was outside the threshold for acceptable performance.
C.5.3.3 The Contractor shall submit and revise on a monthly basis operational performance measures for business
application system processes that include minimum and maximum thresholds as well as average or normal
operational thresholds. NOTE: The Government is considering under a separate infrastructure contract,
purchasing enterprise datacenter monitoring tools and/or services. If these tools and/or services are in place, the
Contractor shall use them to measure the percent of time the business application systems are available to users, not
the servers/network/infrastructure.
C.5.3.4 The Contractor shall have access to and monitor the queues in ServiceDesk system (or any other standard
ticket tracking system used by the Agency, OCIO, and the Agency-wide infrastructure contractor) related to the
systems covered in this task order. If during this task order the Agency adopts an enterprise-wide ticket tracking
system for applications, the Contractor shall adopt within six months as directed by the GTR.
C.5.3.5 The Contractor shall monitor system interfaces and automated data transfers at least once daily to ensure
that transactions are occurring as designed. Current interfaces include:
Electronic Data Interchange (EDI)-IDIS Online interface
IDIS Online–LOCCS interface
IDIS Online-Geocode Service Center interface
DRGR–LOCCS interface
DRGR-Geocode Service Center interface
GMP–IDIS OnLine interface
Software Application and Web-based Service Interface Page 17 of 36
GMP-OCFO Financial Data
Mart interface
IDIS OnLine–CPD Maps
interface.
If
interface processes and/or
automated
data transfers
fail,
the Contractor
shall be responsible for
contacting
appropriate resources
to
troubleshoot and
resolve interface issues.
C.5.3.6
The Contractor
shall provide “Tier
2” technical support to
the first tier
help
desk(s),
National Helpdesk,
project managers,
and/or
GTM.
The Contractor
shall use a ticket tracking
system
(See Sec.
C.5.3.4
and
Sec.
C.5.2.22)
to
intake,
log,
and
track
all Tier
2
tickets through
resolution.
The Contractor
shall log
tickets
within
3
hours
during
normal business
hours.
The Contractor
shall respond
to
ticket requests
which
can
include,
but are not
limited
to,
technical issues, system
access
problems
and
application
questions
(i.e.,
user
cannot enter
data into
a
specific field,
screen
is
not loading,
etc.),
error
messages,
permissions,
performance
issues, batch
processes, EDI,
etc.
C.5.3.7
The Contractor
shall analyze
and
diagnose Tier
2
tickets, identify
problematic components,
re-create the
problem,
perform
a root cause
analysis,
and
provide a description
of
the problem.
The Contractor
shall provide an
initial analysis
of
all Tier
2
tickets within
one business
day.
The Contractor
shall recommend
a strategy
or
strategies
to
the GTM that will fix
or
address
the problem.
C.5.3.8
The Contractor
shall implement the GTM-approved
strategy
to
fix
or
address
the problem
provided
the work
is
within
the scope of
Task
3
(Operational Support).
If
the problem
will require
a HARTS release to
implement, the
ticket shall be categorized
in
the ticket tracking
system
as such,
and
must be addressed
via a Task
2
(Steady-State
Corrective Maintenance)
or
Task
1
(DME)
Work
Request.
C.5.3.9
The Contractor
shall send
information
concerning
the cause of
the problem
to
the organization/resource
best
equipped
to
address
the problem,
for
example,
the Government
infrastructure support contractors
for
hardware/network
issues.
C.5.3.10
The Contractor
shall perform
manual transactions
in
the
event of
an
internal software issue,
data correction,
or
the failure of
an
internal batch
process,
e.g.,
data correction
scripts,
to
ensure the continuity
of
business
operations.
Upon
approval,
the Contractor
will follow
OCIO procedures to
have the data correction
scripts
executed
in
production.
This
also
includes configuration
changes, OLAP
refreshes, or
other
pushes that can
be implemented
to
production
without a
HARTS release.
C.5.3.11
The Contractor
shall act as
Liaison
with
IT
production
support staff
for
troubleshooting
system
problems.
The Contractor
will include the GTM in
the resolution
of
the
problem
and
notify
the CPD program
area
representative after
resolution.
Problem
resolution
may
require a coordinated
effort with
one or
more other
groups
to
resolve.
C.5.3.12
The Contractor
shall act as
Liaison
with
the Office of
the Chief
Financial Officer
(OCFO)
systems
project
personnel to
ensure continuous,
successful business
operations/interfaces between
the systems
of
this
portfolio
and
all relevant OCFO systems.
C.5.3.13
The Contractor
shall access
LOCCS (Line of
Credit
Control System
–
A76)
on
a read
only
basis,
as needed
for
the following
purposes:
To
check
on
the set-up
of
banking
information
for
a grantee
and
its
grants
in
LOCCS;
To
research
disbursement issues that arise by
comparing
disbursement information
in
LOCCS to
what is
in
the CPD system
to
determine whether
a problem
is
due to
a delay
in
payment, a problem
within
LOCCS, or
a problem
within
the CPD system; and
to
assist OCFO in
resolving
issues regarding
improper
set-up
of
grantees
and
their
grants
in
LOCCS or
the modification
of
such
set-up
information.
C.5.3.14
The Contractor
shall write and
test
data correction
scripts
to
make data corrections
in
response to
input
from
GTR/GTM/CPD
staff/Tier
1
help
desk.
Upon
the Government
approval,
the Contractor
shall follow
OCIO
procedures to
have the scripts
executed
in
production.
The Contractor
shall use proactive quality
control processes
Sof
tware Application and Web-based Service Interface Page 18 of 36
and testing to ensure data correction scripts are accurate and do not cause unintended consequences. The Contractor
shall log all data correction scripts to ensure adequate audit trail should the system be audited.
C.5.3.15 At the request of the GTM, the Contractor shall write and execute queries against databases of financial
systems (IDIS OnLine and DRGR) to check for data inconsistencies such as incorrect grant balances or potential
over-committed activities. The Contractor shall propose application code changes and/or database changes that
could be implemented in a Corrective Maintenance (Task 2) work request to prevent future inconsistencies from
occurring and reduce the overall number of data correction scripts required in the future.
C.5.3.16 The Contractor shall load data tables that are provided by CPD for loading in a pre-defined format on an
annual basis. Examples of typical data loads are adding new Fiscal Year grants into IDIS OnLine, or adding a new
list of Low-Mod Census Tracts to IDIS OnLine, data required for GMP risk assessment, or data required for GMP
Congressional Releases. The Contractor must verify that these tables are correct (i.e., no duplicates, no incomplete
records, etc.). This especially pertains to IDIS Online and GMP, but is not limited to these systems.
C.5.3.17 The Contractor shall populate the UAT and development environments with live production data once per
month.
C.5.3.18 The Contractor shall participate in meetings pertinent to this task order that discuss the
operations/supporting infrastructure of the systems of this portfolio including conference calls, Integrated Project
Team (IPT) meetings, HITS Requests Management Board (HRMB) Meetings, Configuration Change Management
Board (CCMB) meetings, Data Steward Advisory Board (DSAG) meetings, etc., as requested by the GTR/GTM.
C.5.3.19 The Contractor shall ensure that all existing application software is fully functional and operational. The
Contractor shall work with the infrastructure support contractors to resolve issues related to software applications.
The Contractor shall start (bring up) and stop (shut down) various on-line systems when necessary for all
environments, as required. As required, the Contractor shall update the Operations and Maintenance Manual which
provides detailed technical instructions to the infrastructure contractors on how to start and stop systems and
services, how overnight transactional processes operate (e.g. Online Analytical Processing [OLAP] refresh, LOCCS
transaction, autosys jobs, chron jobs, authentication), and other essential information on basic system technical
configuration.
C.5.3.20 The Contractor shall participate in testing the existing CPD systems’ Contingency Plans and/or
participating in Disaster Recovery Drills, which ensure CPD’s ability to operate and maintain systems and business
operations in the event of a terrorist attack, natural disaster, or other significant disruption. Typically Contingency
Plan tests / Disaster Recovery Drills occur once per year per system. In the event of a COOP declaration, the
Contractor shall execute the Contingency Plan per the direction of the GTM.
C.5.3.21 The Contractor shall conduct analysis and testing of the impact of Agency-wide datacenter infrastructure or
software upgrades on the systems of this portfolio and support the infrastructure contractor during the upgrades. The
Contractor shall coordinate with OCIO staff, the OCIO infrastructure contractors, and CPD staff during testing and
implementation. Examples may include software patches/upgrades (such as MicroStrategy v.8 to v.9), operating
system patches/upgrades, core database version upgrades (such as Oracle 10g to 11g), or other infrastructure
maintenance impacting the systems within scope of this task order. If the upgrade will require application system
modification and a HARTS release to implement, the effort must be addressed via a Task 2 (Corrective
Maintenance) or Task 1 (DME) Work Request.
C.5.3.22 The Contractor shall maintain a web-based, searchable ticket tracking system that categorizes all system
issues by multiple attributes. The Contractor shall enable select CPD and OCIO staff to access this system to assess
the overall status of each system/project, to assess each documented issue, and to prioritize issues for fixing.
C.5.3.23 The Contractor shall provide support for ad-hoc reports including determining report needs and system
capabilities; defining report requirements and format; generating and providing the report; and providing support for
the IDIS Data Download function, which allows users to download raw data for off-line analysis or ad-hoc
reporting.
Software Application and Web-based Service Interface Page 19 of 36
C.5.3.24 The Contractor shall maintain a shared, web-based document repository (e.g. SharePoint site) for posting
and sharing of documents such as approved Work Requests, prototyped screens, PPM documents, et cetera, for
simplified collaboration with CPD and OCIO staff.
C.5.4 TASK 4 – TRANSITION SERVICES
The Contractor shall provide a detailed transition plan showing the specific tasks and milestones for transition-in
and transition-out activities. The Contractor shall perform transition services necessary to ensure an effective
transition-in and transition-out of contractor support and continued system operations and maintenance, as well as an
orderly transition period without any interruption or loss of proficiency of services within 30 calendar days.
C.5.4.1 Perform Transition-In. The Contractor shall develop a Transition-In Plan that shall facilitate the
accomplishment of a seamless transition from the incumbent to an incoming contractor /government personnel.
Transition-In services shall occur from date of award and shall last an estimated 30 days. The Transition-In Plan
shall identify points-of-contact (POC) for liaison between the Government, the prime contractor, and other
contracted industry partners to ensure a proper and orderly transition and transfer of services and assets between the
parties cited. The Transition-In Plan shall communicate the Contractor’s transition strategy in the Contractor’s
written technical proposal. The Final Transition-In Plan shall reflect any changes, additions, or revisions as required
by GTR/GTM and shall be delivered No Later Than (NLT) three (3) working days after the Kick-Off Meeting.
C.5.4.2 Perform Transition-Out. The Contractor shall develop a Transition-Out Plan that shall facilitate the
accomplishment of a seamless transition from the incumbent to an incoming contractor /government personnel at the
expiration of the task order. The Contractor shall provide a Transition-Out Plan No Later Than (NLT) 90 days prior
to expiration of the task order.
C.6 SECTION 508 COMPLIANCE
Section 508 of the Rehabilitation Act requires Federal agencies to make their electronic and information technology
accessible to people with disabilities. This applies to all Federal agencies when they develop, procure, maintain, or
use electronic and information technology.
All electronic and information technology (EIT) procured through this task order must meet the applicable
accessibility standards specified in 36CFR1194.2, unless an agency exception to this requirement exists. Any agency
exceptions applicable to this task order are listed below.
The standards define Electronic and Information Technology, in part, as “any equipment or interconnected system or
subsystem of equipment that is used in the creation, conversion, or duplication of data or information. The standards
define the type of technology covered and set forth provisions that establish a minimum level of accessibility. The
application section of the standards (1194.2) outlines the scope and coverage of the standards. The standards cover
the full range of electronic and information technologies in the Federal sector, including those used for
communication, duplication, computing, storage, presentation, control, transport and production. This includes
computers, software, networks, peripherals and other types of electronic office equipment.
Applicable Standards, which apply to this acquisition
Section 1194.21: Software Applications and Operating Systems _____X____.
Section 1194.22: Web-based Internet Information and Applications _____X______.
Section 1194.23: Telecommunications Products _______________.
Section 1194.25: Self-Contained, Closed Products _____________.
Section 1194.26: Desktop and Portable Computers _____________.
Section 1194.31: Functional Performance Criteria ______________.
Agency Exceptions, which apply to this acquisition
National Security System _____________.
Acquired by a contractor incidental to a contract _________.
Located in spaces frequented only by a service personnel for maintenance, repair or
Software Application and Web-based Service Interface Page 20 of 36
Occasional monitoring of equipment ____________.
Would impose and undue burden on the agency ____________.
The Contractor must demonstrate compliance to 508 standards or their proposal will not be evaluated.
NOTE: Sections D.1 through D.4 of the offeror’s awarded Alliant GWAC are applicable to this Task Order and are
hereby incorporated by reference. In addition, the following applies.
D.1 DELIVERABLES MEDIA
Any deliverables under this task order will be accepted or rejected in writing by the GTR/GTM. The Contractor
warrants against latent defects for a period of two years all analysis, designs, plans and specifications produced
under this task order. Further constraints shall apply to computer software deliverables. Such products will be
accepted on an interim basis for payment, but must perform satisfactorily from period of acceptance date for 13
months. During this period the GTR/GTM (or designee) will have the right to reject or require correction of any
deficiencies found in the deliverable that are contrary to the information contained in the Contractor's accepted
proposal at no additional cost to the government. In the event of rejection of any deliverable the Contractor will be
notified by the GTR/GTM of the specific reasons why the deliverable is being rejected. Deficiencies discovered
within this period will be articulated by the government and the Contractor shall correct them within a period of 28
calendar days. If the deficiencies continue to exist after this 28 calendar day period, the Contractor shall correct
them at no charge to the government.
Services will be requested and controlled by means of written/verbal descriptions of specific requirements for each
task, which will delineate specific objectives, deliverables and information protection and system security (IPASS)
issues and controls as required. The Contractor shall be responsible for delivering all end items specified in the
work request.
Specific acceptance criteria, delivery schedules, and delivery instructions will be included in for each task where
necessary. Services will be requested and controlled by means of production logs, which will delineate all processed
deliverables. The Contractor shall be responsible for delivering all end items specified in the procedures as well as
production logs. When workload exceeds the production capabilities of the Contractor staff, priorities will be
annotated by the government to ensure that critical tasks are completed in a timely manner. The following are
deliverables that fall within the scope of this task order and are illustrative of some of the types of work the
Government expects to order:
System requirements documentation
System specifications documentation
Program specification documentation
Data analysis
Software maintenance
Quality assurance and quality control analysis and documentation
System/program test plan and analysis report
System software quality assurance report
Joint application design reports
Telecommunications, network and system analysis reports
NOTE: Sections E.1 through E.5 of the offeror’s awarded Alliant GWAC are applicable to this Task Order and are
hereby incorporated by reference. In addition, the following applies.
E.1 PLACE OF INSPECTION AND ACCEPTANCE
Inspection and acceptance of all work performance, reports and other deliverables under this task order will be
performed by the GTM at HUD Headquarters.
Software Application and Web-based Service Interface Page 21 of 36
E.2 SCOPE OF INSPECTION
E.2.1 All deliverables will be inspected for content, completeness, accuracy and conformance to task order
requirements by the GTM. Inspection may include validation of information or software through the use of
automated tools and/or testing of the deliverables, as specified in the task order. The scope and nature of this testing
must be negotiated prior to task order award and will be sufficiently comprehensive to ensure the completeness,
quality and adequacy of all deliverables.
E.2.2 The Government requires a period of not to exceed fifteen (15) work days after receipt of final deliverable
items for inspection and acceptance or rejection.
E.3 BASIS OF ACCEPTANCE
The basis for acceptance will be in compliance with the requirements set forth in the task order, the Contractor’s
proposal and other terms and conditions of the Government Quality Assurance Surveillance Plan. Deliverable items
rejected will be corrected in accordance with the applicable clauses.
E.3.1 For software development, the final acceptance of the software program will occur when all discrepancies,
errors or other deficiencies identified in writing by the Government have been resolved, either through
documentation updates, program correction or other mutually agreeable methods. (Software development only)
E.3.2 Reports, documents and narrative type deliverables will be accepted when all discrepancies, errors or other
deficiencies identified in writing by the Government have been corrected.
E.3.2.1 If the draft deliverable is adequate, the Government may accept the draft and provide comments for
incorporation into the final version.
E.3.2.2 All of the Government's comments to deliverables must either be incorporated in the succeeding version of
the deliverable or the Contractor must demonstrate to the Government's satisfaction why such comments should not
be incorporated.
E.3.2.3 If the Government finds that a draft or final deliverable contains spelling errors, grammatical errors,
improper format, or otherwise does not conform to the requirements stated within this Task Order, the document
may be immediately rejected without further review and returned to the Contractor for correction and resubmission.
If the Contractor requires additional Government guidance to produce an acceptable draft, the Contractor shall
arrange a meeting with the HUD GTR.
E.4 INITIAL DELIVERABLES
E.4.1 The Government will provide written acceptance, comments and/or changes requests, if any, within fifteen
(15 days) work days from receipt by the Government of the initial deliverable.
If there is a need for an extension to this timeframe the Government will notify the Contractor via the GTM/GTR
within 15 days.
E.4.2 Upon receipt of the Government comments, the Contractor shall have ten (10) work days to incorporate the
Government's comments and/or change requests and to resubmit the deliverable in its final form.
E.5 WRITTEN ACCEPTANCE/REJECTION BY THE GOVERNMENT
The Government shall provide written notification of acceptance or rejection of all final deliverables within fifteen
(15) work days. All notifications of rejection will be accompanied with an explanation of the specific deficiencies
causing the rejection.
E.6 NON-CONFORMING PRODUCTS OR SERVICES
Non-conforming products or services will be rejected. Deficiencies will be corrected, by the Contractor, within ten
(10) work days of the rejection notice. If the deficiencies cannot be corrected within ten (10) work days, the
Software Application and Web-based Service Interface Page 22 of 36
Contractor will immediately notify the GTR/GTM of the reason for the delay and provide a proposed corrective
action plan within ten (10) work days.
NOTE: Paragraphs F.1 through F.12 of the offeror’s awarded Alliant GWAC are applicable to this Task Order and
are hereby incorporated by reference. In addition, the following applies.
F.1 PLACE OF PERFORMANCE
All work will be performed at the Contractor’s site. The Government will not furnish office space or equipment for
Contractor staff. However, all project review meetings with the Government and Contractor staffs will be held at
the Headquarters unless instructed otherwise by the GTM.
The Contractor’s off-site facility must be fully operational with remote access (such as Virtual Private Network
(VPN), etc.) to applicable networks/systems as specified by the GTR/GTM during the transition-in period to ensure
smooth transition of operations from the incumbent vendor.
There is a need for close coordination and frequent interaction between the Contractor and personnel to facilitate
day-to-day systems operations, DME efforts, control over documents, and the need for rapid turnaround of work.
Therefore, the Contractor offices will be located in the Washington DC Metropolitan area with access to METRO
rail public transit.
F.2 PERIOD OF PERFORMANCE
This task order has a base period of 12 months, plus four (4) one-year option periods.
F.3 TASK ORDER SCHEDULE AND MILESTONE DATES
The Contractor shall provide the following deliverables based on the Government’s requirements. In accordance
with the PPM methodology, a Project Process Agreement (PPA) shall be used to tailor all project documentation
requirements to the scope, scale, and risk of each project. Following the PPA, the Government shall specify in each
Work Request all documents required of the Contractor. In some cases this may include updates to legacy
documentation under different title but satisfying the same PPM requirement (for example, a Functional
Requirements Document instead of a Requirements Definition Document). The Contractor shall provide all
documentation specified in each Work Request. Most PPM documentation will be developed or updated as part of
Tasks 1 and 2, with only minimal routine updates conducted under Task 3.
TOR
Reference
CLIN
Number
Deliverable
Due Date
Qty
C.5.4
0004
Transition-In Plan
Within 3 days
after contract
Kick-off
Meeting
1
C.5.4
4004
Transition-Out Plan
90 Days before
PoP end date
1
C.5.1.6,
C.5.2.4
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Earned Value Management Reports (ANSI/EIA 748)
Monthly, for
required Work
Requests
1 per Work
Request
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Project Status Meetings/Conference Calls
Weekly, twice
monthly, or
monthly as
required by
Government
1 per system,
as required or
Work Request
as required
C.5.1,
C.5.2,
0001-0004,
1001-1004,
Ad-hoc Meetings/Conference Calls
As required
As required
Software Application and Web-based Service Interface Page 23 of 36
TOR
Reference
CLIN
Number
Deliverable
Due Date
Qty
C.5.3,
C.5.4
2001-2004,
3001-3004,
4001-4004
C.5.1,
C.5.2,
C.5.3,
C.5.4
0001-0004,
1001-1004,
2001-2004,
3001-3004,
4001-4004
Meeting/Conference Calls Minutes
Within 3
business days of
the meeting/
conference call
1 for every
meeting in
which the
Contractor is a
participant
Need/Concept Phase Deliverables
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Project Work Plan showing cost, schedule, resources,
and Work Breakdown Structure (WBS), in the form
of a Microsoft Project-based Gantt chart document.
Prior to Work
Request approval
and updated as
required.
Updated with
performance
weekly after
Work Request is
authorized.
1 per Work
Request
Definition Phase Deliverables
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Requirements Definition Document
As defined in
Project Plan
As defined in
Project Plan
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Requirements Traceability Matrix
As defined in
Project Plan
As defined in
Project Plan
C.5.1
0001, 1001,
2001, 3001,
4001
Solution Architecture Document
As defined in
Project Plan
As defined in
Project Plan
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Quality Assurance Plan
Created/
updated as
required
1 per system,
updated as
required
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Security Risk Assessment
As defined in
Project Plan
1 per system,
updated as
required
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Security Plan
As defined in
Project Plan
1 per system,
updated as
required
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Project Management Plan
As defined in
Project Work
Plan
1 per system
or Work
Request,
updated as
required
Software Application and Web-based Service Interface Page 24 of 36
TOR
Reference
CLIN
Number
Deliverable
Due Date
Qty
C.5.1
0001, 1001,
2001, 3001,
4001
Risk Management Plan
As defined in
Project Plan
1 per system,
updated as
required
C.5.1
0001, 1001,
2001, 3001,
4001
Risk Register
As defined in
Project Plan and
updated weekly
As defined in
Project Plan
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Change Control Register
As defined in
Project Plan and
updated weekly
As defined in
Project Plan
C.5.1
0001, 1001,
2001, 3001,
4001
Configuration Management Plan
Created/
updated as
required
1 per system,
updated as
required
C.5.1
0001, 1001,
2001, 3001,
4001
Communication Management Plan
As defined in
Project Plan
1 per system,
updated as
required
C.5.1
0001, 1001,
2001, 3001,
4001
Staffing Management Plan
As defined in
Project Plan
1 per system,
updated as
required
C.5.1
0001, 1001,
2001, 3001,
4001
Capacity Plan
As defined in
Project Plan
1 per system,
updated as
required
C.5.1
0001, 1001,
2001, 3001,
4001
Concept of Operations (CONOPS)
As defined in
Project Plan
1 per system,
updated as
required
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Lessons Learned
As defined in
Project Plan
As defined in
Project Plan
Design Phase Deliverables
C.5.1
0001, 1001,
2001, 3001,
4001
Business Process Models
As defined in
Project Plan
As defined in
Project Plan
C.5.1
0001, 1001,
2001, 3001,
4001
Proof of Concept
As defined in
Project Plan
As defined in
Project Plan
C.5.1
0001, 1001,
2001, 3001,
4001
Prototype
As defined in
Project Plan
As defined in
Project Plan
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Technical Design Document
As defined in
Project Plan
As defined in
Project Plan
C.5.1
0001, 1001,
2001, 3001,
4001
Data Conversion Plan
As defined in
Project Plan
As defined in
Project Plan
C.5.1
0001, 1001,
2001, 3001,
4001
Interface Control Document
Created/
updated as
required
1 per system,
updated as
required
C.5
0001-0004,
Section 508 Compliance
Created/
1 per system,
Software Application and Web-based Service Interface Page 25 of 36
TOR
Reference
CLIN
Number
Deliverable
Due Date
Qty
1001-1004,
2001-2004,
3001-3004,
4001-4004
updated as
required
updated as
required
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Release Plan
As defined in
Project Plan
As defined in
Project Plan
C.5.1
0001, 1001,
2001, 3001,
4001
Interconnection Security Agreement (ISA)
As defined in
Project Plan
1 per system,
updated as
required
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Test Plan
As defined in
Project Plan
As defined in
Project Plan
Execution of Solution Phase Deliverables
C.5.1,
C.5.2,
C.5.3
0001, 0002,
0003, 1001,
1002, 1003,
2001, 2002,
2003, 3001,
3002, 3003,
4001, 4002,
4003
Operations and Maintenance Manual
Created/ updated
as required
1 per system,
updated as
required
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
User Manual
Created/ updated
as required
1 per system,
updated as
required
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Test Reports
As defined in
Project Plan
As defined in
Project Plan
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
User Acceptance Test Plan and test scenarios/scripts
As defined in
Project Plan
As defined in
Project Plan
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
HARTS Release Request
As defined in
Project Plan
As defined in
Project Plan
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Release Notes
As defined in
Project Plan
As defined in
Project Plan
Deployment Phase Deliverables
Software Application and Web-based Service Interface Page 26 of 36
TOR
Reference
CLIN
Number
Deliverable
Due Date
Qty
C.5.1,
C.5.2
0001, 0002,
1001, 1002,
2001, 2002,
3001, 3002,
4001, 4002
Project Completion Report
As defined in
Project Plan
As defined in
Project Plan
Operate and Maintain Phase Deliverables
C.5.1
0001, 1001,
2001, 3001,
4001
Post Deployment Report
As defined in
Project Plan
As defined in
Project Plan
C.5.3
0003, 1003,
2003, 3003,
4003
Operational Verification Checklist
Quarterly
1 per system,
updated as
required
C.5.3
0003, 1003,
2003, 3003,
4003
Operational Performance Measures
Monthly
1 per system,
updated as
required
C.5.3
0003, 1003,
2003, 3003,
4003
Operational Status Report
Daily (each
business day)
1 which
includes all
systems
C.5.3
0003, 1003,
2003, 3003,
4003
Trouble Call Log (for Tier 2 technical support)
Ongoing
1
C.5.3
0003, 1003,
2003, 3003,
4003
Populate all environments (DEV &UAT) with
production data
Monthly or as
requested by
Government
As required
per system
C.5.3
0003, 1003,
2003, 3003,
4003
Analysis and Testing for Infrastructure or Software
Upgrade(s)
As required
As required
C.5.3
0003, 1003,
2003, 3003,
4003
Participate in IPT’s, CCMB, HRMB, Gate Reviews,
or other operations/infrastructure meetings and/or
conference calls
As required
As required
C.5.3
0003, 1003,
2003, 3003,
4003
Participate in testing the CPD systems’ Contingency
Plans
Annually or as
required by
Government
As required
per system
Decommission Phase Deliverables
C.5.1
0001, 1001,
2001, 3001,
4001
Decommission Plan
Created/ updated
per phase
As defined in
Project Plan
C.5.1
0001, 1001,
2001, 3001,
4001
Post Decommission Report
Created/ updated
per phase
As defined in
Project Plan
F.4 PLACE(S) OF DELIVERY
GSA FAS/National Capital Region
F.5
NOTICE
REGARDING LATE
DELIVERY
The Contractor
shall notify
the
GTR/GTM,
as soon
as it becomes
apparent to
the Contractor,
that a scheduled
delivery
will be late.
The Contractor
shall include in
the notification
the rationale for
late delivery,
the expected
date
for
the delivery
and
the project impact of
the late delivery.
The GTR/GTM
will review
the new
schedule and
Software Application and Web-based Service Interface Page 27 of 36
provide guidance to the Contractor. Such notification in no way limits the Government's right to any and all rights
and remedies up to and including termination.
NOTE: Paragraphs
G.1
through
G.8
of
the offeror’s
awarded
Alliant GWAC
are applicable to
this
Task
Order
and
are hereby
incorporated
by
reference.
In
addition,
the following
applies.
G.1
INVOICE
SUBMISSION
The Contractor
shall provide invoice backup
data,
including
labor
categories, rates and
quantities
of
labor
hours.
The Contractor
shall submit invoices as
follows:
The Contractor
shall utilize
NCR's two
electronic system
to
submit invoices.
Invoices shall be
sent to
both:
https://portal.fas.gsa.gov
www.finance.gsa.gov
G.2 INVOICE REQUIREMENTS
The Contractor
shall submit Requests
for
Payments
in
accordance
with
the format contained
in
GSAM 552.232-70,
INVOICE
REQUIREMENTS (SEPT
1999),
to
be considered
proper
for
payment.
In
addition,
the data elements
indicated
below
shall be included
on
each
invoice.
Task
Order
Number: (from GSA
Form 300,
Block
2)
Paying
Number: (ACT/DAC
NO.)
(From GSA
Form 300,
Block
4)
NCR
Project No.:
Project Title:
The Contractor
shall provide invoice backup
data,
including
labor
categories, rates and
quantities
of
labor
hours.
G.2.1
INVOICING INSTRUCTIONS
A
proper
invoice for
each
task
order
shall be submitted
not later
than
5
work
days
after
acceptance
by
the
Government of
the product,
service,
and/or
cost item.
A
separate invoice for
each
task
order
shall be submitted
on
official company
letterhead
with
detailed
costs
for
each
of
the following
categories:
For
fixed
price tasks,
products delivered
and
accepted,
listed
by
deliverable number
For
time and
materials
tasks,
labor
expended
for
each
skill level
Total labor
charges
Travel and
per
diem
charges
Total invoice amount
Prompt payment discount offered
(if
applicable)
For
time and
materials
tasks,
the amount invoiced
shall include labor
charges for
actual hours
worked
and
other
actual expenses
based
upon
task
order
rates and
conditions,
not to
exceed
the limits
specified
in
the task
order
and
that have been
accepted
by
the
Government.
Copies of
contractor
paid
invoices, receipts;
travel vouchers
completed
in
accordance
with
Federal Travel
Regulations
(FTR)
shall be maintained
by
the contractor
and
made available to
the Government upon
request.
In
addition
to
the above information,
the invoice shall include the following
minimum
task
identification:
GSA
Task
Order
Number
Accounting
Control Transaction
(ACT)
number
(assigned
by
GSA
on
the Delivery
Order,
GSA
Form
300,
Block
4)
Sof
tware Application and Web-based Service Interface Page 28 of 36
Period
of
Performance
(month
services performed
for
work
request Contracts,
month
deliverable completed
for
fixed
price Contracts).
Invoice Number
Client name and
address
When
the paying
office is
GSA,
the original of
each
invoice,
with
supporting
documentation,
shall be submitted
to
the GSA
Paying
Office designated
in
Block
24
of
the GSA
Form
300.
In
those cases
where the paying
office is
other
than
GSA,
the
invoice/paying
office will be as specified
in
the order.
Invoices for
final payment must be so
identified
and
submitted
when
tasks
have been
completed
and
no
further
charges are to
be incurred.
These close-out invoices, or
a written
notification
that final invoicing
has been
completed,
must be submitted
to
the ordering
agency
within
30
days
of
Contract
completion.
A
copy
of
the written
acceptance
of
task
completion
must be attached
to
final invoices.
If
the contractor
requires an
extension
of
the 30
day
period,
a request with
supporting
rationale must be received
prior
to
the end
of
the 30-day
period.
Labor
hours
of
subcontractors
shall not be billed
at a rate other
than
the fully
burdened
hourly
rates agreed
to
in
the
Contract.
G.2.2
TRAVEL
Travel for
contractor
staff
is
not anticipated.
However,
if
the need
for
travel does arise,
the Contractor
shall adhere
to
the following
travel regulations.
Travel will be authorized
by
the Contracting
Officer
(CO)
as requested
by
the
GTR
and/or
GTM as appropriate.
No
local travel will be reimbursed.
All requests
for
travel must be approved
by
the GTR
and/or
GTM as appropriate prior
to
incurring
cost. Prior
to
any
long
distance
travel,
the Contractor
shall
prepare a
Travel Authorization
Request for
Government review
and
approval.
Long
distance
travel will be
reimbursed
in
accordance
with
the Federal Travel Regulations.
G.3
LIMITATION OF COSTS
FAR
Clause 52.232-20
applies
to
this
task
order
on
a Contract Line Item
Number
(CLIN)
basis
and
on
a total task
order b
asis.
The notification
required
by
the subject clause on
the part of
the Contractor
shall be made in
writing
to
the Contracting
Officer.
In
the event the task
order
is
not funded
beyond
the estimated
cost set forth
in
the schedule,
the Contractor
shall deliver
to
the Contracting
Officer
all data collected
and
material produced,
in
process
or
acquired,
in
connection
with
the performance
of
the task
order
together
with
a summary
report, in
three
(3)
copies,
of
its
progress
and
accomplishments
to
date.
NOTE: Paragraphs
H.1
through
H.20
of
the offeor’s
awarded
Alliant GWAC
are applicable to
this
Task
Order
and
are hereby
incorporated
by
reference.
In
addition,
the following
applies.
H.1
GOVERNMENT
FURNISHED PROPERTY (GFP)
HUD shall not furnish
office space or
equipment for
contractor
staff.
H.2
GOVERNMENT
FURNISHED INFORMATION
The Government will furnish,
at no
cost to
the Contractor,
when
required
and
authorized
by
the task
order:
Where possible and
appropriate,
external access
to
Government facilities
and
resources
will be provided.
Government forms,
publications,
documents,
and
other
information
required
for
task
order
performance.
Remote access
such
as
Virtual
Private Network
(VPN)
access
to
HUD’s
development, test,
and
production
environments
to
off-site Contractor
staff,
as
required
to
perform
work
identified
in
this
TOR.
-
Sof
tware Application and Web-based Service Interface Page 29 of 36
H.3 TRAVEL
H.3.1 TRAVEL REGULATIONS
The Contractor shall adhere to the following travel regulations (see FAR 31.205-46):
(1) Federal Travel Regulations (FTR) - prescribed by the General Services Administration, for travel in the
contiguous United States.
H.3.1.2 All requests for Travel must be approved by the by the Contracting Officer (CO) as requested by the
Government GTR and/or GTM as appropriate prior to incurring cost. Prior to any long distance travel, the
Contractor shall prepare a Travel Authorization Request for Government review and approval. Long distance travel
will be reimbursed in accordance with the Federal Travel Regulations (FTR).
H.3.1.2.1 Requests for travel approval shall:
Be prepared in a legible manner;
Include a description of the travel proposed including a statement as to purpose;
Be summarized by traveler;
Identify the task order number;
Identify the CLIN associated with the travel;
Be submitted in advance of the travel with sufficient time to permit review and approval.
The Contractor shall use only the minimum number of travelers and rental cars needed to accomplish the task(s).
Travel shall be scheduled during normal duty hours whenever possible. Airfare will be reimbursed for actual
common carrier fares which are obtained by the most reasonable and economical means.
H.3.1.2.2 The Government will identify the need for a Trip Report (if required) when the request for travel is
submitted. The Contractor shall keep a summary of all long-distance travel, to include, at a minimum, the name of
the employee, location of travel, duration of trip, and POC at travel location.
H.5 SECURITY REQUIREMENTS
H.5.1 SECURITY POLICY
The Government Handbook 2400.24 REV.2 (or the most current version), Security Program, describes the
department’s Data Processing Security Program. The policies outlined in the Handbook support the security
requirements found in the Model Framework for Management Control over Automated Information Systems and the
Security Guidance from the Office of Management and Budget (OMB) within circulars A-123, A-127 and A-130.
The Contractor will adhere to Homeland Security Presidential Directive (HSPD-12) as it applies to the Agency.
H.5.2 SECURITY AND OTHER COMPLIANCE CONCERNS
Any contractor personnel who are involved with the management, use, or operation of a sensitive computer
system/application are required to undergo a background investigation. A background investigation is required for
this task order see Contractor personnel will be required to complete Standard Form 85P, Questionnaire for
Sensitive Positions, Optional Form 305, Declaration for Federal Employment, and FD-258, Finger Print Card, or
any such form as may be required to complete the background investigation. Completed forms must be submitted to
the GTR and/or GTM as appropriate NLT 5 workdays after the effective date of the task order or the individual’s
assignment to this task order.
Any contractor personnel who are involved with the management, use, or operation of a sensitive computer
system/application are required to complete IT security awareness training annually as mandated by the Federal
Information Security Management Act (FISMA).
Software Application and Web-based Service Interface Page 30 of 36
Th
e Contractor shall comply with the Computer Security Act of 1987, the Industrial Security Manual for
Safeguarding Classified Information (DOD 5220.22-M), and the requirements of FAR Clause 52.204-9 – Personal
Identity Verification of Contractor Personnel (JAN 2006).
The Contractor shall provide security briefings to, and ensure compliance by its employees with the Government or
contractor security regulations. The Contractor must provide for the safekeeping, wearing, and visibility of a
contractor provided picture name badge, and any special agency badges. The Contractor shall ensure the return of
all badges, and any other Government property, upon task completion, or when personnel depart a task permanently
or for an extended period of time.
H.6 KEY PERSONNEL
The Alliant GWAC contains the contract labor category descriptions. The contract labor category descriptions
provide the minimum qualifications for the selected labor categories listed in Section B.
Key personnel must be assigned for the duration of the task order and may not be replaced or removed without prior
notification to the Contracting Officer. A comparable replacement must be chosen and agreed to by the GSA COR
and GTR/GTM. Resumes must be provided for each proposed key personnel in accordance with the key personnel
qualifications listed in Attachment 3.
H.7 ORGANIZATIONAL CONFLICT OF INTEREST AND NON-DISCLOSURE REQUIREMENTS
H.7.1 ORGANIZATIONAL CONFLICT OF INTEREST
If the Contractor is currently providing support or anticipates providing support to the Government that creates or
represents an actual or potential organizational conflict of interest (OCI), the Contractor shall immediately disclose
this actual or potential OCI in accordance with FAR Part 9.5. The contractor is also required to complete and sign
an Organizational Conflict of Interest Statement in which the Contractor (and any Subcontractors, consultants or
teaming partners) agree to disclose information concerning the actual or potential conflict with any proposal for any
solicitation relating to any work in the task order. All actual or potential OCI situations shall be handled in
accordance with FAR Subpart 9.5.
H.7.1.1 SERVICE IMPROVEMENTS
a.
Af
ter
task
order
award,
the Government may
solicit, and
the Contractor
is
encouraged
to
propose
independently,
improvements
to
the services,
features, or
other
requirements
of
the task
order.
These
improvements
may
be proposed
to
save money,
to
improve performance,
or
for
any
other
purpose
which
presents
a service advantage to
the Government.
As
part of
the proposed
changes, the
Contractor
shall submit a
price proposal to
the CO for
evaluation.
Those proposed
service
improvements
that are acceptable to
the Government will be processed
as modifications
to
the task
order.
b.
As a minimum,
the following
information
shall be submitted
by
the Contractor
with
each
proposal:
o
A
description
of
the difference
between
the existing
task
order
requirement and
the
proposed
change,
and
the comparative advantages and
disadvantages
of
each;
o
Itemized
requirements
of
the task
order
which
must be changed
if
the proposal is
adopted,
and
the proposed
revision
to
the
task
order
for
each
such
change;
o
An
estimate of
the changes
in
performance
and
cost, if
any,
that will result from
adoption
of
the proposal;
o
An
evaluation
of
the effects
that the proposed
changes would
have on
collateral costs
to
the Government, such
as Government-furnished
property
costs,
costs
of
related
items,
and
costs
of
maintenance,
operation,
and
conversion
(including
Government-premise
equipment);
Sof
tware Application and Web-based Service Interface Page 31 of 36
o A
statement of the time by which the TO modification adopting the proposal must be
issued so as to obtain the maximum benefits of the changes during the remainder of the
task order including supporting rationale; and
o Any effect on the task order completion time or delivery schedule shall be identified.
o The Government will not be liable for proposal preparation costs or any delay in acting
upon any proposal submitted pursuant to this clause. The Contractor has the right to
withdraw, in whole or in part, any proposal not accepted by the Government within the
period specified in the proposal. The decision of the CO as to the acceptance of any such
proposal under this task order is final and not subject to the "Disputes" clause of this task
order.
H.8 TRANSFER OF HARDWARE/SOFTWARE MAINTENANCE AGREEMENTS TO FOLLOW-ON
CONTRACTORS
The Contractor shall ensure that all hardware/software agreements entered into under this task order are transferable
to the Government and/or to other Contractors at the discretion of the Government.
H.9 EARNED VALUE MANAGEMENT CRITERIA
The Contractor shall employ EVM in the management of this task order. While the Government reserves the right
of final approval, a joint determination will be made by the Government and Contractor as to where EVM will be
applicable at the Task Order Kick-Off Meeting. The Government anticipates that the Contractor will employ
innovation in its proposed application of EVM techniques to this task order in accordance with best industry
practices. EVM effectively integrates the project’s technical scope of work with schedule and cost elements for
optimum project planning and control. The qualities and operating characteristics of earned value management
systems are described in American National Standards Institute (ANSI)/Electronic Industries Alliance (EIA)
Standard-748-A-1998, Earned Value Management Systems. A copy of the standard is available from Global
Engineering Documents (1-800-854-7179).
In the performance of this task order, the Contractor shall use an earned value management system to manage the
task order that:
(1) Is recognized by the GSA COR that complies with the guidelines in ANSI/EIA Standard 748.
(2) Provides on a monthly basis or more often as deemed necessary by the GSA COR and the following project
status information:
a)
B
udgeted
(planned)
cost of
work
scheduled
(BCWS)
b)
Budgeted
cost of
work
performed
(BCWP)
c)
Actual Cost of
Work
performed
(ACWP)
d)
Provide a cost curve graph
plotting
BCWS, BCWP,
and
ACWP
on
a monthly
basis
from
inception
of
the Contract
through
the last report, and
plotting
the ACWP
curve to
the estimated
cost at
completion
(EAC)
value
e)
Provide the following
Earned
Value Management variance
analysis:
Cost variance
= (BCWP
minus
ACWP)
Cost Variance
% =
(CV/BCWP
X 100%)
Cost Performance
Index
(CPI)
= (BCWP/ACWP)
Schedule Variance
= (BCWP m
inus
BCWS)
Schedule Variance
% =
(SV/BCWS X 100%)
Schedule Performance
Index
(SPI)
= (BCWP/BCWS)
Two
independent Estimates
at
Completion
(EAC)
ACWPcum
+ 1/CPI
X (BAC
minus
BCWP
cum)
ACWPcum
+ 1/CPI
X SPI
X (BAC
minus
BCWPcum)
Variance
at Completion
(VAC)
= (BAC
minus
EAC)
for
both
EACs
above
Variance
at Completion
% +
(VAC/BAC
X 100%) for
both
EACs
above
Expected
Funds
to
Completion
(ETC)
Sof
tware Application and Web-based Service Interface Page 32 of 36
Expected
Completion
Date
f)
Explain
the reasons
for
all variances
g)
Provide performance
variance.
Explain,
based
on
work
accomplished
as of
the date of
the report,
whether
the performance
goals
will be achieved
h)
Provide the Contractor
EAC
and
the differences
with
the two
independent EAC
calculated
as
above
i)
Discuss
the corrective actions
that will be taken
to
correct the variances,
the risk
associated
with
the actions,
and
how
close these actions
will bring
the project to
the original baseline.
Define
proposed
baseline changes,
if
necessary.
j)
Leverages EVM
techniques
in
managing
the aspects
of
the Contract
to
which
they
are most
beneficial
to
the Government in
accordance
with
best industry
practices.
NOTE: Paragraphs
I.1
through
I.10
of
the offeror’s
awarded
Alliant GWAC
are applicable to
this
Task
Order
and
are hereby
incorporated
by
reference.
In
addition,
the following
applies.
I.1
FEDERAL
ACQUISITION REGULATION (48
CFR
CHAPTER
1)
SOLICITATION CLAUSES (HTTP://WWW.ARNET.GOV/FAR/)
CLAUSE
NO
CLAUSE
TITLE
DATE
52.227-21
TECHNICAL
DATA
DECLARATION REVISION
(JAN 1997)
AND WITHHOLDING OF PAYMENT
–
MAJOR
SYSTEMS
52.237-3
CONTINUITY OF SERVICES
(JAN 1991)
I.2
FAR
52.217-8
OPTION TO EXTEND SERVICES (NOV 1999)
The Government may
require continued
performance
of
any
services within
the limits
and
at the rates specified
in
the contract. These rates may
be adjusted
only
as
a result of
revisions
to
prevailing
labor
rates provided
by
the
Secretary
of
Labor.
The option
provision
may
be exercised
more than
once,
but the total extension
of
performance
hereunder
shall not exceed
6
months.
The Contracting
Officer
may
exercise the
option
by
written
notice to
the
Contractor
within
30
days
of
task
order
expiration.
I.3
FAR
52.217-9
OPTION TO EXTEND THE
TERM OF THE
CONTRACT
(MAR
2000)
The Government may
extend
the term
of
this
contract by
written
notice to
the Contractor
within
10
days;
provided
that the Government gives
the Contractor
a preliminary
written
notice of
its
intent to
extend
at
least 60
days
before the contract expires. The preliminary
notice does not commit the Government to
an
extension.
If
the Government exercises
this
option,
the extended
contract shall be considered
to
include this
option
clause.
The total duration
of
this
contract, including
the exercise of
any
options
under
this
clause,
shall not exceed
five years.
NOTE: SECTION J
of
the offeror’s
awarded
Alliant
GWAC
is
applicable to
this
Task
Order
and
is
hereby
incorporated
by
reference.
J.1 LIST OF ATTACHMENTS
Attachment 1 – Current Systems Environment, Specifications, and Historical Data
Attachment 2 – Quality Assurance Surveillance Plan (QASP)
Attachment 3 – List of Acronyms
Software Application and Web-based Service Interface Page 33 of 36
NOTE: SECTION K of the offeror’s awarded Alliant GWAC is applicable to this Task Order and is hereby
incorporated by reference.
List of Acronyms
Acronym
Description
BA
Business Analysis
BPR
Business Process Re-Engineering
CCB
Change Control Board
CCMB
Configuration Change Management Board
CCR
Change Control Register / Central Contractor Registration
CDBG
Community Development Block Grant Program
CM
Configuration Management
CMP
Configuration Management Plan
COOP
Continuity of Operations
COR
Contracting Officers Representative
CP
Communication Plan
CP
Contingency Plan
CPD
Community Planning and Development
CR
Cost Reimbursable
DCP
Data Conversion Plan
DME
Development/Modernization/Enhancement
DP
Decommission Plan
DRD
Disaster Recovery Drill
DRGR
Disaster Recovery Grant Reporting
DSAG
Data Steward Advisory Board
EA
Enterprise Architecture
EDI
Electronic Data Interchange
EIT
Electronic and Information Technology
e-snaps
electronic Special Needs Assistance Programs Systems
EVM
Earned Value Management
EZ/RC
Empowerment Zone/Renewal Community Performance Measurement System (PERMS)
GMP
Grants Management Process
GMPC
Grants Management and Program Compliance
GR
Gate Reviews
GTM
Government Technical Monitor
GTR
Government Technical Representative
ICD or ISA
Interface Control Document/Interconnection Security Agreement
IDIS
Integrated Disbursement and Information System [online]
IPT
Integrated Project Team
IT
Information Technology
LL
Lessons Learned
Software Application and Web-based Service Interface Page 34 of 36
LMCT
Low-Mod Census Tracts
LOCCS
Line of Credit Control System-A76
LOE
Level of Effort
NLT
No Later Than
O&M M
Operations and Maintenance Manual
OCFO
Office Chief Finance Officer
OCIO
Office Chief Information Officer
OLAP
Online Analytical Processing
OMB
Office Management and Budget [White House]
OSIF
OCIO Office of Systems Integration and Efficiency
OTAM
Office of Technical Assistance and Management
OVC
Operational Verification Checklist
PCR
Project Completion Report
PDR
Post Deployment Report / Post Decommission Report
PERMS
EZ/RC Performance Measurement System
PMBOK
Project Management Body of Knowledge [Guide]
PMI
Project Management Institute
PMLC
Project Management Life Cycle
POA&M
Plan of Action & Milestones
POC
Points of Contact
PPM
Project Planning Management
PWP
Project Work Plan
QA
Quality Assurance
QASP
Quality Assurance Surveillance Plan
RA
Risk Assessment
RDD
Requirements Definition Document
RMP
Risk Management Plan
RN
Release Notes
RP
Release Plan
RR
Risk Register
RTM
Requirements Traceability Matrix
SAD
Solution Architecture Document
SDED
Systems Development and Evaluation Division
SMP
Staffing Management Plan
S-SCM
Steady-State Corrective Maintenance
SSP
System Security Plan
STraCAT
Sound Transmission Classification Assessment Tool
TDD
Technical Design Document
TOR
Task Order Request
TP
Test Plan
TPOCs
Technical Points of Contact
TR
Test Report
Software Application and Web-based Service Interface Page 35 of 36
TRM
Technical Reference Model
UAT
User Acceptance Testing
V&V
Verification and Validation
WBS
Work Breakdown Structure
WR
Work Request
Software Application and Web-based Service Interface Page 36 of 36
