Contracting Guidance to Support 

Modular Development

June 14, 2012
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

Table of Contents
	

I. Purpose and Scope ............................................................................................................................... 2
 

II. Overview............................................................................................................................................... 2
 

III. Background ........................................................................................................................................... 3
 

IV. Modular Development: Key Terms, Principles and Risks ..................................................................... 6
 

A. IT Investment .................................................................................................................................... 6
 

B. Projects and activities ....................................................................................................................... 7
 

C. Key Principles .................................................................................................................................... 9
 

D. Risk and Challenges in Modular Development ................................................................................. 9
 

V. Modular Contracting for IT: Tools and Strategies...............................................................................10
 

A. Contracting Approaches Suitable for Modular Development ........................................................10
 

B. Payment Strategies .........................................................................................................................16
 

C. Use of Competition.........................................................................................................................19
 

D. Provisions and Clauses....................................................................................................................20
 

E. Additional Acquisition Considerations............................................................................................21
 

VI. Appendix: Sample Performance Work Statement..............................................................................23
 

 1 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

I. Purpose and Scope 

The purpose of this guidance is to provide agencies with contracting guidance to support modular 

development, as required by Information Technology (IT) Reform Action 15: Issue Contracting Guidance 

and Templates to Support Modular Development, 25 Point Implementation Plan to Reform Federal 

Information Technology Management.1 This guidance presents a variety of factors that contracting 

officers, in support of IT managers, will need to consider as they plan for modular development efforts, 

such as whether to award to a single vendor or multiple vendors; how to ensure that there is 

appropriate competition at various stages in the process; how broad or specific the statements of work 

should be; when to use fixed-price contracts or rely on other pricing arrangements; and how to promote 

opportunities for small business.2 It also empowers agency leadership and Integrated Project Teams 

(IPTs)3 with strategies and tools to improve investment manageability and budgetary feasibility, reduce 

overall risk, and support rapid delivery of workable solutions. This document is not intended to provide 

comprehensive guidance concerning a development methodology or standards for a modular software 

development lifecycle; rather, it is primarily focused on outlining acquisition guidance to support 

modular development approaches. 

II. Overview 

As outlined in the 25 Point Implementation Plan to Reform Federal Information Technology 

Management4

, Federal agencies have traditionally taken a multi-year “grand design” approach for 

developing, modernizing, and enhancing investments in IT. This approach is grounded in the common 

notion that responsible development necessitates a full detailing of requirements before work can start. 

Although a seemingly reasonable assumption, practical evidence and private sector experience has 

shown that large and complex IT implementations often encounter cost and schedule overruns, as the 

painstaking process of requirements gathering too frequently takes years to complete. Subsequently, 

agencies lose visibility into the performance of these multi-year IT development investments which 

affects their ability to implement corrective actions that reduce risk or mitigate financial exposure. The 

Government increases investment risk in these situations because: (1) the IT solutions that had once 

addressed agency requirements may no longer be pertinent or a priority; (2) substantial funds are 

allocated towards outdated solutions without any returns on the investments; or (3) agencies encounter 

budgetary constraints before substantive work is completed. 

To help resolve these issues, modular approaches should be used in the development of IT investments, 

allowing agencies to implement significant capabilities for investments through the use of modular 

solutions that can be defined, developed, and deployed within months instead of several years. This 

guidance highlights critical success factors for adopting modular approaches, including the need to 

strengthen collaboration among agency IT, program, acquisition, and finance offices in order to design, 

resource, and manage investments in a modular fashion. To ensure successful collaboration across these 

offices, it is important to have a common and consistent vocabulary for key modular IT and acquisition 

1 25 Point Implementation Plan to Reform Federal IT Management: http://www.cio.gov/documents/25-Point-Implementation-Plan-to-ReformFederal%20IT.pdf 

2 Ibid.
 3
 OMB Capital Programming Guide, June 2006, page 9: 

http://www.whitehouse.gov/sites/default/files/omb/circulars/a11/current_year/part7.pdf 

4 25 Point Implementation Plan to Reform Federal IT Management 

 2 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

terms and concepts, describe how the work of each community fits together, and stress the necessity of 

having an IPT5

. This guidance also provides tools and strategies for agencies to employ in the adoption of 

modular IT development practices. Finally, this guidance provides excerpts from a sample performancework statement to support modular software development. Agencies are expected to assess and adjust 

capital planning and investment control and acquisition planning policies and practices to more explicitly 

incorporate these modular approaches in IT development and acquisition. Using these approaches, 

agencies can realize faster returns on IT investments and deploy technology solutions that will propel 

them towards a ͞21st century digital government, one that is efficient, effective and focused on 

improving the delivery of services to the American people.͟6 

III. Background 

Modular approaches involve dividing investments into smaller parts in order to reduce investment risk, 

deliver capabilities more rapidly, and permit easier adoption of newer and emerging technologies. 

Section 5202 of the Clinger-Cohen Act of 1996 and section 39.103 of the Federal Acquisition Regulations 

(FAR) each recognize these potential benefits of modular contracting and state that agencies ͞should, to 

the maximum extent practicable, use modular contracting for an acquisition of a major system of 

information technology.͟7 Furthermore, OMB Circulars A-130 and A-11, as well as the Capital 

Programming Guide, include modular development and contracting approaches for capital asset 

acquisitions in general, which also readily apply to acquiring and developing investments in IT. 

By following a modular approach, agencies can recognize the following benefits: 

 Delivery of usable capabilities that provide value to customers more rapidly as agency missions 

and priorities mature and evolve; 

 Increased flexibility to adopt emerging technologies incrementally, reducing the risk of 

technological obsolescence; 

	 Decreased overall investment risk as agencies plan for smaller projects and increments versus 

“grand design” (each project has a greater overall likelihood of achieving cost, schedule, and 

performance goals than a larger, all-inclusive development effort); 

	 Creation of new opportunities for small businesses to compete for the work; 

	 Greater visibility into contractor performance. Tying award of contracts for subsequent Task 

Orders to the acceptable delivery of prior projects provides agencies better visibility into 

contractor performance and allows a greater opportunity to implement corrective actions 

without sacrificing an entire investment; 

	 An investment can be terminated with fewer sunk costs, capping the risk exposure to the agency 

when priorities change, a technology decision doesn’t work or the contractor’s performance 

doesn’t deliver results. 

5 Guidance On Exhibit 300; —Planning, Budgeting, Acquisition, And Management Of IT Capital Assets, page 4: 

http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/fy13_guidance_for_exhibit_300_a-b_20110715.pdf 

6 Digital Government: Building a 21st Century Digital Platform to better serve the American People, May 23, 2012, page 17: 

http://www.whitehouse.gov/sites/default/files/omb/egov/digital-government/digital-government-strategy.pdf 

7 Federal Acquisition Regulation (FAR), Section 39.103 Modular Contracting, (a): 

https://www.acquisition.gov/far/current/html/Subpart%2039_1.html#wp1096819 

 3 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

Given the imperative that agencies “innovate with less,” it is essential that the IT and acquisition 

communities take advantage of modular approaches to derive these benefits in the following ways: 

	 From an IT perspective, modular development allows agencies to test the probability of the 

successful implementation of solutions in shorter time periods, which better positions agencies 

to adopt new innovative technologies. Successful organizations use modular approaches to 

define high-level requirements, and then continue to refine their needs through an iterative 

process that includes continual engagement and collection of feedback from stakeholders, 

particularly from customers, until work is completed. To minimize risk and maximize the success 

of the deployment, major investment enhancements or capabilities are completed 

incrementally. This includes a prioritization of critical requirements and functionality that will 

deliver features for customers. 

	 From an acquisition perspective, a modular approach to contracting balances the Government’s 

need for fast access to rapidly changing technology and risk management. This approach 

provides for the incremental delivery, implementation, and testing of an investment. A modular 

approach is one of many methods that may be used by Federal Agencies to acquire major IT 

investments. The acquisition may be achieved through a single procurement, or multiple 

procurements, but should balance the Government's need for fast access to rapidly changing 

technology and incentivized contractor performance with stability in program management, 

contract performance and risk management. In addition, it opens new opportunities for small 

businesses to compete for just a part of the work in the overall investment. 

Successful application of modular IT development and contracting also requires a commitment to take 

advantage of IPTs, and understanding what structures, strengths, and benefits they provide. All IPT 

members, including those from IT and acquisition offices, should have defined roles and be part of the 

process, from initiation to completion. The acquisition strategy and the development of the projects 

should be planned and coordinated closely or the investment will bear unnecessary risk. Each member 

of the IPT may have slightly different roles in achieving the investment objectives, but will need to 

collaborate and communicate effectively throughout the process. A sample of key IPT responsibilities in 

using modular approaches is shown in Table 1. 

 4 
 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

Table 1: Sample Integrated Program Team Responsibilities for Modular Approaches 

Acquisition Mission Focus Acquisition Focus IT Focus Budget Focus 

Step8 

Describe the Identify congruent Identify similar Complete the alternative Identify outlays 

problem problems in agency. 

Identify foundational 

elements to the 

problem. Prioritize the 

problems. Build the 

business case. 

problems in the 

agency. Identify how 

other parts of the 

agency are affected 

by the problem. 

analysis, cost benefit analysis 

and capital planning 

procedures. Identify the 

projects in the IT Dashboard. 

addressing problems in 

the agency. Look for 

opportunities to 

aggregate the buying 

power. 

Examine Consider how other Collect market Target “Shared First” and Develop price analysis 

public-sector agencies have research on this “Future Ready”9 capabilities models for the different 

and private- addressed this problem. Look for already in place. Reference types of solutions. 

sector problem. Consider how 

the industry has 

opportunities to buy 

from other agencies 

the Enterprise Architecture 

for the range of solutions. solutions addressed this 

problem. 

instead of making a 

separate award. 

Describe the Consider the longer- Develop an Identify the work in a generic Reconcile the work with 

work term strategy. Identify 

near-term, actionable 

goals to achieve the 

strategy. Identify 6-

month targets. 

acquisition strategy 

to support the near 

and long-term goals 

using a modular 

acquisition approach. 

manner so that other parts of 

the agency can leverage it. 

Plan to develop in projects or 

increments no longer than 6 

months and re-plan. 

the price model and 

refine each. 

Consider how Make sure the IPT is Tie contractor Review this investment’s Monitor cost and 

to measure delivering new features payment, exercise of performance in the agency schedule performance, 

and manage and capabilities. options and follow- TechStat process10 . obligations and actual 

performance on orders or 

contracts with 

successful contractor 

performance. 

costs. 

Select the Develop the Technical Make the Validate that the offeror’s Provide price analysis 

right Evaluation Report and selection(s). approach and experience are support to the 

contractor advise the Contracting 

Officer. 

likely to deliver in a modular 

fashion. In the technical 

evaluation, identify 

inconsistencies with the 

agency’s Enterprise 

Architecture. 

Contracting Officer. 

Manage Invest in developing Invest in developing Invest in developing high- Invest in developing 

performance high-performing IPTs. 

Participate with the 

developers weekly or 

daily, and test new 

features and 

capabilities consistent 

with the Acquisition 

Plan. Plan what is 

needed in the next 

project. 

high-performing IPTs. 

Receive performance 

metrics consistent 

with every project or 

increment, take 

action when 

necessary. 

performing IPTs. Push new 

technology advances into the 

planning of successive 

projects. 

high-performing IPTs. 

Consider the balance 

between capital 

expenditure and 

operating expenditure 

and achieve the mix 

that is right for the 

agency. 

8 Adapted from the Seven Steps to Performance-based contracting: https://www.acquisition.gov/comp/seven_steps/home.html 9 Federal Information Technology Shared Services Strategy, May 2, 2012: http://www.cio.gov/documents/Shared_Services_Strategy.pdf 10 25 Point Implementation Plan to Reform Federal IT Management, December 9, 2010, Point 23 

 5 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

IV. Modular Development: Key Terms, Principles and Risks 

The following sections outline key terms, examples, and principles that are important to understand in 

implementing modular approaches to IT acquisition. Figure 1 establishes a hierarchy of terms for this 

guidance. 

Figure 1: Relationship within an IT Investment11 

Investment (System) 

Project 1 (Increment) Project 2 Activity Activity Activity Project N 

* Clinger-Cohen Act terms are indicated in parentheses 

Modular development focuses on an investment, project, or activity of the overall vision and 

progressively expands upon the agencies’ capabilities, until the overall vision is realized. Investments 

may be broken down into discrete projects, increments, or useful segments, each of which are 

undertaken to develop and implement the products and capabilities that the larger investment must 

deliver. Projects, as defined in Exhibit 300 Guidance, increments as defined in the Clinger-Cohen Act, and 

useful segments as defined in OMB Circular A-130, are each interchangeable terms. Additionally, there 

is a subtle difference between the Capital Programming Guide and the Exhibit 300 guidance concerning 

an IPT. The former refers to Integrated Project Teams and the latter identifies Integrated Program 

Teams. The guidance in this document applies to both the project and program levels. For the balance 

of this guidance the Exhibit 300 terms will be used. Modular development must be viewed within the 

larger context of capital programming and the different levels at which program development is 

accomplished. 

A. IT Investment 

Capital programming begins with the planning and justification of an IT investment that is the 

expenditure of IT resources to accomplish mission objectives. An IT investment may include ͞a project or 

projects for the development, modernization, enhancement, or maintenance of a single IT asset or group 

of IT assets with related functionality and the subsequent operation of those assets in a production 

environment.͟12 Agencies invest in current and planned capital IT assets to enable and support the 

mission and information management needs. Assets are developed, acquired, and managed through the 

CPIC process. From the perspective of the Clinger-Cohen Act, the IT investment is the “system” that is 

subdivided into increments. 

An IT investment is initiated and authorized by management based on a business case that establishes 

the need for a new or modernized information system. The business case serves as a decision support 

document that identifies alternatives and presents business, economic (e.g., cost and benefits), risk, and 

11 FY 2013 OMB Exhibit 300 Guidance, page 17 12 Ibid, page 5 

 6 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

technical arguments for selecting an alternative to achieve organizational or functional missions or 

goals. The business case also establishes an estimated cost, schedule, and performance baseline prior to 

acquisition of the IT system, application, or asset. IT investments are reported by agencies to the IT 

Dashboard, a website enabling federal agencies, industry, the general public and other stakeholders to 

view details of federal information technology investments.13 

It is at the investment level that a modular development approach should be carefully considered for IT 

investments, or other larger or more complex investments with longer development durations. The 

investment may be divided into several smaller components like projects and activities that will deliver 

useful functionality and capability to users and are easier to manage than a single, multifaceted and 

monolithic system. 

B. Projects and activities 

As defined in OMB guidance for IT Capital Planning and Investment Control, projects are temporary 

endeavors with a defined start and end point, and may be comprised of lower-level activities at a more 

granular level of detail.14 Each project must produce a measurable result toward delivering the 

investment’s functionality or capability. Projects are also reported to the IT Dashboard. 

Current guidance, such as OMB Circular A-130, already directs agencies to ͞[s]tructure major 

information systems into useful segments with a narrow scope and brief duration. This should reduce 

risk, promote flexibility and interoperability, increase accountability, and better match mission need with 

current technology and market conditions.͟15 While the terminology may be different, the objective is 

the same. For IT investments, each project must have its own cost estimate, budget identifying full 

funding, schedule, performance expectations, and key deliverables for the product or capability it will 

develop and deliver. Each project should have its own development lifecycle (e.g., planning, acquisition, 

development, and deployment) and should be scoped in a way that it can be acquired independently. 

Put another way, the acquisition of any single project should not commit the Government to acquiring 

any future project.16 This concept of stand-alone functionality is critical to the Government’s ability to 

effectively manage its investments and to minimize the risk of cost overruns, schedule delays, and 

performance failures. 

Projects can be built sequentially or in parallel, depending on the programmatic needs, priorities, 

resources and management capacity of the organization. They can be designed so that subsequent 

projects add capabilities incrementally. Stages of iterative or “agile” development of subsequent 

increments refine and improve upon the initial capability. Other projects can be integrated so that, 

when brought together, they expand the capabilities to meet a wider range of the agency’s 

requirements. Investments, projects and activities (see Table 2) can span fiscal years. Investment data is 

submitted and reported to OMB with the agency annual budget request and periodically through the 

budget formulation process. Cost and schedule performance for projects and activities beginning or 

13 A website to view details of federal information technology investments: http://www.itdashboard.gov/ 14 FY 2013 OMB Exhibit 300 A-B Guidance, page 6 15 Circular Number A-130 Revised: http://www.whitehouse.gov/omb/circulars_a130_a130trans4/ 16 The Clinger-Cohen Act and FAR 39.103(b)(3) state that when using modular contracting, an acquisition of a system of information technology 

may be divided into several smaller acquisition increments that “provide for delivery, implementation, and testing of workable systems or 

solutions in discrete increments, each of which comprises a system or solution that is not dependent on any subsequent increment in order to 

perform its principal functions.” 

 7 
 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

completing in any given budget execution year are reported to OMB on an ongoing basis as required by 

OMB Circular A-11, Exhibit 300. 

Table 2: Characteristics of IT Investment Levels 

Level Characteristics Typical Duration 

Investment Can be a major or a non-major IT investment, but size, scope and 

cost will vary. Also called a system in the Clinger Cohen Act. 

Variable 

Project Each investment may be broken down into one or more projects, 

increments or useful segments, each of which produces a 

measurable result towards delivering the functionality or capability 

identified in the investment’s business case. Projects produce a 

useable system or functionality that can be implemented and used 

effectively independent of future projects. 

Projects should aim to 

deliver functional value 

frequently, producing 

functionality in as little 

as six months. 

17 

Activity Activities are tasks within a project, each of which are necessary for 

the project to be successful. 

Ideally 90 days or less. 

Table 3 provides an example of how an IT investment could be structured using a modular development 

approach. In this case, the first project plans the roadmap, and additional projects can subsequently 

deliver additional capability and interfaces. 

Table 3: Sample IT Investment Structure 

Investment: System N 

Project Activities Functionality 

Planning Overall high-level requirements for 

investment or program 

Roadmap of investment or program 

Base System Requirements and Design 

Release 1 Base functionality: front-end and back-end, authentication 

Migration of legacy data and 

disposition of System Y 

Application X takes over operations from the legacy 

system 

Release 2 Additional functionality 

Release 3 Additional functionality 

Reports Requirements and Design 

Canned Reports – Release 1 Users can produce canned reports 

Ad-Hoc Reports – Release 2 Users can create ad-hoc reports 

Application 

Interfaces 

Requirements and Design 

Interface 1 – Release 1 Application X can interact with system A 

Interface 2 – Release 2 Application X can interact with system B 

Interface 3 – Release 3 Application X can interact with system Z 

Enhancements to 

Application Z 

Requirements and Design 

Release 1 Base functionality 

Release 2 Additional functionality 

Interface Between 

Application X and 

Application Z 

Requirements and Design 

Interface 1 – Release 1 

Simultaneous with Release 3 of 

Application X 

Application X can interact with Application Z 

Pursuant to FAR 39.103, to the maximum extent practicable, deliveries under the contract should be scheduled to occur within 18 months 

after issuance of the solicitation. (Modular contracts for IT should, to the maximum extent practicable, be awarded within 180 days after the 

date on which the solicitation is issued. If award cannot be made within 180 days, agencies should consider cancelling the solicitation.) 

 8 

17 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

C. Key Principles 

There are several general principles agencies should apply to realize the intended benefits of modular 

development: 

 Agencies should share-first, focus on reusability and leverage projects across the organization; 

 IPTs should be formed to identify the functional, technical and other capabilities and 

characteristics required to make each project’s product or deliverable viable and useful; 

 End users should be involved early and throughout the development process. Requirements 

and designs may mature as the understanding of the users’ needs matures; 

	 The IT Project Manager's team and the Contracting Officer's team should collaborate early in the 

requirements definition process. It is especially important for the teams to collaborate on the 

design of the modular development approach and to develop the acquisition strategy that can 

best be applied to deliver the intended results; 

	 The IT Project Manager should use the input from the IPT, end users, and Contracting Officer in 

the development of the Exhibit 300, which explains the agency’s justification for the investment; 

	 Proper governance should be provided to oversee the investments’ and projects’ progress and 

results. Agencies are required to establish cost, schedule and measurable performance goals for 

all major acquisition programs, and achieve, on average 90 percent of those goals;18 

 Cost and schedules should be managed at the project and activity levels, and cost and schedule 

targets should be developed for each activity; 

 Performance measures and outcomes should be defined early in the process, and should be 

monitored throughout the process through the established governance structure. 

D. Risk and Challenges in Modular Development 

Modular development is not a one-size-fits-all strategy. While a modular approach addresses many 

risks, it also creates certain predictable challenges that should be anticipated in evaluating whether it is 

suitable for a given investment. Table 4 identifies some of the challenges agencies can expect to face 

when using modular development strategies. If a decision is made to proceed with a modular approach, 

these challenges should be addressed by the IPT in the Risk Management Plans at the investment and 

project levels. 

Table 4: Challenges in Modular Development 

Challenge Description 

Outdated risk 

management process 

Risk management processes may be aligned to the traditional waterfall approach 

and may require updating. 

Integration The more projects, the greater the potential challenge to integrate the parts (and 

the contractors if there are different contractors performing different parts); gaps 

may develop in responsibility and accountability. 

Communication Compartmentalized work may introduce complexity in communications without a 

strong IPT. 

Acquisition workload 

and schedule 

Each project potentially creates additional workload for the acquisition workforce 

(e.g., such as awards of iterations in a short time frame) and can add to the total 

time required to deliver a capability. 

Federal Acquisition Streamlining Act of 1994, Title V (FASA V) and Clinger-Cohen Act Sec. 5122. 

 9 

18 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

While a modular development approach can allow agencies to implement new technologies within an 

investment, agencies cannot operate outside of the enterprise architecture. The decision to implement 

a new technology must be right for the agency and incorporated into the agency’s future architecture, 

as reflected in project documentation and the agency’s annual Enterprise Roadmap. 

V. Modular Contracting for IT: Tools and Strategies 

Modular development is designed to help position an agency’s customers, also known as end users, to 

realize usable capabilities more rapidly. However, achieving timely results requires the contracting cycle 

to be in alignment with the technology cycle of modular development, which may range from 3 months 

to 18 months, as described in Table 2. Use of modular contracting practices (see Figure 3) can help an 

agency achieve these timeframes and eliminate the costly lag between the time when the Government 

defines its requirements and when the contract begins delivering workable solutions. 

Modular contracting is defined in the FAR as the “use of one or more contracts to acquire information 

technology systems in successive, interoperable increments.͟19 This section of the guidance discusses the 

strategies and practices that are best suited to support the high level of responsiveness that agencies 

need for modular development of IT requirements. 

The acquisition concepts listed below, and described in greater detail in the balance of the document, 

are first steps an agency can take to support an organization’s adoption of modular IT development 

principles. These concepts may be applied not only to individual projects (e.g., base system, reporting 

module, system interface) but also activities within projects (e.g., migration of legacy data, ad-hoc 

reports). 

A. Contracting Approaches Suitable for Modular Development 

There are a variety of ways in which agencies can structure their acquisition strategy to effectively 

support modular development. These include indefinite-delivery indefinite quality (IDIQ) contracts, a 

single contract with options, successive contracts, and performance-based work statements. Each type 

of contract has benefits and limitations unique to modular development, as described in the sections 

below. 

Federal Acquisition Regulations, 39.002 Definitions: https://www.acquisition.gov/far/html/Subpart%2039_1.html 

 10 

19 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

Figure 2: Checklist for Aligning Contracting Practices and Modular Strategies for IT Development 

 Structure contracts to support the level of responsiveness that agencies require 

for a given project or activity. 

 Describe work in a manner that allows contractors to perform due diligence and 

agencies to take advantage of the expertise and innovation that contractors can 

provide to support agencies as they meet mission needs. 

 Use payment strategies that effectively incentivize contractors to provide the 

best value for a given project or activity. 

 Take advantage of competition on contracts and task orders to generate 

alternative solutions from which the agency may select the best value. 

 Include contract terms and conditions that effectively protect the Government’s 

interest, including appropriate data rights. 

 Take advantage of existing contract vehicles before looking to create new ones 

and consider providing capacity for other agencies when creating new vehicles. 

 Provide maximum, practicable opportunities for small businesses and other 

targeted socio-economic groups (e.g. small disadvantaged businesses, womenowned small businesses, veteran-owed small businesses, service-disabled 

veteran-owned small businesses, and small businesses in historically 

underutilized business zones). 

1.	 Indefinite-delivery indefinite-quantity (IDIQ) task and delivery order contracts 

IDIQ contracts are likely to be the most popular contracting form as agencies migrate to modular 

development approaches. Under an IDIQ contract, the agency awards an “umbrella” contract to one or 

more contractors with a statement of work that describes the general scope, nature, complexity and 

purposes of the goods or services to be procured. The agency then places orders for specific goods or 

services within this general scope of work as needs arise. IDIQ contracts may be particularly 

advantageous when the scope of all subsequent projects cannot be clearly defined when the contract is 

first awarded. 

Using IDIQ contracts in modular development can: 

	 Allow the agency to issue small orders for short time periods to fulfill specific project 

development needs within six month intervals as well as rapid response activities in 90 day 

periods (e.g., one release every 90 days rather than two releases together after six months). An 

order may provide for delivery of an individual project, negotiated with or competitively 

awarded to a qualified vendor or group of qualified vendors on the contract; 

	 Provide a high level of acquisition responsiveness, as agencies avoid the time and expense of 

having to compete and award a series of successive, stand-alone contracts (e.g., each with their 

own terms and conditions, pricing, and contractor qualification requirements); 

	 Accommodate the full spectrum of the system lifecycle with multiple contract line items (CLINs) 

that provide both development and operational products and services. Development activities 

may include requirements specification, architectural design, and software design and 

development; 

 11 
 

 12 

 

 

 

 

 

 

 

 

 

 

 

 

-

-

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

	 Mitigate the agency’s legal and financial exposure, as the Government is only obligated for a 

stated minimum. Future obligations may be made when requirements are clearer or when the 

agency has resources to acquire additional functionality; 

 Increase opportunities to set aside orders for small businesses; 

 Provide maximum flexibility and increased competition when using multiple award and hybridtype IDIQ contracts (discussed below). 

In 1994, the Federal Acquisition Streamlining Act modified procurement laws to clarify that agencies 

may make multiple awards under the same solicitation for more than one IDIQ contract, known as 

multiple award contracts. Multiple award contracts allow agencies to conduct streamlined minicompetitions between contract holders who must be given a “fair opportunity to be considered” for 

each order over the micro-purchase threshold, currently $3,000. This authority has significantly 

enhanced the utility of IDIQ contracts, both by giving agencies a means to generate efficient competition 

and by allowing agencies to consider a broader range of market-based solutions under one vehicle for 

each identified increment of work without being forced to negotiate on a sole source basis for 

technology refreshment and other needs. It has also made it easier to facilitate interagency acquisition 

through Government-wide acquisition contracts (GWACs), multi-agency contracts, and the Federal 

Supply Schedules managed by the General Services Administration (GSA). (See Subsection E for 

additional discussion.) 

Figure 3: Moving from a Traditional to Modular Approach 

The Department of Homeland Security’s (DHS) Immigration and Customs Enforcement (ICE) Office of the Chief 

Information Office is leading an effort to transition from methods seeking enterprise solutions through large scale, 

long-term contracts, to “bite-size” awards supporting agile-based development and a significantly shortened time 

to value. 

As an example of this transition, ICE’s strategy includes IDIQ contracts for requirements, architectural design and 

software development and a blanket purchase agreement (BPA) under the GSA Schedule for software operations 

and maintenance. The IDIQ contracts and blanket purchase agreements will save time by simplifying acquisition 

planning and technical evaluation for these services while providing the agency with ready access to a range of 

sources that can be quickly considered to perform these tasks to support a range of IT projects being undertaken 

within the agency. 

Traditional Approach Modular Approach 

Award Small Orders for Short Time Periods 

 Shorter acquisition cycle leverages streamlined 

processes 

 Multiple vendors provide a variety of services 

Use Modular and Agile Development Methodologies 

 Rapid incremental releases 

Award Large, Long term Contracts 

 Lengthy procurement cycle 

 Awarding option years is the rule, not the exception 

 Project success is dependent on a single vendor’s heroics 

Use Waterfall based Development Methodologies 

 Time to market is very lengthy 
 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

2. Single contract with options 

Award of a single contract with options may be beneficial when the integration effort will involve unique 

skills obtainable only through the success of previous projects. Agencies must take care to ensure that 

competition among all potential bidders is fair and that all options are priced with the proposal. 

Providing that the industry is able to identify prices and the Government is able to effectively evaluate 

them, a single contract can be a good tool to support modular acquisition. 

3. Successive contracts 

Successive contracts may be appropriate when there is sufficient time to award successful individual 

contracts, the administrative cost is outweighed by the potential cost/technical benefits derived from 

the competitive marketplace, and where contractor continuity is not a predominant concern. This 

approach allows the agency to distribute risk among multiple contracts. 

Figure 4: Distributing Risk Between Multiple Contractors to Support Modular Development 

The Veterans Benefits Management System (VBMS) is improving service to Veterans by migrating from a paperintensive process to an entirely electronic system for processing disability claims from submission to payment. 

VBMS was designed to provide a stable, scalable technology infrastructure and a business process that 

empowers Regional Offices to process even the most complex claims more efficiently. In developing VBMS, a 

large and complex system, VA decided to break the scope into pieces that were more easily managed 

individually allowing the agency to focus its attention on the specific outcome assigned to each of the contracted 

project. This allowed industry partners to bid on work with particular specialization and core competencies. 

Once the system projects were defined, the VA competitively awarded individual stand-alone contracts to eight 

different vendors to provide the various functionalities required for the system. The chart below shows the 

various projects and the functionality provided by each project. Other contracts were included for services and 

projects that did not provide direct user functionality, such as for architectural, security, documentation, 

program management, and deployment support services applicable to all projects. 

# Project Functionality Contractor 

1 Systems Engineering, Integration, 

& Test Support (SEITS) 

Provide systems engineering (SE), integration, and test 

support 

A 

2 Virtual Regional Office (VRO) 

Application Development 

Develop customer interface screens and claims 

processing management software application A 

3 Scanning Prototype Develop initial document scanning capability B 

4 Scanning System Development Develop high-volume scanning capability C 

5 Correspondence System Develop application for communicating (via messages) a 

claim’s status at various stages D 

6 Rating Board Automation (RBA) 

Modernization 

Develop software application for assessing ratings to be 

applied to disability claims E 

7 VBMS Phase 2 (P2) Development Provide P2 development engineering services A 

8 VBMS Phase 3 (P3) Development Provide P3 development engineering services C 

This approach requires an IPT in which all the members understand the overall investment strategy and how 

each of the modular acquisitions fit into that strategy. It also may be more complicated to administer this 

number of acquisitions for one investment, but it provides opportunities for the agency in terms of quality, cost, 

schedule and other factors that may be equally important. 

 13 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

4. Performance-based Work Statements 

An agency faced with a complex system development effort will typically find that it initially can describe 

only the high level goals and desired outcomes of the overall investment and requires the near 

immediate expertise of a contractor to help the agency in gaining a better understanding of the types of 

solutions that can best address its challenges. To support modular software development, for example, 

an agency may need contractor support to build prototypes, analyze feedback from customer focus 

groups, and develop system documentation. An agency can improve its ability to acquire the best 

support and smartest solutions by using a performance-based statement of work, also known as a 

performance work statement (PWS), that describes desired mission-related outcomes,20 rather than 

how the work is to be performed. Further, by tying payment to the contractor’s successful achievement 

of measurable performance standards, it incentivizes the contractor to be efficient and effective. 

The PWS used to support award of the underlying contract and initial project can be refined to reflect 

advances in thinking by program and IT personnel that is gained from customer feedback on early 

development work and analyses from the contractor. If an IDIQ contract or BPA is used, the PWS for the 

individual order would be finalized just before the requirement was issued to the vendor community, 

allowing maximum refinement. This approach allows the Government customer to identify course 

corrections in a more timely manner and obtain software that meets the customer’s requirements in a 

shorter timeframe. 

If modular development is being used to replace a legacy system, a PWS may be especially helpful to 

support a project under the investment for acquiring services associated with development of the base 

system, or initial capability. However, a PWS may be less suitable for a follow-on project on the same 

investment if end users wish to be more prescriptive in their depiction of work. Based on experience, 

for example, end users may be able to describe the desired design for canned reports and ad-hoc 

reports, which would be activities or releases under the reporting project. 

! number of agencies have successfully used PWS’s to support agile software development. The 

appendix includes a sample PWS. Figure 5 illustrates how one agency successfully used a PWS to support 

the agile development of a tool to monitor grantee performance. 

Figure 5: Using a Performance Work Statement to Support Modular Development 

The Department of Agriculture (USDA) created a tool to assist the agency with monitoring grantee performance 

in the Women, Infants and Children (WIC) program. USDA took advantage of agile development techniques and 

modular contracting to support the rapid development and delivery of this software. These techniques were 

facilitated through a PWS. 

Instead of laying out a detailed prescription of technical requirements, the agency: 

 Identified the goals and the desired outcomes of the development effort; 

 Outlined the expected performance standards; 

 Requested a certain number of requirements sessions and focus group sessions with the customer; 

 Received system documentation as deliverables for fixed price payments; and 

 Requested five “build iterations” of software development. 

20 FY 2013 Exhibit 300 A-B Guidance, page 5 

 14 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

The agency used focus group sessions to develop the broad scope of the program. Requirements gathering 

sessions allowed the agency to learn from end users and map out use cases. The agency used quality assurance 

sessions for final development based on customer feedback. Customers provided feedback through the 

development of software iterations, functional “builds” of the software. 

Based on these cycles of information gathering and feedback from end-users, the contractor developed the 

details that comprise the finished product and allowed the agency to avoid some of the potential shortcomings 

of a traditional approach, which would have involved agency experts developing detailed requirements based 

on their program needs, without the benefit of a contractor’s technical expertise – a process that can lead to 

long delays and increased costs if the generated requirements are not technologically feasible. Instead, the two 

groups collaborated to ensure that program needs were met in the most technologically appropriate, costeffective manner. 

The agency successfully deployed a Management Evaluation Tool in the first year, which was expanded the 

subsequent year to meet requirements from the Summer Food Service Program and the Financial Management 

Review process. Each deployment was a successive project or increment to build momentum, and was deployed 

in 6 months or less. 

Irrespective of whether the agency is using a performance-based acquisition, agencies should consider 

whether the magnitude of changes to a work statement require them to reach out to the industry to 

have additional competition. Specifically, competition would be required if changes to the work 

statement were so substantial as to exceed what unsuccessful bidders to the initial solicitation could 

have anticipated. In this case, they may have submitted different technical and cost proposals to satisfy 

the requirement. Of course, competition would also be required if a change is outside the scope of the 

original contract. 

To ensure the contractor does not perform inherently governmental work, the agency should carefully 

delineate the roles and responsibilities of the contractor in the solicitation. It may identify the types of 

decisions expected to be made and ensure that Federal employees oversee and make final decisions 

regarding the disposition of the requirements. These actions will ensure the contractor’s work does not 

become so extensive or close to the final agency product as to effectively preempt the Government 

officials’ decision-making process, discretion, or authority. 

The contract administration team must also watch for “scope creep” where work is added to the 

contract that is not necessarily related to the program’s requirements. Such augmentation can lead to 

wasteful cost overruns and unnecessary delay in work schedule. 

The agency should also be mindful of potential organizational conflicts of interest (OCIs). If a vendor 

helps to develop or draft the specification for a future procurement (e.g., a software project developed 

as part of a larger enterprise-wide architectural effort), the agency must consider whether OCI rules 

prohibit that vendor from competing for that future procurement to ensure the contractor’s advice in 

shaping the requirements document remains impartial and does not provide an unfair competitive 

advantage during competition. 

Finally, service level agreements (SLAs) or other performance metrics should be used to spell out specific 

levels of service (e.g., minimum acceptable service level, target service level); performance standards 

applicable to each level of service; how service will be measured; the weight assigned to each measure; 

the frequency of measurement; and the office responsible for measurement. The sample in Figure 6 

illustrates how an SLA could be used to support testing and integration. 

 15 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

Figure 6: Sample Service Level Agreement 

Service Description: This SLA measures performance for integration and test timeliness, and the quality of 

commercial off-the-shelf (COTS) hardware and software. 

Performance Measure Description: Provision of test networks, platforms, software, databases, and simulation 

software with sufficient capacity to model the agency’s production and user workload. 

Timely completion of COTS hardware, software, and system integration testing. 

Timely completion of application release testing for normal and emergency releases. Test completion is either 

validating that the application meets test requirements or returning the application with an analysis of 

problems that prevent system acceptance. 

Who: Computer and Systems Management Organization Group 

Frequency: Monthly 

Where Measured: Agency Headquarters 

How Measured: Service Level reporting will be derived from the integration, test and acceptance activities; the 

approved change management request; Enterprise Test Center (ETC) logs; and summaries of the number of 

applications or systems received for testing, the number of applications or systems tested, the number 

accepted, and the number returned for rework. This will be reported on a monthly basis. A comparison of the 

integration, test and acceptance activities, the approved change management request and any resulting 

problem ticket will be used to identify a negative impact to the agency processing environment. Statistics for 

release tests will be provided in weekly status reports and in monthly Contract Data Requirements Lists (CDRLs). 

Performance Standard Applicable to Each Level of Service: Prime Hours 0700 to 1800 daily, Monday to Friday 

and 0800 to 1700 Saturday. 

Level of Service: Committed Level is Completion of 93% of regular application release testing within two weeks 

of submission and 93% of emergency release testing within 4 days of submission. 

Incentive/Disincentive: Incentive applies if 95% of regular system and application release testing is completed 

within two weeks of submission and release is successfully introduced in the production environment as 

measured by a Severity 1 or 2, and if 95% of system and emergency release testing is completed within 3 days 

of submission, or by the scheduled completion date, and the release is successfully introduced in the production 

environment as measured by a Severity 1 or 2. 

Disincentive applies if committed level is not met, or if any release that is approved by the Enterprise Test 

Center (ETC) causes a Severity 1 or 2 outage as a result of inadequate testing through the release process in the 

ETC. 

B. Payment Strategies 

Agencies should select a payment strategy that effectively incentivizes the contractor to provide the 

best value for a given project or activity. To do so, agencies must give careful consideration to the level 

of uncertainty regarding their requirements. The greater the certainty, the more likely an agency can 

successfully use a fixed-price arrangement where payment is tied to the delivery of a completed product 

or service. The greater the uncertainty, the more likely an agency may need to consider a costreimbursement or time-and-materials arrangement where payment is tied to costs incurred and more 

risk is assumed by the Government. As explained below, these different strategies may be combined in 

a “hybrid” contract that supports a particular project so that agencies have access to different payment 

strategies that match the level of uncertainty associated with different projects and activities. 

Whenever possible, agencies should employ strategies that encourage up front due diligence so that 

vendors can come up with lower risk solutions that can be met with fixed-price contracts at the earliest 

feasible point in the acquisition lifecycle, thereby limiting the need to resort to riskier contracting forms. 

 16 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

1. Fixed-price contracts and task orders 

In fixed-price contracts and task orders, price is negotiated before award and payment is tied to the 

delivery of a completed product or services. Fixed-price arrangements should be used for the acquisition 

of COTS and development services for software projects or increments where the Government knows 

the specific functional characteristics that will satisfy its objectives. In these situations, fixed-price 

contracts provide the greatest incentive for the contractor to control costs and perform effectively. 

2. Cost-reimbursement contracts 

Cost-reimbursement contracts are appropriate when uncertainty in the requirement and the risk of 

failure cannot be managed by the contractor within economically reasonable bounds. This uncertainty 

may be due to lack of knowledge regarding the effort needed to meet a defined requirement, including 

the Government’s and industry’s lack of cost experience in performing the work. Alternatively, the 

uncertainty may be due more fundamentally to a lack of knowledge about what is possible and practical, 

as is often the case with research or leading-edge innovation. 

In recognition of the risk associated with paying an agency for its best efforts rather than delivery of a 

completed product or service, the FAR now requires, if a cost-reimbursement contract is used, that 

documentation in the acquisition plan or contract file explain why the particular contract type was 

selected; how the Government will manage and mitigate risk; and how the Government will minimize 

the use of other than firm-fixed-price contracts on future acquisitions for the same requirement and 

transition to firm-fixed-price contracts to the maximum extent practicable. The rule also requires 

approval of the acquisition plan (e.g., where one is required) for other than firm-fixed-price contracts at 

least one level above the contracting officer and designation of a properly trained contracting officer’s 

representative prior to award of the contract or order.21 

3. Time-and-materials and labor-hour contracts 

Time-and-materials (T&M) and labor-hour (LH) contracts may help agencies accomplish tasks for a 

reasonable cost where the needed amount of labor effort cannot be specified in advance, such as when 

an IT office must diagnose the cause of a system failure or an agency is reacting to an emergency. Before 

an agency uses a T&M or LH contract, or places a T&M or LH order (e.g., including under GS!’s Federal 

Supply Schedules), it must make a determination that it is not possible at the time of placing the 

contract or order to accurately estimate the extent or duration of the work to anticipate costs with any 

reasonable degree of certainty and no other authorized contract type is suitable.22 Because a T&M or LH 

contract provides no positive profit incentive to the contractor for cost control or labor efficiency, 

appropriate Government surveillance of contractor performance is required to give reasonable 

assurance that efficient methods and effective cost controls are being used. 

Over time, experience should generally enable the agency to address these uncertainties, making it 

possible to convert to a fixed-price contract that creates a better incentive to provide the desired 

products or services within time and on budget 

4. Incentive contracts 

21 See FAR Case 2008-030, available at http://www.gpo.gov/fdsys/pkg/FR-2012-03-02/html/2012-4481.htm 22 FAR 8.404(h)(3) (for acquisitions under the Federal Supply Schedules), 12.207(b)(1) (for acquisitions of commercial items), and 16.601(d) (for 

non-commercial item acquisitions). 

 17 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

Consistent with the December 2007 Memorandum concerning the Appropriate Use of Incentive 

Contracts,23 agencies have the authority to use different types of incentives (e.g., both cost and noncost) in conjunction with fixed-price and cost-type contracts to motivate greater cost control and better 

performance. There are three main types of fees: (1) incentive fees; (2) award fees; and (3) fixed fees. 

An agency might use an objective incentive fee when cost and performance targets can be 

predetermined and a formula can be used to adjust the negotiated fee based on variations relative to 

objective targets. If it is neither feasible nor effective to devise predetermined objective incentives for 

cost, technical, performance, or schedule, an agency might consider an award fee or a fixed fee. In an 

award fee contract, the amount of fee earned is commensurate with the contractor’s overall cost, 

schedule, and technical performance, as measured against contract requirements in accordance with 

the criteria stated in an award-fee plan (e.g., fee goes down proportionate to delay of code delivery). 

Agencies must take appropriate cautions to ensure that no fee is paid if overall performance is below 

the satisfactory level and that contractors are not given a second chance to earn fees in a subsequent 

performance period that was not earned initially (a practice known as “roll over”). Fixed fees are 

negotiated at the inception of the contract, do not vary with actual costs, and leave most of the risk with 

the Government. 

5. Hybrid contracts 

An agency undertaking a large-scale IT project should be able to reduce inefficiency and waste by using a 

“hybrid” contract that allows the agency to achieve a better match between the requirement and how 

the work is priced. Work for which there is a basis for firm pricing can be awarded for a firm-fixed price 

while requirements for which there remains considerable uncertainty can be acquired on a cost, T&M or 

LH basis. IDIQ contracts can be structured as hybrid contracts to allow the agency to choose between a 

fixed-price, cost-reimbursement, T&M or LH basis for the payment of different increments or activities 

within increments. As illustrated in Table 5, an acquisition office could use a hybrid contracting model to 

include contract line items with different pricing strategies so that an agency could, for example, buy 

studies of early design on a cost or T&M or LH basis, later design and initial development using a costplus incentive fee arrangement, and initial and full scale production for a firm-fixed price. 

Table 5: Example of the Type of Pricing Flexibility a Hybrid Contract Might Authorize 

Contract Line Item Number (CLIN) Pricing Strategies 

System Design Cost-plus-fixed fee (CPFF), Cost-plus-award fee (CPAF), 

T&M, or LH 

System Requirements Analysis CPFF or CPAF 

Software Coding Fixed-price or Cost Plus Incentive Fee (CPIF) 

Software Testing Fixed-price or CPIF 

In the case of the hypothetical example in which the agency is replacing a legacy system discussed in the 

section above, base functionality, migration of legacy data, and systems interface activities might be 

paid for on a T&M, LH, CPFF, or CPAF basis, whereas the development of canned and ad hoc reports 

might be paid for using a fixed-price arrangement. 

23 Appropriate Use of Incentive Contracts, December 4, 2007: 

http://www.whitehouse.gov/sites/default/files/omb/assets/omb/procurement/memo/incentive_contracts_120407.pdf 

 18 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

A hybrid contract may require additional monitoring to ensure payment is made in accordance with 

agreed-upon terms (e.g., overruns created by performance inefficiencies on work awarded for a firmfixed price must not be charged to a cost-reimbursement line item). 

C. Use of Competition 

Available contracting tools offer a number of ways to take advantage of marketplace competition. 

1. Multiple award contracts 

As explained above, multiple award contracts allow agencies to conduct streamlined mini-competitions 

between contract holders who must be given a “fair opportunity to be considered” for each order. 

Multiple award contracts may be structured to support awards under the same umbrella contract for 

different projects and/or activities. For example, one competition could be conducted for design, 

training, and testing while another is conducted for development. Making awards to different vendors 

may introduce some creative tension within the project and eliminate the possibility that any vendor 

would have a continuing monopoly with any application or system. Similarly, competitions for different 

types of projects or activities may emphasize different values. For example, quality may be identified as 

the most important factor in a competition for architectural design, while price might be identified as 

being of equal or greater value for independent verification and validation services. 

In a multiple award IDIQ the “contracting officer may exercise broad discretion in developing appropriate 

order placement procedures/ Contracting officers may use streamlined procedures, including oral 

presentations. If the order does not exceed the simplified acquisition threshold, the contracting officer 

need not contact each of the multiple awardees under the contract before selecting an order awardee if 

the contracting officer has information available to ensure that each awardee is provided a fair 

opportunity to be considered for each order.͟24 

Contracting officers should consider including on-ramp and off-ramps in their contracts to ensure 

adequate competition for requirements, increase available alternatives, and encourage the best price 

proposals. On-ramps would allow the Government to have an open season to attract new contractors 

and capabilities to the contract. Off-ramps would allow the Government to remove contractors that 

have not been successful in securing work or performing at a satisfactory level. 

2. Single award contracts 

While competition saves money for the taxpayer and improves contractor performance, ongoing 

competitions can create burden for an agency and can also serve as a disincentive for a contractor to 

invest seriously in a project for the long-haul. There are a number of situations where a single award 

“soup to nuts” IDIQ contract (or single award BP!) will be preferred to a multiple award approach, such 

as where the expected cost of administration of multiple contracts outweighs the expected benefits of 

making multiple awards, the projected orders are so integrally related that only a single contractor can 

reasonably perform the work, or, based on the contracting officer’s knowledge of the market, more 

favorable terms and conditions, including pricing, will be provided if a single award is made.25 Where a 

single award task order contract is established, the project can still be sub-divided into sub-projects. By 

24 FAR 16.505(b)(ii).) 25 FAR 16.505(c)(1)(ii)(B).) 

 19 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

issuing an order for each sub-project, the contractor can be held to meeting minimum performance 

standards before being allowed to move forward to the next sub-project. 

Pursuant to law and regulation, a single award IDIQ contract cannot have a ceiling that exceeds $103 

million (including all options) unless the head of the agency determines in writing that: (i) the task or 

delivery orders expected under the contract are so integrally related that only a single source can 

reasonably perform the work; (ii) the contract provides only for fixed-price task or delivery orders for 

products for which unit prices are established in the contract for the specific tasks to be performed; (iii) 

only one source is qualified and capable of performing the work at a reasonable price to the 

Government; or (iv) it is necessary, in the public interest, to award the contract to a single source due to 

exceptional circumstances.26 

D. Provisions and Clauses 

When awarding a modular contract, agencies should include provisions in their solicitations and clauses 

in their contracts that reinforce modular principles, such as a requirement to provide specific 

functionality that delivers value to the customer within a specified period of time after a work order is 

issued, and a requirement that ties subsequent work to the acceptable delivery of prior releases. The 

Appendix includes sample language that might be included in a statement of work addressing a variety 

of issues associated with either developing the current requirement (e.g., focus groups) or ensuring that 

the current requirement will work with future requirements (e.g., scalability, interfacing). In addition, 

the FAR provides guidance for when and how to use provisions and clauses to address a number of 

issues regarding the resulting business relationship (e.g., use of incentive or award fees to motivate 

greater cost control and better performance). 

Figure 7 provides a sample checklist of issues for agencies to consider as they develop terms and 

conditions for their solicitations and contracts. If modular contracting or streamlined development 

methodologies are new to the agency or the requiring office, early vendor engagement is strongly 

encouraged. 

Figure 7: Terms and Conditions - Sample Checklist 

Issue Language and/or Guidance Source 

 Focus groups See Appendix 

 Requirements gathering sessions See Appendix 

 Quality assurance sessions See Appendix 

 Build projects See Appendix 

 User acceptance testing See Appendix 

 Data portability See Appendix 

 Modular interface capability (e.g., 

application protocol interfaces, etc.) 

See Appendix 

 Content segregation See Appendix 

 Scalability See Appendix 

26 FAR 16.505(c)(1)(ii)(D). 

 20 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

 Incentive and fee arrangements See FAR 16.204 – Fixed-price Incentive Contracts 

See FAR 16.304 – Cost-plus-incentive-fee Contracts 

See FAR 16.4 – Incentive Contracts 

 Conflicts of interest See FAR 3.11 – Preventing Personal Conflicts of 

Interest for Contractor Employees Performing 

Acquisition Functions 

See FAR 9.5 – Organizational and Consultant 

Conflicts of Interest 

 Ownership of software developed 

under contract 

See FAR 27 – Patents, Data, and Copyrights 

 Ownership of data developed or 

derived from the effort of the 

contractor 

See FAR 27.4 – Rights in Data and Copyrights 

Contract clauses are only effective if used in conjunction with a sound contract management approach. 

Contracts for modular development require the Contracting Officer, Contract Specialists, and 

Contracting Officer Representatives to ensure that contractors perform to established cost, schedule, 

and performance goals for each project. When a contractor misses deliverables – or performs well – the 

contractor’s performance must be documented in the Contract Performance Assessment Reporting 

System (CPARS) for storage in the Past Performance Information Retrieval System (PPIRS) where 

contracting officers may access and consider it in future contract award decisions. In the case of multiple 

award contracts, contractor performance may be considered in determining award of subsequent 

orders under the contract. 

E. Additional Acquisition Considerations 

1. Using established intra-agency or interagency contract vehicles 

A number of agencies manage large interagency contracts for IT products and services that are available 

for use by other agencies. By considering the suitability of existing intra-agency and interagency vehicles 

before creating new ones, an agency can avoid the unnecessary expense of redundant planning and 

administration of separate stand-alone contracts, and also reap the benefits of the Government’s buying 

leverage, especially for commodities. 

Interagency vehicles that should be considered before awarding a new contract include the following: 

 General Services Administration (GSA) Federal Supply Schedules; 

 Government-wide Acquisition Contracts (GWACs); 

 Multi-Agency Contracts. 

In terms of GWACs, the GSA, National Aeronautics and Space Administration (NASA) and National 

Institute of Health (NIH) each have awarded GWACs that may be able to support modular development 

of agency requirements. 

 21 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

2. Taking full advantage of small businesses 

Because the key to modular development is in scoping the projects into smaller, self-contained pieces, 

the opportunity to award that work to one or more small businesses increases. Modular development 

and acquisition approaches can help agencies meet small business contracting goals by identifying 

opportunities for small businesses in the Federal marketplace. Many small businesses in this field have 

the expertise and capacity to perform individual projects, either as a prime contractor or as a 

subcontractor. For example, small businesses may be well suited to provide services for independent 

verification and validation of work performed under projects, security configuration, database tuning, 

and training, among other things. Contracting officers, small business technical advisors, and the Small 

Business !dministration’s Procurement Center Representatives can assist in maximizing the use of small 

business concerns through full and open competition, set-asides (e.g., where there is a reasonable 

expectation of obtaining offers from two or more responsible small business concerns that are 

competitive in terms of market prices, quality, and delivery) and under subcontracting plans submitted 

by a large business prime contractor. 

A number of GWACs have been set-aside for small businesses, including one for small disadvantaged 

businesses participating in SB!’s section 8(a) business development program, and one for servicedisabled veteran-owned small businesses. IPTs should consider them when developing the acquisition 

strategy. 

In the fall of 2011, OMB directed agencies to begin accelerating payments to small business 

contractors.27 Specifically, agencies were instructed to make their payments to small business 

contractors as soon as practicable, with the goal of making payments within 15 days of such receipt. 

This policy is reducing the time in which agencies pay small businesses – by up to half in many cases. 

This is getting money back in the hands of small businesses faster, improving their cash flow and 

allowing then to reinvest funds in their business. 

27 OMB Memorandum M-11-32, Accelerating Payments to Small Businesses for Goods and Services, (September 15, 2011): 

http://www.whitehouse.gov/sites/default/files/omb/memoranda/2011/m11-32.pdf 

 22 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

VI. Appendix: Sample Performance Work Statement 

Focus Groups 

The focus group will consist of [Relevant Stakeholders]. The group will concentrate on capturing the 

business needs for the [Project Name]. [Number] focus group sessions will be conducted to obtain the 

inputs for determining the scope of the project. 

Each meeting will include an Agenda as well as a Read-Ahead Package (RAP) to ensure efficient progress. 

Each meeting will finish with the delivery of meeting notes identifying discussions that transpired during 

the meeting and assigning any action items to people. There will also be a focus group survey and focus 

group summary report to be completed for each focus group session. The contractor is required to 

provide administrative meeting support during the sessions including facilitating the meetings. 

Requirements Gathering Sessions 

Requirements Gathering Sessions (RGS) are the building blocks for success in this type of project. It is 

vital that the right stakeholders participate in the RGS and it is equally important that momentum is 

sustained throughout the overall process. Each [Stakeholder Category] will be able to participate in at 

least [Number] RGS. 

The objective of the RGSs is to obtain inputs from stakeholders pertaining to the determination and 

construction of [Project Features]. It is imperative that the RGS achieve consensus in the [Essential 

Project Features]. To achieve this, the contractor should focus on using activity diagrams, use case 

models and use case narratives to identify the normal flow and as many as is reasonable alternate flows. 

The contractor shall update and revise the [Project Status Document] to reflect the changing state of 

the application and the business needs. 

Quality Assurance Sessions 

Quality assurance (QA) sessions are where requirements turn into detailed design. It is in this phase 

that the pro-forma workflows will be identified and reviewed. Essentially all information that is 

necessary to build the product is captured in this phase and it is reflected to the stakeholder team for 

verification. As part of these QA sessions, each [Stakeholder] will be required to verify and sign-off on 

the [Project Features] determined in the previous RGSs. The requirements documents will also be 

verified as part of these sessions. 

It is important that the contractor use the information gathered from these sessions to identify the 

[Important Project Element]. It is also important that the workflow for standard correspondence is 

documented in Microsoft Visio or another standard modeling tool. Finally the [Contract Deliverable] 

shall be delivered and marked as final. 

Various test plans suitable to test the application functionality (e.g. for unit test, detailed application 

test and user acceptance tests) shall also be developed and delivered by the contractor and approved by 

[Agency] prior to the next phase. The test plans shall clearly indicate the timeline and responsibility for 

various test phases. 

 23 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

Build Projects 

Projects are fully functional iterations of an application that allow the contractor and the Government to 

refine their functions as they perform it and grow more efficient at it. There will be [Number] project(s) 

in which it would have full capability for 25 percent of the [Customer Population] in each project. The 

first project release will need additional time, but subsequent release should be at 35-40 day turnover. 

For each release, the contractor shall facilitate a walkthrough meeting in which the functionality that 

has been delivered is demonstrated to the user community. All [Stakeholder Group] are invited to the 

walkthrough meeting. For each release, the contractor shall invite [Relevant Customer Population] to 

test the application. Customer testing will require a minimum response threshold of [Percentage] of the 

invited population. The contractor will also deliver the release test plan which is a step by step 

walkthrough of the functionality in the release and allows the user community to make notes and 

comments regarding how that functionality can be improved and made more useable or error-free. The 

contractor shall work to correct all errors and increase usability. Comments that are delivered within 5 

business days of the release walkthrough shall be included in the subsequent release or the product 

delivered for [Agency] in the event it is the final release. 

Each meeting will include an agenda as well as a read-ahead package (RAP) to ensure efficient progress. 

Each meeting will finish with the delivery of meeting notes identifying discussions that transpired during 

the meeting and assigning any action items to people. The contractor will facilitate these meetings. 

User Acceptance Testing 

User Acceptance Testing (UAT) is the final point in which the Government makes the decision regarding 

whether the functionality that has been delivered is able to be placed in the production environment. All 

outstanding comments to Iterations shall be addressed in the functionality delivered for UAT. The 

criteria for making this decision with respect to the binary decision about passing UAT will be the 

agreement that the [Requirement Standard] for each requirement in the [Requirements Document] 

has been satisfied, the functionality is consistent with the templates and workflows documented in the 

QA Sessions and the application has no significant vulnerabilities as identified by the Information 

Security Office. 

A walkthrough, facilitated by the contractor, for the entire user base shall be required. The testing 

period will commence with no less than [Timeframe] for functional testing by the user community. 

Following the successful completion of functional testing the application will undergo full penetration 

testing. Provided that has been successfully completed the contractor shall deliver an Installation and 

Configuration Guide that shall be a very detailed document including screen shots of each step in the 

process to build and configure the application in the [Agency] production environment. 

Data Portability 

The data must be portable to other systems to facilitate future systems upgrades and changes. 

Portability does not include alternative operating system platforms. While these changes are not known 

at this time, the developer is expected to keep data in a format that may be accessed by known 

components today for export/import into future systems. 

Project Interface Capability 

The application shall provide notifications of [User Activity] to affected users using standard email 

delivery. Additionally, the application shall send [Software Prompt] to reviewers using an Application 

 24 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

CONTRACTING GUIDANCE TO SUPPORT MODULAR DEVELOPMENT 

Programming Interface (API) set compatible with [Existing Software Package] so [User Activities] can be 

automatically recorded in existing configurations. 

The application shall interface with existing [Access Management System] resources for the purpose of 

user validation and role identification. The application shall access this resource as a read-only entity. 

The application will have access to database resources as needed. The application may use the database 

for data storage and retrieval and may add appropriate database related controls (e.g., triggers, jobs and 

stored procedures). 

Content Segregation 

The [Agency] may deploy record management systems around this application in the future. The 

application is a process management system that maintains status information and work product to 

support the production of [Application Output]. The resulting [Application Output] (as well as the 

incoming [Application Input]) may need to be drawn from and saved to a third party record 

management system. To facilitate this, the system shall be capable of supporting an API set for data 

inputs ([Specific Examples]) and outputs ([Specific Examples]). These will not be a part of the initial 

deployment. The developer shall document these APIs for the [Agency]. 

Scalability 

It is expected that the initial application will be deployed to the current staff for an undetermined trial 

period. Based on the success of the trial period, the application may be deployed for a larger user base. 

This level of expansion will require the application to be scalable beyond a single [Branch] organizational 

structure. The software and final detailed design will need to detail and provide for this potential 

expansion. 

 25 