1. Another Government Organization Learns Lessons about Software
Projects the Hard Way
Complex software development and integration
will likely always be a difficult project to tackle.
Undoubtedly, the federal government has
undertaken some of the biggest such projects over
the last several years. Unfortunately, whether
they’re focused on national defense or citizen
services, there have been far too many cases of
government software projects gone awry. The
Department of Homeland Security’s (DHS’s)
“Secure Border Initiative: Project 28” (P28) is one
such example.
In 2005, the Government allocated $2.1 billion to a large prime contractor for the development
and integration of southern US border security surveillance technology, which was slated to be
implemented in 2007i. The technology plan included software to support long-range sensors,
communications, command and control (C3) equipment, common operating picture (COP), and
other components. Project 28 was designed as the initial effort to prototype this type of
systemii.
According to several Government Accountability Office (GAO) reports, however, the planned
software portion of the project’s cost and schedule estimates were unrealistic from the very
beginningiii,iv,v. For example, what DHS thought would be the project’s cost per mile turned out
to be only half of the actual cost. Over a six-year period, more than one billion taxpayer dollars
were put toward the P28, which ultimately led to an inadequate system that failed to satisfy
the stated DHS border security requirementsvi,vii.
Although there may be several other factors at play here, this costly (not just in money, but in
also in time and effort) outcome might have been mitigated by following several key software
project management best practicesviii,ix and, at the very least, similar software disasters can be
avoided by implementing these practices.
First, use a proven, industry standard software parametric estimation tool (SLIM-Estimate® is
one such parametric estimation tool) to more accurately estimate the program’s required
software cost, time, and effort, and carefully analyze the developer’s historical performance
data, which does not appear to have been the case for the P28x. After arriving at a more
realistic project scope, one must identify risk in the project development and integration

2. schedule and establish reasonable developer expectations from an informed customer position.
Since the GAO report suggests unrealistic expectations were also at playxi,xii, there was certainly
room for improvement. By using QSM’s SLIM® suite of tools to support software development
best practices and subsequent course of action decisions, project managers can thus help
ensure that the software - often a program’s single most critical and costly component – is
more accurately estimated and its risks are mitigated early on in a program’s development,
when it is far cheaper and easier to address. Especially within the Government acquisition
arena, as implied in the case of DHS’ P28, critical taxpayer dollars may be more effectively used
for better planned and managed programs that result in successful outcomes. Instead, in this
particular case, DHS was left with virtually no functional software, appropriate for its specific
needsxiii. According to recent reports, DHS is apparently starting again from scratch, and vowing
to not make the same mistakes againxiv,xv,xvi.
i Performance-Based Acquisitions:Creating Solutions or Causing Problems?, Hearing before the Committee on
Homeland Security, United States House of Representatives, May8, 2008, 110th Cong. 2, Serial 110-112 (Washington, D.C.:
2008).
ii Secure Border Initiative: SBInet Three Years Later, Hearing before the Subcommittee on Border, Maritime, and Global
Counterterrorism of the Committee on Homeland Security, United States House of Representatives September 17, 2009, 111th
Cong. 1, Serial 111-35 (Washington, D.C.:2009).
iii Ibid.
iv General Accounting Office (GAO), Secure Border Initiative:Observations on the Importance of Applying Lessons
Learned to Future Projects, GAO-08-508T (Washington, D.C.:Feb. 27, 2008)
v GAO, Secure Border Initiative: Observations on Selected Aspects of SBInet Program Implementation, GAO-08-131T
(Washington, D.C.:Oct. 24, 2007).
vi Performance-Based Acquisitions:Creating Solutions or Causing Problems?, Hearing before the Committee on
Homeland Security, United States House of Representatives, May8, 2008, 110th Cong. 2 Serial 110-112 (Washington, D.C.:
2008).
vii GAO, Secure Border Initiative Fence Construction Costs, GAO-09-244R (Washington, D.C.: Jan. 29, 2009).
viii GAO, GAO Cost Estimating and Assessment Guide:Best Practices for Developing and Managing Capital Program
Costs, GAO-09-3SP (Washington, D.C.:Mar. 2009).
ix
GAO, Secure Border Initiative: SBInet Planning and Management Improvements Needed to Control Risks, GAO-07-
504T (Washington, D.C.:February27, 2007).
x GAO, Department of Homeland Security: Better Planning and Assessment Needed to Improve Outcomes for Complex
Service Acquisitions, GAO-08-263 (Washington, D.C.:April 22, 2008).
xi GAO, Secure Border Initiative: DHS Needs to Address Significant Risks in Delivering Key Technology Investment, GAO-
08-1086 (Washington, D.C.:Sep. 22, 2008).
xii GAO, Secure Border Initiative: DHS Has Faced Challenges Deploying Technology and Fencing Along the Southwest
Border, GAO-10-651T (Washington, D.C.:May4, 2010).
xiii GAO, Secure Border Initiative: DHS Needs to Strengthen Management and Oversight of Its Prime Contractor, GAO-
11-6 (Washington, D.C.:Oct. 2010).
xiv GAO-11-6 (Washington, D.C.:Oct. 2010).

3. xv CBS News, SixtyMinutes, “Watching the Border: The Virtual Fence, Steve Kroft Reports on The High-Tech Project
That Is Supposed to Secure The U.S.-Mexican Border,” (Jan., 7, 2010) (transcript available at
http://www.cbsnews.com/news/watching-the-border-the-virtual-fence/4/).
xvi InformationWeek, DarkReading, “DHS MayScrap Border Patrol Project” (Feb. 22, 2010).