FOREWORD

The General Services Administration (GSA) is issuing this *Guide for
Modular Contracting* to assist federal agencies in employing modular
contracting techniques for their major information technology
development efforts. It provides useful information on the application
of modular contracting techniques, and it should be used in conjunction
with Federal and agency regulations and directives.

This guide is one in a series to be issued by GSA that will focus on key
issues and important topics in the acquisition and management of
information technology (IT) resources. We welcome your comments
regarding this guide and the acquisition guide series. Comments and/or
suggestions for improving future versions of the guides should be sent
to:

> U.S. General Services Administration
>
> Emerging IT Policies Division
>
> Attn: Richard N. Kellett, or David Middledorf
>
> Room 2218, 1800 F Street, N.W.
>
> Washington, DC 20405

We also welcome suggestions for topics to be covered in future guides.
Please contact the Emerging IT Policies Division at (202) 501-1551.

Acquisition guides and white papers published to date, as well as
additional information about federal IT acquisition, are available on
the IT Policy OnRamp:
[http://www.itpolicy.gsa.gov](http://www.itpolicy.gsa.gov/).

> Dr. Joan Steyaert
>
> Deputy Associate Administrator for Information Technology
>
> Office of Governmentwide Policy
>
> U.S. General Services Administration

> INTENTIONALLY LEFT BLANK

ACKNOWLEDGEMENTS

GSA's Office of Information Technology, wishes to acknowledge the
efforts of GSA's Emerging IT Policies Division, Acquisition Solutions,
Inc., and SIGNAL Corporation, who developed this Guide for Modular
Contracting. We believe it represents an important step in providing the
IT program manager helpful, "how to" information on implementing a
modular contracting approach.

GSA also gratefully acknowledges the following individuals who assisted
in the review of this guide: Ms. Diana Maykowskyj, Defense Logistics
Agency; Mr. Stan March, United States Social Security Administration;
Mr. Walter Cate, United States Department of State; and Mr. Carl
Peckinpaugh, Winston and Strawn law firm. GSA also thanks the Federal
Systems Integration and Management Center (FEDSIM), who provided program
management and contracting assistance in developing the series. It also
acknowledges the Modular Acquisition Work Group of the Government
Information Technology Services Board, whose *Modular Acquisition in
Support of "Access America": A Best Practices Guide* was used in the
development of this guide. Finally, GSA would like to thank the
Robbins-Gioia Inc., of Alexandria, Virginia for granting permission to
include its program management plan outline as an attachment to this
guide.

**GSA's Office of Emerging IT Policies** **(MKE)** identifies,
addresses, and develops emerging business, management, legal, and
technology issues. MKE disseminates timely and useful IT policies,
guidance (such as this Modular Contracting Guide), and best practices to
federal agencies. For more information about the Emerging IT Policies
Division, please contact Mr. Richard Kellett at (202) 501-1650, or by
e-mail at [richard.kellett@gsa.gov](../richard.kellett@gsa.gov), or
contact Mr. David Middledorf at (202) 501-1551, or by e-mail at
[dave.middledorf@gsa.gov](../dave.middledorf@gsa.gov).

**Federal Systems Integration and Management Center (FEDSIM)** is a part
of GSA's Federal Technology Service and provides information technology
client services on a fee-for-service basis. For more information on
FEDSIM's capabilities, please contact Ms. Martha Banks, Program Manager,
at (703) 756-4234, or by email at
[Martha.Banks@gsa.gov](../Martha.Banks@gsa.gov).

**SIGNAL Corporation** is a leading high-technology services company,
providing Information Technology, Engineering and Management, and
Multimedia Services in industry and government. For more information on
SIGNAL's capabilities, please contact Mr. Wayne Self, Vice President, at
(703) 205-2461, or by email at
[wayne_self@signalcorp.com](../wayne_self@signalcorp.com), or view
SIGNAL's web site at [www.signalcorp.com](../www.signalcorp.com).

**Acquisition Solutions, Inc (ASI)** is a small business dedicated to
helping government agencies understand and implement acquisition reform
and best practices. For information on this guide, or on ASI corporate
capabilities, contact Mr. Chip Mather, Senior Vice President, at (703)
378-3226, or by email atchip.mather@acqsolinc.com .

> INTENTIONALLY LEFT BLANK

EXECUTIVE SUMMARY

Modular contracting is an acquisition strategy that breaks a large
"grand design" program into discrete components that are easier to
manage. To increase the application of modular contracting techniques in
the acquisition of major information technology (IT) systems, Congress
passed, and the President signed, the Information Technology Management
Reform Act (ITMRA, P.L. 104-106, also known as the Clinger-Cohen Act).
Section 5202 of this law directs federal agencies to use modular
contracting "to the maximum extent practical" in the acquisition of
major IT systems. Following Clinger-Cohen, the President issued
Executive Order No. 13011, which instructs agencies to apply modular
contracting "where appropriate" and "to the maximum extent practicable."

As defined in the Clinger-Cohen legislation and Executive Order, modular
contracting provides for the delivery, implementation, and testing of a
workable system or solution in discrete increments or modules. In its
simplest terms, modular contracting is the acquisition of a major IT
system in successive increments of interoperable modules that:

-   Are easier to manage individually than they would be in one
    comprehensive acquisition.

-   Address complex IT objectives incrementally to enhance the
    likelihood of achieving workable solutions to attain those
    objectives.

-   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.

-   Provide an opportunity for subsequent increments of the acquisition
    to take full advantage of any evolution in technology or needs that
    occur during implementation of the earlier increments.

Analysis of relevant laws, regulations and studies, etc., indicates that
modular contracting can provide a significant opportunity to address and
overcome problems endemic to major systems development efforts. Through
the appropriate application of an incremental strategy, agencies can
decrease overall program risk, obtain quicker results, realize a more
rapid return on investment, and incorporate rapidly evolving
technologies into subsequent modules and increments. Practical
application of modular contracting techniques has the potential to
greatly improve the chances of success in large federal information
technology development programs.

The Guide for Modular Contracting provides government program,
technical, and contracting officials with an introduction to modular
contracting. It provides valuable background and "how to" information on
the application and use of modular contracting techniques. This guide is
intended to greatly assist an agency in successfully planning and
conducting a modular development effort. However, despite the
comprehensive scope of this guide, the application of modular
contracting techniques to major systems development efforts requires
significant judgment and experience.

While reducing some risk associated with system development, application
of modular strategies introduces a number of additional management and
cultural changes. Modular contracting techniques require increased
attention to areas such as agency IT architecture, interoperability
standards, systems integration, program management, and configuration
control.

Modular contracting is one strategy that can be used by federal agencies
to acquire major IT systems. However, no matter what the acquisition
strategy, people continue to be the deciding factor for success. The
knowledge, skills, talent, and experience of both the project team and
contractor personnel remain the key determinant of a successful
development program. Agencies are encouraged to ensure that a highly
skilled and knowledgeable team of acquisition professionals is available
to be dedicated to a program before pursuing any major development
effort.

GUIDE FOR Modular Contracting

TABLE OF CONTENTS

Page

CHAPTER 1 INTRODUCTION [1-1](#introduction)

1.1 Background [1-1](#background)

1.2 Audience [1-2](#audience)

1.3 Objective [1-2](#objective)

Chapter 2. LEGISLATIVE AND POLICY GUIDANCE
[2-1](#legislative-and-policy-guidance)

2.1 Federal Legislative Policy and Guidance
[2-1](#federal-legislative-policy-and-guidance)

2.1.1 Legislative [2-1](#legislative)

2.1.2 Policy [2-2](#policy)

2.1.3 Regulatory [2-2](#regulatory)

2.1.4 Budgetary [2-3](#budgetary)

Chapter 3. MODULAR CONTRACTING CONCEPTS AND ACQUISITION STRATEGIES
[3-1](#modular-contracting-concepts-and-acquisition-strategies)

3.1 Traditional Systems Development Approach
[3-1](#traditional-systems-development-approach)

3.2 Modular Contracting Approach [3-1](#modular-contracting-approach)

3.2.1 Characteristics of Modular Contracting
[3-2](#characteristics-of-modular-contracting)

3.3 Modular Contracting Preference and\
Application [3-2](#modular-contracting-preference-and-application)

3.4 Contracting Strategies and Techniques for\
Modular Contracting
[3-3](#contracting-strategies-and-techniques-for-modular-contracting)

3.5 System Design and Modular Identification
[3-3](#system-design-and-modular-identification)

3.6 Contract Strategy [3-4](#contract-strategy)

3.6.1 Serial Versus Parallel Development
[3-4](#serial-versus-parallel-development)

3.6.2 Contract Type [3-5](#contract-type)

3.6.3 Single Versus Multiple Contracts
[3-6](#single-versus-multiple-contracts)

3.6.3.1 Single Contracts [3-6](#single-contracts)

3.6.3.2 Successive Competitions [3-7](#successive-competitions)

3.6.3.3 Task Order Contracts [3-7](#task-order-contracts)

3.7 Rights in Technical Data and Computer Software
[3-8](#rights-in-technical-data-and-computer-software)

3.8 Source Selection Considerations
[3-8](#source-selection-considerations)

3.8.1 Past Performance Evaluation Criteria
[3-8](#past-performance-evaluation-criteria)

3.8.2 Software Capability Maturity Model (CMM)
[3-9](#software-capability-maturity-model-cmm)

Chapter 4. MANAGING THE PROGRAM [4-1](#managing-the-program)

4.1 Program Management Overview [4-1](#program-management-overview)

4.2 Systems Acquisition Process [4-1](#systems-acquisition-process)

4.3 Program Management [4-1](#program-management)

4.3.1 Program Management Office [4-2](#program-management-office)

4.3.2 Integrated Product Team [4-3](#integrated-product-team)

4.3.3 Interface Control Working Group
[4-3](#interface-control-working-group)

4.4 Risk Management and Control [4-3](#risk-management-and-control)

4.4.1 Configuration Management [4-3](#configuration-management)

4.4.2 Change Management [4-4](#change-management)

4.4.3 Integration Risk [4-4](#integration-risk)

4.4.3.1 Integration Testing [4-5](#integration-testing)

4.5 Cost and Schedule Performance Tracking
[4-5](#cost-and-schedule-performance-tracking)

4.5.1 Earned Value Measurement [4-6](#earned-value-measurement)

4.5.2 Work Breakdown Structure [4-6](#work-breakdown-structure)

4.5.3 Organization Breakdown Structure (OBS)
[4-7](#organization-breakdown-structure-obs)

4.5.4 Cost Accounts [4-8](#cost-accounts)

4.5.5 Precedence (Critical Path) Schedule
[4-8](#precedence-critical-path-schedule)

4.5.6 Software Measures and Metrics
[4-9](#software-measures-and-metrics)

4.6 Agency Information Technology Architecture
[4-10](#agency-information-technology-architecture)

4.6.1 Standards-Based Environment [4-11](#standards-based-environment)

Chapter 5. CONCLUSION [5-1](#conclusion)

APPENDIX 1 ITMRA SECTION 5202 (Division E of the Clinger-Cohen Act)
A.1-1

APPENDIX 2 EXECUTIVE ORDER 13011 A.2-1

APPENDIX 3 FAR 39.002, 39.103 MODULAR CONTRACTING A.3-1

APPENDIX 4 GLOSSARY A.4-1

APPENDIX 5 THE PROJECT MANAGEMENT PLAN A.5-1

APPENDIX 6 CONTACTS FOR MORE INFORMATION A.6-1

list of EXHIBITS

Exhibit Page

3-1 System Design Relationships [3-5](#__RefHeading___Toc438005730)

3-2 Five Levels of the Software Capability Maturity Model
[3-9](#__RefHeading___Toc438005732)

4-1 Work Breakdown Structure [4-7](#__RefHeading___Toc438005734)

4-2 Organization Breakdown Structure [4-8](#__RefHeading___Toc438005736)

4-3 Cost Account Derivation---Responsibility Matrix
[4-9](#__RefHeading___Toc438005738)

4-4 Precedence (Critical Path) Schedule
[4-9](#__RefHeading___Toc438005740)

4-5 Software Process and Product Quality Factors
[4-10](#__RefHeading___Toc438005742)

> INTENTIONALLY LEFT BLANK

list of ACRONYMS

AFCEA Armed Forces Communications and Electronics Association

CCB Configuration Control Board

CIO Chief InformationOfficer

CLIN Contract Line Item Number

CM Configuration Management

CMM Capability Maturity Model

COTS Commercial Off-the-Shelf

CPFF Cost Plus Fixed Fee

EO Executive Order

FAR Federal Acquisition Regulation

FASA Federal Acquisition Streamlining Act (P.L. 103-355)

FFP Firm Fixed Price

FSS Federal Supply Schedule

FY Fiscal Year

GPRA Government Performance and Results Act (P.L. 103-62)

GSA General Services Administration

GWAC Governmentwide Acquisition Contract

ICD Interface Control Document

ICWG Interface Control Working Group

ID/IQ Indefinite Delivery/Indefinite Quantity

IPT Integrated Product Team

IT Information Technology

ITMRA Information Technology Management Reform Act (P.L. 104-106); also
known as the Clinger-Cohen Act

ITOIWG Information Technology Oversight Improvement Working Group

OBS Organization Breakdown Structure

OMB Office of Management and Budget

PL Public Law

PM Program Manager

PMP Program Management Plan

RFP Request for Proposal

ROI Return on Investment

WBS Work Breakdown Structure

#  INTRODUCTION

## Background

The current statutory preference for modular contracting is the result
of a considerable history of high-profile, multi-billion dollar failures
of "grand design" information technology (IT) development efforts. The
"grand design" approach to IT development often resulted in systems that
were extremely expensive, fielded years behind schedule (if at all),
provided less than the desired capabilities, and were most often
technologically outdated by the time they were implemented.

While the failure of megasystem grand design development efforts was
well known, former Senator Cohen captured the scope of the problem in
his seminal October 1994 report [Computer Chaos, Billions Wasted Buying
Federal Computer Systems]{.underline}[^1]. One of the major findings of
the report was that "the Government should address automation in
manageable segments that are compatible with other systems and easily
canceled if they run into any cost and schedule difficulties."

Partially as a result of the findings in the [Computer
Chaos]{.underline} report, in May of 1995, the Information Technology
Oversight Improvement Working Group (ITOIG) prepared a white paper
addressing areas for improvement in information technology[^2]. One of
the white paper's conclusions was that the government needed "to expand
agency efforts to use incremental and evolutionary approaches to major
systems development and acquisition." The ITOIG recommended that the
government adopt "an acquisition process that models industry best
practices," which would require agencies to "structure IT acquisitions
into relatively short-term modules that can be easily evaluated and will
allow projects to change direction." The ITOIG recognized that, while
much could be done to improve existing practices within the current
procurement statutes, statutory changes were required to promote modular
acquisition.

In addition to Congressional and industry recognition of the failure of
a grand design approach to major system development, the current focus
on modular-type approaches was also encouraged by the efforts of the
Canadian "Common Purpose Procurement Framework." The Canadian approach
encouraged an innovative teaming relationship between the government and
the contractor(s). It further embraced risk management and modular,
phased delivery as principal features of its approach to major system
design and development.

On June 20, 1995, Senator Cohen introduced the Information Technology
Management Reform Act (ITMRA) of 1995. Section 203 of that act
(Incremental Acquisition of Information Technology) required that "to
the maximum extent practicable, an executive agency's needs for
information technology should be satisfied in successive, incremental
acquisitions of interoperable systems," [^3] otherwise known as modular
contracting.

As a result of both statutory direction and the experiences of the
Canadian and industry approaches to systems development, modular
contracting is now the preferred method for acquiring major
developmental IT systems. It is most effectively applied when a
requirement can be satisfied in successive acquisitions of interoperable
increments. In its simplest terms, modular contracting is the
acquisition of a major IT system through smaller, successive increments
of interoperable modules.

While a statutory preference for modular contracting exists, even with
its potential benefits, it represents a significant challenge and a
major change from the traditional IT acquisition strategies. Although it
presents a beneficial alternative to the traditional development models,
modular contracting cannot be viewed as a "silver bullet" solution. As
discussed later in this guide, the careful application of modular
contracting techniques has considerable potential to solve some very
troubling acquisition issues while at the same time raising others.
These new challenges, however, do not negate the significant benefits
associated with a modular contracting approach.

The planning and management of any major IT development effort is a
complex and demanding task. Acquisition strategies must be carefully
crafted, balancing the risks presented by the facts and circumstances of
the particular requirement and environment. The knowledge, skills,
talent, and experience of the project team remain the key determinant of
a successful IT development program. Given the statutory preference, and
the opportunities and advantages offered by modular contracting,
agencies should seek ways to understand and incorporate this acquisition
innovation to the maximum extent practicable.

## Audience

This guide was developed for government program, technical, and
contracting officials involved in major IT development programs.

## Objective

The General Services Administration (GSA) published this guide to help
agencies understand and successfully plan and conduct modular IT
development efforts. Modular contracting represents a new approach to
acquiring major IT systems. As with any new process, it is important to
understand the underlying principles and concepts in order to apply them
successfully to each agency's unique requirements. Therefore, this guide
addresses the laws, regulations, directives, and policies issued to
implement modular contracting. It also provides guidance on modular
contracting and program management approaches and techniques.

#  LEGISLATIVE AND POLICY GUIDANCE

## Federal Legislative Policy and Guidance

During the past several years, Congress has passed numerous initiatives
intended to re-invent the way the federal government conducts its
business. These initiatives have streamlined the federal acquisition
processes and procedures, specifically bringing the acquisition of IT
more in line with the realities of the forces of the commercial market
place and the risks involved in acquiring information technology. As an
evolving public policy objective, guidance to date on modular
contracting has been limited. The government guidance that has been
issued falls into four general categories: legislative, policy,
regulatory, and budgetary.

### Legislative

The principal statutory direction making modular contracting the
preferred acquisition approach for agencies to use in acquiring major IT
developmental systems is found in Section 5202 of the Clinger-Cohen Act
of 1996, originally referred to as ITMRA[^4]. The statute requires that
the head of the agency should "to the maximum extent practicable, use
modular contracting for an acquisition of a major system of information
technology." The act describes modular contracting as follows:

Under modular contracting, an executive agency's need for a system is
satisfied in successive acquisition of interoperable increments. Each
increment complies with common or commercially accepted standards
applicable to information technology so that the increments are
compatible with other increments of information technology comprising
the system.

Further, the statute directed that the Federal Acquisition Regulation
(FAR) require that, under the modular contracting process, an
acquisition of a major IT system may be divided into several smaller
acquisition increments that:

-   Are easier to manage individually than would be one extensive
    acquisition.

-   Address complex information technology problems incrementally in
    order to enhance the likelihood of achieving workable solutions to
    these problems.

-   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 other increment in
    order to be workable for the purposes for which acquired.

-   Provide an opportunity for later increments of the acquisition to
    take advantage of any evolution in technology or needs that occurs
    during conduct of the earlier increments.[^5]

In addition, Section 5202 of Clinger-Cohen required that "an increment
of an information technology acquisition should to the maximum extent
practicable, be awarded within 180 days after the date on which the
solicitation is issued". If the contract for that increment cannot be
awarded within that time, the increment should be considered for
cancellation. Additionally, the delivery of the information technology
should occur within 18 months after the date the solicitation was
issued.

In February 1998, the requirements of the Act were incorporated into the
FAR. See Section 2.1.3.

### Policy

The principal policy direction for implementing modular contracting is
found in the July 16, 1996 Executive Order 13011, Federal Information
Technology (Appendix 2). Under the order, agencies are tasked to
significantly improve the management of their information systems,
including the acquisition of information technology. The order also
promotes the strategy of structuring information systems investments
"into manageable projects as narrow in scope and brief in duration as
practicable" (modular contracting).

### Regulatory

On February 23, 1998, Federal Acquisition Circular 97-04 added guidance
and direction on modular contracting requirements to FAR Part 39,
*Acquisition of Information Technology*. This change implemented the
statutory requirements of Clinger-Cohen Section 5202.

In drafting the FAR language, the FAR IT committee discussed the need to
include discretionary material and guidance on modular contracting. The
committee recognized that modular contracting is a complex subject, and
there has been little or no guidance on how to implement this new
approach to acquiring major IT systems. The committee concluded that it
would be more appropriate to issue such guidance as a separate document.
While FAR guidance does not contain detail on how to implement modular
contracting, it does provide some guidance beyond that contained in the
Clinger-Cohen statute. (See Appendix 3 for the full text of the FAR
language.)

FAR part 39.002 includes a definition for modular contracting: "'Modular
contracting,' as used in this part, means use of one or more contracts
to acquire information technology systems in successive, interoperable
increments."

FAR part 39.103 implemented Section 5202, Incremental Acquisition of
Information Technology, Clinger-Cohen Act of 1996 (P.L. 104-106). It
states in part that:

Modular contracting is intended to reduce program risk and to
incentivize contractor performance while meeting the government's need
for timely access to rapidly changing technology. Consistent with the
agency's information technology architecture, agencies should, to the
maximum extent practicable, use modular contracting to acquire major
systems.

FAR part 39.103 (b) also specifies that, when using modular contracting,
the IT system may be divided into several smaller acquisitions that:

-   Are easier to manage individually than would be possible in one
    comprehensive acquisition.

-   Address complex information technology objectives incrementally in
    order to enhance the likelihood of achieving workable systems or
    solutions for attainment of those objectives.

-   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 principle functions.

-   Provide an opportunity for subsequent increments to take advantage
    of any evolution in technology or needs that occur during
    implementation and use of the earlier increments.

-   Reduce risk of potential adverse consequences on the overall project
    by isolating and avoiding custom-designed components of the system.

FAR part 39.103 (c) adds guidance on factors to be considered in
designating increments (modules). It suggests agencies should address
the following issues:

-   To promote compatibility, IT modules for each increment should
    comply with common or commercially acceptable IT standards and the
    agency's master information technology architecture.

-   The performance requirements of each increment should be consistent
    with the performance requirements of the completed overall
    system...and should address the interface requirements with
    succeeding increments.

The FAR guidance continues with FAR 39.103 (d) stating that contracting
officers shall choose the appropriate contracting technique for the
particular circumstances (e.g., indefinite delivery, indefinite quantity
(ID/IQ), single-award contracts with options, successive contracts,
multiple award task order contracts, etc.). Additionally, the
contracting technique should facilitate the acquisition of subsequent
increments. Whatever the contractual approach, the FAR requires that
contract(s) be structured to ensure that the government is not required
to procure additional increments.

Finally, FAR part 39.103(d) includes the statutory requirement that, to
the maximum extent practicable, a modular contract for IT should be
awarded within 180 days after the date the solicitation was issued. It
also requires that, to the maximum extent practicable, deliveries under
the contract should occur within 18 months after issuance of the
solicitation.

### Budgetary

Budgetary guidance and direction is one area where modular contracting
requirements have been incorporated and compliance is expected. The
Office of Management and Budget (OMB) has made it clear that funding for
IT systems will be dependent to a large extent on following a modular
approach.

Former OMB Director Franklin Raines made OMB's position on grand design
programs very clear. At the Armed Forces Communications and Electronics
Association's (AFCEA's) 1998 Virtual Government conference, he stated
"We aren't smart enough to manage a multi-billion dollar project, turn
it on the last day, and see if it works." Instead, Raines suggested
agencies plan and budget their IT initiatives in phases, with regular
milestones to measure performance. He suggested that "the time period
from a project's conception to getting some use out the program should
be 6 to 9 months. Otherwise, return on investment will probably shrink,
and the technology may become outdated." This principle is the essence
of modular contracting.

OMB has promulgated its modular contracting guidance in multiple
documents, including OMB Policy Memorandum M-97-02 and OMB Circular
A-11. OMB Memorandum M-97-02 contained what is now referred to as
"Raines\' rules."[^6] Raines\' rules are eight rules that were
originally issued on October 25, 1996 Rules 6 and 7 incorporate modular
contracting direction for budget submission. OMB will apply the
following criteria in recommending new or continued funding for IT
investments.

Investments in major information systems proposed for funding the
President's budget should:

6\. reduce risk by: avoiding or isolating custom-designed components to
mini­mize the potential adverse consequences on the overall project;
using fully tested pilots, simulations, or prototype implementations
when necessary before going to production; establishing clear measures
and accountability for project progress; and, securing substantial
involvement and buy-in throughout the project from the program officials
who will use the system.

7\. be implemented in phased, successive segments as narrow in scope and
brief in duration as practicable, each of which solves a specific part
of an overall mission problem and delivers a measurable net benefit
independent of future segments, unless it can be demonstrated that there
are significant economies of scale at acceptable risk from funding more
than one segment or there are multiple units that need to be acquired at
the same time.

Raines\' rules were subsequently incorporated in OMB Circular A-11
(Preparation and Submission of Budget Estimates), (1997 and 1998
versions), Appendix 300A, Principles of Budgeting for Capital Asset
Acquisitions. In addition, A-11\'s Exhibit 300B, Capital Asset Plan and
Justification, requires the agencies to describe the use of modular
contracting techniques as part of the asset\'s acquisition strategy.

#  MODULAR CONTRACTING CONCEPTS AND ACQUISITION STRATEGIES

## Traditional Systems Development Approach

To appreciate the advantages offered by modular contracting, it is
important to compare this approach to the traditional process.
Traditional system development procurement models follow the same
conceptual approach as those used in non-IT supply and service
procurements. While the standard procurement model is suitable for
numerous types of federal acquisitions, it adds a significant degree of
difficulty to large-scale IT systems development and modernization
acquisitions. This difficulty arises from limitations in the standard
model, which does not allow for the higher magnitude complexities,
risks, uncertainties, and rate of technological change inherent in
large-scale IT development efforts.

Difficulties associated with the traditional procurement process can be
attributed to the fact the model requires that agencies "solve" the
entire operational problem during the pre-award source selection. For
example, offerors are asked to propose and price the design,
development, test, and implementation of a software system that, in many
cases, has not been fully defined or understood. The problem with this
approach is that the actual tasks will take place several years in the
future. The government also often requires proposals to include the
design and sizing of the computer hardware and system software, which
also will not exist for several years. Once the contract is awarded,
these estimates and assumptions became the baseline requirements by
which the success or failure of the program is measured.

For some IT acquisitions, the traditional procurement model can provide
satisfactory results and meet all desired program objectives. However,
in many cases, applying the traditional approach to a major system
development imposes significant obstacles and unnecessary demands and
risks. The traditional "procurement model" demands specificity in
planning, funding, and acquisition, and a predictive precision that is
extremely difficult to achieve in large-scale IT systems. This fact is
particularly true in today's rapidly changing environments. The
traditional approach considers any deviation from the early planning
estimates as a failure or mistake, warranting some form of penalty and
additional oversight. Forcing this rigidity into the systems development
acquisition process --- intending to minimize risks and mistakes --- can
actually exacerbate it.

By developing systems in much smaller increments (modules), the "event
horizons" are much closer, have much less complexity, and are easier to
estimate, plan, and manage. Modular contracting provides an opportunity
to adapt the current procurement model to the realities of the IT
environment.

## Modular Contracting Approach

Modular contracting offers an alternative acquisition process that
allows agencies to incrementally acquire a system. This alternative
provides for the delivery, implementation, and testing of a workable
system or solution in discrete increments, or modules. The modules can
be acquired via a single procurement or multiple procurements, but the
intent is to ensure that the government is not obligated to purchase
more than one module at a time.

Under the modular contracting approach, the agency incrementally
contracts and manages the program. In contrast to the traditional
acquisition methods, where the entire effort is priced and baselined in
the initial program source selection, the modular approach allows
agencies to make decisions based on smaller, more manageable increments.
Acquisition strategies can allow for the competition and pricing of the
future modules to take place "just in time" for module development.
Hardware and system software can be acquired when sizing information is
available. In this way, future efforts can take advantage of any lessons
learned or advancements in technology.

### Characteristics of Modular Contracting

As stated in the Clinger-Cohen Act, agencies must, to the maximum extent
practicable, use modular contracting to acquire major IT systems. The
structure and content of a module may vary significantly, depending on
the type of IT being acquired and the nature of the program being
developed. The characteristics that define modular contracting are
specified in legislation, regulation, and OMB guidance, which stipulate
that a module must:

-   Be an economically and programmatically separable segment of the
    system that is, or should be, fully funded.

-   Have substantial programmatic use, even if no additional segments
    are acquired; that is, each module should provide for delivery,
    testing, and implementation of a functional system or solution that
    is not dependent on any subsequent module in order to perform its
    significant functions.

-   Provide an opportunity for later increments of the acquisition to
    take advantage of any evolution in technology or needs that are
    identified during the acquisition or implementation of the earlier
    increments.

-   Reduce the risk of potential adverse consequences on the overall
    project by isolating and avoiding custom-designed components of the
    system.

-   Reduce integration risk; each module should comply with common or
    commercially acceptable IT standards when available and appropriate.
    Additionally, each module must be developed within the agency's
    standard IT architecture.

## Modular Contracting Preference and Application

While Clinger-Cohen imposed a statutory "preference" for the use of
modular contracting (maximum extent practicable), the legislation did
not *mandate* that agencies use modular contracting. There are times
when application of modular contracting technique is inappropriate for
the system being developed. For example, a system or business process
that is seamless and monolithic, with no logical breakout, is not a
candidate for modular acquisition. Conversely, an enterprise-type system
comprised of multiple business component programs is an ideal candidate
for the modular approach.

To determine if modular contracting is practicable, agencies must decide
if the system to be acquired can be separated into logical segments.
Major IT systems are comprised of a mix of hardware, software
development, commercial off-the-shelf (COTS) software, integration,
support services, transition, conversion, training, and related
services. While most major IT systems have logical modular break points,
it is difficult to envision a system in which each module completely
meets the requirements noted in Section 3.2.1. In reality, the majority
of systems require at least some degree of modular interoperability.
Modules in these systems cannot operate at full capability without both
preceding and subsequent modules. This situation becomes an issue when
subsequent modules are required to enable the system to meet operational
and programmatic goals and objectives.

However, the advantages offered by a modular approach should not be
rejected because a segment does not meet the strict definition of a
module, or it cannot be contracted for within 180 days or delivered
within 18 months. Agencies who fail to adopt a modular contracting
approach because they strictly apply the definitions and time
constraints will lose the benefits of this valuable acquisition
technique. The extent to which these principles can be applied is
dependent upon the nature of the system being acquired. Even traditional
program development efforts can benefit from modular contracting
techniques and philosophies.

**The key to implementing modular contracting is to phase the system's
development to minimize the integration risk and define each module so
that "*to the maximum extent practicable"* it meets the objectives noted
in law and regulation.**

## Contracting Strategies and Techniques for Modular Contracting

Selecting the appropriate contracting strategy and technique is a key
factor for success of any development effort. This fact is especially
true for modular contracting. Determining the number and type of
contracts and the number of contractors is critical to program control
and success. After completing the requirement analysis, conducting
market research, and understanding the program constraints,
contingencies, and system design, the program manager, contracting
officer, and other members of the program office working together can
craft the appropriate contracting approach. The key to success is to
craft a contract strategy that can accommodate rapid changes in
technology, increased interoperability and integration risk, and
potentially, multiple contractors.

## System Design and Modular Identification

To determine if modular contracting is practicable, agencies must first
decide if the requirement can be separated into logical segments. One of
the first steps in making this determination is for the program office
to prepare a high-level logical system design. It is extremely unlikely
that logical breakout modules can be identified without first having a
system design. This effort will be the key factor in determining the
acquisition and development methodology.

The challenge raised by the modular approach is to structure the program
so that modular components can be integrated into a single system. This
capability requires that modules are designed and controlled so that
increments:

-   Remain backward-compatible with previously developed modules.

-   Are compatible with future modules.

-   Are compatible with agency IT architecture standards and will, as
    required, be compatible with other agency systems.

-   Maintain compatibility across the program to ensure users have
    continuous availability of the system during implementation of
    subsequent modules.

Addressing these challenges requires a management discipline that
includes system engineering and very strong program and configuration
management. In many cases, the program office may wish to acquire the
services of a systems integrator to assist in program management and the
development of the system design.

If the system is a candidate for modular contracting, the design will
include an agency-developed optimum module breakout structure and
phasing schedule. This approach includes implementing modules that have
the biggest "payback" (Return on Investment, or ROI) early in the
program. The more realistic the system design is, the more informed the
risk decisions, strategies, and contracting actions will be.

Exhibit 3-1 depicts the integration and interrelationships between the
agency's IT architecture, standards and business processes, other agency
systems, identification of modules that will comprise system "B," and
integration testing and control.

## Contract Strategy

In crafting a modular contracting strategy, the program team must
consider several factors. In addition to designing the program to meet
the definition and objectives of a module, the contract(s) should:

-   Ensure that the acquisitions of the modules are independent of each
    other and the agency is not obligated to purchase more than one
    module at a time.

-   To the maximum extent practicable, be awarded within 180 days after
    the date on which the solicitation is issued.

-   To the extent practicable, schedule deliveries under the contract to
    occur within 18 months after issuance of the solicitation.

Prior to acquisition reform and streamlining initiatives, it would have
been difficult to meet these requirements. In today's environment of
streamlined source selection and the availability of governmentwide
agency contracts (GWACs) (multiagency and agency task order contracts
focused on IT system development), program teams have a number of
options.

Crafting a contract strategy is not an exact science. What would be a
best practice for one acquisition could be a disaster for another. Each
acquisition option and technique has associated advantages,
disadvantages, overhead requirements, and risks.

Additionally, program teams are not limited to a single approach. They
can simultaneously use a variety of contract vehicles and techniques to
satisfy their requirements. The "best" acquisition approach for a
particular project or program can only be determined after examining
each requirement's many different objectives, risks, and environments.

### Serial Versus Parallel Development

Under one model, modular contracting can be viewed as a serial process
in which one module is completed and implemented before subsequent
development efforts are initiated. This approach can reduce program risk
by ensuring the module is complete and any deficiencies are corrected
before implementation. Modular contracting can also follow a parallel
development strategy, in which multiple modules are being developed
simultaneously or in a slightly staggered fashion.

A parallel development strategy can significantly reduce development
time and allow a faster implementation and ROI for the program. However,
this strategy increases interface and interoperability risks and places
greater oversight demands on the program's systems integrator.
Furthermore, if parallel development is chosen, the agency will be
expending resources before preceding modules are implemented. If these
preceding modules are canceled or fail to meet objectives, parallel
development could be adversely affected. For these reasons, parallel
development should only be applied if the risk of developing subsequent
modules is considered acceptable and if adequate resources are available
to manage the increased oversight workload.

![](media/image2.wmf){width="6.497916666666667in"
height="6.860416666666667in"}

### Contract Type

One important aspect of any contract strategy is the proper allocation
of risk. The selection of contract type is one means of determining the
extent to which the government and contractor share risk. A major factor
in determining the amount of risk present in a requirement is the amount
of "unknowns" it contains. For example, system design and requirements
definition efforts have more unknowns and are usually higher-risk tasks
than coding and testing or acquiring COTS computer hardware and
software. A cost reimbursement-type contract line item or task order
would be appropriate for the design and requirements definition modules.
A fixed-price relationship is appropriate for the lower-risk tasks.

### Single Versus Multiple Contracts

Even though modular contracting has the potential to mitigate many of
the risks inherent in major IT system development efforts, it raises
some new challenges. Perhaps the most significant of these new
challenges is integration risk. When the government takes a large
requirement and breaks it down into successive acquisitions of
interoperable increments, it must address the responsibility for and the
process of integration. Although the government can assume overall
systems integration responsibilities, it is generally recommended that
these duties be assigned to a contractor with specialized systems
integration expertise.

In developing a modular contract strategy, the potential impact of
having multiple contractors perform the effort must be assessed. Having
one contractor perform both module development and system integration
tasks mitigates integration risk and may be an appropriate strategy. At
the same time however, the single contractor approach eliminates the
significant advantages associated with maintaining competition
throughout the program's development. It would be very beneficial to
have a single contractor responsible for integration while maintaining
the program flexibility to compete the development of each module.

One strategy that may come close to achieving this balance is for the
program office to begin the development of the modular program by
acquiring the services of a systems integrator. The system integrator
ensures that adequate interface and interoperability standards are
specified. The system integrator further assists the program office in
ensuring that contractor(s) developing the modules comply with interface
and interoperability direction. Finally, the systems integrator assists
the program office in maintaining interface control and configuration
management. Under this strategy, modules are competed and the agency
benefits from the competitive pricing. The program office can also take
advantage of the contractor's past development performance for future
module competitions.

#### Single Contracts

One of the major advantages of modular contracting is the ability to
contract for each module's development at the most appropriate time.
This advantage is constrained if a single contract strategy is proposed.
A single contract may be most appropriate when the scope of subsequent
modules can be clearly defined at contract inception.

The initial effort is acquired with contract award and future modules
structured as options. Structuring the contract so that future modules
are orderable as options ensures that the government is not obligated to
purchase more that one module at a time. However, options must be priced
in the initial competition. This condition constrains the introduction
of lessons learned and incorporation of new technology into future
modules, as these changes must be made by contract modification. For
this reason, the single contract strategy is generally not recommended
for modular contracts.

**Advantages**

-   Single source selection reduces overhead in awarding and managing
    the contract.

-   Single contractor reduces integration risk.

**Disadvantages**

-   Requires the entire program to be priced and technical solution to
    be proposed at time of contract award.

-   Lessons learned and technology changes must be incorporated by
    modification.

-   Competitive environment is not maintained.

#### Successive Competitions

A more appropriate strategy for modular contracting may be conducting
successive competitive contracts. Successive competitive contracts allow
the government to conduct a separate competition for each module. Using
streamlined source selection techniques, the government can award a
series of contracts for module development. While the method allows for
introduction of lessons learned and incorporation of new technology, it
requires significant time and resources to conduct each source
selection. Additionally, this strategy will most likely result in
multiple contractors, increasing integration risk.

**Advantages**

-   Optimal pricing and technical solution for each module is obtained
    "just in time," allowing incorporation of lessons learned and new
    technology.

-   Competitive environment is maintained throughout the program
    development.

**Disadvantages**

-   Significant probability of multiple contractors increases
    integration risk.

-   Large overhead requirement to conduct multiple source selections,
    with increased risk of protest and program delays.

#### Task Order Contracts

Task order-type, ID/IQ contracts represent perhaps the best option for
modular contracting. Ranging from GWACs to GSA Federal Supply Schedules
(FSS), nearly every IT product and service needed for modular
development is readily available under an existing contract. In most
cases, program managers can have a major systems integrator or developer
under task order within a maximum of 60 days from initiating the
request. Additionally, there are several multiple-award GWAC and
multiagency ID/IQ contract programs whose primary focus is software
development and integration. These contracts are important because they
have been awarded to contractors that specialize in developmental
efforts. In addition, the contracts contain special provisions and
contract types appropriate for development and integration efforts.

These contracts are particularly useful for modular contracting because
of the ease of task order award and the vast array of products and
development contractors. Through the task order "fair opportunity"
competitive process, agencies can compete each module's development and
maintain a competitive environment. Conversely, the task order's
competitive process recognizes that directed awards for a follow-on
effort may also be appropriate. The directed award option may be a
significant advantage when the program office wants to reduce
integration risk by allowing the incumbent contractor to continue the
development effort. Finally, the issues that contractors can protest in
a fair opportunity competition are limited.

**Advantages**

-   Wide selection of products and services available from top-ranked
    integrators and developers.

-   Fair opportunity competitive procedures are very streamlined (\<60
    days) and require significantly less overhead than full and open
    competitions.

-   Fair opportunity competitive procedures authorize directed follow-on
    orders.

-   Numerous contracts are available offering a range of contract types
    \[e.g., cost plus contract line item numbers (CLINs)\] and contract
    provisions.

-   Competitive environment can be maintained throughout program
    development.

**Disadvantages**

Some potential loss of direct administrative control if using another
agency's contract.

## Rights in Technical Data and Computer Software

In using a modular contracting approach, it is essential that the agency
has a well-defined IT architecture and interface requirements. The
contract must also contain the appropriate provisions that require the
developmental contractor(s) to fully document the module design and
interfaces. Documentation of the module design and interfaces is an
integral part of the system and must be completed before module
acceptance. If the government does not obtain adequate rights and
software documentation, it may prove impossible to develop and integrate
individual modules, especially if the acquisition approach plans on
using multiple contractors.

The cost structure, license agreements, and methods of distribution for
COTS software can also be problematic. Issues dealing with data rights,
license fees, and impact of upgrades and updates can result in delays
and significant increased program costs. The assistance of a dedicated
systems integrator can prove invaluable in anticipating and resolving
issues dealing with software license, data rights, and upgrade/update
integration issues.

## Source Selection Considerations

As with any source selection, a competition for a modular contracting
development effort should focus on selecting the contractor(s) that
provides the government the highest degree of confidence that it can
meet or exceed cost, schedule, and performance requirements. To achieve
this goal, the agency must select evaluation criteria that identify the
contractor(s) that can successfully manage and develop a complex
software development effort that contains higher levels of integration
risk. The objective should be to select the contractor(s) that has
successfully developed comparable software systems and demonstrates a
mature software development capability and process. In light of this
objective, two evaluation criteria that are particularly applicable to
modular efforts include past performance and the software capability
maturity model (CMM).

### Past Performance Evaluation Criteria

Recent changes to the FAR have made an offeror's past performance a
mandatory source selection evaluation factor. The complexities involved
in any major IT development effort make it essential for the government
to select only the highest qualified and experienced contractor(s).
While not infallible, past performance information is arguably the
single best predictor of quality and potential customer satisfaction.
Past performance information provides the source selection official with
valuable data to estimate the future performance of a contractor by
answering: In contracts of similar size, scope, and complexity, how well
did the contractor:

-   Conform to the contract requirements and standards of high-quality
    workmanship?

-   Adhere to contract schedules?

-   Forecast and control costs?

-   Provide reasonable and cooperative behavior and commitment to
    customer satisfaction?

### Software Capability Maturity Model (CMM)

The Software Engineering Institute (a Federally Funded Research and
Development Contractor) developed the software development capability
maturity model (CMM). The CMM provides organizations with a framework
for improving their software engineering and management processes. It
provides both government and contractor organizations with guidance on
how to gain control of processes for developing and maintaining
software.

In simplest terms, the offeror with the more mature software development
process is more likely to develop software within the contract's cost,
schedule, and performance requirements. Thus, the CMM provides an
excellent tool to assist the government in identifying and selecting the
offeror that provides the greatest probability of completing the
development effort successfully.

The CMM is organized into five (5) levels as shown in Exhibit 3-2. It
has been reported that over 80 percent of commercial firms engaged in
software development are at Level 1.

While it is obvious that a CMM evaluation can be a powerful
discriminator in any software development source selection, like most
tools, it requires a complete understanding of its proper usage. CMM
evaluation is a complex action that can be costly for both the offerors
and the government. It is strongly recommended that agencies ensure they
have either in-house or contract support personnel who are knowledgeable
in the CMM and software capability assessments before applying CMM as a
source selection evaluation criterion.

#  MANAGING THE PROGRAM

## Program Management Overview

A meaningful and disciplined program management process is essential to
effectively manage the risks of any software development program. This
need is even more critical in conducting a modular contracting
development effort. The inherent integration risks and the increased
opportunity for multi-functional disciplines (e.g., engineering,
customers, procurement, finance, other agencies, oversight, etc.) to
participate in system development make strong and effective program
management critical for success.

## Systems Acquisition Process

A major IT development program requires a systematic acquisition process
that takes into consideration the efforts, complexities, and
uncertainties. OMB Circular A-109, Major Systems Acquisition, provides
some guidance in this area. Of particular note is the recognition of a
"systems acquisition process" one that differs from the norm that must
be managed more deliberately, fully and carefully. That process is
defined in paragraph 5.i of the Circular to cover:

the sequence of acquisition activities starting from the agency's
reconciliation of its mission needs with its capabilities, priorities,
and resources, and extending through the introduction of a system into
operational use or the otherwise successful achievement of program
objectives.

In this context, A-109 principles call for an integrated, systematic
approach for establishing mission needs, budgeting, contracting,
managing the program, improving opportunities for innovative private
sector contributions, and avoiding premature commitment to unwise
courses of action (an advantage of modular contracting). The A-109
management concepts are designed to achieve program objectives within
resource constraints. A-109 requires an analysis of the acquisition and
risk management strategy to best match mission needs with business and
technical approaches. A well-defined and integrated program management
plan becomes the framework for managing research development, testing,
production, fielding, support, and other essential program activities.

## Program Management

Large-scale systems development, "grand design" class, and
modular-oriented programs are critically dependent on effective,
acquisition-oriented program management. The planning and management of
any major IT development effort is a complex and demanding task.
Acquisition strategies must be carefully crafted, balancing the risks
presented by the facts and circumstances of the particular requirement
and environment.

For major IT development efforts, program management cannot be viewed as
a part-time effort or additional duty. It requires a dedicated Program
Manager (PM) leading a team of highly trained and experienced personnel.
The team should also be familiar with and apply sophisticated management
techniques such as "earned value reporting," strong configuration
management, and other performance measuring tools. The knowledge,
skills, talent, and experience of the program team remains a key
determinant of a successful IT development program.

Effective program management:

-   Vests authority, responsibility, and accountability for success in
    one individual.

-   Establishes a single point of contact for the customer(s).

-   Facilitates rapid responses to problems and conflict resolution.

-   Keeps a central focus on program success, with the ability to make
    appropriate trade-offs among cost, schedule, and performance.

Program managers and program management planning should focus on:

-   Non-technical program management activities, such as:

```{=html}
<!-- -->
```
-   Developing a program management plan as the conceptual basis for
    program execution.

-   Planning and controlling the framework, milestone schedules,
    reporting, risk management, etc.

-   Systematically scheduling all steps and products required for
    appropriate visibility, assignment, identification, and tracking.

-   Gathering information to support decision making.

-   Reviewing input from team members and contractors on all activities

```{=html}
<!-- -->
```
-   Technical program management activities, such as:

```{=html}
<!-- -->
```
-   Controlling the system design so that all elements are integrated
    into the optimum system.

-   Using configuration management to identify functional/physical
    characteristics (baselining), control changes, record/ report
    changes.

-   Measuring and reviewing technical performance.

### Program Management Office

The majority of developmental program disappointments can be attributed
to failure to identify and manage cost, schedule, and/or performance
risks. The primary method for mitigating such risks is to establish a
program control office responsible for tracking and evaluating the
program's achievement of cost, schedule, and performance objectives.

A more informed and effective modular contract strategy is possible when
the program office identifies and plans for the systems acquisition's
risks. One method to ensure a well-planned strategy is to develop a
baselined program management plan (PMP). (See Appendix 5 for a program
management plan template.) The PMP describes how the overall system will
be modularized, managed, integrated, and deployed; it includes such
items as:

-   Module definition and go/no-go criteria.

-   Determination as to whether the agency will assume the high-risk
    integration role/re­spon­sibility, or contract it out, etc.

-   Resource requirements, make or buy.

-   Sequencing, phasing, scheduling module development, testing.

-   Information needs from agency and contractor, performance measure
    development and utilization.

-   Requirements and change control, configuration management.

-   Decision-making processes.

-   System testing, deployment, operational support.

-   Security/privacy standards.

### Integrated Product Team

Successful modular contracting demands communication between the various
internal government activities as well as with, and among, the various
contractors. Integrated Product Teams (IPTs) have proven to be an
important organizational tool that has shown considerable potential to
help achieve this increased communication and improve program office
decision making. Program offices that have structured their organization
based on IPT principles have seen significant improvements in both the
quality and timeliness of decision making.

IPTs are composed of representatives from all appropriate functional
disciplines (e.g., program management, engineering, manufacturing, test,
logistics, financial management, procurement, contract administration,
etc.). They are brought together early in to the program to work
together to identify and resolve issues and problems. The goal of the
IPT is to build successful and balanced programs, identify and resolve
issues, and make sound and timely decisions. Thus, the IPT seeks to use
teamwork to significantly reduce turnaround time for decisions and to
ensure delivery of a system that best meets the total life-cycle
requirements of the end-user.

### Interface Control Working Group

Another program management organization that can be particularly useful
in managing a modular effort is the Interface Control Working Group
(ICWG). The ICWG is established when interface requirements exist
between two or more organizations. This scenario can occur often in
modular contracting, as modules may satisfy different organizational
requirements. The ICWG is tasked to maintain the interface baseline and
ensure that modules will integrate. This responsibility is carried out
through the management of an interface control document.

An interface control document (ICD) explicitly defines the standards and
agreed-upon methods of communication within the program. No changes may
be made to the ICD without the consent of the member organizations. In
this manner, any changes can be assessed for their impact on both
previously implemented modules and future increments.

## Risk Management and Control

Program risk is generally identified as falling into four categories:
technical risks, program stability risks, programmatic risks, and cost
and schedule risks. In addition to defining the overall program goals,
deliverables, milestones, etc., an important aspect of the program
management plan is to systematically identify, analyze, and plan for
monitoring relevant risk areas. A systems development and/or
modernization program management strategy must identify and select the
available program management tools and tracking options to reduce or
control selected areas of risk. This goal can be accomplished through
combinations of risk avoidance, control, assumption, and transfer.

### Configuration Management

Configuration management (CM) defines both the functional and physical
characteristics of a system throughout its life cycle. It is a critical
component of any modular development effort, because a change to one
module may affect the ongoing procurement, development, or operation of
any other modules in the system. CM applies to hardware, software,
documentation, testing, and virtually any element that requires detailed
tracking. CM promotes the integrity and continuity of the design and
engineering and enables the evaluation of trade-offs that are made as
products evolve. It shows how the project got from one point to another.

A simple example, which many users of word processing software have
experienced, shows the importance of maintaining strong configuration
management. Word processing software users who upgrade their systems
often find that the systems are no longer compatible with previous
versions. Users of the previous versions cannot read documents produced
in updated format. In a modular contracting environment, the program
office must decide whether to upgrade the entire system, including any
previously implemented modules, in order to maintain interoperability.
The challenge is in recognizing the need to integrate newer components
of segments into a system of older components. Strong CM practices will
assist in identifying and documenting these requirements.

### Change Management

Change management provides a disciplined process to prevent arbitrary
changes to the system(s). Change management applies administrative
discipline and supplies management direction throughout the design,
production, implementation, operation, and maintenance phases of a
project's lifecycle. Each element is identified and described, forming
the baseline from which all changes are controlled. Changes require
complete justification. The justification process should require
analyses of the impact on the cost, schedule, and technical elements of
the project before the change is implemented.

Change management consists of four processes, each of which works in
conjunction with an established baseline:

-   ***Configuration Identification***---The process of establishing and
    maintaining a basis for control and status accounting for an item
    throughout its life cycle.

-   ***Change Control***---The process of regulating justification,
    evaluation, and coordination of all proposed changes.

-   ***Audit and Verification***---The process of verifying the item is
    in compliance with its corresponding configuration information.

-   ***Configuration Status Accounting***---The process of ensuring
    accurate identification of each configuration item so that logistics
    support is available.

The concept of baselines is fundamental to change management. A baseline
is an agreed-upon set of characteristics of any configuration item. The
baseline is defined in a manner that prevents unauthorized alteration.
Baselines cannot be changed without the approval of the PM and
configuration control board (CCB).

All change management procedures should be identified and documented in
a PM-approved Configuration Management Plan. The availability of a
change management plan and procedures, and the PM's enforcement of the
discipline, is critical to the success of any system implementation, but
it is especially critical to a system implemented through modular
contracting.

### Integration Risk

A high-risk area raised by the modular acquisition methodology is
integration risk. Integration risk means that the independently
developed modules may be fully operational themselves, but when they are
integrated into the overall system, the individual modules reveal flaws
or gaps that degrade system or module performance. Failure to manage the
integration effort significantly raises the risk of system failure.

When the government takes a large requirement and breaks it down into
successive acquisitions of interoperable increments, it must address the
responsibility for and process of integration. In traditional system or
solution buys, the problem of integration is contracted out as part of
the overall acquisition. In modular buys, however, agencies must address
integration in terms of government or contractor responsibility,
standards, and deliverables. In reality, rarely does the government have
the necessary in-house expertise to manage the integration effort and,
in most cases, it should consider obtaining contractor support for this
critical effort.

The definition of the system's modules and their integration and
interoperability requirements is important for the success of any
modular effort. Modular contracting by its very nature contains a higher
degree of risk that developed modules will not integrate or operate
together. The single greatest way to mitigate and control this risk is
the formulation and enforcement of an agency-wide IT architecture based
on common and commercial standards. As the overall system is based on
agency standards, each module should, in turn, be consistent with the
approved standards. While modular contracting success is possible
without an agency-wide architecture, it is highly improbable.

#### Integration Testing

Integration testing is also a critical component of the modular
contracting methodology. Testing is one of the most challenging and
costly process activities, and yet it is generally one of the least
understood and most underfunded processes in system implementation.

As described by the Illinois Institute of Technology's Burnstein and
Carlson[^7], most organizations believe that testing consists of an ad
hoc "debugging" process in which the only objective is to show that the
software works. Some organizations have progressed to the level where
they understand that testing is required. However, these organizations
believe the goal of testing is merely to show that the software meets
its specifications[^8], so testing is limited to a phase that follows
coding.

Because of the intricacies of integrating separate modules into an
overall system, it is incumbent upon the PM to establish a testing
process that considers the system during all stages of its life cycle.
Testing must thus consist of quantified and documented test and quality
assurance objectives measured and administered by a professional test
cadre.

## Cost and Schedule Performance Tracking

There are three key elements that are normally associated with any
project: performance, cost, and schedule. An effective program
management control system should provide data that indicates conclusive
work progress and relevant cost, schedule, and technical performance
characteristics. To enable the government to monitor performance in
terms of cost and schedule, the contractor should be required to submit
periodic reports that inform the program office of the actual progress
of the project. These reports constitute a series of data points that
account for :

-   The variances in cost between the planned budget and the actual
    cost, and,

-   The variances between the completed tasks versus the planned ones,
    expressed in dollars.

Based on the variance indicators, the government can determine the
contractor's performance status in managing both cost and schedule. To
optimize the utility of this information, the cost and schedule data
must be provided in a timely, accurate, and valid fashion. A PM can
successfully control the program by using this information to predict
shortcomings and reduce program risks.

Programs and projects can be considered budgeted efforts that consist of
numerous tasks that are spread out over a period of time. The PM must
make sure the contractor accomplishes each project by finishing all the
tasks that were planned, on time and within budget. At completion, the
program should have been finished on schedule and within cost while
meeting performance requirements. The degree to which performance varies
from the original plan, in terms of cost and schedule as a function of
time, forms the basis of earned value.

### Earned Value Measurement

Earned value is a sophisticated management technique for measuring cost
and schedule performance. The earned value concept provides a practical
approach to the planning of work, the monitoring of progress against the
plan (or the *earned value*), and the accumulation of costs incurred to
accomplish the completed work that is in progress. The monitoring of
progress against the earned value plan enables an organization to assess
the cost, schedule, and technical value of the accomplished work and
identify variant conditions that require management attention to
mitigate cost growth or schedule slippage.

From an overall management standpoint, earned value is a set of control
principles and disciplined practices used in the execution of
acquisition projects to monitor cost, performance, and schedule
progress. The concept of earned value goes beyond the two-dimensional
approach of comparing budgeted costs to actual costs. It attempts to
compare the value of the actual work accomplished during a given period
with the work planned for that period. Earned value is an "early
warning" management tool that enables managers to identify and control
problems before they become insurmountable. Earned value information
provides management with greater insight into potential risk areas. It
also provides estimates that are more accurate for projected completion
costs. With this information, managers can develop risk mitigation plans
based upon the actual cost, schedule, and technical progress of the
work[^9].

### Work Breakdown Structure

The work breakdown structure (WBS) is one of the most important and
useful tools available to the PM. The WBS provides essential definition
for baseline identification, change control, cost estimating,
contractual actions, and execution of work. The WBS clearly and
explicitly identifies all the deliverables of each project on which to
base project estimates for schedule, cost, and performance.

An essential element of any earned value reporting system, the WBS uses
a "family tree" arrangement to display the products, services, and data
items to be developed or produced for the project (see Exhibit 4-1). The
tree relates the WBS elements to each other and to the end product. The
WBS breaks the program down into lower-level logical categories that
facilitate the comprehensive identification of all constituent program
elements. At the same time, the logical structure of the WBS helps
ensure that each project element is identified in a mutually exclusive
way, preventing items from being accidentally double-counted or billed.

In a modular acquisition, the WBS will have two levels: one for the
program or system, and one for each module. A program summary WBS is
developed early in the program and used throughout the program life
cycle as a framework for both technical and management activities. As
the name implies, the program summary WBS consolidates the technical and
management activities of multiple modular development efforts into a
single, program-level tracking and reporting tool. The program summary
WBS is used to guide and organize the development of user requirements,
system specifications, budgets, and statements of work and to establish
standards for progress, performance, and cost
reporting.![](media/image4.wmf){width="6.492361111111111in"
height="2.765972222222222in"}

The module-level WBS identifies all efforts required to complete the
development, testing, and integration of the module. This WBS allows
tracking of module progress and performance, as well as cost reporting.
To enable consistent tracking and reporting, each module WBS follows the
framework and conventions established by the program-level WBS.

### Organization Breakdown Structure (OBS)

The organization breakdown structure (OBS) is an organization-oriented
family tree identical to an organization chart. Its purpose is to define
the top-down hierarchical structure of the organization or work group
responsible for implementing the products or services defined in the
WBS. The OBS mirrors the hierarchical structure used to assign
responsibility for any work within an organization (see Exhibit 4-2). In
most cases, the existing corporate organization chart can be used.

The OBS identifies the person or element within the organization
responsible for ensuring that the work to deliver a product or service
is performed. This entity usually corresponds to the lowest element of
budgetary responsibility, although it may be even lower on some
occasions. However, the level selected should be the lowest responsible
manager. Once the lowest-level responsible manager is identified, cost,
plans, and efforts can be tracked for the entire program. The OBS shows
exactly who in the organization has the responsibility for getting the
work done.

The OBS may be developed for any organization providing products or
services to a program or project. There could be an OBS for the primary
organization responsible for delivering the products and services as
well as a separate OBS for each
project.![](media/image5.wmf){width="6.465277777777778in"
height="1.7013888888888888in"}

### Cost Accounts

A cost account is the core of earned value performance measurement. A
cost account is the point at which the WBS and OBS intersect and
functional responsibility is assigned. Each cost account must contain a
specific scope of work, time frame, and budget. These accounts are the
focal point for the integration of cost, schedule, and performance. Each
cost account must have the capability of distinguishing the planned
value with its earned value and the earned value against the actual
costs[^10]. The sum of the individual cost accounts forms the
performance measurement baseline.

The cost account is derived by determining what product, as defined by
the WBS, is being provided by a particular person or group, as defined
by the OBS. In some instances, this process is described as a
responsibility matrix. (See Exhibit 4-3.)

This product is usually a budgeted item that a particular manager will
be responsible for delivering. The manager's goal is to deliver that
product or service within the budget and time constraints agreed on by
the manager and the project leaders.

### Precedence (Critical Path) Schedule

Once the WBS is developed and tasks are identified, the next step is to
relate them sequentially in a precedence-type network. A precedence
network, in its final form, identifies the interrelationship between
activities and their associated time duration. Such information in
graphic form enables the PM to determine project duration and tasks that
are critical. The expected project duration is based on the estimated
time required to accomplish each activity. The critical path represents
the longest time path within the network diagram. (See Exhibit 4-4.)

By identifying the critical path within the network, the PM and
development contractor(s) can focus on those issues most in need of
management attention and can analyze the effects of shifting resources
from one activity to another. The resources for the tasks, both
personnel and physical, can be identified and profiled in accordance
with the schedule, thereby providing the means to calculate the
personnel resources and associated budget requirements. By integrating
the WBS to the precedence network, the PM can determine the following
task relationships:

1.  What must be done before starting a particular activity?

2.  What can be done
    concurrently?![](media/image7.wmf){width="3.998611111111111in"
    height="1.1729166666666666in"}

3.  What follows this activity?

### Software Measures and Metrics

As noted in Section 3.8.2, software developers are increasingly seeking
to improve the management of the development process. A goal for many of
the top software developers is to reach CMM Level 4---Managed. Achieving
this level indicates the developer collects detailed measures of the
software process and product quality. Software development contractors
who reach CMM Level 4 ranking are quantitatively measuring their
software processes and product quality on factors such as those shown in
Exhibit 4-5.

It is, however, well beyond the scope of this guide to address the
relative merits of quality measurements for software development. Two
excellent sources of information are *Practical Software Management, A
Guide to Objective Program Insight,* sponsored by the Joint Logistics
Commanders, Joint Group on Systems Engineering (JLC-JGSE), available on
the Internet at http:www.cards.com/psm, and the Software Engineering
Institute's *Software Measurement for DOD Systems: Recommendations for
Initial Core Measures* (Technical Report CMU/SEI-92-TR-19), also
available on the Internet at http:www.sei.cmu.edu.

## Agency Information Technology Architecture

The Clinger-Cohen Act of 1996 (Public Law 104-106) made the Chief
Information Officer (CIO) within each agency responsible for developing,
maintaining, and facilitating the implementation of an agency's
information technology architecture. This responsibility includes
ensuring that:

-   The requirements for agency-sponsored information systems are
    aligned with the processes that support the agency's missions and
    goals.

-   Information systems have adequate interoperability, redundancy, and
    security.

-   The agency applies and maintains a collection of standards by which
    it evaluates and acquires new systems.

Agencies have considerable latitude to tailor their respective concepts
of the IT architecture. However, to be considered compliant, the IT
architecture will contain two elements: the Enterprise Architecture and
a Technical Reference Model and Standards Profiles.[^11]

An enterprise architecture is a strategic information asset base that
defines the business, the information necessary to operate the business,
the technologies necessary to support the business operations, and the
transitional processes necessary for implementing new technologies in
response to the changing needs of business.[^12] The enterprise
architecture should take into account the agency's overall goals and
direction. Then it should consider how issues such as interoperability,
open systems, public access, end-user satisfaction, and security promote
the ability to achieve the overall goals. In determining the enterprise
architecture, agencies should consider the following elements:

-   Business Processes

-   Information Flows and Relationships

-   Applications

-   Data Descriptions

-   Technology Infrastructure

### Standards-Based Environment

A critical component of reducing the risks associated with modular
contracting is the existence of a standard, agency-wide IT architecture
based on common and commercial standards. Whereas the agency
architecture framework describes the fundamental relationship between
business, IT program, and technical policy, the technical element of an
actual IT architecture requires much greater specificity and an approved
set of technology standards. By identifying agency development and
interface standards, the agency can reduce program risk by selecting and
reusing proven solutions and sharing common functionality.

The technical element of an IT architecture will help the agency
eliminate:

-   Duplication of development (in areas such as mapping, track
    management, and communications interfaces), and

-   Design incompatibility among agency systems.

A well-defined technical architecture standard enables the agency to
increase inter­operability, reusability, portability, and operational
capability, while at the same time curtailing program risk by reducing
development time, technical obsolescence, training requirements, and
life-cycle costs. It may be possible to conduct a module development
effort without a technical architecture. However, its absence will
significantly increase program risk. Agencies are strongly encouraged to
put a comprehensive architecture framework in place before attempting a
modular development effort.

#  CONCLUSION

As stated in the Executive Summary, the purpose of this guide is to
provide government program, technical, and contracting officials with an
introduction to the techniques, advantages, and considerations
associated with modular contracting. The guide is structured to provide
both valuable background and "how-to" information on the application and
use of modular contracting techniques. It is intended to help an agency
successfully plan and conduct a modular development effort.

In its simplest terms, modular contracting is acquisition of a major
system of IT in successive purchases of interoperable modules. Its
application allows the government to quickly access the latest
technology and make informed decisions at a time when pertinent facts
are available. The flexibility inherent in modular contracting allows
the agency to control costs by stopping or altering the acquisition of
future modules while retaining the maximum value from modules acquired
to date. Additionally, because follow-on efforts are not guaranteed,
modular contracting provides a powerful incentive for the selected
contractors to produce high-quality products within projected cost
estimates. Thus, if properly planned and managed, modular contracting
has the potential to offer significant advantages over traditional
system development approaches.

Although it presents a beneficial alternative to the traditional
procurement model, modular contracting should not be viewed as a "silver
bullet" solution. Its application does solve

some very troubling issues, but it raises others. For example, modular
contracting requires agencies to have agency-wide architecture and
interoperability standards in place to ensure that the modules will
integrate. This requirement is critical if modular contacting is to be
successful.

Successful application of modular techniques also requires strong
program management and careful attention to configuration management and
system integration issues. A meaningful and disciplined program
management process is essential to effectively manage the risks of any
software development program. More-over, given the increased integration
issues, this need is especially critical in conducting a modular
contracting development effort. These new challenges, however, do not
negate the numerous benefits associated with modular contracting.

The single greatest determinant of success of any development effort is
its people. Modular development demands a dedicated team of highly
skilled, trained, and experienced personnel using sophisticated program
management and system development techniques. If this experience is not
available within the government, contract support should be obtained to
fill the need. To be successful, modular contracting demands one
additional attribute: it requires a strong partnering approach between
the government and the contractor(s). In reality, both the government
and contractor have the same objective---a successful program that meets
or exceeds cost, schedule, and performance criteria!

The question as to whether to apply modular contracting techniques to a
development effort should not be a matter of debate. Given
Clinger-Cohen's statutory direction, Presidential Executive Order 13011,
OMB guidance, and the opportunities and advantages offered by modular
contracting, the question is not *whether* to apply modular techniques,
but rather how to maximize the degree to which they can be applied.

APPENDIX

1.  ITMRA Sections 5201 & 5202 (Division E of Clinger-Cohen Act)

2.  Executive Order 13011 "Federal Information Technology" July 1996

3.  FAR 39.002, 39.103

4.  Glossary of Terms

5.  Program Management Plan

6.  Contacts for More Information

APPENDIX 1. ITMRA Sections 5201 & 5202\
(Division E of the Clinger-Cohen Act)

TITLE LII---PROCESS FOR ACQUISITIONS OF INFORMATION TECHNOLOGY

SEC. 5201. PROCUREMENT PROCEDURES.

The Federal Acquisition Regulatory Council shall ensure that, to the
maximum extent practicable, the process for acquisition of information
technology is a simplified, clear, and understandable process that
specifically addresses the management of risk, incremental acquisitions,
and the need to incorporate commercial information technology in a
timely manner.

SEC. 5202. INCREMENTAL ACQUISITION OF INFORMATION TECHNOLOGY.

\(a\) POLICY- The Office of Federal Procurement Policy Act (41 U.S.C.
401 et seq.) is amended by adding at the end the following new section:

SEC. 35. MODULAR CONTRACTING FOR INFORMATION TECHNOLOGY.

\(a\) IN GENERAL- The head of an executive agency should, to the maximum
extent practicable, use modular contracting for an acquisition of a
major system of information technology.

\(b\) MODULAR CONTRACTING DESCRIBED- Under modular contracting, an
executive agency's need for a system is satisfied in successive
acquisitions of interoperable increments. Each increment complies with
common or commercially accepted standards applicable to information
technology so that the increments are compatible with other increments
of information technology comprising the system.

\(c\) IMPLEMENTATION- The Federal Acquisition Regulation shall provide
that\--

\(1\) under the modular contracting process, an acquisition of a major
system of information technology may be divided into several smaller
acquisition increments that\--

\(A\) are easier to manage individually than would be one comprehensive
acquisition;

\(B\) address complex information technology objectives incrementally in
order to enhance the likelihood of achieving workable solutions for
attainment of those objectives;

\(C\) 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; and

\(D\) provide an opportunity for subsequent increments of the
acquisition to take advantage of any evolution in technology or needs
that occur during conduct of the earlier increments;

\(2\) a contract for an increment of an information technology
acquisition should, to the maximum extent practicable, be awarded within
180 days after the date on which the solicitation is issued and, if the
contract for that increment cannot be awarded within such period, the
increment should be considered for cancellation; and

\(3\) the information technology provided for in a contract for
acquisition of information technology should be delivered within 18
months after the date on which the solicitation resulting in award of
the contract was issued.

\(b\) CLERICAL AMENDMENT- The table of contents in section 1(b) of such
Act is amended by inserting after the item relating to Section 34 the
following new item: Sec. 35. Modular contracting for information
technology.

APPENDIX 2. Executive Order 13011

EXECUTIVE ORDER 13011 OF JULY 16, 1996\
FEDERAL INFORMATION TECHNOLOGY

A government that works better and costs less requires efficient and
effective information systems. The Paperwork Reduction Act of 1995 and
the Information Technology Management Reform Act of 1996 provide the
opportunity to improve significantly the way the federal government
acquires and manages information technology. Agencies now have the clear
authority and responsibility to make measurable improvements in mission
performance and service delivery to the public through the strategic
application of information technology. A coordinated approach that
builds on existing structures and successful practices is needed to
provide maximum benefit across the federal government from this
technology.

Accordingly, by the authority vested in me as President by the
Constitution and the laws of the United States of America, it is hereby
ordered as follows:

**Section 1. Policy.** It shall be the policy of the United States
Government that executive agencies shall:

\(a\) significantly improve the management of their information systems,
including the acquisition of information technology, by implementing the
relevant provisions of the Paperwork Reduction Act of 1995 (Public Law
104-13), the Information Technology Management Reform Act of 1996
(Division E of Public Law 104-106) ("Information Technology Act"), and
the Government Performance and Results Act of 1993 (Public Law 103-62);

\(b\) refocus information technology management to support directly
their strategic missions, implement an investment review process that
drives budget formulation and execution for information systems, and
rethink and restructure the way they perform their functions before
investing in information technology to support that work;

\(c\) establish clear accountability for information resources
management activities by creating agency Chief Information Officers
(CIOs) with the visibility and management responsibilities necessary to
advise the agency head on the design, development, and implementation of
those information systems. These responsibilities include:
(1) participating in the investment review process for information
systems, (2) monitoring and evaluating the performance of those
information systems on the basis of applicable performance measures,
and, (3) as necessary advising the agency head to modify or terminate
those systems;

\(d\) cooperate in the use of information technology to improve the
productivity of federal programs and to promote a coordinated,
interoperable, secure, and shared government-wide infrastructure that is
provided and supported by a diversity of private-sector supplies and a
well-trained corps of information technology professionals; and

\(e\) establish an interagency support structure that builds on existing
successful interagency efforts and shall provide expertise and advice to
agencies; expand the skill and career development opportunities of
information technology professionals; improve the management and use of
information technology within and among agencies by developing
information technology procedures and standards and by identifying and
sharing experiences, ideas, and promising practices; and provided
innovative, multi-disciplinary, project-specific support to agencies to
enhance interoperability, minimize unnecessary duplication of effort,
and capitalize on agency successes.

**Section 2. Responsibilities of Agency Heads.** The head of each
executive agency shall:

\(a\) effectively use information technology to improve mission
performance and service to the public;

\(b\) strengthen the quality of decision about the employment of
information resources to meet mission needs through integrated analysis,
planning, budgeting, and evaluation processes, including:

\(1\) determining, before making investments in new information systems,
whether the government should be performing the function, if the private
sector or another agency should support the function, and if the
function needs to be or has been appropriately redesigned to improve its
efficiency;

\(2\) establishing mission-based performance measures for information
systems investments, aligned with agency performance plans prepared
pursuant to the Government Performance and Results Act of 1993 (Public
Law 103-62);

\(3\) establishing agency-wide and project-level management structures
and processes responsible and accountable for managing, selecting,
controlling, and evaluating investments in information systems, with
authority for terminating information systems when appropriate;

\(4\) supporting appropriate training of personnel; and

\(5\) seeking the advice of, participating in, and supporting the
interagency support structure set forth in this order;

\(c\) select CIOs with the experience and skills necessary to accomplish
the duties set out in law and policy, including this order and involve
the CIO at the highest level of the agency in the processes and
decisions set out in this section;

\(d\) ensure that the information security policies, procedures, and
practices of the executive agency are adequate;

\(d\) where appropriate, and in accordance with the Federal Acquisition
Regulation and guidance to be issued by the Office of Management and
Budget (OMB), structure major information systems investments into
manageable projects as narrow in scope and brief in duration as
practicable, consistent with the Information Technology Act, to reduce
risk, promote flexibility and interoperability, increase accountability,
and better correlate mission need with current technology and market
conditions; and

\(e\) to the extent permitted by law, enter into a contract that
provides for multiagency acquisitions of information technology as an
executive agent for the government , if and in the manner that the
Director of OMB considers it advantageous to do so.

**Section 3. Chief Information Officers Council.**

\(a\) [Purpose and Functions]{.underline}. A Chief Information Officers
Council ("CIO Council") is established as the principal interagency
forum to improve agency practices on such matters as the design,
modernization, use, sharing, and performance of agency information
resources. The Council shall:

\(1\) Develop recommendations for overall federal information technology
management policy, procedures, and standards;

\(2\) share experiences, ideas, and promising practices, including work
process redesign and the development of performance measures, to improve
the management of information resources;

\(3\) identify opportunities, make recommendations for, and sponsor
cooperation in using information resources;

\(4\) assess and address the hiring, training, classification, and
professional development needs of the federal government with respect to
information resources management;

\(5\) make recommendations and provided advice to appropriate executive
agencies and organizations, including advice to OMB on the
government-wide strategic plan required by the Paperwork Reduction Act
of 1995; and

\(6\) Seek the views of the Chief Financial Officers Council, Government
Information Technology Services Board, Information Technology Resources
Board, Federal Procurement Council, industry, academia, and State and
local governments on matters of concern to the Council as appropriate.

\(b\) [Membership]{.underline}. The CIO Council shall be composed of the
CIOs and Deputy CIOs of the following executive agencies plus two
representatives from other agencies:

1.  Department of State;

2.  Department of the Treasury;

3.  Department of Defense;

4.  Department of Justice;

5.  Department of the Interior;

6.  Department of Agriculture;

7.  Department of Commerce;

8.  Department of Labor;

9.  Department of Health and Human Services;

10. Department of Housing and Urban Development;

11. Department of Transportation;

12. Department of Energy;

13. Department of Education;

14. Department of Veterans Affairs;

15. Environmental Protection Agency;

16. Federal Emergency Management Agency;

17. Central Intelligence Agency;

18. Small Business Administration;

19. Social Security Administration;

20. Department of the Army;

21. Department of the Navy;

22. Department of the Air Force;

23. National Aeronautics and Space Administration;

24. Agency for International Development;

25. General Services Administration;

26. National Science Foundation;

27. Nuclear Regulatory Commission; and

28. Office of Personnel Management.

The Administrator of the Office of Information and Regulatory Affairs of
OMB, the Controller of the Office of Federal Financial Management of
OMB, the Administrator of the Office of Federal Procurement Policy of
OMB, a Senior Representative of the Office of Science and Technology
Policy, the Chair of the Government Information Technology Services
Board, and the Chair of the Information Technology Resources Board shall
also be members. The CIO Council shall be chaired by the Deputy Director
for Management of OMB. The Vice Chair, elected by the CIO Council on a
rotating basis, shall be an agency CIO.

**Section 4. Government Information Technology Services Board.**

\(a\) [Purpose and Functions.]{.underline} A Government Information
Technology Services Board ("Services Board") is established to ensure
continued implementation of the information technology recommendations
of the National Performance Review and to identify and promote the
development of innovative technologies, standards, and practices among
agencies and state and local governments and the private sector. It
shall seek the views of experts from industry, academia, and state and
local governments on matters of concern to the Services Board as
appropriate. The Services Board shall also make recommendations to the
agencies, the CIO Council, OMB, and others as appropriate, and assist in
the following:

\(1\) creating opportunities for cross-agency cooperation and
intergovernmental approaches in using information resources to support
common operational areas and to develop and provide shared
government-wide infrastructure services;

\(2\) developing shared government-wide information infrastructure
services to be used for innovative, multiagency information technology
projects;

\(3\) creating and utilizing affinity groups for particular business or
technology areas; and

\(4\) developing with the National Institute of Standards and Technology
and with established standards bodies, standards and guidelines
pertaining to federal information systems, consistent with the
limitations contained in the Computer Security Act of 1987 (40 U.S.C.
759 note), as amended by the Information Technology Act.

\(b\) [Membership]{.underline}. The Services Board shall be composed of
individuals form agencies based on their proven expertise or
accomplishments in fields necessary to achieve its goals. Major
government mission areas such as electronic benefits, electronic
commerce, law enforcement, environmental protection, national defense,
and health care may be represented on the Services Board to provide a
program operations perspective. Initial selection of members will be
made OMB in consultation with other agencies as appropriate. The CIO
Council may nominate two members. The Services Board shall recommend new
members to OMB for consideration. The Chair will be elected by the
Services Board.

**Section 5. Information Technology Resources Board.**

\(a\) [Purpose and Functions]{.underline}. An Information Technology
Resources Board ("Resource Board") is established to provide independent
assessments to assist in the development, acquisition, and management of
selected major information systems and to provide recommendations to
agency heads and OMB as appropriated. The Resources Board shall:

\(1\) review, at the quest of an agency and OMB, specific information
systems proposed or under development and make recommendations to the
agency and OMB regarding the status of systems or next steps;

\(2\) publicize lessons learned and promising practices based on
information systems reviewed by the Board; and

\(3\) seek the views of experts from industry, academia, and state and
local governments on matters of concern to the Resources Board, as
appropriate.

\(b\) [Membership]{.underline}. The Resources Board shall be composed of
individuals from executive branch agencies based on their knowledge of
information technology, program, or acquisition management within
federal agencies. Selection of members shall be made by OMB in
consultation with other agencies as appropriate. The Chair will be
elected by the Resources Board. The Resources Board may call upon the
department or agency whose project is being reviewed, or any other
department or agency to provide knowledgeable representation(s) to the
Board whose guidance and expertise will assist in focusing on the
primary issue(s) presented by a specific system.

**Section 6. Office of Management and Budget.** The Director of OMB
shall:

\(a\) evaluate agency information resources management practice and, as
part of the budget process, analyze, track and evaluate the risks and
results of all major capital investments for information systems;

\(b\) notify an agency if it believes that a major information system
requires outside assistance;

\(c\) provide guidance on the implementation of this order and on the
management of information resources to the executive agencies and to the
Boards established by this order; and

\(d\) evaluate the effectiveness of the management structure set out in
this order after 3 years and make recommendations for any appropriate
changes.

**Section 7. General Services Administration.** Under the direction of
OMB, the Administrator of General Services shall:

\(a\) continue to manage the FTS2000 program and coordinate the
follow-on to that program, on behalf of and with the advice of customer
agencies;

\(b\) develop, maintain, and disseminate for the use of the federal
community, as requested by OMB or the agencies, recommended methods and
strategies for the development and acquisition of information
technology;

\(c\) conduct and manage outreach programs in cooperation with agency
managers;

\(d\) be a focal point for liaison on information resources management,
including federal information technology, with state and local
governments, and with non-governmental international organizations
subject to prior consultation with the Secretary of State to ensure such
liaison would be consistent with and support overall United States
foreign policy objectives;

\(e\) support the activities of the Secretary of State for liaison,
consultation, and negotiation with intergovernmental organizations in
information resources management matters;

\(f\) assist OMB, as requested, in evaluating agencies.
performance-based management tracking systems and agencies. achievement
of cost, schedule, and performance goals; and

\(g\) provide support and assistance to the interagency groups
established in this order.

**Section 8. Department of Commerce.** The Secretary of Commerce shall
carry out the standards responsibilities under the Computer Security Act
of 1987, as amended by the Information Technology Act, taking into
consideration the recommendations of the agencies, the CIO Council, and
the Services Board.

**Section 9. Department of State.**

\(a\) The Secretary of State shall be responsible for liaison,
consultation, and negotiation with foreign governments and
intergovernmental organizations on all matters related to information
resources management, including federal information technology. The
Secretary shall further ensure, in consultation with the Secretary of
Commerce, that the United States is represented in the development of
international standards and recommendations affecting information
technology. In the exercise of these responsibilities, the Secretary
shall consult, as appropriate, with affected domestic agencies,
organizations, and other members of the public.

\(b\) The Secretary of State shall advise the Director on the
development of United States positions and policies on international
information policy and technology issues affecting federal government
activities and the development or international information technology
standards.

**Section 10. Definitions.**

\(a\) "Executive agency" has the meaning given to that term in
section 4(1) of the Office of Federal Procurement Policy Act
(41 U.S.C. 403 (1)).

\(b\) "Information Technology" has the meaning given that term in
section 5002 of the Information Technology Act.

\(c\) "Information resources" has the meaning given that term in
section 3502(6) of title 44, United States Code.

\(d\) Information resources management" has the meaning given that term
in section 3502(7) of title 44, Untied States Code.

\(e\) "Information system" has the meaning given that term in
section 3502(8) of title 44, United States Code.

\(f\) "Affinity group" means any interagency group focused on a business
or technology area with common information technology or customer
requirements. The functions of an affinity group can include identifying
common program goals and requirements; identifying opportunities for
sharing information to improve quality and effectiveness; reducing costs
and burden on the public; and recommending protocols and other
standards, including security standards, to the National Institute of
Standards and Technology for government-wide applicability, for action
in accordance with the Computer Security Act of 1987, as amended by the
Information Technology Act..

\(g\) "National security system" means any telecommunications or
information system operated by the United States Government, the
function, operation, or use of which (1) involves intelligence
activities; (2) involves cryptologic activities related to national
security; (3) involves command and control of military forces;
(4) involves equipment that is an integral part of a weapon or weapons
system; or (5) is critical to the direct fulfillment of military or
intelligence missions, but excluding any system that is to be used for
routine administrative and business applications (including payroll,
finance, logistics, and personnel management applications).

**Section 11. Applicability to National Security Systems.** The heads of
executive agencies shall apply the policies and procedures established
in this order to national security systems in a manner consistent with
the applicability and related limitations regarding such systems set out
in the Information Technology Act.

**Section 12. Judicial Review.** Nothing in this Executive order shall
affect any otherwise available judicial review of agency action. This
Executive order is intended only to improve the internal management of
the executive branch and does not create any right or benefit,
substantive or procedure, enforceable at law or equity by a party
against the United States, its agencies or instrumentalities, its
officers or employees, or any other person.

William J. Clinton

THE WHITE HOUSE

July 16, 1996

APPENDIX 3. FAR 39.002, 39.103 Modular Contracting

**39.002 Definitions.**

"Modular contracting," as used in this part, means use of one or more
contracts to acquire information technology systems in successive,
interoperable increments."

**39.103 Modular Contracting.**

\(a\) This section implements Section 5202, Incremental Acquisition of
Information Technology, of the Clinger-Cohen Act of 1996 (Public Law
104-106). Modular contracting is intended to reduce program risk and to
incentivize contractor performance while meeting the government's need
for timely access to rapidly changing technology. Consistent with the
agency's information technology architecture, agencies should, to the
maximum extent practicable, use modular contracting to acquire major
systems (see 2.101) of information technology. Agencies may also use
modular contracting to acquire non-major systems of information
technology.

\(b\) When using modular contracting, an acquisition of a system of
information technology may be divided into several smaller acquisition
increments that\--

\(1\) Are easier to manage individually than would be possible in one
comprehensive acquisition;

\(2\) Address complex information technology objectives incrementally in
order to enhance the likelihood of achieving workable systems or
solutions for attainment of those objectives;

\(3\) 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;

\(4\) Provide an opportunity for subsequent increments to take advantage
of any evolution in technology or needs that occur during implementation
and use of the earlier increments; and

\(5\) Reduce risk of potential adverse consequences on the overall
project by isolating and avoiding custom-designed components of the
system.

\(c\) The characteristics of an increment may vary depending upon the
type of information technology being acquired and the nature of the
system being developed. The following factors may be considered:

\(1\) To promote compatibility, the information technology acquired
through modular contracting for each increment should comply with common
or commercially acceptable information technology standards when
available and appropriate, and shall conform to the agency's master
information technology architecture.

\(2\) The performance requirements of each increment should be
consistent with the performance requirements of the completed, overall
system within which the information technology will function and should
address interface requirements with succeeding increments.

\(d\) For each increment, contracting officers shall choose an
appropriate contracting technique that facilitates the acquisition of
subsequent increments. Pursuant to Parts 16 and 17 of the Federal
Acquisition Regulation, contracting officers shall select the contract
type and method appropriate to the circumstances (e.g., indefinite
delivery, indefinite quantity contracts, single contract with options,
successive contracts, multiple awards, task order contracts).
Contract(s) shall be structured to ensure that the government is not
required to procure additional increments.

\(e\) To avoid obsolescence, a modular contract for information
technology 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 cancellation of
the solicitation in accordance with 14.209 or 15.206(e). To the maximum
extent practicable, deliveries under the contract should be scheduled to
occur within 18 months after issuance of the solicitation.

APPENDIX 4. Glossary

**Acquisition** means the acquiring by contract with appropriated funds
of supplies or services (including construction) by and for the use of
the federal government through purchase or lease, whether the supplies
or services are already in existence or must be created, developed,
demonstrated, and evaluated. Acquisition begins at the point when agency
needs are established and includes the description of requirements to
satisfy agency needs, solicitation and selection of sources, award of
contracts, contract financing, contract performance, contract
administration, and those technical and management functions directly
related to the process of fulfilling agency needs by contract.

**Contracting** means purchasing, renting, leasing, or otherwise
obtaining supplies or services from non-federal sources. Contracting
includes description (but not determination) of supplies and services
required, selection and solicitation of sources, preparation and award
of contracts, and all phases of contract administration. It does not
include making grants or cooperative agreements.

**Delivery Order Contract** means a contract for supplies that does not
procure or specify a firm quantity of supplies (other than a minimum or
maximum quantity) and that provides for the issuance of orders for the
delivery of supplies during the period of the contract.

**Earned Value** is a management technique that relates resource
planning to schedules and to technical performance requirements. Earned
value management (EVM) uses earned value as the tool for integrating
cost, schedule, and technical performance and risk management.

**Government-wide Acquisition Contracts** (GWACs) are contracts that
enable agencies (requesting agencies) that need information technology
products and services to obtain them from another federal agency
(servicing agency) that has entered into a contract:

\(a\) Before August 7, 1996, under a delegation of procurement authority
issued by the General Services Administration (GSA) under authority
granted to it by the Brooks Act, 40 U.S.C. 759, or

\(b\) After being designated as an executive agent for such by the
Office of Management and Budget (or otherwise covered by such
designation) pursuant to section 5112(e) of the Clinger-Cohen Act, 40
U.S.C. 1412(e). GWACs are subject to applicable Executive branch
policies and procedures. However, they are not subject to the
requirements and limitations of the Economy Act.

**Information Technology** means any equipment, or interconnected
system(s) or subsystem(s) of equipment, that is used in the automatic
acquisition, storage, manipulation, management, movement, control,
display, switching, interchange, transmission, or reception of data or
information by the agency.

\(a\) For purposes of this definition, equipment is used by an agency if
the equipment is used by the agency directly or is used by a contractor
under a contract with the agency which:

\(1\) Requires the use of such equipment, or

\(2\) Requires the use, to a significant extent, of such equipment in
the performance of a service or the furnishing of a product.

\(b\) The term "information technology" includes computers, ancillary
equipment, software, firmware, and similar procedures, services
(including support services), and related resources.

\(c\) The term "information technology" does not include:

\(1\) Any equipment that is acquired by a contractor incidental to a
contract, or

\(2\) Any equipment that contains embedded information technology that
is used as an integral part of the product, but the principal function
of which is not the acquisition, storage, manipulation, management,
movement, control, display, switching, interchange, transmission, or
reception of data or information. For example, HVAC (heating,
ventilation, and air conditioning) equipment, such as thermostats or
temperature control devices, and medical equipment for which information
technology is integral to its operation, are not information technology.

**Major Systems**, as defined by the Federal Acquisition Regulation
(FAR) 2.101 include:

-   Civilian Agency systems with total expenditures of more than
    \$750,000 (based on Fiscal Year (FY) 1980 constant dollars),

-   Department of Defense systems with total expenditures for research,
    development, test, and evaluation estimated to be more than
    \$115,000,000 (based on FY 1990 constant dollars) or an "eventual
    total expenditure for the acquisition" in excess of \$540,000,000
    (FY 1990 constant dollars), or

-   Any system designated a "major system" by the head of the Agency
    responsible for the system.

**Module:** A module is an economically and programmatically separable
segment that has a substantial programmatic use, even if no additional
segments are acquired.

**Modular Contracting:** Modular contracting is accomplished when an
"agency's need for a system is satisfied in successive acquisitions of
interoperable increments. Each increment complies with common or
commercially accepted standards applicable to IT so that the increments
are compatible with other increments of IT comprising the system."

**Multiagency Contracts** are ID/IQ contracts that enable agencies
(requesting agencies) that need products and services, including but not
limited to information technology services, to obtain them from another
federal agency (servicing agency) that also has a need for such services
and has awarded, or will be awarding, a contract for such services.
Multiagency contracts are subject to the requirements and limitations of
the Economy Act (except where more specific statutory authority exists)
and applicable Executive branch policies and procedures, including, for
information technology services, OMB Memorandum M-97-07 dated February
26, 1997.

**Task Order Contract** means a contract for services that does not
procure or specify a firm quantity of services (other than a minimum or
maximum quantity) and that provides for the issuance of orders for the
performance of tasks during the period of the contract.

APPENDIX 5. The Project Management Plan[^13]

I. OUTLINE

A project management plan (PMP) could include all or most of the
sections that follow. Tailoring is essential, and additional sections
should be added as appropriate.

**Section Title**

1\. Project Summary and Authorization

2\. Project Management

3\. System Engineering and Configuration Management

4\. Test and Evaluation

5\. Telecommunications

6\. Operations

7\. Facilities Engineering

8\. Logistics

9\. Manpower and Organization

10\. Personnel Training

11\. Application of Directives and Policy

II\. PREPARATION GUIDELINES

Project Summary and Authorization (Section 1)

This section briefly describes the requirements, the project, and the
management approach to be used to ensure that participating
organizations and management officials understand the key features of
the project. It also summarizes the background of the project and the
rationale for the approach being taken.

This section should also include a summary of or reference to the source
of project approval and the documents that establish project parameters,
identify resources, and otherwise govern the continued actions of
participating organizations.

Project Management (Section 2)

This section provides a more detailed description of the overall
management concept and approach used to meet the requirements of the
project. The management methods should ensure sufficient visibility to
allow for continuous assessment of project progress and technical
performance, including schedule and costs. This section should include
the following major subsections:

1\. **Project Manager's Charter.** This subsection summarizes the
manager's authority, responsibility, and accountability as established
in the formal charter issued by the sponsoring authority. Typically, the
following items covered in the charter should be summarized here:

-   Name of the project manager

-   Reporting channels

-   Project manager's authority

-   Interfaces and other agencies involved in the project

-   Support to be provided to the project manager

-   Peculiar relationships not covered by existing policy or procedure

-   Special instructions

-   Special reporting requirements

-   Structure of the project management office and project management
    organization

-   Conditions under which the project manager will transfer
    responsibility to the operational staff

2\. **Performance**. This subsection develops a management approach that
provides for continuous assessment of project accomplishments in
relation to the stated requirements.

3\. **Schedules**. Participating organizations should assist in
preparing a master schedule or major milestones, key events, and any
critical actions essential to timely execution of the project. Detailed
schedules should also be included in this subsection, such as:

-   Master Project/Overall Milestone Schedule

-   Acquisition and Development Schedules

-   Facilities and Site Activation Schedules

-   Test Schedules

-   Training Schedules

-   Any other specialized schedules

> The project manager should ensure that the scheduled activities of
> participating organizations are compatible and consistent with the
> project schedules, and that the schedules are refined and updated as
> the project proceeds.

4\. **Interrelationships**. This subsection defines the responsibilities
and interrelationships of organizations that provide major support to
the project. Reference should be made to written agreements with
participating organizations. The use of any independent assessment teams
or contractor-selected key milestones in the project should be
described.

5\. **Reporting Requirements**. This subsection identifies the reports
(especially milestone reports) needed to meet the requirements of higher
management and other participating organizations. It also indicates the
requirements for contractor reporting.

6\. **Financial**. This subsection summarizes the total cost of the
project, including the costs of acquisition, logistic support, related
construction, and user operation. The project manager is responsible for
the overall development, collection, analysis, and presentation of
financial data for the program management plan. The participating and
support organizations are the source of financial estimates for their
areas of responsibility, and they normally furnish the project
management office with cost data and information on the methods,
techniques, and factors used in developing their estimates.

7\. **Acquisition**. This subsection includes a description of the
resources to be contractually acquired and a summary of the project's
acquisition strategy, types of contracts, and major contractual features
that may be required.

System Engineering and Configuration Management (Section 3)

This section describes the system engineering and configuration
management approaches to be used throughout the life of the project.

1\. **System Engineering Management**. This subsection describes the
effort for defining the preferred system design, the
engineering/technical management approach, and the integration of
engineering disciplines. It includes summaries or plans for risk
reduction, technical reviews, and studies and analyses; particularly
life cycle cost analyses, if appropriate. System engineering resources
and organizational responsibilities should be identified.

2\. **Configuration Management**. This subsection describes the
configuration management approach, including those management tools to
be used to apply the fundamental principles of configuration management
(identification of configuration items, change control, and status
accounting). Organizational responsibilities for configuration
management and preparation of the configuration management plan should
be addressed.

Test and Evaluation (Section 4)

This section describes the test management concept, including the
organizational structure and responsibilities. All participating
organizations should be identified, as well as critical issues and areas
of risk, and specific test objectives and strategies.

Telecommunications (Section 5)

This section should identify telecommunications support requirements
individually for the following items:

-   Project Management (any special communications requirements of the
    project manager/ project management office)

-   Development and Testing

-   Deployment and Operations

-   Privacy and security issues

Operations (Section 6)

This section should incorporate inputs from the operating organization
and expand the operational concept for the use of the system or
equipment as further formulated during the project life cycle. It should
include information on the operational use of the system, as
appropriate, including the following elements:

-   Deployment and operations

-   Training

-   Conversion and phase-out

-   Maintenance (system and hardware)

-   Documentation

-   Logistics support

Facilities Engineering (Section 7)

Where appropriate, this section includes or refers to a master plan
prepared for each installation or sub-installation that outlines the
proposed site development for the total facilities required. This
section describes the management of responsibilities and procedures for
programming, design, modification, construction, and maintenance and
acceptance of real property facilities.

Logistics (Section 8)

This section requires inputs from the responsible logistics
organizations and other participating agencies. It should provide a
comprehensive description of the tailored logistics concepts for the
project, including provision for maintenance of equipment, spare parts,
and operating supplies.

Manpower and Organization (Section 9)

This section describes the organization and staffing of the project
office and summarizes the relationships and roles of the other
organizations involved in the acquisition project. It should reference
any formal agreements with participating organizations and the extent
and characteristics of matrix tasking and relationships.

Personnel Training (Section 10)

This section requires inputs from the operating and training
organizations. It summarizes the personnel training required for system
testing, deployment, operations, and support, and it should
cross-reference other sections to reflect related actions where
appropriate. It should also include the following items:

-   Requirements for trained personnel for the system/equipment in terms
    of numbers and skills

-   Types, location, and key dates of individual training courses,
    emphasizing early planning for training courses

-   Required training equipment

-   Major training facility requirements

Application of Directives and Policy (Section 11)

This section describes the policy and directives that apply, wholly or
in part, to the project and to which all participants must adhere or
which they must observe. There are many directives that may require
action by the project office in managing a project. The project manager
is responsible for determining and enforcing directives that apply to a
particular project, as well as for requesting waivers for directives
that will not be enforced, even though they may be required. Before
approving the project management plan, the project manager should ensure
that any requests for necessary waivers are submitted to the appropriate
authority.

Summary

The project management plan is a living document that is intended to:

-   Explain the management approach selected for the project.

-   Identify the activities, strategies, schedules, and resources for
    the project effort.

-   Serve as the single baseline management document used by all
    participating organizations and outside parties to establish project
    objectives, assign responsibilities, define tasks, and publish
    schedules.

-   Be revised throughout the life of the project to reflect the
    project's current status and the latest plan and resource
    information. Major revisions and updates are usually associated with
    milestone reviews.[^14]

APPENDIX 6. Contacts for More Information

GSA IT Policy web site - Modular Contracting

<http://www.itpolicy.gsa.gov/mks/moddir/modtoc.htm>

Software Engineering Institute's Software Capability Maturity Model

<http://www.sei.cmu.edu/technology/cmm.html>

*Practical Software Management, A Guide to Objective Program Insight,*
sponsored by the Joint Logistics Commanders, Joint Group on Systems
Engineering (JLC-JGSE),

[http://www.cards.com.psm](http://www.cards.com.psm/)

Software Engineering Institute's *Software Measurement for DOD Systems:
Recommendations for Initial Core Measures* (Technical Report
CMU/SEI-92-TR-19

[http://www.sei.cmu.edu](http://www.sei.cmu.edu/)

Department of the Air Force, Software Technology Support Center's
*Guidelines for Successful Acquisition and Management of Software
Intensive Systems V2.0*

<http://stsc.hill.af.mil/stscdocs.html>

CROSSTALK. "The Journal of Defense Software Engineering"

<http://stsc.hill.af.mil/CrossTalk/crostalk.html>

Integrated Product Teams

<http://www.dsmc.dsm.mil/jdam/contents/ipt.htm>

The Canadian Plan: Common Purpose Procurement Framework

<http://www.itpolicy.gsa.gov/mks/whitepr/cppfrpt.htm>

Robbins-Gioia, Inc., 11 Canal Center Plaza, Alexandria, VA 22314,

\(703\) 548-7006

[^1]: "Computer Chaos: Billions Wasted Buying Federal Computer Systems,"
    an investigative report by Senator William S. Cohen, Subcommittee On
    Oversight of Government Management, Senate Governmental Affairs
    Committee, October 1994.

[^2]: "Report of Information Technology Working Group, Roger Johnson,
    Administrator of GSA and John A. Koskien, Deputy Director for
    Management of OMB, May 7, 1995.

[^3]: Congressional Record, June 20, 1995, pg. S8686.

[^4]: The ITMRA of 1996 was passed by Congress and signed into law as
    Division E of the National Defense Authorization Act of 1996 (P.L.
    104-106).^?^ It was later re-titled as the Clinger-Cohen Act.

[^5]: Congressional Record, June 20, 1995, pg S8686.

[^6]: Named for past OMB Director Franklin D. Raines.

[^7]: Burnstein, I., T. Suwannasart, and C. R. Carlson, "Developing a
    Testing Maturity Model: Part I," Crosstalk, STSC, Hill Air Force
    Base, Utah, August 1996.

[^8]: Gelperin, D. and B. Hetzel, "The Growth of Software Testing,"
    CACM, Vol. 31, No. 6, 1988, pp. 687-695 as set forth by Burnstein,
    I., T. Suwannasart, and C. R. Carlson, "Developing a Testing
    Maturity Model: Part II," Crosstalk, STSC, Hill Air Force Base,
    Utah, 1996.

[^9]: General Accounting Office, "Major Acquisitions-Significant Changes
    Underway in DOD's Earned Value Management Process", May 1997.

[^10]: Fleming, Quentin W. and Joel M. Koppelman, "Earned Value Project
    Management", Project Management Institute, 1996 as cited by Rita Le,
    "Earned Value," July 98.

[^11]: OMB Memorandum, "Information Technology Architectures," June 18,
    1997.

[^12]: The Federal Conceptual Model Subgroup for the CIO Council, "The
    Federal Enterprise Architecture Conceptual Framework - Draft",
    August 1998.

[^13]: ^^ Copyright 1996 Robbins-Gioia, Inc., 11 Canal Center Plaza,
    Alexandria, VA 22314 (Used With Permission)

[^14]: ^^ Copyright 1996 Robbins-Gioia, Inc., 11 Canal Center Plaza,
    Alexandria, VA 22314 (Used With Permission)