-----------------------------------------------------------------------
  **Module Title**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image1.wmf){width="3.9506944444444443in"   Slide \# 3-1
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

**Module 3: Basics of Contracting**

**Module Outline**

  ------------------------------------------------- --------- ---------------------
  Topic                                                       Time Frame

  Introduction/Objectives                           10        
                                                    minutes   

  Acquisition of Resources                          60        
                                                    minutes   

  Acquisition Planning                              60        
                                                    minutes   

  Contraction Administration                        90        
                                                    minutes   

  Review                                            15        
                                                    minutes   

  **Estimated/Approximate Time for Module           **4       
  Completion**                                      hours**   
  ------------------------------------------------- --------- ---------------------

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image2.wmf){width="3.9506944444444443in"   Slide \# 3-2
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This module will discuss recognition of the supervision, leadership   |
| and management processes/procedures involving the acquisition of      |
| supplies and services, construction, research and development.        |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives (continued)**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image4.wmf){width="3.9506944444444443in"   Slide \# 3-3
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Briefly review the module agenda by introducing the topics that will  |
| be covered. Topics include:                                           |
|                                                                       |
| -   Topic 2: Acquisition of Resources                                 |
|                                                                       |
| -   Topic 3: Acquisition Planning                                     |
|                                                                       |
| -   Topic 4: Contract Management                                      |
|                                                                       |
| -   Topic 5: Review                                                   |
|                                                                       |
| As you will see, each of these topics addresses a key aspect (or      |
| aspects) of the learning objectives for this module which we will     |
| review next.                                                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives (continued)**
  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image6.wmf){width="3.9506944444444443in"   Slide \# 3-4
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6916666666666667in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| [Objectives]{.underline}                                              |
|                                                                       |
| At the end of this module, you will be able to:                       |
|                                                                       |
| -   Describe the program manager's role in ensuring appropriate       |
|     recognition of processes/procedures in acquisition functions.     |
|                                                                       |
| -   Using a program case study, determine the applicable acquisition  |
|     planning tasks for all phases of contract management, and apply   |
|     the appropriate standard of management.                           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 1: Introduction/Objectives (continued)**
  -----------------------------------------------------------------------

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on the introduction and objectives After     |
| addressing any questions the participants may have, inform them that  |
| we will be moving on to the next topic: Acquisition of Resources      |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image7.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  the introduction and objectives?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image8.wmf){width="3.9506944444444443in"   Slide \# 3-5
  height="2.9680555555555554in"}                       

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The acquisition strategy for a program results from extensive         |
| planning and preparation and a thorough understanding of both the     |
| specific acquisition program and the general agency acquisition       |
| environment.                                                          |
|                                                                       |
| When developing the acquisition strategy, the program manager and     |
| supporting team members should keep in mind their total systems       |
| responsibility.                                                       |
|                                                                       |
| As such, and consistent with statute and regulation, the program      |
| manager must tailor the program planning and required information to  |
| the specific program needs.                                           |
|                                                                       |
| Additionally, the needs of the decision makers who will coordinate or |
| approve the strategy should guide the preparation of the acquisition  |
| strategy.                                                             |
|                                                                       |
| These program needs and decision maker needs will influence the       |
| identification and acquisition of resources.                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| This module and its topics will address management of contracting     |
| elements that are critical to successful acquisitions.                |
|                                                                       |
| Ask the following question to get participants thinking about         |
| acquisition strategy from a broader management perspective.           |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**True or False. The acquisition        |
| strategy defines the management approach that will achieve program    |
| goals.**                                                              |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| True                                                                  |
|                                                                       |
| The Acquisition Strategy defines the management approach that will    |
| achieve program goals. It fully describes the planning considerations |
| and decisions that affect the acquisition of resources necessary for  |
| the program and its contract requirements.                            |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| -   The acquisition strategy defines the approach the program will    |
|     use to achieve full capability: either evolutionary or single     |
|     step. It will include a brief rationale to justify the choice.    |
|                                                                       |
| -   The acquisition strategy will further address the estimated       |
|     program cost and the planned program funding, including funding   |
|     under an evolutionary acquisition strategy and advance            |
|     procurement.                                                      |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following questions to generate a discussion about            |
| evloutionary acquisition strategy and corresponding concepts.         |
|                                                                       |
| Use the follow-up questions to continue the discussion about programs |
| where a single-step acquisition strategy would most likely be used    |
| versus an evolutionary acquisition strategy.                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What is the evolutionary acqusition   |
| approach?**                                                           |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Evolutionary acquisition is an approach that delivers capability in   |
| increments, recognizing, up front, the need for future capability     |
| improvements.                                                         |
|                                                                       |
| **Note:** *This approach is sometimes referred to as incremental      |
| acquisition.*                                                         |
|                                                                       |
| The objective is to balance needs and available capability with       |
| resources, and to put capability into the hands of the user quickly.  |
|                                                                       |
| The success of the strategy depends on consistent and continuous      |
| definition of requirements, and the maturation of technologies that   |
| lead to disciplined development and production of systems that        |
| provide increasing capability towards a material concept.             |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What sorts of programs would most     |
| likely use an evolutionary acquisition approach?**                    |
|                                                                       |
| **Why?**                                                              |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| The evolutionary approach is well suited to situations where the much |
| is known about the basic requirements and a limited risk exists in    |
| meeting them but expectations exist that additional related           |
| requirements will arrive in the future                                |
|                                                                       |
| For example, "Build an automated machine translation device for       |
| Persian language; if successful expect to build similar devices for   |
| other languages such as Kurdish."                                     |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What sorts of programs would most     |
| likely use a single step acquisition strategy approach?**             |
|                                                                       |
| **Why?**                                                              |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Single step acquisition (also known as "waterfall") is most suited to |
| situations where the requirements are well understood and well        |
| documented and where a relatively low level of risk exists with       |
| respect to major requirement changes.                                 |
|                                                                       |
| It is also well suited to situations where the program manager has a  |
| limited amount of experience with the more complicated to manage      |
| incremental and agile methodologies.                                  |
|                                                                       |
| For example, "Build a bridge across the river."                       |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The choice of an acquisition strategy has a very powerful impact on   |
| the success of a project. Shorter and smaller projects succeed more   |
| often than longer and larger projects. So size does matter!           |
|                                                                       |
| Let's discuss the "Three Pillars of Success".                         |
|                                                                       |
| The Standish Group (the authors of the CHAOS reports) believes three  |
| key metrics can assess a project\'s success potential: project size,  |
| project duration, and team size.                                      |
|                                                                       |
| As project costs rise, typically through the addition of features and |
| functions that are rarely or never used, the likelihood of success    |
| falls.                                                                |
|                                                                       |
| One school of thought would argue that larger projects with more      |
| funding and resources should be more successful and should produce    |
| more function.                                                        |
|                                                                       |
| Instead, the reverse appears to be true. Smaller projects tend to be  |
| more manageable.                                                      |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Project Duration and Team Size.                                       |
|                                                                       |
| The smaller the team and shorter the duration of the project, the     |
| greater the likelihood of success.                                    |
|                                                                       |
| Obviously, this does not suggest that compressing the schedule and    |
| reducing the resources of a large project will make it successful.    |
|                                                                       |
| Nor should it be construed that large projects with large teams       |
| cannot be successful. Standish believes that any project can be       |
| successful if all the key criteria are met.                           |
|                                                                       |
| Small is beautiful. Projects costing less than \$750,000 are more     |
| successful than any other.                                            |
|                                                                       |
| Project managers should realize at the outset that the more expensive |
| a project becomes, the less likely its chance of success.             |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image9.jpeg){width="4.009722222222222in"   Slide \# 3-6
  height="3.0125in"}                                   

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| We have long been convinced that shorter time frames, with delivery   |
| of software components early and often, increase the success rate.    |
|                                                                       |
| Shorter time frames foster an iterative process of design, prototype, |
| develop, test, and deploy small elements.                             |
|                                                                       |
| \"Growing\" (instead of \"developing\") software engages the user     |
| earlier and confers ownership. And because each software component    |
| has a clear and precise statement and set of objectives, realistic    |
| user expectations are set.                                            |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Once the acquisition strategy is identified, certain key decisions    |
| will have to be made about how the government agency selects the      |
| contractor or "source." The acquisition strategy will provide a       |
| source design option ranging from:                                    |
|                                                                       |
| -   Sole-source procurement -- government negotiates with only one    |
|     contractor                                                        |
|                                                                       |
| -   Limited competition -- government solicits bids from a            |
|     prequalified list of firms or invites some limited group of firms |
|     to bid on an ad hoc basis                                         |
|                                                                       |
| -   Full and open competition -- any firm is entitled to bid and have |
|     its bid fairly evaluated                                          |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Within a competitive source design, the government may choose the     |
| bidder:                                                               |
|                                                                       |
| -   Who complies with all contract requirements and bids the lowest   |
|     price, traditionally called "low bid" or                          |
|                                                                       |
| -   Who provides the best trade-off between price and various         |
|     quality-related factors, traditionally called \"best value\"      |
|     source selection.                                                 |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to generate a discussion about best value  |
| source selection.                                                     |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**Is the lowest priced procurement      |
| always the best value selection?**                                    |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Some contracting professionals refer only to low-price procurements   |
| as \"competitive,\" but, in fact, there are a number of possible      |
| source selection alternatives that are all fully competitive and      |
| could be considered a best value source selection.                    |
|                                                                       |
| The program manager must consider the source that best meets all the  |
| acquisition strategy design options.                                  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image10.png) **Activity:**                                  |
|                                                                       |
| Activity Purpose:                                                     |
|                                                                       |
| This activity provides participants with an opportunity to identify   |
| which acquisition strategy the program manager would utilize for the  |
| VCF business case.                                                    |
|                                                                       |
| (*This module activity continues the business case that will be used  |
| throughout this course to apply various concepts and reinforce        |
| learning through the use of critical thinking and application         |
| skills.*)                                                             |
|                                                                       |
| Activity Length: 30 minutes                                           |
|                                                                       |
| Activity Instructions:                                                |
|                                                                       |
| a.  Allow participants 5 - 10 minutes to individually review the *VCF |
|     Acquisition Program Management Business Case* found in their      |
|     Participant Guide and on the following page of this Instructor    |
|     Guide. Participants should read the content and answer the        |
|     following questions about the business case:                      |
|                                                                       |
|     a.  Identify whether a single-step or evolutionary program        |
|         approach is best for this program?                            |
|                                                                       |
|     b.  Why (or why not)?                                             |
|                                                                       |
| b.  Pose each of the questions asked to the whole group, and allow    |
|     individuals to answer on a volunteer basis.                       |
|                                                                       |
| c.  Use the answers given to generate a large group discussion to     |
|     elicit other opinions about the question. There may be more than  |
|     one correct answer or viewpoint for each question. **Note:**      |
|     *Relevant answers for each question are found on the following    |
|     page of this Instructor Guide.*                                   |
|                                                                       |
| d.  After all the questions have been discussed, summarize the        |
|     activity by telling participants that the evolutionary            |
|     acquisition strategy would be the most likely choice for this     |
|     program.                                                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

**The Virtual Case File (VCF)**

[September 2001: Inadequate System Exposed; the Virtual Case File is
Born]{.underline}

On 4 September 2001, Robert S. Mueller III became the tenth director in
FBI history. One week later, terrorists pulverized New York City\'s
World Trade Center and a piece of the Pentagon. The inability of FBI
agents to share the most basic information about Al Qaeda\'s U.S.
activities blew up into a front-page scandal. Within days, the FBI\'s
pathetic technology infrastructure went from being so much arcane trivia
to a subject of daily fulmination by politicians and newspaper
columnists. In the face of intense public and congressional pressure,
Mueller shifted Trilogy into high gear.

Recognizing the limitations of the new web interface feature of Trilogy
and ACS, Robert J. Chiaradio the FBI\'s executive assistant director for
administration decided that the Bureau needed an entirely new database,
graphical user interface, and applications, which would let agents
search across various investigations to find relationships to their own
cases. The new case management system would host millions of records
containing information on everything from witnesses, suspects, and
informants to evidence such as documents, photos, and audio recordings.
To address concerns being raised by intelligence experts and lawmakers
in the wake of 9/11, these records would be accessible to both the
FBI\'s agents and its intelligence analysts. The new system was dubbed
the Virtual Case File.

With no detailed description of the FBI\'s processes and IT
infrastructure to go by (i.e., an enterprise architecture), a team of
FBI agents led by Larry Depew began to characterize investigative
processes such as witness interviews and surveillance operations and map
them to the FBI\'s software and databases. Depew, a veteran Special
Agent from the Trenton, New Jersey office, was a self taught database
programmer. Over a six-week period in the fall of 2001, the group
defined how agents worked, how they gathered information, and how that
information was fed into ACS. Working with engineers from SAIC, they
drew up diagrams and flowcharts of how the case management system
operated then and how they wanted the new case management system, the
VCF, to operate in the future.

\[1\]

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[December 2001: Contract Changes and an Accelerated
Schedule]{.underline}

In December 2001, the FBI asked SAIC to stop building a Web front end
for the old programs. Instead, SAIC was asked to devise a new
application, database, and graphical user interface to completely
replace ACS.

To formally define what users needed the VCF to do for them, SAIC
embarked on a series of Joint Application Development (JAD) sessions. In
these meetings, the FBI's team of agents and experts got together with a
group of SAIC engineers to hash out what functions the VCF would
perform. Ideas captured in these sessions formed the basis of the
requirements document that guided SAIC\'s application designers and
programmers.

In January 2002, the FBI requested an additional \$70 million to
accelerate Trilogy; Congress went further, approving \$78 million.
DynCorp committed to delivering its two components by July 2002. SAIC
agreed to deliver the initial version of the VCF in December 2003
instead of June 2004.

SAIC and the FBI were now committed to creating an entirely new case
management system in 22 months. While the Trilogy contracts were changed
to reflect the aggressive new deadlines, neither the original software
contract nor the modified one specified any formal criteria for the FBI
to use to accept or reject the finished VCF software. Furthermore, those
contracts specified no formal project schedules at all, let alone
milestones that SAIC and DynCorp were contractually obligated to meet on
the way to final delivery.

In reaction to the new deadline, SAIC broke its VCF development group
into eight teams, working in parallel on different functional pieces of
the program. The eight threads would later prove difficult for SAIC to
combine into a single system. Nevertheless, Rick Reynolds, vice
president and operations manager for SAIC, defended the decision to
change tactics. \"People forget the urgency that we were under and our
customer was under. And we were right beside them,\" he declared. \"We
were in the foxhole together.\"

[March 2002: Defining Requirements]{.underline}

Over a six-month period, the JAD team met in two-week sessions. After a
two-week JAD session finished, a two-week feedback cycle would begin.
SAIC provided Depew\'s team with information gleaned from the session,
including needs statements, flow charts, and meeting minutes. Depew\'s
team reviewed these materials and gave SAIC feedback while
simultaneously preparing subject matter experts for the next round of
JAD sessions, which immediately followed the feedback cycle. There were
no breaks.

\[2\]

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

Mueller, Dies, and Chiaradio recruited C.Z. (\"Sherry\") Higgins, a
seasoned IT program manager with experience at Lucent and AT&T, to be
the FBI's new project management executive for the Office of the
Director. The new Office of Program Management would centralize IT
management and oversee, develop, and deploy the bureau\'s most
expensive, complex, and risky projects. But her most important
assignment was to manage Trilogy. Her first move when she came on board
in March 2002 was to appoint Depew, who had no IT project management
experience, the VCF project manager.

[April 2002: Schedules Start to Slip]{.underline}

In mid-April 2002, Higgins, demanded a detailed schedule from DynCorp.
After she got it, she pulled the project teams from the FBI and DynCorp
into a meeting and went through the document. Shortly after that,
Higgins broke the news to the director: the computers and networks would
not be delivered in July of that year as had been scheduled. She told
Mueller that DynCorp didn\'t stand a chance of hitting the delivery
target, because it didn\'t have a detailed schedule that mapped out how
it would deploy, integrate, and test the new computers and networks.

[July 2002: VCF Looked Good on Paper]{.underline}

The JAD sessions had produced an exhaustively detailed requirements
document. This plan for a case-management system would combine the ACS
with two other systems: the Telephone Application, the bureau\'s central
repository of telephone records related to investigations, and parts of
the Criminal Law Enforcement Application, a repository for investigative
data about people, organizations, locations, vehicles, and
communications.

The VCF system would accept scanned documents, photographs, and other
electronic media---to simplify evidence tracking. People with the proper
credentials would be able to access that evidence from any FBI office.
The way work flowed through the bureau would change dramatically, too.
Instead of filling out a form either by hand or in a word-processing
program and then faxing or FedEx-ing the paper form to a supervisor, an
agent would fill out a form online and, with a click of the mouse, route
it to the supervisor. The document would pop up in a supervisor\'s
in-box, and the agent could track it to see if it had been approved. And
perhaps most important, information collected within a case file would
eventually be available to software applications that would compare data
among cases to search for correlations---to connect the proverbial dots.

\[3\]

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[Summer 2002: Detailed Requirements]{.underline}

By August 2002 SAIC had around 200 programmers on the job. Matthew
Patton joined the SAIC team as a security engineer. Patton, who was
later removed from the project after criticizing its management in an
Internet posting, was unimpressed by the 800-plus pages of requirements.
\"In a requirements document, you want to dictate the whats, not the
hows,\" Patton said. \"We need an e-mail system that can do x, and
there\'s 12 bullets. Instead, we had things like \'there will be a page
with a button that says e-mail on it.\' We want our button here on the
page or we want it that color. We want a logo on the front page that
looks like x. We want certain things on the left-hand side of the page.
They were trying to design the system layout and then the whole
application logic before they had actually even figured out what they
wanted the system to do.\"

The overly specific nature of the requirements focused developers on
their tiny piece of the puzzle. They were writing code, Patton said,
with no idea of how their piece fit with the others. This presaged the
integration problems that would later plague the project.

Patton also claimed that SAIC was determined to write much of the VCF
from scratch. This included an e-mail-like system that at least one
team, to his knowledge, was writing, even though the FBI was already
using an off-the-shelf software package, Novell\'s GroupWise, for
e-mail.

[December 2002: The March of the Change Requests]{.underline}

In December 2002, Higgins asked lawmakers to invest an additional
\$137.9 million in Trilogy. Congress approved another \$123.2 million
for a project whose total cost had now ballooned to \$581 million.

After the FBI and SAIC agreed to the baseline set of requirements, SAIC
programmers began cranking out code. The company had settled on a spiral
development methodology, an iterative approach to writing software.
Basically, SAIC programmers would write and compile a block of code that
performed a particular function, then run it to show Depew\'s agents
what it would do. The agents gave the programmers feedback, and the
programmers tried to incorporate the suggested changes. Sometimes
Depew\'s team had only two days to review a batch of code. Agents would
pull all-nighters to get the evaluation finished, \"and in the next
iteration their comments wouldn\'t be taken into account,\" Higgins
said. Sometimes, she acknowledged, these evaluations would include
changes to the requirements---functions that the agents had decided that
they needed once they saw what they were going to get. Other times the
FBI team would find bugs that needed to be fixed.

\[4\]

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

If there was a dispute as to whether the change could or should be made,
the agents sent an official request to the change control board,
composed of SAIC engineers and FBI personnel, for review. It wasn\'t
long before the change requests started rolling in---roughly 400 from
December 2002 to December 2003, according to SAIC.

\"Once they saw the product of the code we wrote, then they would say,
\'Oh, we\'ve got to change this. That isn\'t what I meant,\'\" said
SAIC\'s Reynolds. \"And that\'s when we started logging change request
after change request after change request.\" Reynolds added that SAIC\'s
bid on the original contract, and each subsequently revised cost
estimate, was based on there being \"minimal, minor changes\" to the
program once a baseline set of requirements had been agreed on.

Some of the changes were cosmetic---move a button from one part of the
screen to another, for instance. Others required the programmers to add
a new function to a part of the program, such as the graphical user
interface, common to all eight development threads.

[March 2003: The Network is Delayed]{.underline}

In March 2003, Computer Sciences Corp., which had acquired DynCorp that
month, told Higgins that the final deployment of the computers and
networks would be delayed until October. In August, October became
December. And in October, December became April 2004. The problem
wasn\'t the PCs, which had been trickling in since 2001, but changing
the e-mail system from Novell\'s GroupWise to Microsoft Outlook and,
obtaining the components needed to connect the field offices to the wide
area network. Higgins added that the delays were compounded by the
FBI\'s own sloppy inventories of existing networks and its
underestimation of how taxing the network traffic would be once all
22,000 users came online using their new PCs.

While the FBI and SAIC waited for the networks to go live so they could
test the VCF on a real system, changes and fixes continued. Many of the
changes had to be to be made by all eight of SAIC\'s development teams.
Arnold Punaro, SAIC executive vice president and general manager,
admitted in a posting on the company\'s Web site that in the rush to get
the program finished by December, SAIC didn\'t ensure that all of its
programmers were making the changes the same way. That inconsistency
occasionally meant that different modules of the VCF handled data in
different ways. Consequently, when one module needed to communicate with
another, errors sometimes occurred.

\"This, however, did not compromise the system,\" according to Punaro.
The real killers, he said, were \"significant management turbulence\" at
the FBI, \"the ever-shifting nature of the requirements,\" and the
agents\' \"trial-and-error, \'We will know it when we see it\' approach
to development.\"

\[5\]

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[September 2003: Testing Begins]{.underline}

SAIC began testing the program in the fall of 2003, and problems started
cropping up, some of which the agents had warned SAIC about over the
previous summer. SAIC officials complained to Higgins that Computer
Sciences Corp. didn\'t have its hardware and network in place, so SAIC
couldn\'t adequately test the VCF, crucial for a successful flash
cutover. They informed her that they would deliver a version of the VCF
to be in technical compliance with the terms of the contract and that
the FBI should feel free to make changes to it afterward.

[December 2003: VCF Delivery and Failure]{.underline}

On 13 December 2003, SAIC delivered the VCF to the FBI. Under the
direction of the FBI's new interim CIO, Zalmai Azmi, the FBI rejected
SAIC\'s delivery. The bureau found 17 \"functional deficiencies\" it
wanted SAIC to fix before the system was deployed. SAIC argued that at
least some of these deficiencies were changes in requirements. An
arbitrator was called in. The arbitrator found fault with both SAIC and
the FBI. Of the 59 issues and subissues derived from the original 17
deficiencies, the arbitrator found that 19 were requirements
changes---the FBI\'s fault; the other 40 were SAIC\'s errors.

While SAIC fixed bugs, Azmi, with the help of Depew\'s team, created
investigation scenarios that would take different cases from opening to
closing and tested them on the VCF. Those tests revealed an additional
400 deficiencies. \"We have requirements that are not in the final
product, yet we have capabilities in the final product that we don\'t
have requirements for,\" said Azmi.

At the same time Computer Sciences Corp was delivering the final pieces
of equipment to the FBI. By April, 22,251 computer workstations, 3408
printers, 1463 scanners, 475 servers, and new local and wide area
networks would all be up and running, 22 months later than the
accelerated schedule called for.

Azmi and SAIC had yet to agree on the VCF\'s ultimate fate, much less
when it would be deployed. Azmi rejected SAIC's proposal to take one
more year to make all the changes the FBI wanted at the cost of an
additional \$56 million.

[June 2003: Trying to Salvage Something from VCF:]{.underline}

Azmi asked SAIC to take the electronic workflow portion of the VCF, code
that was in relatively good shape, and turn that into what was
eventually called the Initial Operating Capability (IOC), at an
additional fixed price to the FBI of \$16.4 million. SAIC and the FBI
project team had six months to deliver a software package that would be
deployed to between 250 and 500 field personnel in Louisiana and at the
Hoover Building.

\[6\]

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

The objectives for the new project were clear: test-drive the VCF\'s
electronic workflow; see how people reacted to the graphical user
interface; create a way to translate the output from the VCF forms, into
the ACS system; check out network performance; and develop a training
program. The IOC would use Azmi\'s rigorous approach to software
development and project management, which he called the Life Cycle
Management Directive.

[June 2004: SAIC Begins the IOC Project]{.underline}

With new management in place, about 120 SAIC engineers began work on the
IOC project. The FBI and SAIC agreed to keep to a strict development
schedule, define acceptance criteria, and institute a series of control
gates. Azmi\'s project manager worked closely with his SAIC counterpart
to adhere to the baseline requirements SAIC and the FBI had agreed on
for the IOC in July, thus avoiding a death spiral of change requests. In
January, the IOC was rolled out as a pilot right on schedule.

[March 2005: IOC Pilot Fails]{.underline}

The IOC pilot ended in March. The verdict: \"Although the IOC
application was an aid to task management, its use did not improve the
productivity of most users,\" according to an internal FBI assessment.
FBI employees, particularly agents, found that the IOC actually
increased their workload. Agents filled out forms electronically and
routed them to superiors for approval, after which the electronic form
was uploaded to the ACS, still in use, to be shared with the rest of the
FBI. But to comply with the FBI\'s paper-based records management
system, the form had to be printed out, routed, signed, and filed.

[May 2005: Sentinel Rises from the Ashes of VCF]{.underline}

In May 2005 Mueller announced Sentinel, a four-phase, four-year project
intended to do the VCF\'s job and provide the bureau with a Web-based
case- and records-management system that incorporates commercial
off-the-shelf software.

[March 2006: Sentinel goes to Contract]{.underline}

The FBI awarded a \$305M contract to Lockheed Martin for Sentinel. Total
program cost is estimated to be \$425M.

[June 2007: Sentinel's First Deployment]{.underline}

The FBI and Lockheed Martin rolled out Phase 1 Sentinel capabilities to
the FBI workforce. According to a press release from the FBI phase 1
includes a "Personal Workbox, which summarizes a user's cases and
leads....and user-friendly search capabilities." Azmi announces his
intent to use agile development to deliver new capability to the desktop
every six to nine months.

\[7\]

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image11.png)**Activity (continued)**                        |
|                                                                       |
| **Key Findings**                                                      |
|                                                                       |
| a.  Identify whether a single-step or evolutionary program approach   |
|     is best for this program?                                         |
|                                                                       |
| > The VCF is a classic example of a project failure caused in large   |
| > part by scope changes and creep within a single-step (waterfall)    |
| > program life cycle. A most effective approach for success in this   |
| > type of environment is to use an evolutionary (or iterative)        |
| > program approach. The Standish Group (and many others) have shown   |
| > that small/shorter projects succeed more often.                     |
| >                                                                     |
| > The VCF single-step occurred in September 2001 when "they drew up   |
| > diagrams and flowcharts of how the case management system operated  |
| > then and how they wanted the new case management system, the VCF,   |
| > to operate in the future" and then proceeded to head straight for   |
| > the end goal by devising "a new application, database, and          |
| > graphical user interface to completely replace ACS."                |
| >                                                                     |
| > It continued in December 2002 in spite of the use of an             |
| > evolutionary development approach. "SAIC programmers began cranking |
| > out code. The company had settled on a spiral development           |
| > methodology, an iterative approach to writing software. Basically,  |
| > SAIC programmers would write and compile a block of code that       |
| > performed a particular function, then run it to show Depew\'s       |
| > agents what it would do. The agents gave the programmers feedback,  |
| > and the programmers tried to incorporate the suggested changes.     |
| > Sometimes Depew\'s team had only two days to review a batch of      |
| > code. Agents would pull all-nighters to get the evaluation          |
| > finished, \"and in the next iteration their comments wouldn\'t be   |
| > taken into account,\" Higgins said. Sometimes, she acknowledged,    |
| > these evaluations would include changes to the                      |
| > requirements---functions that the agents had decided that they      |
| > needed once they saw what they were going to get. Other times the   |
| > FBI team would find bugs that needed to be fixed."                  |
| >                                                                     |
| > Note that in June 2007 the Sentinel project adopts the evolutionaly |
| > approach when "Azmi announces his intent to use agile development   |
| > to deliver new capability to the desktop every six to nine months." |
| >                                                                     |
| > A key point demonstrated by the VCF case is the important           |
| > difference between the program approach and the development         |
| > approach. VCF followed a single-step program approach (that failed) |
| > and it followed an evolutionary development approach.               |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image12.png)**Activity (continued)**                        |
|                                                                       |
| **Key Findings (continued)**                                          |
|                                                                       |
| b.  Why (or why not)?                                                 |
|                                                                       |
| > Risk, complexity, uncertainty, and change were dominant             |
| > characheristics of the VCF case. In December 2001 "SAIC and the FBI |
| > were now committed to creating an entirely new case management      |
| > system in 22 months." This single-step approach resulted in         |
| > multiple delays beginning in March 2003.                            |
| >                                                                     |
| > "In March 2003, Computer Sciences Corp., which had acquired DynCorp |
| > that month, told Higgins that the final deployment of the computers |
| > and networks would be delayed until October. In August, October     |
| > became December. And in October, December became April 2004." In    |
| > June 2004 problems were so great that "With new management in       |
| > place, about 120 SAIC engineers began work on the IOC project." In  |
| > March 2005 the IOC pilot failed when "the IOC application was an    |
| > aid to task management, its use did not improve the productivity of |
| > most users." In May 2005 Sentinel rises from the ashes when         |
| > "Mueller announced Sentinel, a four-phase, four-year project        |
| > intended to do the VCF\'s job."                                     |
| >                                                                     |
| > Breaking up the VCF project into smaller steps could have lowered   |
| > the risk, complexity, uncertainty, and change to managable levels.  |
| > Approaches for the smaller steps could have included: evolving and  |
| > delivering portions of the functions over time, building and        |
| > delivering to selected field offices over time.                     |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 2: Acquisition of Resources (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The acquisition strategy defines the management approach that will    |
| achieve program goals. As such, the program manager must identify     |
| whether a single-step or evolutionary program approach is best for    |
| the acquisition. Next, key decisions will have to be made about how   |
| the government agency selects the contractor or "source" -- sole      |
| source procurement, limited competition or full and open competition. |
|                                                                       |
| The acquisition planning process incorporates the management approach |
| and method for source selection as part of its development.           |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on the acquisition of resources. After       |
| addressing any questions the participants may have, inform them that  |
| we will be moving on to the next topic: Acquisition Planning.         |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image7.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  the Acquisition of Resources?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning**

  -----------------------------------------------------------------------

  ---------------------------------------------------- ----------------------
  ![](media/image13.wmf){width="4.069444444444445in"   Slide \# 3-7
  height="3.05in"}                                     

  ---------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key points:**                                                       |
|                                                                       |
| The program manager can be considered the "agency glue" that can      |
| translate strategic acquisition objectives into actionable plans, and |
| then manage the projects into deliverables that achieve the desired   |
| program result.                                                       |
|                                                                       |
| A program has objectives and risks, as does a project. When           |
| considering the most appropriate design solution for the program, the |
| program manager must consider how it will be "architected."           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key points:**                                                       |
|                                                                       |
| The architecting of a program can address basic questions including   |
| but not limited to:                                                   |
|                                                                       |
| -   How many projects?                                                |
|                                                                       |
| -   What is the functional split between the projects?                |
|                                                                       |
| -   Which of the projects carries the risk?                           |
|                                                                       |
| What are the risk reduction projects? To put a program together, the  |
| program manager must develop one or more strategies which serve the   |
| purpose of achieving the program objectives, and ultimately, the      |
| program goal. These strategies work to create the program             |
| architecture.                                                         |
|                                                                       |
| The strategies proposed should work together to achieve every         |
| specific objective in the program. There does not need to be a        |
| strategy for each objective, because a given strategy may serve to    |
| meet more than one specific objective. Similarly, it may be useful to |
| specify more than one strategy for a given objective.                 |
|                                                                       |
| Normally, there are many possible strategies for achieving a specific |
| goal however agency policy and practices (as discussed in Module 2 of |
| this course) will influence the program manager's choices.            |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| -   The acquisition strategy guides program execution across the      |
|     entire program life-cycle. The strategy evolves over time and     |
|     should continuously reflect the current status and desired end    |
|     point of the program.                                             |
|                                                                       |
| -   The strategy must be flexible enough to accommodate acquisition   |
|     oversight decisions both on this program and on other programs    |
|     that may affect this program. It should address the availability  |
|     of required capabilities to be provided by other programs.        |
|                                                                       |
| -   Therefore, the program manager must consider a number of elements |
|     as part of the overall acquisition planning process for any       |
|     program.                                                          |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to generate a broad discussion about the   |
| types of decisionmaking a program manager uses during oversight of a  |
| program.                                                              |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What are some of the types of         |
| acquisition oversight decisions a program manager might be required   |
| to make during the life of a program?**                               |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Since the program manager manages a mix of related projects he/she    |
| will be focused on three aspects:                                     |
|                                                                       |
| -   Benefits management                                               |
|                                                                       |
| -   Stakeholder management                                            |
|                                                                       |
| -   Program governance                                                |
|                                                                       |
| In performing these oversight aspects, the program manager will need  |
| to decide, for example:                                               |
|                                                                       |
| -   Is the organization receiving the needed value from the program?  |
|                                                                       |
| -   What adjustments need to be made to the interdependencies between |
|     the projects in the program?                                      |
|                                                                       |
| -   How responsive is the program to the stakeholders?                |
|                                                                       |
| -   What adjustments need to be made to the projects in the program?  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Overall, the elements the program manager must consider as part of    |
| the acquisition strategy planning and development for a               |
| performance-based program include:                                    |
|                                                                       |
| -   Information Technology                                            |
|                                                                       |
| -   Program Structure                                                 |
|                                                                       |
| -   Acquisition Approach                                              |
|                                                                       |
| -   Capability Needs                                                  |
|                                                                       |
| -   Test and Evaluation                                               |
|                                                                       |
| -   Risk Management                                                   |
|                                                                       |
| -   Resource Management                                               |
|                                                                       |
| -   Systems Engineering Plan                                          |
|                                                                       |
| -   Interoperability                                                  |
|                                                                       |
| -   Research and Technology Protection                                |
|                                                                       |
| -   Information Assurance                                             |
|                                                                       |
| -   Product Support Strategy                                          |
|                                                                       |
| -   Human Systems Integration                                         |
|                                                                       |
| -   Environment, Safety and Occupational Health (ESOH)                |
|                                                                       |
| -   Modular Open Systems Approach (MOSA)                              |
|                                                                       |
| -   Business Considerations                                           |
|                                                                       |
| -   Best Practices                                                    |
|                                                                       |
| -   Relief, Exemption or Waiver                                       |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| An acquisition program must be structured in such as way that allows  |
| for program management skills to be implemented with the desired      |
| results. The program structure must include five essential policies   |
| that include:                                                         |
|                                                                       |
| -   Flexibility                                                       |
|                                                                       |
| -   Responsiveness                                                    |
|                                                                       |
| -   Innovation                                                        |
|                                                                       |
| -   Discipline                                                        |
|                                                                       |
| -   Streamlined and Effective Management                              |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| **Flexibility** in a program addresses the fact that there is no one  |
| best way to structure an acquisition program to accomplish the        |
| objective of the agency.                                              |
|                                                                       |
| -   The program manager must tailor program strategies and oversight, |
|     including documentation of program information, acquisition       |
|     phases, the timing and scope of decision reviews, and decision    |
|     levels, to fit the particular conditions of that program.         |
|                                                                       |
| -   The program strategies and oversight must be consistent with      |
|     applicable laws and regulations and the time-sensitivity of the   |
|     capability need.                                                  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| **Responsiveness** in a program addresses, in particular, the         |
| technological aspect of a program that enable its acquisition         |
| strategy to be evolutionary:                                          |
|                                                                       |
| -   Advanced technology should be integrated into producible systems  |
|     and deployed in the shortest time practicable.                    |
|                                                                       |
| -   Approved, time-phased capability needs matched with available     |
|     technology and resources enable evolutionary acquisition          |
|     strategies.                                                       |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| **Innovation** in a program structure encourages the use of existing  |
| and development of new best practices:                                |
|                                                                       |
| -   The program manager should continuously develop and implement     |
|     initiatives to streamline and improve agency acquisition systems. |
|                                                                       |
| -   The program manager should examine and, as appropriate, adopt     |
|     innovative practices (including best commercial practices and     |
|     electronic business solutions) that reduce cycle time and cost,   |
|     and encourage teamwork.                                           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| **Discipline** must be incorporated into the program structure in     |
| order to enable the program manager to manage the program consistent  |
| with statute and regulatory requirements specified for the            |
| acquisition.                                                          |
|                                                                       |
| -   The program manager must establish program goals for the minimum  |
|     number of cost, schedule, and performance parameters that         |
|     describe the program over its life cycle.                         |
|                                                                       |
| -   Approved program baseline parameters will serve as control        |
|     objectives, and be used by the program manager to identify        |
|     deviations from approved acquisition program baseline parameters  |
|     and exit criteria.                                                |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Finally, a **streamlined and effective management approach** as part  |
| of the program structure is required.                                 |
|                                                                       |
| -   Responsibility for the acquisition of systems should be           |
|     decentralized to the maximum extent practicable.                  |
|                                                                       |
| -   The program manager should serve as a single point of contact     |
|     (individual) that has sufficient authority to accomplish the      |
|     approved program objectives for development, production, and      |
|     sustainment.                                                      |
|                                                                       |
| -   The program manager will ensure accountability and maximize       |
|     credibility in cost, schedule, and performance reporting.         |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to generate a discussion about program     |
| structure policies. Use participant responses to develop additional   |
| policies the participants feel are important to include in program    |
| structure.                                                            |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What other program structure policies |
| do you feel are important for the program manager to include?**       |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Discuss participant responses. There may or may not be other policies |
| identified.                                                           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| -   Performance-based agreements are one of the key components of an  |
|     effective product support strategy.                               |
|                                                                       |
| -   In addition to the policies that govern the acquisition program   |
|     structure, there are significant performance-based considerations |
|     that must be addressed by the Program Manager during the program  |
|     management.                                                       |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to generate a discussion about             |
| performance-based considerations. This will allow the instructor to   |
| assess what prior knowledge the participants bring to the classroom   |
| prior to discussing the subject further.                              |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What are some of the concerns you     |
| might want to address with a performance-based agreement?**           |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| A performance-based agreement, as part of a performance-based         |
| business environment (PBBE) should have an acquisition strategy that  |
| includes a performance-based business strategy.                       |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| In order to create a performance-based business strategy, the program |
| manager must keep in mind that a performance-based business           |
| environment (PBBE) relates the business considerations of the         |
| acquisition strategy to the life-cycle considerations of systems      |
| engineering, life-cycle logistics (LCL), and human systems            |
| integration.                                                          |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to generate a discussion about relating    |
| the PBBE business considerations to the business environment. Use the |
| discussion to capture the relevant key points on a flip chart as they |
| are tabled by the participants.                                       |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**How does the program manager          |
| structure a PPBE program to effectively relate the acquisition        |
| strategy to a performance-based business environment?**               |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| The program manager should structure a PBBE to accomplish the         |
| following:                                                            |
|                                                                       |
| -   Convey product definition to industry in performance terms        |
|                                                                       |
| -   Use systems engineering and management practices, including       |
|     affordability, integrated product and process development and     |
|     support, to fully integrate total life cycle considerations       |
|                                                                       |
| -   Emphasize past performance                                        |
|                                                                       |
| -   Motivate process efficiency and effectiveness up and down the     |
|     entire supplier base -primes, subcontractors and vendors --       |
|     through the use of contractor-chosen commercial products,         |
|     practices and processes                                           |
|                                                                       |
| -   Encourage life cycle risk management versus risk avoidance        |
|                                                                       |
| -   Simply acquisition                                                |
|                                                                       |
| -   Transfer acquisition tasks to industry where cost effective,      |
|     risk-acceptable and where commercial capabilities exist           |
|                                                                       |
| -   Use performance specifications or convert to performance          |
|     specifications during re-procurement of systems, subsystems,      |
|     components, spares and services beyond the initial production     |
|     contract award; and during post-production support to facilitate  |
|     technology insertion and modernization of existing                |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Source selection is the process by which bids are solicited and       |
| evaluated and a winning contractor is selected.                       |
|                                                                       |
| The source selection, based on the "request for proposal" (RFP)       |
| solicitation, includes the essential features for program acquisition |
| strategy and corresponding business arrangement:                      |
|                                                                       |
| -   Specifications                                                    |
|                                                                       |
| -   Pricing arrangements                                              |
|                                                                       |
| -   Special incentives                                                |
|                                                                       |
| -   Methods that will be used to evaluate bids                        |
|                                                                       |
| The Competition in Contracting Act (CICA) is the basic statute        |
| currently governing federal procurement.                              |
|                                                                       |
| -   Establishes principle of "full and open competition"              |
|                                                                       |
| -   Provides a number of exceptions to full and open competition      |
|     principle                                                         |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following questions to generate a discussion about CICA and   |
| open competition principles.                                          |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What are some of the exceptions to    |
| the full and open competition principle in CICA?**                    |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| CICA exceptions include:                                              |
|                                                                       |
| -   Compelling and unusual urgency of the procurement                 |
|                                                                       |
| -   Presence of only one source who can do the job                    |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What approvals are required for       |
| exceptions to the full and open competition principle in CICA?**      |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| The amount and type of the procurement will determine the level of    |
| approval required for limited competition or sole source              |
| acquisitions:                                                         |
|                                                                       |
| -   Depending on the procurement amount, the approval decision varies |
|     from the Program Manager to the senior agency official for        |
|     acquisitions with any limits on bids                              |
|                                                                       |
| -   Sole source limitations almost always require senior agency       |
|     official approval                                                 |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Excluding sole source contracts, the award of a procurement based on  |
| competitively priced negotiation is based on the evaluation criteria  |
| that are established. These criteria include both:                    |
|                                                                       |
| 1.  Evaluation factors -- what the government values                  |
|                                                                       |
| ```{=html}                                                            |
| <!-- -->                                                              |
| ```                                                                   |
| 1.  Evaluation weights -- how much the government values each factor  |
|                                                                       |
|     The source selection approach will result in either a low bid or  |
|     best value selection.                                             |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following questions to generate a discussion about low bid    |
| and best value selection awards.                                      |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What are some of the issues that may  |
| result from a low bid contract?**                                     |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Some low bid issues the program manager may encounter include:        |
|                                                                       |
| -   Contractor, willfully or in ignorance, may underestimate the cost |
|     or difficulty of the program's requirements which increases the   |
|     risk of contract performance                                      |
|                                                                       |
| -   Contractor use of "buy in and get well" low bid strategy with     |
|     initial unrealistic low bid prices and intention to make          |
|     financial deficit through contract modifications post-award       |
|                                                                       |
| -   If the contract specifications are vague, low bid contractors     |
|     have no incentive to propose a level of performance that is even  |
|     slightly above that specified in the solicitation, even if those  |
|     results can be achieved at a same or slightly higher cost         |
|                                                                       |
| -   Specifically for a sealed bid solicitation, it is difficult to    |
|     exclude those contractors with poor past performance records and  |
|     to reward those contractors with good records                     |
|                                                                       |
| -   Low bid source selection is very risky for best-efforts           |
|     contracting since there is a likelihood of getting poor-quality   |
|     personnel with little chance of achieving program's goals         |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What are some of the issues that may  |
| arise with a best value contract award?**                             |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Some issues the program manager may encounter with best value awards  |
| include:                                                              |
|                                                                       |
| -   Possibility that trade-offs are too subjective and give too much  |
|     discretion to contracting officials                               |
|                                                                       |
| -   Solicitation must include well constructed and specific           |
|     evaluation factors which commonly include price, technical        |
|     capability and past performance                                   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Upon receipt of written bid proposals to a solicitation, two basic    |
| principles of proposal evaluation are enacted:                        |
|                                                                       |
| -   Grading proposals based solely on published evaluation factors    |
|     and their weights                                                 |
|                                                                       |
| -   Transparency, achieved through the explanation and documentation  |
|     of decisions                                                      |
|                                                                       |
|     Agency awards are typically made based on initial written         |
|     proposal.                                                         |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Agencies typically reserve the right to make awards based on initial  |
| written proposals received. However, agencies can choose to enter     |
| into negotiations with the best bidders to:                           |
|                                                                       |
| -   Resolve problems or uncertainties in the proposal                 |
|                                                                       |
| -   Try and get a better deal for the procurement                     |
|                                                                       |
|     This is accomplished by establishment of a competitive range for  |
|     finalist bidders.                                                 |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| For significant procurements, proposals are graded by a source        |
| selection team comprised of contracting people and program people who |
| will be working on the contract. The team may be sub-divided into     |
| teams focused on:                                                     |
|                                                                       |
| -   Technical criteria                                                |
|                                                                       |
| -   Management criteria                                               |
|                                                                       |
| -   Past performance criteria                                         |
|                                                                       |
| -   Cost criteria                                                     |
|                                                                       |
|     The final source selection may be made by a source selection      |
|     authority within the agency, typically an official at a level     |
|     above the source selection team.                                  |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| This initial module activity continues the business case that will be |
| used throughout this course to apply various concepts and reinforce   |
| learning through the use of critical thinking and application skills. |
| Completion of this activity is at the instructor's discretion based   |
| on his/her participant group; the activity will serve to develop a    |
| summary listing of the key elements of an acquisition plan and their  |
| corresponding timeline throughout the VCF business case.              |
|                                                                       |
| The business case study will provide a learning continuum as          |
| participants progress through the modules included as part of FAI     |
| Program Management Government Specific Course III.                    |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image14.png) **Activity (Optional)**                        |
|                                                                       |
| Activity Purpose:                                                     |
|                                                                       |
| This activity provides participants with an opportunity to consider   |
| key elements of an acquisition plan that would be appropriate for the |
| Virtual Case File (VCF) acquisition business case.                    |
|                                                                       |
| (*This module activity continues the business case that will be used  |
| throughout this course to apply various concepts and reinforce        |
| learning through the use of critical thinking and application         |
| skills.*)                                                             |
|                                                                       |
| Activity Length: 30 minutes                                           |
|                                                                       |
| Activity Instructions:                                                |
|                                                                       |
| 1.  Divide the participants into small groups.                        |
|                                                                       |
| 2.  Allow participants 5 minutes to individually review the *VCF      |
|     Acquisition Program Management Business Case* found in their      |
|     Participant Guide and on the following pages of this Instructor   |
|     Guide..                                                           |
|                                                                       |
| 3.  Allow each group 10 minutes to answer the following question.     |
|                                                                       |
|     a.  What are the key events and timeline for including in an      |
|         acquisition plan the program manager could have used to led   |
|         to the Spring 2001 award?                                     |
|                                                                       |
| 4.  Solicit the answers from the groups during a class-wide           |
|     discussion and allow individuals to answer on a volunteer basis.  |
|                                                                       |
| 5.  If necessary, elaborate on the key events and timeline to ensure  |
|     correct information is provided for the whole group.              |
|                                                                       |
| > **Note:** *Relevant example answers for each question are found on  |
| > the following page of this Instructor Guide.*                       |
|                                                                       |
| 6.  After all the questions have been discussed, summarize the        |
|     activity by telling participants that there is a considerable     |
|     amount benefit to a program by developing and following a         |
|     comprehensive acquisition plan.                                   |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image15.png) **Activity (continued)**                       |
|                                                                       |
| **Key Findings**                                                      |
|                                                                       |
| The following is a sample list of key elements and timeline for a     |
| acquisition plan leading to a spring 2001 award.                      |
|                                                                       |
|   ------------------------------------------- ----------------------  |
|   **ELEMENT**                                 **DATE**                |
|                                                                       |
|   Market Research                             3 September 2000        |
|                                                                       |
|   Market Survey                               7 September 2000        |
|                                                                       |
|   RFP Package Submitted to Contracts          17 September 2000       |
|                                                                       |
|   **Release Draft RFP**                       **1 October 2000**      |
|                                                                       |
|   Pre-Solicitation Conference                 12 October 2000         |
|                                                                       |
|   Comments Received and RFP Revised           22 October 2000         |
|                                                                       |
|   **Release Final RFP**                       **2 November 2000**     |
|                                                                       |
|   **Questions Due From Offerors**             12 November 2000        |
|                                                                       |
|   Answers Furnished by the Government         16 November 2000        |
|                                                                       |
|   **Receive Proposals at Contracting Office** **3 December 2000**     |
|                                                                       |
|   Begin Initial Evaluations                   3 December 2000         |
|                                                                       |
|   Complete Initial Evaluations                21 December 2000        |
|                                                                       |
|   Initial ET Report Due To SSEB               28 December 2000        |
|   ------------------------------------------- ----------------------  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image16.png) **Activity (continued)**                       |
|                                                                       |
| **Key Findings (continued)**                                          |
|                                                                       |
|   ------------------------------------------- ----------------------  |
|   **ELEMENT**                                 **DATE**                |
|                                                                       |
|   **SSA Competitive Range Determination**     **4 January 2001**      |
|                                                                       |
|   Discussions With Offerors (if required)     11 January 2001         |
|                                                                       |
|   Receive Revised Proposals                   18 January 2001         |
|                                                                       |
|   Complete Final Evaluations                  25 January 2001         |
|                                                                       |
|   Final ET Report Due To SSEB                 8 February 2001         |
|                                                                       |
|   SSA Selection                               15 February 2001        |
|                                                                       |
|   Final Negotiations                          22 February 2001        |
|                                                                       |
|   **Contract Award**                          **3 March 2001**        |
|                                                                       |
|   Contractor Debriefings                      3 March 2001            |
|   ------------------------------------------- ----------------------  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 3: Acquisition Planning (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| As discussed, the acquisition strategy guides program execution       |
| across the entire program life-cycle. The strategy evolves over time  |
| and should continuously reflect the current status and desired end    |
| point of the program.                                                 |
|                                                                       |
| Once the strategy has been developed, including award of the          |
| contract, contract administration activities begin.                   |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on acquisition planning. After addressing    |
| any questions the participants may have, inform them that we will be  |
| moving on to the next topic: Contract Administration.                 |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image7.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  Acquisition Planning?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 4: Contract Management**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image17.wmf){width="3.9506944444444443in"   Slide \# 3-8
  height="2.9680555555555554in"}                        

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| In order for a contract to be meaningful, it must be administered     |
| after it is awarded.                                                  |
|                                                                       |
| A relative lack of attention to contract administration can be a      |
| serious problem with the overall management of an acquisition         |
| program.                                                              |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image18.wmf){width="3.9506944444444443in"   Slide \# 3-9
  height="2.9680555555555554in"}                        

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Contract administration includes five distinct activities:            |
|                                                                       |
| -   Monitoring costs                                                  |
|                                                                       |
| -   Monitoring performance                                            |
|                                                                       |
| -   Contract modifications                                            |
|                                                                       |
| -   Settling claims                                                   |
|                                                                       |
| -   Contract termination or close-out                                 |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The first activity of contract administration, **[monitoring          |
| costs]{.underline}**, is very crucial and one of the hardest parts of |
| the program as it spans across all phases of projects from conception |
| to closure.                                                           |
|                                                                       |
| Cost monitoring ("management") does not refer just to the actions     |
| required for controlling program costs. Instead, it relates to the    |
| program manager's involvement in definitive planning and budgeting,   |
| collecting cost associated data and comparing it to prepared budgets, |
| and taking appropriate actions when necessary.                        |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The second activity, **[monitoring performance]{.underline}**, should |
| occur at multiple points in the contracting process. According to the |
| General Accounting Office (GAO) publication dated July 18, 2007       |
| titled, "Use of Contractor Performance Information," the government   |
| contracting process provides for consideration of various aspects of  |
| contractor performance at multiple points including:                  |
|                                                                       |
| -   Past performance as source selection factor: Only relatively      |
|     recently have federal agencies been required to consider past     |
|     performance in selecting their contractors. In 1997, the Federal  |
|     Acquisition Regulation (FAR) was modified to require that         |
|     agencies consider past performance information as an evaluation   |
|     factor in source selection (which will be addressed later in this |
|     course). Past performance is now required to be an evaluation     |
|     factor in selecting contractors, along with factors such as       |
|     price, management capability, and technical approach to the work. |
|                                                                       |
| -   Responsibility determinations: Once a contractor is selected for  |
|     award, the contracting officer must make an affirmative           |
|     determination that the prospective awardee is capable and         |
|     ethical. This is known as a "responsibility determination," and   |
|     includes, for example, whether a prospective awardee has adequate |
|     financial resources and technical capabilities to perform the     |
|     work, has a satisfactory record of integrity and business ethics, |
|     and is eligible to receive a contract under applicable laws and   |
|     regulations.                                                      |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Other contractor performance multiple points include:                 |
|                                                                       |
| -   Surveillance of performance under the current contract: Once a    |
|     contract is awarded, the program manager should monitor a         |
|     contractor's performance throughout the performance period.       |
|     Surveillance includes oversight of a contractor's work to provide |
|     assurance that the contractor is providing timely and quality     |
|     goods or services and to help mitigate any contractor performance |
|     problems. An agency's monitoring of a contractor's performance    |
|     may serve as a basis for past performance evaluations in future   |
|     source selections.                                                |
|                                                                       |
|     **Note:** The term "monitoring" does not fully convey the need    |
|     for the program manager to actively "manage" performance.         |
|                                                                       |
| -   Suspension and debarment: Contractor performance also comes into  |
|     play in suspensions and debarments. A suspension is a temporary   |
|     exclusion of a contractor pending the completion of an            |
|     investigation or legal proceedings, while a debarment is a        |
|     fixed-term exclusion lasting no longer than 3 years. To protect   |
|     the government's interests, agencies can debar contractors from   |
|     future contracts for various reasons, including serious failure   |
|     to perform to the terms of a contract.                            |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| The third activity, **[contract modifications]{.underline}**, is      |
| administered via the provisions of the contract "Changes" clause. The |
| \"Changes\" clause is probably the most powerful clause in the        |
| contract's standard terms and conditions as it enables the program    |
| manager to make unilateral changes to the contract during             |
| performance, so long as those changes fall within the contract\'s     |
| scope.                                                                |
|                                                                       |
| **Note**: The program manager also has responsibility for managing    |
| changes that do not rise to the level of requiring actual contract    |
| modifications.                                                        |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to generate a discussion about how the     |
| Changes clause enables the program manager to impact the contractor   |
| and project performance.                                              |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**Give some examples of Changes clauses |
| and how they can affect a contract.**                                 |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| (The following is not all-inclusive but is provided for purposes of   |
| facilitating discussion.)                                             |
|                                                                       |
| -   Under the standard \"Changes\" clause used in fixed price supply  |
|     contracts, the CO may make changes, in writing, to: (1) the       |
|     drawings, designs, or specifications when the item is being       |
|     specifically manufactured for the Government; (2) the method of   |
|     shipment or packing; or (3) the place of delivery. FAR 52.243-1.  |
|     The change does not necessarily work to the disadvantage of the   |
|     contractor, however, because the contractor is entitled to an     |
|     \"equitable adjustment\" to the contract if the change results in |
|     increased contract costs or time of performance.                  |
|                                                                       |
| -   Under the \"constructive change\" doctrine, informal government   |
|     actions or inactions not initially identified or admitted to be   |
|     changes \-- but which require extra work \-- by the CO may        |
|     nonetheless constitute changes. Typical categories of             |
|     constructive changes that have been recognized by the             |
|     administrative boards of contract appeals and the courts are: (1) |
|     informal extra work directives; (2) defective government          |
|     specifications or impossibility of performance; (3) incorrect     |
|     contract interpretations taken by the government causing extra    |
|     work; and (4) failure of the government to cooperate during       |
|     performance.                                                      |
|                                                                       |
| -   If the formal or constructive change causes an increase or        |
|     decrease in contract price, the CO must equitably adjust the      |
|     contract in writing. The contractor must assert its right to this |
|     equitable adjustment in writing within a specified time period    |
|     (usually 30 days) of the CO\'s written formal change order, or    |
|     before final payment if it is constructive change. Failure to     |
|     agree on the equitable adjustment to which the contractor is      |
|     entitled constitutes a dispute under the \"Disputes\" clause.     |
|     Regardless of any dispute, however, the contractor must continue  |
|     performing under the contract, including any changes the CO may   |
|     have made. FAR 52.243-1(e)                                        |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| The fourth activity, **[settling claims]{.underline}**, is the        |
| process followed for disputes arising under a contract between the    |
| government and a contractor. This process applies to all disputes     |
| arising under or relating to a government contract.                   |
|                                                                       |
| A contractor initiates the disputes process by presenting a \"claim\" |
| to the program manager (or CO). The \"Disputes\" clause of the        |
| contract defines a claim as \"a written demand or written assertion   |
| by one of the contracting parties seeking, as a matter of right, the  |
| payment of money in a sum certain, the adjustment or interpretation   |
| of contract terms, or other relief arising under or relating to       |
| \[the\] contract.\" FAR 52.233-1 (c).                                 |
|                                                                       |
| According to the clause\'s definition, a claim must (1) be in         |
| writing; (2) request a \"sum certain\"; and (3) demand a final        |
| decision. If the claim is over \$100,000, it must also be certified   |
| by the contractor. FAR 52.233-1(d)(2). The contractor must attest     |
| that (a) the claim is made in good faith, (b) the supporting data are |
| accurate and complete to the best of his or her knowledge and belief, |
| (c) the amount requested accurately reflects the contract adjustment  |
| for which the contractor believes the government is liable, and (d)   |
| the individual certifying is duly authorized to do so on behalf of    |
| the contractor.                                                       |
|                                                                       |
| If the contractor and government are unable to negotiate a resolution |
| to the dispute, the program manager must issue a \"final decision.\"  |
| This is a written articulation of the agency\'s position with respect |
| to the claim. A contractor cannot commence litigation until such a    |
| decision has been issued, however if, after the passage of time, a    |
| final decision is not provided to the contractor, he may attempt to   |
| appeal the government's so-called \"deemed denial\" of the claim to   |
| an administrative board of contract appeals or the U.S. Court of      |
| Federal Claims (COFC).                                                |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to facilitate a large group discussion     |
| using experiences the participants have had with settling claims.     |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**Who can give us an example of a time  |
| you had a project that required a difficult claim settlement?**       |
|                                                                       |
| **What was the issue and how did you resolve it?**                    |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| (Ask for several examples.) Use participant responses to facilitate a |
| large group discussion about how and when they have been required to  |
| settle a dispute and what the impact was on the overall program.      |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| The fifth activity, **[contract termination]{.underline}**, is most   |
| important in that the program manager understands what termination    |
| options there are for a contract, and what rights those termination   |
| options give the contractor/agency. These options include:            |
|                                                                       |
| -   Termination for default -- contractor fails to perform            |
|                                                                       |
| -   Termination for convenience -- agency does not need products or   |
|     services anymore                                                  |
|                                                                       |
| Several provisions apply for a contract that is terminated for        |
| default:                                                              |
|                                                                       |
| -   For a terminated fixed-price contract, the contractor will not be |
|     paid for any work the agency deems unacceptable.                  |
|                                                                       |
| -   If the contractor has received advance payments for undelivered   |
|     or unacceptable items, those payments must be returned to the     |
|     agency.                                                           |
|                                                                       |
| -   If the government pays a higher price when it re-procures the     |
|     items covered under the terminated contract, the contractor must  |
|     pay the government "excess re-procurement costs."                 |
|                                                                       |
| -   A contract terminated for default will hurt the contractor\'s     |
|     past performance ratings on future government work for which it   |
|     also bids.                                                        |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following questions to generate discussion about the          |
| termination by default decisions.                                     |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**Which type of contract is least       |
| likely to be terminated for default?**                                |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| It is virtually impossible to prove a case for terminating a          |
| contractor for default in a best-efforts contract.                    |
|                                                                       |
| Terminations for default almost never occur for cost-reimbursement    |
| contracts.                                                            |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**When might the agency decide not to   |
| terminate a poorly performing contractor?**                           |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| The decision to terminate a poorly performing contractor for default  |
| is a business decision for the agency.                                |
|                                                                       |
| Sometimes, the government puts up with poorly performing contractors  |
| because of the time it takes to re-procure or, unfortunately, because |
| of the prospect of bitter litigation where the program manager or     |
| agency officials may not have fully documented the problems with the  |
| contractor                                                            |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Finally, due to the drastic nature of termination for default, the    |
| rules offer significant due process protection to contractors.        |
|                                                                       |
| -   Terminations for default must be preceded by a \"cure notice\"    |
|     formally explaining the problems and giving the contractor ten    |
|     days to show they are, or will be, remedied.                      |
|                                                                       |
| -   Terminations for default are frequently challenged in court, and  |
|     the agency must be able to show that its actions did not          |
|     materially contribute to the contractor\'s performance problems.  |
|                                                                       |
| -   Government agencies have the unilateral ability to terminate a    |
|     contract \"for convenience\" or simply because a decision is made |
|     that there is not a further need for the products or services     |
|     anymore.                                                          |
|                                                                       |
| -   Contractors are treated more generously when contracts are        |
|     terminated for convenience versus when they are terminated for    |
|     default. They are reimbursed for work undertaken up to the time   |
|     of termination, including costs of labor, purchased materials and |
|     parts, indirect costs, and certain preparation costs.             |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| Ask the following question to generate discussion about contractor    |
| reimbursements in termination by convenience decisions.               |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**What costs are not reimbursed to a    |
| contractor in the instance of a contract termination for              |
| convenience?**                                                        |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| Contractors may not be reimbursed for \"anticipatory profits,\" that  |
| is, profits they would have earned on work performed after contractor |
| termination.                                                          |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Legislation and Policies:                                             |
|                                                                       |
| There is specific legislation and policies that guide the program     |
| manager in contract award termination decisions.                      |
|                                                                       |
| FAR 49.402-3(f) specifically tells contracting officials when         |
| considering terminations for default to look at factors such as \"the |
| excuses for the failure,\" \"the availability of the supplies or      |
| services from other sources,\" and \"the urgency of the need for the  |
| supplies or services and the period of time required to obtain them   |
| from other sources, as compared with the time delivery could be       |
| obtained from the delinquent contractor.\"                            |
|                                                                       |
| FAR 49.201 specifically provides for contractor reimbursement of      |
| \"the preparations made for the terminated portions of the contract\" |
| in the case of a termination for convenience.                         |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image19.png) **Activity:**                                  |
|                                                                       |
| Activity Purpose:                                                     |
|                                                                       |
| This activity provides participants with an opportunity to identify   |
| instances where contract administration activities should have        |
| occurred and did or did not, depending on the timeline and            |
| corresponding event(s).                                               |
|                                                                       |
| (*This module activity continues the business case that will be used  |
| throughout this course to apply various concepts and reinforce        |
| learning through the use of critical thinking and application         |
| skills.*)                                                             |
|                                                                       |
| Activity Length: 45-60 minutes                                        |
|                                                                       |
| Activity Instructions:                                                |
|                                                                       |
| 1.  Allow participants 15 minutes to individually review the *VCF     |
|     Acquisition Program Management Business Case* found in their      |
|     Participant Guide and on the following page of this Instructor    |
|     Guide. Participants should read the content and answer the        |
|     following questions about the business case:                      |
|                                                                       |
|     a.  Identify at least one point where each of the five contract   |
|         administration activities should or could have occurred.      |
|                                                                       |
|     b.  Identify the impact of the administration activity (or        |
|         failure to perform).                                          |
|                                                                       |
| 2.  Break participants into table groups and have them discuss their  |
|     findings in small groups. Appoint someone to be a scribe for the  |
|     group findings.                                                   |
|                                                                       |
| 3.  Begin with the first table group, and ask them to share an        |
|     example of one contract administration activity they identified   |
|     and what it's corresdponding impact was on the program.           |
|                                                                       |
| 4.  Use the answers given to generate a large group discussion to     |
|     elicit other opinions about the activity and group's findings.    |
|     There may be more than one correct answer or viewpoint for each   |
|     question.                                                         |
|                                                                       |
| > **Note:** *Relevant answers for these questions will be identified  |
| > by the participant group.*                                          |
|                                                                       |
| 5.  Continue to all the table groups at least once (and more if time  |
|     allows and/or participant focus and interest warrants).           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

**The Virtual Case File (VCF)**

[September 2001: Inadequate System Exposed; the Virtual Case File is
Born]{.underline}

On 4 September 2001, Robert S. Mueller III became the tenth director in
FBI history. One week later, terrorists pulverized New York City\'s
World Trade Center and a piece of the Pentagon. The inability of FBI
agents to share the most basic information about Al Qaeda\'s U.S.
activities blew up into a front-page scandal. Within days, the FBI\'s
pathetic technology infrastructure went from being so much arcane trivia
to a subject of daily fulmination by politicians and newspaper
columnists. In the face of intense public and congressional pressure,
Mueller shifted Trilogy into high gear.

Recognizing the limitations of the new web interface feature of Trilogy
and ACS, Robert J. Chiaradio the FBI\'s executive assistant director for
administration decided that the Bureau needed an entirely new database,
graphical user interface, and applications, which would let agents
search across various investigations to find relationships to their own
cases. The new case management system would host millions of records
containing information on everything from witnesses, suspects, and
informants to evidence such as documents, photos, and audio recordings.
To address concerns being raised by intelligence experts and lawmakers
in the wake of 9/11, these records would be accessible to both the
FBI\'s agents and its intelligence analysts. The new system was dubbed
the Virtual Case File.

With no detailed description of the FBI\'s processes and IT
infrastructure to go by (i.e., an enterprise architecture), a team of
FBI agents led by Larry Depew began to characterize investigative
processes such as witness interviews and surveillance operations and map
them to the FBI\'s software and databases. Depew, a veteran Special
Agent from the Trenton, New Jersey office, was a self taught database
programmer. Over a six-week period in the fall of 2001, the group
defined how agents worked, how they gathered information, and how that
information was fed into ACS. Working with engineers from SAIC, they
drew up diagrams and flowcharts of how the case management system
operated then and how they wanted the new case management system, the
VCF, to operate in the future.

\[1\]

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[December 2001: Contract Changes and an Accelerated
Schedule]{.underline}

In December 2001, the FBI asked SAIC to stop building a Web front end
for the old programs. Instead, SAIC was asked to devise a new
application, database, and graphical user interface to completely
replace ACS.

To formally define what users needed the VCF to do for them, SAIC
embarked on a series of Joint Application Development (JAD) sessions. In
these meetings, the FBI's team of agents and experts got together with a
group of SAIC engineers to hash out what functions the VCF would
perform. Ideas captured in these sessions formed the basis of the
requirements document that guided SAIC\'s application designers and
programmers.

In January 2002, the FBI requested an additional \$70 million to
accelerate Trilogy; Congress went further, approving \$78 million.
DynCorp committed to delivering its two components by July 2002. SAIC
agreed to deliver the initial version of the VCF in December 2003
instead of June 2004.

SAIC and the FBI were now committed to creating an entirely new case
management system in 22 months. While the Trilogy contracts were changed
to reflect the aggressive new deadlines, neither the original software
contract nor the modified one specified any formal criteria for the FBI
to use to accept or reject the finished VCF software. Furthermore, those
contracts specified no formal project schedules at all, let alone
milestones that SAIC and DynCorp were contractually obligated to meet on
the way to final delivery.

In reaction to the new deadline, SAIC broke its VCF development group
into eight teams, working in parallel on different functional pieces of
the program. The eight threads would later prove difficult for SAIC to
combine into a single system. Nevertheless, Rick Reynolds, vice
president and operations manager for SAIC, defended the decision to
change tactics. \"People forget the urgency that we were under and our
customer was under. And we were right beside them,\" he declared. \"We
were in the foxhole together.\"

[March 2002: Defining Requirements]{.underline}

Over a six-month period, the JAD team met in two-week sessions. After a
two-week JAD session finished, a two-week feedback cycle would begin.
SAIC provided Depew\'s team with information gleaned from the session,
including needs statements, flow charts, and meeting minutes. Depew\'s
team reviewed these materials and gave SAIC feedback while
simultaneously preparing subject matter experts for the next round of
JAD sessions, which immediately followed the feedback cycle. There were
no breaks.

\[2\]

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

Mueller, Dies, and Chiaradio recruited C.Z. (\"Sherry\") Higgins, a
seasoned IT program manager with experience at Lucent and AT&T, to be
the FBI's new project management executive for the Office of the
Director. The new Office of Program Management would centralize IT
management and oversee, develop, and deploy the bureau\'s most
expensive, complex, and risky projects. But her most important
assignment was to manage Trilogy. Her first move when she came on board
in March 2002 was to appoint Depew, who had no IT project management
experience, the VCF project manager.

[April 2002: Schedules Start to Slip]{.underline}

In mid-April 2002, Higgins, demanded a detailed schedule from DynCorp.
After she got it, she pulled the project teams from the FBI and DynCorp
into a meeting and went through the document. Shortly after that,
Higgins broke the news to the director: the computers and networks would
not be delivered in July of that year as had been scheduled. She told
Mueller that DynCorp didn\'t stand a chance of hitting the delivery
target, because it didn\'t have a detailed schedule that mapped out how
it would deploy, integrate, and test the new computers and networks.

[July 2002: VCF Looked Good on Paper]{.underline}

The JAD sessions had produced an exhaustively detailed requirements
document. This plan for a case-management system would combine the ACS
with two other systems: the Telephone Application, the bureau\'s central
repository of telephone records related to investigations, and parts of
the Criminal Law Enforcement Application, a repository for investigative
data about people, organizations, locations, vehicles, and
communications.

The VCF system would accept scanned documents, photographs, and other
electronic media---to simplify evidence tracking. People with the proper
credentials would be able to access that evidence from any FBI office.
The way work flowed through the bureau would change dramatically, too.
Instead of filling out a form either by hand or in a word-processing
program and then faxing or FedEx-ing the paper form to a supervisor, an
agent would fill out a form online and, with a click of the mouse, route
it to the supervisor. The document would pop up in a supervisor\'s
in-box, and the agent could track it to see if it had been approved. And
perhaps most important, information collected within a case file would
eventually be available to software applications that would compare data
among cases to search for correlations---to connect the proverbial dots.

\[3\]

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[Summer 2002: Detailed Requirements]{.underline}

By August 2002 SAIC had around 200 programmers on the job. Matthew
Patton joined the SAIC team as a security engineer. Patton, who was
later removed from the project after criticizing its management in an
Internet posting, was unimpressed by the 800-plus pages of requirements.
\"In a requirements document, you want to dictate the whats, not the
hows,\" Patton said. \"We need an e-mail system that can do x, and
there\'s 12 bullets. Instead, we had things like \'there will be a page
with a button that says e-mail on it.\' We want our button here on the
page or we want it that color. We want a logo on the front page that
looks like x. We want certain things on the left-hand side of the page.
They were trying to design the system layout and then the whole
application logic before they had actually even figured out what they
wanted the system to do.\"

The overly specific nature of the requirements focused developers on
their tiny piece of the puzzle. They were writing code, Patton said,
with no idea of how their piece fit with the others. This presaged the
integration problems that would later plague the project.

Patton also claimed that SAIC was determined to write much of the VCF
from scratch. This included an e-mail-like system that at least one
team, to his knowledge, was writing, even though the FBI was already
using an off-the-shelf software package, Novell\'s GroupWise, for
e-mail.

[December 2002: The March of the Change Requests]{.underline}

In December 2002, Higgins asked lawmakers to invest an additional
\$137.9 million in Trilogy. Congress approved another \$123.2 million
for a project whose total cost had now ballooned to \$581 million.

After the FBI and SAIC agreed to the baseline set of requirements, SAIC
programmers began cranking out code. The company had settled on a spiral
development methodology, an iterative approach to writing software.
Basically, SAIC programmers would write and compile a block of code that
performed a particular function, then run it to show Depew\'s agents
what it would do. The agents gave the programmers feedback, and the
programmers tried to incorporate the suggested changes. Sometimes
Depew\'s team had only two days to review a batch of code. Agents would
pull all-nighters to get the evaluation finished, \"and in the next
iteration their comments wouldn\'t be taken into account,\" Higgins
said. Sometimes, she acknowledged, these evaluations would include
changes to the requirements---functions that the agents had decided that
they needed once they saw what they were going to get. Other times the
FBI team would find bugs that needed to be fixed.

\[4\]

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

If there was a dispute as to whether the change could or should be made,
the agents sent an official request to the change control board,
composed of SAIC engineers and FBI personnel, for review. It wasn\'t
long before the change requests started rolling in---roughly 400 from
December 2002 to December 2003, according to SAIC.

\"Once they saw the product of the code we wrote, then they would say,
\'Oh, we\'ve got to change this. That isn\'t what I meant,\'\" said
SAIC\'s Reynolds. \"And that\'s when we started logging change request
after change request after change request.\" Reynolds added that SAIC\'s
bid on the original contract, and each subsequently revised cost
estimate, was based on there being \"minimal, minor changes\" to the
program once a baseline set of requirements had been agreed on.

Some of the changes were cosmetic---move a button from one part of the
screen to another, for instance. Others required the programmers to add
a new function to a part of the program, such as the graphical user
interface, common to all eight development threads.

[March 2003: The Network is Delayed]{.underline}

In March 2003, Computer Sciences Corp., which had acquired DynCorp that
month, told Higgins that the final deployment of the computers and
networks would be delayed until October. In August, October became
December. And in October, December became April 2004. The problem
wasn\'t the PCs, which had been trickling in since 2001, but changing
the e-mail system from Novell\'s GroupWise to Microsoft Outlook and,
obtaining the components needed to connect the field offices to the wide
area network. Higgins added that the delays were compounded by the
FBI\'s own sloppy inventories of existing networks and its
underestimation of how taxing the network traffic would be once all
22,000 users came online using their new PCs.

While the FBI and SAIC waited for the networks to go live so they could
test the VCF on a real system, changes and fixes continued. Many of the
changes had to be to be made by all eight of SAIC\'s development teams.
Arnold Punaro, SAIC executive vice president and general manager,
admitted in a posting on the company\'s Web site that in the rush to get
the program finished by December, SAIC didn\'t ensure that all of its
programmers were making the changes the same way. That inconsistency
occasionally meant that different modules of the VCF handled data in
different ways. Consequently, when one module needed to communicate with
another, errors sometimes occurred.

\"This, however, did not compromise the system,\" according to Punaro.
The real killers, he said, were \"significant management turbulence\" at
the FBI, \"the ever-shifting nature of the requirements,\" and the
agents\' \"trial-and-error, \'We will know it when we see it\' approach
to development.\"

\[5\]

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

[September 2003: Testing Begins]{.underline}

SAIC began testing the program in the fall of 2003, and problems started
cropping up, some of which the agents had warned SAIC about over the
previous summer. SAIC officials complained to Higgins that Computer
Sciences Corp. didn\'t have its hardware and network in place, so SAIC
couldn\'t adequately test the VCF, crucial for a successful flash
cutover. They informed her that they would deliver a version of the VCF
to be in technical compliance with the terms of the contract and that
the FBI should feel free to make changes to it afterward.

[December 2003: VCF Delivery and Failure]{.underline}

On 13 December 2003, SAIC delivered the VCF to the FBI. Under the
direction of the FBI's new interim CIO, Zalmai Azmi, the FBI rejected
SAIC\'s delivery. The bureau found 17 \"functional deficiencies\" it
wanted SAIC to fix before the system was deployed. SAIC argued that at
least some of these deficiencies were changes in requirements. An
arbitrator was called in. The arbitrator found fault with both SAIC and
the FBI. Of the 59 issues and subissues derived from the original 17
deficiencies, the arbitrator found that 19 were requirements
changes---the FBI\'s fault; the other 40 were SAIC\'s errors.

While SAIC fixed bugs, Azmi, with the help of Depew\'s team, created
investigation scenarios that would take different cases from opening to
closing and tested them on the VCF. Those tests revealed an additional
400 deficiencies. \"We have requirements that are not in the final
product, yet we have capabilities in the final product that we don\'t
have requirements for,\" said Azmi.

At the same time Computer Sciences Corp was delivering the final pieces
of equipment to the FBI. By April, 22,251 computer workstations, 3408
printers, 1463 scanners, 475 servers, and new local and wide area
networks would all be up and running, 22 months later than the
accelerated schedule called for.

Azmi and SAIC had yet to agree on the VCF\'s ultimate fate, much less
when it would be deployed. Azmi rejected SAIC's proposal to take one
more year to make all the changes the FBI wanted at the cost of an
additional \$56 million.

[June 2003: Trying to Salvage Something from VCF:]{.underline}

Azmi asked SAIC to take the electronic workflow portion of the VCF, code
that was in relatively good shape, and turn that into what was
eventually called the Initial Operating Capability (IOC), at an
additional fixed price to the FBI of \$16.4 million. SAIC and the FBI
project team had six months to deliver a software package that would be
deployed to between 250 and 500 field personnel in Louisiana and at the
Hoover Building.

\[6\]

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

**VCF Program Acquisition Business Case Study**

The objectives for the new project were clear: test-drive the VCF\'s
electronic workflow; see how people reacted to the graphical user
interface; create a way to translate the output from the VCF forms, into
the ACS system; check out network performance; and develop a training
program. The IOC would use Azmi\'s rigorous approach to software
development and project management, which he called the Life Cycle
Management Directive.

[June 2004: SAIC Begins the IOC Project]{.underline}

With new management in place, about 120 SAIC engineers began work on the
IOC project. The FBI and SAIC agreed to keep to a strict development
schedule, define acceptance criteria, and institute a series of control
gates. Azmi\'s project manager worked closely with his SAIC counterpart
to adhere to the baseline requirements SAIC and the FBI had agreed on
for the IOC in July, thus avoiding a death spiral of change requests. In
January, the IOC was rolled out as a pilot right on schedule.

[March 2005: IOC Pilot Fails]{.underline}

The IOC pilot ended in March. The verdict: \"Although the IOC
application was an aid to task management, its use did not improve the
productivity of most users,\" according to an internal FBI assessment.
FBI employees, particularly agents, found that the IOC actually
increased their workload. Agents filled out forms electronically and
routed them to superiors for approval, after which the electronic form
was uploaded to the ACS, still in use, to be shared with the rest of the
FBI. But to comply with the FBI\'s paper-based records management
system, the form had to be printed out, routed, signed, and filed.

[May 2005: Sentinel Rises from the Ashes of VCF]{.underline}

In May 2005 Mueller announced Sentinel, a four-phase, four-year project
intended to do the VCF\'s job and provide the bureau with a Web-based
case- and records-management system that incorporates commercial
off-the-shelf software.

[March 2006: Sentinel goes to Contract]{.underline}

The FBI awarded a \$305M contract to Lockheed Martin for Sentinel. Total
program cost is estimated to be \$425M.

[June 2007: Sentinel's First Deployment]{.underline}

The FBI and Lockheed Martin rolled out Phase 1 Sentinel capabilities to
the FBI workforce. According to a press release from the FBI phase 1
includes a "Personal Workbox, which summarizes a user's cases and
leads....and user-friendly search capabilities." Azmi announces his
intent to use agile development to deliver new capability to the desktop
every six to nine months.

\[7\]

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image20.png) **Activity (continued)**                       |
|                                                                       |
| **Key Findings**                                                      |
|                                                                       |
| > Identify at least one point where each of the five contract         |
| > administration activities should or could have occurred./Identify   |
| > the impact of the administration activity (or failure to perform).  |
|                                                                       |
| -   [Monitoring costs]{.underline} -- From July 2000 to March 2005    |
|     costs ballooned "In September 2000, Congress approved \$379.8     |
|     million over three years for what was then called the FBI         |
|     Information Technology Upgrade Project" "In December 2002,        |
|     Higgins asked lawmakers to invest an additional \$137.9 million   |
|     in Trilogy. Congress approved another \$123.2 million for a       |
|     project whose total cost had now ballooned to \$581 million."     |
|                                                                       |
| -   [Monitoring performance]{.underline} -- April 2002 was preceded   |
|     by substantial requirements definition yet "Higgins, demanded a   |
|     detailed schedule from DynCorp. After she got it, she pulled the  |
|     project teams from the FBI and DynCorp into a meeting and went    |
|     through the document. Shortly after that, Higgins broke the news  |
|     to the director: the computers and networks would not be          |
|     delivered in July of that year as had been scheduled. She told    |
|     Mueller that DynCorp didn\'t stand a chance of hitting the        |
|     delivery target, because it didn\'t have a detailed schedule that |
|     mapped out how it would deploy, integrate, and test the new       |
|     computers and networks" and in December 2003 "While SAIC fixed    |
|     bugs, Azmi, with the help of Depew\'s team, created investigation |
|     scenarios that would take different cases from opening to closing |
|     and tested them on the VCF. Those tests revealed an additional    |
|     400 deficiencies. \"We have requirements that are not in the      |
|     final product, yet we have capabilities in the final product that |
|     we don\'t have requirements for,\" said Azmi."                    |
|                                                                       |
| -   [Contract modifications]{.underline} -- In Summer 2002, detailed  |
|     requirements were developed that resulted "In December 2002,      |
|     Higgins asked lawmakers to invest an additional \$137.9 million   |
|     in Trilogy. Congress approved another \$123.2 million for a       |
|     project whose total cost had now ballooned to \$581 million."     |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image21.png) **Activity (continued)**                       |
|                                                                       |
| **Key Findings (continued)**                                          |
|                                                                       |
| > Identify at least one point where each of the five contract         |
| > administration activities should or could have occurred./Identify   |
| > the impact of the administration activity (or failure to perform).  |
| > (continued)                                                         |
|                                                                       |
| -   [Settling claims]{.underline} -- December 2003 dispute resulted   |
|     "On 13 December 2003, SAIC delivered the VCF to the FBI. Under    |
|     the direction of the FBI's new interim CIO, Zalmai Azmi, the FBI  |
|     rejected SAIC\'s delivery. The bureau found 17 \"functional       |
|     deficiencies\" it wanted SAIC to fix before the system was        |
|     deployed. SAIC argued that at least some of these deficiencies    |
|     were changes in requirements. An arbitrator was called in. The    |
|     arbitrator found fault with both SAIC and the FBI. Of the 59      |
|     issues and subissues derived from the original 17 deficiencies,   |
|     the arbitrator found that 19 were requirements changes---the      |
|     FBI\'s fault; the other 40 were SAIC\'s errors."                  |
|                                                                       |
| -   [Contract termination or close-out]{.underline} -- In June 2004   |
|     after experiencing huge failures with VCF the FBI continues to    |
|     rely on SACI "With new management in place, about 120 SAIC        |
|     engineers began work on the IOC project. The FBI and SAIC agreed  |
|     to keep to a strict development schedule, define acceptance       |
|     criteria, and institute a series of control gates."               |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 4: Contract Management (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.4048611111111111in"                    |
| height="0.6354166666666666in"} **Instructor Notes:**                  |
|                                                                       |
| This concludes the topic on contract administration. After addressing |
| any questions the participants may have, inform them that we will be  |
| moving on to the next topic: Module Review.                           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image7.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have regarding
  contract administration?**

  -----------------------------------------------------------------------

  -----------------------------------------------------------------------
  **Topic 5: Review**

  -----------------------------------------------------------------------

  ----------------------------------------------------- ----------------------
  ![](media/image22.wmf){width="3.9506944444444443in"   Slide \# 3-10
  height="2.9680555555555554in"}                        

  ----------------------------------------------------- ----------------------

+-----------------------------------------------------------------------+
| ![](media/image5.png){width="0.75in" height="0.6868055555555556in"}   |
| **[CONTENT TO BE PRESENTED:]{.underline}**                            |
|                                                                       |
| **Key Points:**                                                       |
|                                                                       |
| Let's review the learning objectives for this module on the Basics of |
| Contracting.                                                          |
|                                                                       |
| -   Describe the program manager's role in ensuring appropriate       |
|     recognition of processes/procedures in acquisition functions.     |
|                                                                       |
| -   Using a program case study, determine the applicable acquisition  |
|     planning tasks for all phases of contract management, and apply   |
|     the appropriate standard of management.                           |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 5: Review (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| The following series of questions are provided to evaluate            |
| participants' knowledge of the content presented during this Basics   |
| of Contracting module.                                                |
|                                                                       |
| Review each question and its correct response with participants. You  |
| may elect to have participants answer questions individually          |
| [or]{.underline} ask the questions of the whole group as a review.    |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**All of the following are valid source |
| design option in an acquisition strategy except: (Select all that     |
| apply)**                                                              |
|                                                                       |
| A.  **-Source procurement -- government negotiates with only one      |
|     contractor**                                                      |
|                                                                       |
| B.  **Unilateral award -- government pre-selects contractor and does  |
|     not use a solicitation**                                          |
|                                                                       |
| C.  **Limited competition -- government solicits bids from a          |
|     prequalified list of firms or invites some limited group of firms |
|     to bid on an ad hoc basis**                                       |
|                                                                       |
| D.  **Diversity competition -- government solicits bids exclusively   |
|     from minority-owned contractors**                                 |
|                                                                       |
| E.  **Full and open competition -- any firm is entitled to a fairly   |
|     evaluated bid**                                                   |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| B, D                                                                  |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 5: Review (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**True or False. A pitfall of low bid   |
| awards is the contractor use of a "buy in and get well" low bid       |
| strategy with initial unrealistic low bid prices and the intention to |
| make financial deficit through post-award contract modifications.**   |
|                                                                       |
| **Answer:**                                                           |
|                                                                       |
| True                                                                  |
+-----------------------------------------------------------------------+

+-----------------------------------------------------------------------+
| ![](media/image7.png){width="0.5006944444444444in"                    |
| height="0.4888888888888889in"}**Which of the following provisions     |
| apply in the instance of a contract terminated for default? (Select   |
| all that apply)**                                                     |
|                                                                       |
| A.  **For a terminated fixed-price contract, the contractor will be   |
|     paid for all work performed, regardless of acceptability**        |
|                                                                       |
| B.  **If the contractor has received advance payments for undelivered |
|     or unacceptable items, those payments must be returned to the     |
|     agency.**                                                         |
|                                                                       |
| C.  **If the government pays a higher price when it re-procures the   |
|     items covered under the terminated contract, the contractor must  |
|     pay the government "excess re-procurement costs."**               |
|                                                                       |
| D.  **A contract terminated for default will hurt the contractor\'s   |
|     past performance ratings on future government work for which it   |
|     also bids.**                                                      |
|                                                                       |
|     **Answer:**                                                       |
|                                                                       |
|     B, C, D (For a terminated fixed-price contract, the contractor    |
|     will **[not]{.underline}** be paid for work performed that the    |
|     agency deems unacceptable.)                                       |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  **Topic 5: Review (continued)**

  -----------------------------------------------------------------------

+-----------------------------------------------------------------------+
| ![](media/image3.png){width="0.40555555555555556in"                   |
| height="0.6354166666666666in"}**Instructor Notes:**                   |
|                                                                       |
| This concludes Module 3 -- Basics of Contracting.. Address any        |
| questions the participants may have before moving on to Module 4 --   |
| Pre-Solicitation Phase.                                               |
+-----------------------------------------------------------------------+

  -----------------------------------------------------------------------
  ![](media/image7.png){width="0.5006944444444444in"
  height="0.4888888888888889in"}**What questions do you have about Module
  3 -- Basics of Contracting?**

  -----------------------------------------------------------------------