[House Hearing, 111 Congress]
[From the U.S. Government Printing Office]
[H.A.S.C. No. 111-77]
CHALLENGES TO EFFECTIVE
ACQUISITION AND MANAGEMENT OF INFORMATION TECHNOLOGY SYSTEMS
----------
HEARING
BEFORE THE
PANEL ON DEFENSE ACQUISITION REFORM
OF THE
COMMITTEE ON ARMED SERVICES
HOUSE OF REPRESENTATIVES
ONE HUNDRED ELEVENTH CONGRESS
FIRST SESSION
----------
HEARING HELD
JULY 9, 2009
[GRAPHIC(S)] [NOT AVAILABLE IN TIFF FORMAT]
[H.A.S.C. No. 111-77]
CHALLENGES TO EFFECTIVE
ACQUISITION AND MANAGEMENT OF INFORMATION TECHNOLOGY SYSTEMS
__________
HEARING
BEFORE THE
PANEL ON DEFENSE ACQUISITION REFORM
OF THE
COMMITTEE ON ARMED SERVICES
HOUSE OF REPRESENTATIVES
ONE HUNDRED ELEVENTH CONGRESS
FIRST SESSION
__________
HEARING HELD
JULY 9, 2009
[GRAPHIC(S)] [NOT AVAILABLE IN TIFF FORMAT]
_______
U.S. GOVERNMENT PRINTING OFFICE
51-959 WASHINGTON : 2010
____________________________________________________________________________
For sale by the Superintendent of Documents, U.S. Government Printing Office,
http://bookstore.gpo.gov. For more information, contact the GPO Customer
Contact Center, U.S. Government Printing Office. Phone 202-512-1800, or
866-512-1800 (toll-free). E-mail, gpo@custhelp.com.
PANEL ON DEFENSE ACQUISITION REFORM
ROBERT ANDREWS, New Jersey, Chairman
JIM COOPER, Tennessee K. MICHAEL CONAWAY, Texas
BRAD ELLSWORTH, Indiana DUNCAN HUNTER, California
JOE SESTAK, Pennsylvania MIKE COFFMAN, Colorado
Kevin Gates, Professional Staff Member
John Wason, Professional Staff Member
Alicia Haley, Staff Assistant
C O N T E N T S
----------
CHRONOLOGICAL LIST OF HEARINGS
2009
Page
Hearing:
Thursday, July 9, 2009, Challenges to Effective Acquisition and
Management of Information Technology Systems................... 1
Appendix:
Thursday, July 9, 2009........................................... 25
----------
THURSDAY, JULY 9, 2009
CHALLENGES TO EFFECTIVE ACQUISITION AND MANAGEMENT OF INFORMATION
TECHNOLOGY SYSTEMS
STATEMENTS PRESENTED BY MEMBERS OF CONGRESS
Andrews, Hon. Robert, a Representative from New Jersey, Chairman,
Panel on Defense Acquisition Reform............................ 1
Conaway, Hon. K. Michael, a Representative from Texas, Ranking
Member, Panel on Defense Acquisition Reform.................... 3
WITNESSES
Harp, Timothy J., Deputy Assistant Secretary of Defense, Command,
Control, Communications, Intelligence, Surveillance,
Reconnaissance and Information Technology Acquisition, Office
of the Assistant Secretary of Defense for Networks and
Information Integration/DOD Chief Information Officer.......... 5
Kerber, Dr. Ronald L., Co-Chair, Defense Science Board Task Force
on Department of Defense Policies and Procedures for the
Acquisition of Information Technology.......................... 9
Nielsen, Dr. Paul D., Director and Chief Executive Officer,
Software Engineering Institute, Carnegie Mellon................ 7
APPENDIX
Prepared Statements:
Andrews, Hon. Robert......................................... 29
Conaway, Hon. K. Michael..................................... 30
Harp, Timothy J.............................................. 34
Kerber, Dr. Ronald L......................................... 62
Nielsen, Dr. Paul D.......................................... 48
Documents Submitted for the Record:
Defense Science Board 2006 Summer Study on Information
Management for Net-Centric Operations, Volume I, Main
Report, April 2007......................................... 234
Defense Science Board 2006 Summer Study on Information
Management for Net-Centric Operations, Volume II,
Operations Panel Report, April 2007........................ 352
Report of the Defense Science Board: Creating a DOD Strategic
Acquisition Platform, April 2009........................... 87
Report of the Defense Science Board Task Force on Department
of Defense Policies and Procedures for the Acquisition of
Information Technology, March 2009......................... 133
Witness Responses to Questions Asked During the Hearing:
[There were no Questions submitted during the hearing.]
Questions Submitted by Members Post Hearing:
Mr. Andrews.................................................. 433
CHALLENGES TO EFFECTIVE ACQUISITION AND MANAGEMENT OF INFORMATION
TECHNOLOGY SYSTEMS
----------
House of Representatives,
Committee on Armed Services,
Panel on Defense Acquisition Reform,
Washington, DC, Thursday, July 9, 2009.
The panel met, pursuant to call, at 8:00 a.m., in room
2212, Rayburn House Office Building, Hon. Robert Andrews
(chairman of the panel) presiding.
OPENING STATEMENT OF HON. ROBERT ANDREWS, A REPRESENTATIVE FROM
NEW JERSEY, CHAIRMAN, PANEL ON DEFENSE ACQUISITION REFORM
Mr. Andrews. We are very happy to have you with us this
morning. The witnesses have done a really good job preparing
their written testimony. We look forward to hearing them
elaborate on that testimony this morning so we can learn more.
The panel is focused on the difference, if any, that exists
between cost and value for our uniformed personnel, their
support personnel, and the taxpayers of the country.
We spend an enormous amount of money in the defense of our
country, and we should. It is our responsibility to make sure
that that money is spent prudently and wisely, so those who
step forward to defend our country have the best technology
available, the best tools available to do their jobs for our
country so that the taxpayers are receiving full and robust
value for their investment in the defense of the country.
The panel's work project has proceeded in several steps. We
had begun with the question of whether there are adequate
metrics to measure the difference, if any, between cost and
value. We are now proceeding in a second mode of analysis,
which deals with hypotheses about why differences between cost
and value have emerged. The third section of our inquiry will
deal with proposed solutions to deal with those problems. Then,
finally, the panel will convene toward the end of our term and
come up with recommendations, which we look forward to
advocating in the fiscal year 2011 armed services authorization
bill.
This morning, we are going to focus on a critical
hypothesis about the difference between cost and value, and
that is the inadequacies through which the United States
Department of Defense (DOD) purchases information technology
(IT) and the challenges that we face in doing that. This is
sort of a collision of two cultures, as I see it.
For good reasons, we have a culture of deliberation and
care in the purchase of equipment and systems and supplies in
our Department of Defense, and we should. We want to be very
careful to be sure that things work right. We want to be sure
that we are doing things in an honest and proper way in the
procurement process so that the process matches the
requirements and budgeting needs of the Department of Defense.
This culture which is understandably based upon due
deliberation and process clashes with the hyperventilated
culture of the tech world where, as Moore's Law would tell us,
things always change in a big hurry, usually for the better.
So, when you combine the dynamic of the tech world with the
more deliberative culture of Department of Defense procurement,
you get some trouble. You get some challenges, and that is what
we are here to talk about this morning.
I want to say from the very outset that the gap that has
been identified between cost and value I do not ascribe to any
weakness or deficiency by any individual or institution in the
procurement process. I am not here this morning to say that
someone has dropped the ball or has not done his or her job. I
am sure that is true in some instances, but my sense here is
that there is a systemic problem which owes itself to this
culture clash that I mentioned a few minutes before, that it is
a very hard thing to capture a whirling dervish, which is this
technology dynamic, and tame it. It is a very difficult thing
to do, and we do not want to go to either extreme, right?
We do not want an extreme where we say, buy the next thing
that comes out, it will probably work. Well, that is really not
a very good way to serve our uniformed personnel or our
taxpayers.
On the other hand, we do not want to say we do not care how
fast technology is moving. If something looked like it was the
right thing to do in 2004, buy it in 2009 or 2010 or 2011 or
2012. We are looking for a happy medium between those two
polarizing positions.
Now, the data would certainly show that we need that happy
medium. Work by the Defense Science Board (DSB) task force,
which dates back to November of 2000, tells us some very
forboding statistics: Only 16 percent of all IT projects were
completed on time and on budget; 31 percent of those projects
were cancelled before completion; 53 percent were late and over
budget with the typical cost growth exceeding the original
budget by more than 89 percent, which is a very significant
number; and of the IT projects that are completed, the final
product typically contains only 61 percent of the original
specified features. Now, that could be a good thing or bad
thing.
I know one of the things that we are going to talk about
this morning is how requirements creep, which in other areas of
procurement is regarded as a bad thing, may well be a necessary
and good thing in this field because of that technological
dynamic that I talked about earlier.
At any rate, we have assembled a panel of three gentlemen
who thoroughly know this subject, who, I think, will contribute
much to our discussion this morning. We look forward to
welcoming them.
At this time, I am going to turn to my friend, the ranking
member from Texas, Mr. Conaway, for his comments.
[The prepared statement of Mr. Andrews can be found in the
Appendix on page 29.]
STATEMENT OF HON. K. MICHAEL CONAWAY, A REPRESENTATIVE FROM
TEXAS, RANKING MEMBER, PANEL ON DEFENSE ACQUISITION REFORM
Mr. Conaway. Well, thank you, Mr. Chairman.
I thank the panel for coming out this morning and for
sharing your thoughts with us.
Today's hearing is going to focus on helping us understand
how IT acquisition systems versus the normal, traditional
hardware acquisition systems differ and how they should and
getting a better understanding of the impact that different
styles, for lack of a better phrase, go at this issue.
Clearly, information technology and the hardware attached
to that is marketed differently. If you look at the F-4, which
had about 8 percent of its systems run by computers, versus the
F-22, of which like 80 percent of its systems are run by
computer, it is a different world and growing.
The Vice Chief of Staff of the Army, Peter Chiarelli, has
said that the antiquated system we operate is an albatross
around the neck of the Army. The chairman has already mentioned
the Defense Science Board's findings from the March 2009 report
that says, in short, that the report found that the fundamental
problem the Department of Defense faces is that the deliberate
process through which weapons systems and information
technology are acquired does not match the speed at which new
IT capabilities are being introduced in today's information
age. The report's principal recommendation is that the
Department needs a new acquisition system for information
technology.
While it is certainly easy to recognize that the
introduction of new IT capabilities outpaces the speed of the
acquisition system, what is less clear is what such a new
acquisition system for IT would look like. Time will have to be
a critical factor.
How will the Department minimize time of delivery while
ensuring proper oversight and avoiding wasteful spending?
Another question is, is there a reason to believe that the
DOD can be successful at such a new approach? If so, why
wouldn't a similar approach work for traditional weapons
systems?
This is particularly true as our weapons systems get more
and more IT content. At some point, how does one distinguish
between an automated information system, like a business system
or Intranet, and an aircraft that has 80 percent of its
functionality delivered from electronic sensors and information
processing capability?
I look forward to hearing from our witnesses. I want to
thank the chairman for starting this hearing right on time.
[The prepared statement of Mr. Conaway can be found in the
Appendix on page 30.]
Mr. Andrews. Thank you very much, my friend.
I am going to, at this point, introduce our three
witnesses.
Without objection, your opening statements will be included
in the record of the hearing, and we would ask you to synopsize
your written statements for us so we can proceed to questions.
I would also say that any member of the panel who wishes to
have an opening statement entered, without objection, will be
permitted to do so.
So I am going to read the biographies of the witnesses, and
then we will proceed with synopses of your statements and then
get on to questions and answers from the members of the panel.
Timothy J. Harp is the Deputy Assistant Secretary of
Defense for C3ISR and IT Acquisition. Mr. Harp is responsible
for the review of major acquisition programs for command,
control, communications, intelligence, surveillance,
reconnaissance, space and information technology programs. In
addition, he leads reviews of major defense acquisition
programs and major automated information systems as chairman of
the command, control, communications, and intelligence
overarching integrated product team in support of the Defense
Acquisition Board and Information Technology Acquisition Board.
Mr. Harp received his bachelor's of science (BS) degree in
business administration from Penn State University--he is a
Nittany Lion--and a master's of business administration degree
in financial management from the George Washington University.
He is Defense Acquisition Workforce Integrity Act Level III
certified in program management, business, cost-estimating and
financial management and acquisition logistics. His awards
include the Defense Meritorious Civilian Service Medal, the
Defense Exceptional Civilian Service Medal, and the Defense
Superior Service Medal.
Mr. Harp resides in Manassas, Virginia.
Welcome. Glad you are with us.
Mr. Conaway. Can you get that all on one business card--the
command, control, communications, intelligence, surveillance,
reconnaissance, space and information technology?
Mr. Andrews. We might have to introduce legislation that
limits the name of any group to no more than three or four
words. That would probably save us quite a bit of money in
business card printing.
Dr. Paul Nielsen is director and chief executive officer of
the Software Engineering Institute (SEI), a federally funded
research and development center operated by Carnegie Mellon
University. The SEI advances software engineering principles
and practices through focused research and development, which
is transitioned to the broad software engineering community.
The SEI serves as a global leader in process improvement
and networked systems survivability. Additionally, the SEI is a
key innovator in software architecture, software product lines,
interoperability, the integration of software-intensive
systems, and the increasing overlap of software and systems
engineering.
In a very distinguished career in the United States Air
Force, Dr. Nielsen served in the U.S. Air Force, retiring as a
Major General after 32 years of distinguished service for which
we thank him. In 2004, Dr. Nielsen became a fellow of the
American Institute of Aeronautics and Astronautics (AIAA). He
served as the AIAA president from 2007-2008. He serves on the
Air Force Scientific Advisory Board and is a member of the
board of directors for the Hertz Foundation, a nonprofit that
awards graduate school fellowships in the applied sciences.
Thank you, Dr. Nielsen, for your service and for being with
us this morning.
Finally, Dr. Ronald Kerber is an experienced executive with
a successful record of leading and growing domestic and global
businesses. His leadership responsibilities have included
general management, innovation, product development,
procurement, cost reduction, and profitability in diverse
global organizations. He currently splits his time among a
variety of entrepreneurial and pro bono activities as president
of Small Business Development Center (SBDC), a small consulting
firm; as partner and cofounder of Dominion Development Company
and Profit Station, LLC; as visiting professor at the Darden
Business School at the University of Virginia; and as a member
of the Department of Defense Science Board.
Dr. Kerber received his BS degree from Purdue University
and his master's of science (MS) and Ph.D. degrees in
engineering science from the California Institute of
Technology.
Gentlemen, thank you for your meticulous preparation. As I
said, your written statements are considered to be part of the
record.
Mr. Harp, we will begin with your oral testimony. We would
ask you to summarize in about five minutes so we can get to
questions from the panel.
Good morning.
STATEMENT OF TIMOTHY J. HARP, DEPUTY ASSISTANT SECRETARY OF
DEFENSE, COMMAND, CONTROL, COMMUNICATIONS, INTELLIGENCE,
SURVEILLANCE, RECONNAISSANCE AND INFORMATION TECHNOLOGY
ACQUISITION, OFFICE OF THE ASSISTANT SECRETARY OF DEFENSE FOR
NETWORKS AND INFORMATION INTEGRATION/DOD CHIEF INFORMATION
OFFICER
Mr. Harp. Good morning Chairman Andrews, Representative
Conaway and other members of the Defense Acquisition Reform
Panel.
Thank you for this opportunity to testify on challenges to
effective acquisition and management of information technology
systems. I have submitted my written statement, as you
mentioned, for the record, and will now briefly highlight a few
key points.
Specifically, I would like to point out some challenges
within the information technology environment that
differentiate information technology acquisition from the major
weapons systems acquisition that I experienced throughout my
22-year Navy career as a weapons system acquisition
professional. I would like to contrast this to my recent
experience over the past six years as a member of the IT
culture that you mentioned.
Based on my experience, the traditional DOD acquisition
process is far too slow to keep pace with the extremely rapid
pace of information technology change. Even the different
phases of the acquisition process, as set forth for weapons
systems, are ill-suited for information technology systems.
Phase A is intended to mature technology; yet our underlying
information technologies are now largely matured in the
commercial sector. Phase B is intended to ready a program for
production; yet information technologies typically are not
produced in quantity. Phase C is a production phase, which
again is generally not relevant to information technology that
is not produced in quantity.
The term ``life cycle'' has also become ambiguous because,
similar to the B-52 experience where we build an airframe and
then update the pieces over time rather than build a full
replacement, the inherent modularity and dynamics of
information technology and the pace of commercial information
technology development allow us to build or adopt the
information technology equivalent of an airframe and continue
to modify it indefinitely rather than replace an entire system
in a predetermined period of time.
As noted by the recent DSB report, acquisition reform
studies have been ongoing almost continuously since the
original Goldwater-Nichols legislation was passed in 1986. Most
often, acquisition-related problems in those reports have been
attributed to requirements creep and funding instability.
With regard to information technology requirements creep,
Moore's Law, the hypothesis that the power of information
technology will double every 18 months, has proven to be valid
with regard to the information technologies that we acquire.
This puts pressure on information technology acquirers to
change the system-level requirements during the design process
to enable the fielding of relevant technology.
In addition, combat operations are being conducted in
rapidly changing circumstances, placing pressure to change
requirements during information system acquisition to respond
to adversary tactics. Also our customers, the warfighters of
today, are information-technology savvy, often termed digital
natives, with expectations to leverage the unprecedented
innovation in the commercial market to enhance our information
systems and capability in terms of agility, flexibility,
responsiveness, and effectiveness, adding to the requirements
creep pressure.
The combination of these three very real forces leads to
significant requirements change pressure on our information
technology process. We should begin to embrace the concept that
changing requirements might actually be desirable for
information technology acquisitions rather than to follow the
inherent weapons system acquisition process assumption of
stable requirements over time.
Funding stability in this dynamic environment is also a
significant challenge to information technology acquisition. A
large portion of the Department's discretionary funding is
allocated to acquisition. Within the acquisition accounts,
information technology programs are relatively more flexible
because, unlike weapons system programs, information technology
programs typically do not have significant out-year production
quantities to amplify near-term changes in the execution of
budget year funding. So, when faced with a Hobson's choice, the
Department will defer to information technology more often than
weapons system technology. This aspect of information
technology programs tends to drive a degree of funding
instability that adds to the requirements stability.
In short, the weapons system acquisition process is
optimized to manage production risk and does not really fit
information technology acquisition that does not lead to
significant production quantities. Also, a foundational weapons
system acquisition assumption of requirements and funding
stability is ill-suited for the information technology
acquisition.
The information technology acquisition model proposed by
the Defense Science Board recognizes the unique aspects of
information technology, and addresses the requirements and
funding challenges through the application of agile processes
and exploitation of the inherent modular nature of the
information technology to build smaller capability releases
rather than large programs.
The Department welcomes the House Armed Services Committee
(HASC) Fiscal Year 2010 defense language that gives the DOD the
authority to establish 10 pilot programs to rapidly acquire
information technology capabilities under an alternative
acquisition process, and we look forward to working with this
panel in the future to create an effective acquisition and
management construct for the information technology systems. We
also appreciate the committee's inclusion of section 1111,
which would allow us to bring industry IT experts to DOD on an
exchange basis to help with this effort.
Thank you.
[The prepared statement of Mr. Harp can be found in the
Appendix on page 34.]
Mr. Andrews. Thank you very much, Mr. Harp. We appreciate
that.
Dr. Nielsen, welcome to the committee.
STATEMENT OF DR. PAUL D. NIELSEN, DIRECTOR AND CHIEF EXECUTIVE
OFFICER, SOFTWARE ENGINEERING INSTITUTE, CARNEGIE MELLON
Dr. Nielsen. Thank you, sir.
Chairman Andrews, Ranking Member Conaway, and other
committee members, I thank you for this opportunity to appear
before this panel, talking about a very important subject for
our country.
There have been a number of excellent studies on defense
acquisition over the years. They all pretty much agree on the
findings and on the recommendations, and I know you are well
aware of all of them. Rather than re-plow this sort of well-
furrowed ground, I would like to talk about one aspect that, I
think, is important and central to all of defense acquisition,
and that is the whole side of software in defense systems. That
is true in weapons systems, enterprise business systems, and IT
systems.
Software is almost everywhere now, and the amount of
software continues to grow, as was mentioned by Representative
Conaway. Software engineering is a young discipline, and it is
not rooted in the physical world like some of the other
engineering disciplines such as civil engineering, aeronautical
engineering, mechanical engineering, and electrical
engineering.
Without physical constraints, the design space is so vast
for these large programs, which need strong architectural
principles, disciplined processes and talented people to be
successful. The larger the program, the more important this is,
and we know the Department has some of the larger programs.
The software engineering community has made major advances
in the last 50 years, but the size, function and complexity of
software has continued to grow. The bar keeps getting higher in
these areas. As mentioned, Moore's Law has helped us a lot by
giving us more computational throughput, a lot of storage, but
this has led to more and more functionality resting in software
in all of our defense systems, and sometimes the line between
what is an IT system and what is a major weapons system gets a
little blurred now.
This is true not only in the defense world. This is true in
the commercial world, aerospace, telecommunication, automotive,
medical. Software is just everywhere. Cars now have almost 100
million lines of software in them. Telephones and cell phones
that each of us has have 2 million to 10 million lines of
software.
Tremendously innovative concepts keep opening up in the
software engineering world and new challenges as well. We are
now in an era when an increasing number of systems are linking
via networks, such as the Internet. The convenience, power, and
cost benefits of these approaches are compelling, but the
complexity of architecting, developing, testing, and operating
these ultra-large systems is daunting, and we are all becoming
more and more aware of the pervasive cyber implications of
these connective systems. We have to worry about that, too.
More than ever, we need strong quality built into our
systems from the initial design and architecture. This is a
major theme in software engineering over these last 20-30 years
that, through strong architectures, disciplined processes and
pervasive attention to quality, you can deliver complex systems
on time and within budget. And yet, by following these
principles, you will also develop software and IT systems that
are more secure.
To accomplish this, we really need the entire community to
understand software engineering principles and to work together
to address the acquisition problems we face immediately and
also to have some forward-looking research to address the
problems that are coming down in the future. We will have even
larger systems with even more connectivity.
IT systems have their own unique characteristics. We really
have to worry about the different tempo that IT systems have
and the ubiquity of IT systems, but we also need to worry about
the systemic issues that affect IT and weapons systems programs
as well.
As we look to the future, the bar is going to keep getting
higher. There is no doubt about that. We are going to need
government engineers and program managers who are trained and
experienced to handle the systems we build, who understand the
architectural principles and trades that are made and who have
the expertise and passion for this business. We will need
industry engineers and managers on the IT as well as on the
weapons systems side who have kept up with the latest
techniques and who have contributed to the best practices and
innovations in software and systems engineering. We need robust
research programs at our universities to address the
opportunities and problems that are yet to come.
Mr. Chairman and committee members, with that, I will end
my statement, and I look forward to your questions.
[The prepared statement of Dr. Nielsen can be found in the
Appendix on page 48.]
Mr. Andrews. Dr. Nielsen, thank you very much. We
appreciate your testimony.
Dr. Kerber, welcome.
STATEMENT OF DR. RONALD L. KERBER, CO-CHAIR, DEFENSE SCIENCE
BOARD TASK FORCE ON DEPARTMENT OF DEFENSE POLICIES AND
PROCEDURES FOR THE ACQUISITION OF INFORMATION TECHNOLOGY
Dr. Kerber. Thank you.
Mr. Chairman and members, it is a pleasure to appear before
your panel. I am a member of the Defense Science Board, and I
have submitted to you copies of three reports that inform my
testimony.
Mr. Andrews. Without objection, they will be entered into
the record.
[The information referred to can be found in the Appendix
beginning on page 87.]
Dr. Kerber. Okay. I must also state that I am appearing as
a private individual, and my comments do not necessarily
reflect those of the views of the Department.
We have looked at the defense acquisition process, and as
you well know, there have been many reports and many studies,
and the question is: Why do these activities not address the
problem that has lasted for so long? We would say that it does
not address the root causes of the problem.
The problems appear to be caused by immature technology,
requirements creep, funding instability, but we would argue
most of that is caused by inexperienced and unproven
leadership, and programs are not structured and initiated in a
way that can be successfully completed. There is no silver
bullet to solving this problem. It is really a commonsense
approach.
We also think the problem is beyond the scope of the Under
Secretary of Defense for Acquisition, Technology, and Logistics
(USD-AT&L). It is really a problem of the scope of the
Secretary of Defense (SECDEF), and it should be because many of
those players who perform in the acquisition arena do not
report to the Under Secretary of Acquisition.
So what is needed?
It seems simple, but we need to buy the right things. We
need to select an effective leadership team. We need to reform
and streamline the acquisition process, and we need to improve
acquisition execution. We also need your support in helping the
Department to do this, and we need to instill a sense of
urgency.
Just a couple of comments on buying the right things: That
seems simple, but we really need a resource-balanced business
plan-type concept for the DOD that includes funded acquisition.
We need to specify the capability needs to support our National
Security Strategy. Then we need to also effectively represent
the combatant commanders in the process of determining what we
buy. Then we need to use comprehensive systems engineering and
analysis early and throughout the process to determine what we
are buying and how we are buying it. We need to avoid hard
requirements without extensive analysis and trade-off.
Then we need to, secondly, select an effective leadership
team. Acquisition cannot be fixed without a proven effective
leadership team, and that goes back to the recommendation of
the Packard Commission. Signs of poor leadership include poorly
designed product development strategies, poor management of
technical risk, the selection of inexperienced contractors,
poor contract incentives, and reward for change orders. Skills
in program administration are often confused in the acquisition
community with management ability. Managers manage what they
understand. Proven experience should lead to better judgment
and execution.
Another point that is equally important is that the
Secretary of Defense has many offices that contribute to the
decision process and acquisition, such as Program Analysis and
Evaluation (PA&E), the Chief Information Officer (CIO), the
Director of Defense Research and Engineering (DDR&E), the
Comptroller, and the Operational Test and Evaluation (OT&E),
plus the services, of course. Often these groups are not
aligned. These groups must be aligned once a decision is made
to have an acquisition or to buy something in the Department,
and their constructive input should be early and continuous,
not just at decision milestones.
We need to improve acquisition processes for major systems,
commercial derivatives, information technology, and services.
We need to establish more streamlined processes with in-depth
analysis up front, planned spiral development and block
upgrades, and the use of competitive prototypes.
For IT acquisition, these systems continue to grow both in
size and in content in embedded systems. The DOD acquisition
process is inconsistent with the rapid change of commercial IT
technology.
You, Congress, have imposed new requirements to shorten the
acquisition IT cycle time for all but national security
systems. That is important, but the Department needs processes
and the capability to do that.
We have recommended for the IT acquisition process a new
streamlined decision process, and we have also recommended how
and when to use it. We also want to point out that, as has been
mentioned earlier, IT systems do not satisfy the laws of
physics, and so we do not always know what we are buying, so we
need to minimize the acquired system vulnerabilities. We need
to adopt an IT acquisition strategy that confounds the enemy,
using variety, change and rapid acquisition. The Joint Chiefs
must assure that field commanders are trained to test
information technology systems for authenticity and to operate
them in degraded modes. We need to clarify IT off-site
accountability. We need to strengthen the CIO authority for the
enterprise to provide IT vision, policy and architecture, and
we need to make sure that we identify clearly who has oversight
accountability for all systems. As the growth of IT systems
continues, that percentage of the total acquisition will grow,
and we feel that that needs to be managed under the Office of
the USD (AT&L).
We need to improve acquisition execution. I have talked
about that in the report. I would just say a significant point
is we need to right-size the acquisition workforce with
experience. We can do that by process mapping the process and
the workflow to determine the right size and to assure clear
accountability and authority for everyone. Finally, we need to
develop process metrics for all that we do.
Just one final comment. In the private sector, there are
different characteristics for acquisition. The customer is
clearly defined. The decision authority is more clear.
Accountability is more clear. Incentives are more clear. Yet it
is very difficult to do this process even in the private
sector, and few private companies really do it well. Especially
for the DOD, it is very difficult to do this kind of process on
a public stage.
Thank you.
[The prepared statement of Dr. Kerber can be found in the
Appendix on page 62.]
Mr. Andrews. Well, thank you very much.
We appreciate the statements from each of the witnesses,
and we will begin the questioning.
Mr. Harp, you made reference to the language that would
authorize 10 pilot programs for an alternative acquisition
process in IT, which the committee has supported.
Can you give us some thoughts about what principles you
might rely on in that pilot process and what kinds of
differences you would institute in the acquisition process?
Mr. Harp. Well, as we look to the inventory systems that we
are considering, there seem to be four natural types of
systems. We have some systems where we are buying just
commercial, off-the-shelf hardware, and that is considered an
IT system. That does not require the same process as a system
where we are actually developing and writing software code and
developing a capability by writing code.
Another type of acquisition that we do is we buy software
that is commercial software, and we put it together, and we
build the interfaces between the systems, so we develop a
system of systems, if you will, using commercial off-the-shelf
(COTS). So that would be a different approach as well.
So we are looking at some different templates on how we
might approach that, but some of this becomes--I mentioned the
B-52 model. If you get to a system where you do not really need
to replace the core system--there have been studies that show,
when you build a new system, up to 60 percent of the code you
have to write to make it work does not get used over time, so
we do not want to replicate building that 60 percent. A lot of
times, we can take the core system that we have and just fix
the piece that is broken or can add the capability that you
need by building modules, right? With the funding discussion
that I had, we have seen through our experience that many of
these programs are level-funded over time, and the decision on
how much you are going to fund in an acquisition program is
actually made during execution rather than----
Mr. Andrews. But, in layperson's terms, what would you try
to do differently in the pilot as opposed to what is being done
now? How are you going to use the pilot to break new ground?
Mr. Harp. What I would do is take a larger system, identify
the modules of that system and the interfaces, the commercial
or standards that exist for those modules to talk together, and
would approach each module as if it were a separate release, or
a separate part of a system, rather than waiting for all the
modules to be developed before we go to test. So you can test
and release individual systems in an agile fashion, individual
releases in an agile fashion, rather than waiting for the
entire thing to be completed, because oftentimes we will have
several modules under development in parallel, and we cannot
get to the final test until we complete the final module, and
other modules that could be used are----
Mr. Andrews. I think it was your testimony that said that
the average time to get to the finish line was about 81 months.
Was that in your statement?
Mr. Harp. Yes, sir.
Mr. Andrews. What do you think a plausible goal is to
reduce that to? In an optimal world, if the pilot worked great
and became a great success, by how much time would we reduce
that 81 months?
Mr. Harp. Well, conceivably, you could reduce it to 12 to
18 months, but again, you are not talking about delivering the
same thing. The 81 months is a large system with several
releases, with several modules, all delivering at the same
time. In 12 to 18 months, you could deliver capability in
pieces of that large system, so it is not really an apples-to-
apples comparison.
Mr. Andrews. I assume this is where the open architecture
and the standards become important.
Mr. Harp. Yes, sir. Yes, sir.
Mr. Andrews. If your first release in month 18 becomes
obsolete by month 36, you have got to have a platform where it
can easily be modified, an architecture where it can easily be
modified, and not tear it up and start all over again. Am I
right about that?
Mr. Harp. Yes, sir.
Mr. Andrews. Dr. Nielsen, one of the ideas that you talked
about, and it really followed on Mr. Harp's testimony, was sort
of changing the presumption of purchasing and procurement in
the IT world. In the regular procurement world, although it is
rarely met, the presumption is that the requirements you start
out with should not change and that there has to be some burden
of proof on he or she who wants to change the requirements. You
are suggesting a different presumption, I think, in the IT
purchasing world where you presume there are going to be
changes because of Moore's Law, and you have a different
question, but you also said that the line between software
procurement and weapons systems is blurred.
Dr. Nielsen. Yes.
Mr. Andrews. So how do we reconcile that problem?
If we were to take your idea and institutionalize in the
law a different set of presumptions about requirements in the
IT purchasing, where would we draw the line between the IT
purchasing and the weapons system purchasing so we do not
exempt weapons system purchasing from some very important
adherence to requirements that we start out with?
Dr. Nielsen. Well, sir, I think there are some things that
are clearly pure IT systems, and I think Mr. Harp mentioned
that. You know, if you look at the desktops of everybody in the
Department of Defense, they have desktops that are commercially
procured desktops for the most part--Dell, IBM, whoever--
computers with Microsoft or Apple or whatever software. That is
kind of clearly in the IT world.
Mr. Andrews. Right.
Dr. Nielsen. But as you migrate more to command-and-control
systems, which have an information technology kind of function,
you start to get to where life-and-death decisions are made
based on these things, so it starts to migrate into the weapons
system.
Mr. Andrews. I mean, is the data system in the cockpit of
an airplane an IT acquisition, or is it a weapons system
acquisition?
Dr. Nielsen. You know, I would consider it a weapons system
myself.
Mr. Andrews. Yes.
Dr. Nielsen. But yet it certainly has some IT----
Mr. Andrews. You understand the importance of that question
is not simply metaphysical.
Dr. Nielsen. Yes, sir. Yes, sir.
Mr. Andrews. One of the driving forces in cost overruns and
weapons systems is requirement changes.
Dr. Nielsen. Right.
Mr. Andrews. Requirement creep.
If we want to wrestle that problem to the ground, we
certainly want to keep the present presumption, which is that
the requirements you start out with do not change.
On the other hand--and I hear what you are saying--if
Moore's Law has pushed the envelope and, by year six of a
procurement process, the system we are going to put in the
cockpit is not the best one, we do not want to be stuck with
that either.
Dr. Nielsen. Yes, sir.
I remember, you know, I was the vice commander of the
Aeronautical Systems Center, which buys the airplanes for the
U.S. Air Force, from 1999 to 2000. At that point, even as the
F-22 was coming into production, there were some parts that
were no longer made for it that were baselined into the system
because they were IT kinds of parts that were designed in the
1980s, and you know, in the year 2000, you are not going to
have those parts anymore.
So we have a pace problem in all of our systems right now.
I would like to see us experiment on the IT systems, especially
with the ones that are more on the pure IT side; but if we find
principles that work there--gosh knows we have some issues in
the weapons system acquisition world, too--then maybe we can
take those good ideas and best practices----
Mr. Andrews. This is what we are hoping, that Mr. Harp's
pilot will lead us to some good data and to some good
conclusions about that. My time is up for now.
I will turn to my friend Mr. Conaway for his questions.
Mr. Conaway. Thank you, Mr. Chairman.
Again, thanks, gentlemen, for being here.
You know, anecdotes drive a lot of stuff. I recall, in
2005-2006, the Army had a requirement for a biometric tool they
could use in Iraq to capture fingerprints. There was an
elaborate process of designing what that ought to look like,
how much it ought to weigh, the battery. One of the deals was
weight. They said it had to weigh seven pounds.
While they were trying to work that out, the commercial
side of the world had a three- or four-pound thumbprint/
fingerprint model that was available. You know, I do not know
if it was at RadioShack, but it was available out there, so
that kind of exemplifies the struggle that we have got.
Mr. Nielsen, you mentioned the laptops that everybody at
the Pentagon is using and the struggle that most organizations
have of making sure every three or four years those are, you
know, redone or replaced or whatever. That is the mundane side
of what we are talking about. Then you have got the clear
message you mentioned about the F-22 in that, you know, it was
21 years between the start to the first time it landed at
Langley to go to work.
Dr. Nielsen. Yes, sir.
Mr. Conaway. There is a whole world of difference in the
size and in the power of that deal.
The key, though, is people. Mr. Kerber, you mentioned that.
At Price Waterhouse, if I could get the really bright staffers
to work my jobs, my life was real easy. If I got the less--you
know, the brand new rookies, my life was not very easy. So it
all gets down to people. You know, your stereotypical IT person
does not wear a uniform and does not work the same hours. I
mean, it is a different culture altogether.
How do you get the right people who are willing to make
those commitments? If you have got that background, how does
the Defense Department keep them and incent them to stay on
board? How do you address that?
Any of you.
Dr. Nielsen. Perhaps I will answer a little bit on that.
When I was the commander of the Air Force Research Lab, we
were always looking for great people, and we were competing
with industry lots of times for the smartest people we could
find. We found that there were lots of people who wanted to
come work for the government. There are lots of people in our
country who feel a commitment, and they want to provide some
service for our country, whether it is in uniform or as
civilians.
There are some impediments. One of the impediments we had
that, I think, this committee is trying to address is, when we
tried to hire people, it could take 9 to 12 months before we
could bring them on board. Even if they were committed to us,
if they were staring at an offer from a company that was ready
to respond in two or three months, it was hard for them to wait
for all that time.
Mr. Conaway. Is that because of security clearances or
what?
Dr. Nielsen. It is for all kinds of reasons, sir. It is not
just security clearances. Some of it is just the personnel
system itself. We have to be able to respond faster, and I
think there are some innovative proposals that are being made
for how we might respond faster to hire the kind of people who
want to provide some service to our country.
Mr. Conaway. Mr. Kerber, any thoughts? You are out in the
real world.
Dr. Kerber. I would think, first of all, the Department
does offer very interesting and challenging problems, so that,
by itself, is a little bit of a draw. Strong recognition would
help. Also, you have several special programs to hire a
specialist, if you will, and when we have looked at it, those
programs have really been underutilized. You do also have a
bonus structure that you can award bonuses for outstanding
performance. So, between bonuses, recognition and giving
challenging problems, you have an opportunity, if managed right
and effectively, plus the special hiring capability, to do
that.
Mr. Harp. Today, the HASC section 821 is enhancing the
expedited hiring authority for defense acquisition workforce
personnel.
One of the things we could do to get these two cultures to
cross the two cultures would be to expand that to include the
IT workforce, including the Information Assurance (IA)
personnel, who are trying to build up for our cybersecurity and
that kind of thing. So, if we could expand that provision to
include the IT workforce, that would be helpful to us. We have
a parallel challenge in the IT culture that you mentioned in
the acquisition culture. We need to bring them both along at
the same time. So, if we could get that expanded to the IT
workforce, that would be helpful.
Mr. Conaway. Yes.
Mr. Harp. I will mention, though, that I feel that there
are some examples of where the weapons systems have
successfully embraced the commercial technology. We have a
submarine combat system that is based on commercial technology.
The only hardware components in there that are not commercial
are the transducers and the racks. The racks have to be special
because they have to be water-cooled because of the fans, and
air-cooled makes too much noise for the submarine. Other than
that, all the cables, all the screens, all the circuit cards,
everything in that system, and 80 percent of the software in
that system is commercially procured.
The program has a lab-like environment, the program office
that they have been running for almost 10 years now, that
watches over the commercial industry and that follows the
commercial industry. When one of those components is upgraded,
they bring the piece in and test it and make sure that it does
what it says it will do and that it has all the right
requirements for our environment. When it gets a green light,
then they plan on which submarine it will go in next, and they
orchestrate that whole process.
So there are models out there that are like, as you
mentioned, anecdotal, that show that we can make progress in
this area. Now, there are some challenges with that model, and
we are looking at that, but that is the kind of thing that we
are trying to move towards to address this IT in the weapons
system world.
Mr. Conaway. Thank you, Mr. Chairman.
Mr. Andrews. Thank you, Mr. Conaway.
The Chair recognizes Mr. Ellsworth for five minutes.
Mr. Ellsworth. Thank you, Mr. Chairman.
I benefit in the downside of being number three, as Mr.
Conaway asked my first question about personnel and about
finding that talent.
Mr. Kerber, I do not know when the last time was that you
were in West Lafayette, but it is still alive and well.
Welcome to the Boilermaker.
Dr. Kerber. Good.
Mr. Ellsworth. Since we had the Nittany Lion comment
earlier, I thought I had to throw one out there for Hoosiers.
Dr. Kerber. Thank you.
Mr. Ellsworth. We do that all the time, don't we?
Mr. Andrews. I understand. That is right.
Mr. Ellsworth. Dr. Kerber, could you talk a little bit more
about--you made a comment about quick change to confound the
enemy. I know, again, everything we are talking about is
counterintuitive to what we are saying of finding something
that works and something that takes long to initiate. Then
again, we want to change it because we know the enemy is
constantly changing also.
I guess I just would like you to explore it a little more.
I guess it goes back to Mr. Harp's module, which is that we get
the base, and then we are plugging in new modules to change it.
Is that kind of what we are talking about? Maybe you would like
to elaborate more on that.
Dr. Kerber. Yes, let me just explain that in context.
First, we did one study where we said that the information
management system of the Department needs to be considered part
a weapons system because of the importance of it in managing
combat and in managing our troops and their logistics, their
availability, including precision weapons, et cetera. So,
whether it is in the fighter aircraft or it is a handheld or it
is a personal computer (PC), it should be managed as a weapons
system and protected that way.
The issue you have when you change systems too rapidly, of
course, is every time you change a software system, you need to
take with that some training. And you can really have chaos in
the field if you are not careful about how you manage training
along with the introduction of new systems.
I would argue, whether it is in a fighter aircraft or in
any other system, that you do need to plan for upgrades at the
start of any program so that you can continually upgrade it in
an orderly way. It does not have to absolutely track commercial
technology, but it certainly does have to track it well enough
so that you can keep current with replacement parts and the
capability you would like.
With that, you would like to do things rapidly enough so
that the enemy who is trying to penetrate your systems,
especially some of the larger, sophisticated command-and-
control systems, you would like to change parts of that so that
their penetration of those systems is more difficult. So you
have to balance the acquisition, the training and the
confounding the enemy, if you will, as a group in order to have
an effective weapons system.
Mr. Ellsworth. Dr. Nielsen.
Dr. Nielsen. Yes, I would like to add just a little bit to
that because he is right on in this regard.
One of the things, in the software engineering world, we
talk about something called quality attributes. In the systems
engineering world, they talk about nonfunctional requirements.
One of the big quality attributes of nonfunctional requirements
for all of our systems is actually the ability to evolve. I
think that, when we see the IT systems, this may be one of the
most important requirements that is out there; yet it is one
that is often not specified. But we do not really start from
scratch in any of these systems. We have systems that have to
evolve over time, and I think if we start paying attention to
more of that and architecting for the evolution of our systems,
we would be in a lot better shape.
With respect to some diversity in our systems, we have, for
the large part, what we now call a monoculture. A lot of our
systems, especially our IT systems, are Intel- and Windows-
based. That means that if you are an enemy, if you are a cyber
enemy, you know what you have to go against. It would be a lot
better for us to have a little more of a diverse culture there
and to have some systems that are not Windows-based and that
are not Intel-based because that makes it harder for people to
attack, and if they can bring something down, they cannot bring
the whole system down.
Mr. Ellsworth. Thank you very much.
Mr. Chairman, we have got a tough road. I yield back.
Mr. Andrews. It is one we will traverse together.
The Chair recognizes Mr. Coffman.
Mr. Coffman. Thank you, Mr. Chairman.
There has been a movement afoot to say that we have
outsourced too much in terms of the technical expertise engaged
in the contracting process and that to improve the process,
that we are going to bring a lot of that expertise back in and
have them as Federal employees as opposed to private-sector
individuals under contract. Some of you have addressed the
issue about competing for expertise in the private sector
versus the public sector.
Is that, in the world of the IT professional of needing to
move this process along, bringing that expertise in-house
versus having it available on a contractual basis as needed, is
that movement going to hurt or help moving the IT process
forward in defense acquisition?
Mr. Harp. Well, this argument is interesting in the IT
world because, in the IT world, what we outsourced largely were
people who were writing code, and what we are trying to bring
in are software systems engineers who can manage contracts
where the vendor is writing the code, but they understand the
necessary hard points to make sure that it is done right and
that it fits into the open environment we are trying to
develop.
So we are not bringing back the same skill set that we
outsourced, and we are bringing it back in a lesser quantity,
and we will still be dependent upon industry to do the code
writing and the things that are more dynamic while we maintain
an ability to understand what we are asking for and an
understanding of what they are delivering. So that is the
balance we are trying to achieve, but we have a ways to go.
Dr. Nielsen. Sir, I think you have really no alternative
but to have people in the government who are educated at some
level. They perhaps do not have to be the design engineers, but
they have to have engineering awareness if they are making
complex decisions. If they are managing programs that have
engineering challenges in them, they have to know enough to
know if what they are being told is right to make good
decisions.
Another thing that is very important in this regard is that
you cannot just rest on a person's education, you know, when
they finish school in 1981 or in 1985 or whatever. This is an
area that is expanding so fast that you have to have continuous
education in this, so the government has to continue to send
these people to short courses, long courses, whatever it is, to
maintain their currency in this regard.
Dr. Kerber. Maybe I will make a couple of comments.
One is, I think you clearly need the leadership in the
Department who understands the problem, who has actually done
it well, and who can provide oversight and guidance and
understand when things are in trouble and how to start and
manage programs. So you certainly need that within the
Department.
If you talk about, as was mentioned, creating code or
creating even new ideas, I think you are really going to have
to rely on the private sector for that because that is where
that really comes in. I just think back to my many cases of
managing technical people. If you have a large cadre of
technical people in-house, they become very defensive of what
they have designed and have developed. That is called the NIH
problem, not invented here, and they are very resistant to
ideas that come from outside. And so you need a capability to
reach out, because if you do not reach out, you will never keep
up with the private sector. So I would say there is a danger of
having too much development inside that would actually thwart
your ability to keep current on the outside.
Dr. Nielsen. That is true.
Mr. Coffman. Thank you.
We have had testimony in prior meetings in defense
acquisition whereby the issue about requirement changes would
come up, and it might be that, you know, somebody just felt
that they had a better way of doing it or that there was an
analysis of current threat conditions and they had changed or
something was left out, but that requirement changes were out
of control, and that they were driving costs, and you know,
that we needed to just kind of close the door at some point and
say, this system is good enough. Let's just go forward.
On the IT side of that, is that just more straightforward
in terms of the changing requirements for IT versus the
hardware weapons acquisition process, itself?
Dr. Kerber. Maybe I will comment. A couple things.
One is I do know that our attention was brought to the
Defense Logistics Agency (DLA) and them bringing in a new
logistics system. The person in charge of that, I cannot
remember his name. But anyway, he basically froze the
requirements, brought in a system, and then opened it up for
improvement. We would argue that the smart way to do that is at
some point freeze requirements--I do not even like the word--
freeze capabilities, introduce the system, make a list, then do
a spiral development or block upgrade and have that planned
from the get-go. Then you have an orderly way of bringing in
new ideas. And you cannot continually just dribble them in. You
have got to bring them in, in blocks, and maybe in the 12 or 18
month sequence, you bring in the new ideas you have. It is a
very orderly way to do it. You can train your workforce. You
can deliver the systems capability much quicker, and it is
always essentially current.
Mr. Harp. Where that is a challenge is when you freeze the
system for too long a period of time. You start running into
Moore's Law. You start running into people that are saying, I
cannot wait for this; I have got to do it now to get my job
done, and they work around you. That is where some of that
requirements churn comes in.
So I agree. You need to freeze it at some point, but you do
not want to freeze it for a period of time so, when you deliver
it, it is obsolete and you have got a huge cost to fix it and
to implement it. So there is a balance there.
Again, it argues back to the DSB model that says, have
shorter, smaller programs, and deliver things in modules rather
than freezing an entire capability until you get the entire
capability built, right? So, for each module, you might freeze
that capability until you build it in the short period of time.
That has more chance of success than freezing the entire
capability until you deliver the entire system.
Mr. Coffman. Thank you, Mr. Chairman.
I yield back the balance of my time.
Mr. Andrews. Thank you very much.
Mr. Cooper is recognized.
Mr. Cooper. Thank you, Mr. Chairman.
I thank the witnesses.
I am worried that you IT guys basically are at the
frontlines of a cyber war that is already happening, whether
declared or undeclared. You get some attention but not that
much. This is a war that is hard for people to comprehend
because it is regardless of national boundaries or timetables
or nationality or anything like that. So, with all the
bureaucratic gobbledygook that we hear in these reports, there
tends to be a certain lack of urgency and awareness. There also
seems to be no more difference between capability and
vulnerability because any system is attackable.
Dr. Nielsen mentioned, wouldn't it be nice to have diverse
cultures? You know, we are so wedded to chips made primarily in
mainland China that are so almost infinitely complex, that you
add an infinitely complex software overlay of it with a couple
hundred million lines of code, who knows? And are we hiring the
best students from the best schools? You know, Mr. Conaway's
question.
This is an area that should be focusing more national
attention. So I am grateful for your all's expertise, but even
in your testimony, I feel a certain lack of urgency. I
appreciate Dr. Kerber's recent reports, excellent work for the
Defense Science Board, but I have this nagging feeling that our
defense establishment is not getting the best that the private
sector has to offer and that we are having difficulty
recruiting the best to join the government service.
I know there are a lot of wonderful people who have been
patriotic enough to join and to survive the 9- to 12-month
delay in hiring and all the bureaucratic rules, but I think we
should be working as strenuously as possible to make it much
easier for the best to come work for Uncle Sam and to stay
working for Uncle Sam and to achieve things that leave Google
and Microsoft and all these other high companies awestruck.
Yet I get the sense that we are more awestruck by them than
they are by us. I know their compensation packages can be
larger than we can imagine and things like that, but there has
got to be a way so that we feel the urgency of this struggle
because, when the Pentagon is hacked 35,000 times a day, when
there is an allegation that someone has already stolen F-22
code, and various government departments were hacked just two
or three days ago, you know, we are dangerously somnolent about
this.
When I have talked to our defense friends and have asked
them what kind of computers they have at home, it is never the
system that is in the office. Never. I am not knowledgeable to
know which one is better, but it is getting pretty scary here.
So I hope you gentlemen bring to your jobs a sense of
urgency, and if these are truly SECDEF-level issues that are
beyond, you know, under secretaries or assistant secretaries or
anything like that, well, let's make sure the SECDEF is paying
attention.
I think Gates, overall, is doing a great job, but for
issues of this importance, it should not be, you know, a few
sleepy folks at eight o'clock in the morning who are talking
jargon that most people cannot understand. This is as important
as Iraq or Afghanistan or anything because this is everything.
This is every weapons system. This is the security of every
American. This is the security of our banking system and tons
of things so that these are no longer technical issues. These
are life and death survival issues that, unfortunately, due to
the science involved or the math or the technicalities, a lot
of folks just are not getting.
So maybe to the extent you could help us translate these
issues into plain, everyday English, it would be good because
people have to enlarge their imaginations to be able to cope
with the challenges they are facing. Right now, this is far
more difficult for them to think of than biological warfare or
things like that that are also exotic, but at least people have
a sense of disease. They are less aware of viruses, computer
viruses.
So this is more of a statement than a question, but I
appreciate your all's expertise. Really, challenge this
committee. Challenge your superiors to be the best that they
can be.
That is all I have got, Mr. Chairman.
Mr. Andrews. I congratulate the gentleman for using the
word somnolent, which is the first time it has been used in the
committee's proceedings. I am very impressed by that.
Mr. Cooper. It is not a New Jersey word.
Mr. Andrews. No, it is not. You can't use a lot of New
Jersey words here in this sort of place.
With the indulgence of my colleagues and the panel, we
would like to offer people a second round of questioning. I am
going to take that option myself.
The disturbing news is evident. And as I said at the
outset, that 53 percent of the IT projects are late and over
budget. Typical cost growth exceeds the target budget by 89
percent. This is at a time when our reliance upon software and
IT work is growing in importance. An interesting chart, I
believe it is from DSB task force. The F-4, 8 percent of its
functions were performed by software in 1960. By 1970, the F-
111 had 20 percent of its functions performed by software. By
1982, the F-16 had 45 percent of its functions performed by
software. Then you get to 2000, the F-22, 80 percent. And I am
sure that number is growing.
So the importance of this is growing, but the problem is
worsening. I want to focus for a minute on the success stories.
And I guess I would ask you which entities, if any, within the
DOD world have different results? Which entities have proven to
be successful models at the acquisition of IT products? Are
there some corners of our system right now that are working
well or at least better than these data? If so, who are they?
Where are they? And what have they gotten right that the rest
of the system hasn't?
Dr. Kerber. I will just comment, Mr. Harp mentioned the
submarine program, which is designed to be changed out with COT
systems in an orderly way. And as we looked at it, it was one
of the top managed programs in IT in the Department.
Mr. Andrews. Now, Dr. Kerber, to what do you ascribe the
relative success of that program? I think I know, but I would
like to hear you answer the question.
Dr. Kerber. Well, they do have strong leaders, and the
leaders come up through a program in the Navy that is--trains
them basically. But also they have designed the whole system
and process around the concept that they need to refresh it
periodically. And so they can do that in an orderly way by the
way they set the capabilities that they need, how they acquire
them, et cetera. So the whole program is structured for success
basically.
Mr. Andrews. Do you know offhand the data that would
compare, the data I just used about how they matched up with
respect to time and budget in the submarine program?
Dr. Kerber. I don't, but I know they were doing a good job.
I don't know the numbers.
Mr. Andrews. I think what we will do is ask the staff to
just supplement the record. That was kind of a pop quiz. I
wouldn't expect you to know it.
Dr. Kerber. I don't work for the Department incidentally.
Mr. Andrews. One of the things we want to do in this panel
is to look at problem areas without question, but also look at
some success areas and try to learn from those best practices.
One of the statements, I am not sure which, said it is very
important not to use problems as a stick to beat people over
the head with. I am not sure whose testimony that was in, but I
appreciate that. I said at the outset, I don't think we have a
lot of incompetent, ill-intentioned people creating these
problems. I think the opposite is true. We have a lot of really
dedicated, competent people who are working within a system
that is just not serving them very well. So we want to find the
instances where there has been success and learn from those
instances and try to replicate them.
Would either of the other two witnesses want to answer that
question.
Mr. Harp. We have had some success. We are kind of in what
I call an interim ugly period right now. Because we are going
from these large systems that evolved using proprietary
software, millions of lines of code; we are trying to evolve to
a system that is more of a layered process, as service oriented
architecture (SOA) or cloud computing or some of these new
concepts. And as we progress into those new realms, it gives us
much more ability to control the dynamics of the IT world.
Where if you are in a proprietary environment, it is very
difficult to do that.
One of the agencies that is out in front in that area right
now that is making some progress is the National Security
Agency (NSA). They have a couple of programs that are not--I
don't want to say they are--I don't want to hold them up as
saying complete, but they are making progress in the right
direction here. And they are a little bit out in front on that.
So I would hold them up as a good example. They turned around
their process in the last few years and have made some good
strides.
Mr. Andrews. Dr. Nielsen, do you have any----
Dr. Nielsen. Sure. Sure. This is an area that teaches a lot
of people humility, and as Churchill once said, we have a lot
to be humble about in this business.
Mr. Andrews. We in the Congress fully understand that.
Dr. Nielsen. But there are some success stories out there.
They are too isolated. Naval Air Systems Command (NAVAIR) has
done some wonderful work, especially on reengineering software
on some of the maintenance software that they build for systems
that are already in existence.
Warner Robins in the Air Force has done a really wonderful
job on elevating their software game and doing pretty well on
some of the software that they provide.
The Army has had a really interesting story over the last
five or six years where they have crafted an education program
for all their senior leaders, acquisition leaders, to be more
aware of software engineering principles, architecture and
such. And we are seeing some effect of that as it----
Mr. Andrews. Is that done through the War College?
Dr. Nielsen. It is done some through DAU, the Defense
Acquisition University, and some through an Army-specific
program. And the people at Army Redstone in Huntsville have
particularly benefited from that.
Mr. Andrews. I know Chairman Skelton has an acute interest
in military education. He will be interested in that.
Dr. Nielsen. And then there are some in the intel
community, too, that is a little harder to talk about. But
there have been some successes in the intel community as well.
Mr. Andrews. Very good. We are going to look more closely
at those examples, because, again, we want to identify places
where people are making progress and try to replicate those
models.
Mr. Conaway, did you have follow-up questions?
Mr. Conaway. One other question, real quick question, is in
line with the successes. But does DOD have an enterprise-wide
set of metrics that says, here is what success would look like
in the IT world? And then, do they actually systematically and
comprehensively collect data over time to measure various
systems against those metrics to say--in fact, flush out who
the good guys--who are having successes and who have been
humbled is a better way to put it?
Mr. Harp. The metrics that we have been using have been the
financial metrics and the acquisition process metrics. And the
whole purpose of this study in committee is that we found they
don't work very well in measuring IT success. Because of the
churn in the technology, if you say I want to have an
acquisition baseline and, five years later, I am going to
deliver something, five years later you can deliver something
that the warfighter thinks is great but is totally broken from
an acquisition perspective because it was successful.
We have built systems for a small group, and it worked so
well in other groups that say, hey, I want that, too. And
pretty soon the system that was intended for 10 people is now
being used by 1,000, right? So the cost went up tenfold, and it
generates a statistic like we are mentioning here that you add
cost growth, but in fact, it was a successful system because it
expanded beyond what they imagined it would do.
So I don't think we have a good set of metrics, and that is
part of what we are trying to develop here as part of this
effort. And I guess I will just leave it at that. I think that
the financial metrics and I think the milestone metrics for a
fixed big program are the wrong metrics. I know we have been
successful--you will see a correlation between the successful
programs that we find and mention and size. Smaller programs
are more successful. If we are delivering--we can compete with
industry delivering programs of 75,000 lines of code or less.
When you start getting up into the million lines of code, even
industry can't deliver them on time and schedule. And so that
kind of suggests that this whole direction that we are going
with the small modular approach may lend itself to more
successes.
Mr. Conaway. Anybody else?
Dr. Nielsen. Yes, sir.
Sir, I am a strong proponent of earned value management.
The DOD uses that, but sometimes not to the level of fidelity
that they need early in a program. We found that if you do this
where you really get credit--you plan what your work is going
to be, you budget what your work is going to be and then you
measure against how that is being done, you have to do that at
a fine enough level of detail to get an early indication of
whether you are successful. It is not good enough to find out
five years into a program, because then you are really in
trouble. We have had some successes with that in the military.
The Navy program has done that somewhat. NAVAIR has done
that. But in addition, we have worked with some of the
commercial companies and had great success with this. The one
we are most proud of I think is some of the work we have done
with Intuit, that of course works on Turbo Tax and Quicken and
some of those products that follow some of these principles and
has seen a remarkable improvement in their productivity and in
their ability to meet their schedules, which obviously for tax
software was very important.
Mr. Conaway. Thank you, Mr. Chairman.
Mr. Andrews. Mr. Ellsworth, any follow-up? I am sure you
are going to say that the good example is these Boilermakers.
Mr. Ellsworth. I was just going to say that, now that Mr.
Cooper is gone, I think what he was really trying to say, and
being from Tennessee he will understand, that everybody wants
to shoot the rabbit, but nobody wants to skin it, is an old
saying. And that makes it much more simple for me being from
Indiana.
I guess my question then is, who do we need to skin the
rabbit? Like you said, is it the SECDEF? Is it you, Mr. Harp?
Is it us? Is it all of us together? Are we moving in the right
direction? I keep hearing we need to, we need to, we need to.
And like Dr. Kerber said, all the studies--who needs to be
skinning the rabbit, and how do we implement that? Let's move
forward. That is what this panel is convened to do, is kick
this ball down the court in the right direction. So help us
implement what we need to be doing.
Dr. Nielsen. I think it is a combined responsibility. And
the DSB is right on about the importance at the very senior
leadership levels how important this is. And even that at some
points the Under Secretary of Defense for Acquisition,
Technology, and Logistics isn't high enough; that it requires
everybody to be in this.
But I also believe that a lot of acquisition is done at the
contact point. And so you need smart program managers, smart
system engineers kind of working on this as well. I mentioned
in my statement, this requires the whole community to do this.
And everybody has to feel responsible.
Mr. Ellsworth. If there are specific things that you all
see about that, the hiring of folks--and I know that taking the
nine months versus three, whatever it is that you can see to
put a bug in our ear of people we can get to, we would be glad
to take that on and try to speed that up to do exactly these
things you are saying that we need to do.
Thank you, Mr. Chairman. I would yield back.
Mr. Andrews. Thank you.
Mr. Coffman, any follow-up.
Mr. Coffman. No, Mr. Chairman.
Mr. Andrews. Well, I would like to thank the witnesses, as
I said, for a very thorough, well thought-out testimony this
morning. We are going to be calling upon you again as the
committee proceeds. Our intention is to explore these areas for
the balance of 2009 and then convene early in 2010 and identify
the best practices and recommendations that we will make in the
form of legislative recommendations for the fiscal year 2011
authorization bill. So that is the timetable we are on.
I think this morning was both confirmatory, and it opened
up some new areas of inquiry for us that certainly confirm, Dr.
Kerber, our sense that the quality of the people, the human
leadership is the pivotal point. I just think that can't be
said enough.
Dr. Nielsen, I think that you identified and confirmed a
point that we understand, that the acquisition process for IT
is just very different than it is for lots of other things, and
we can't superimpose that same orthodox model.
And then, Mr. Harp, the reason the committee supported the
language for these pilots is we want you to be innovative and
creative, and we are encouraged that you are going to do that.
What I found interesting and somewhat groundbreaking this
morning was some of the testimony about the successes that we
have had. We do want to learn more about that because we think
that there can be successes that need to be highlighted and
learned from so that we can find the best practices that these
better leaders are implementing and replicating it and do more
of it.
Again, we would welcome comments from the witnesses as we
proceed in this process. It is our goal not to write a whole
bunch of new rules, but to produce some legislative
recommendations that would help fix this problem.
And I would like to thank our colleagues for their time and
attention this morning and invite the witnesses to continue to
correspond with the panel.
And with that, I declare the hearing adjourned.
[Whereupon, at 9:12 a.m., the panel was
adjourned.]Note: not printing the following blank
folios 108, 191, 193, 197, 201, 205, 214, 402 deg.
=======================================================================
A P P E N D I X
July 9, 2009
=======================================================================
PREPARED STATEMENTS SUBMITTED FOR THE RECORD
July 9, 2009
=======================================================================
[GRAPHIC(S)] [NOT AVAILABLE IN TIFF FORMAT]
=======================================================================
DOCUMENTS SUBMITTED FOR THE RECORD
July 9, 2009
=======================================================================
[GRAPHIC(S)] [NOT AVAILABLE IN TIFF FORMAT]
=======================================================================
QUESTIONS SUBMITTED BY MEMBERS POST HEARING
July 9, 2009
=======================================================================
QUESTIONS SUBMITTED BY MR. ANDREWS
Mr. Andrews. What incentives does the DoD have to attract and
retain quality skilled IT personnel? How do those incentives compare
with the private sector?
Mr. Harp. The DoD must compete with the rest of the Federal
Government and the private sector for highly skilled talent with the
necessary business, technology and acquisition competencies. Many of
the skills that DoD has defined as ``mission critical'' mirror those
defined by the private sector. Generally, and not surprising, some of
the most highly sought after skills are those that involve information
technology/data architecture and information/Cyber Security (IA).
Additionally, knowledge of government practices and DoD regulations,
and possession of required security clearances, are lucrative
commodities.
The DoD has limited incentives targeted to IT personnel, which are
described below. Those it does have often provide only a partial
solution. The DoD CIO, the newly appointed IT Functional Community
Manager for the DoD civilian IT community, has been working to create a
comprehensive strategy that can be used universally to support the
management of defense IT occupations. The DoD also has the opportunity
to use federal-wide authorities such as recruiting, retention, and
relocation bonuses and the student loan repayment program. The
challenge is the ability to deploy these tools in a strategic manner
for maximum benefit. Unlike the military community where recruiting and
retention programs are funded and managed centrally, or DoD's centrally
funded Defense Acquisition Workforce Development Fund, almost no DoD IT
civilian workforce incentives are managed or funded centrally.
Scholarships
Information Assurance Scholarship Program (IASP). In 2001, with
Congressional support, the DoD CIO established the IASP, a cooperative
venture with numerous educational institutions to award scholarships to
undergraduate and graduate students enrolled in Centers of Academic
Excellence in Information Assurance Education. The IASP enables DoD to
recruit top students majoring in various disciplines to fill critical
IT/Cyber Security (IA) billets and create a continuous pool of skilled
IT professionals to meet current and future work requirements. Current
IASP issues:
Funding levels resulted in only 50% of Components'
requested quotas for the 2009-2010 academic years being filled.
Lack of a specific hiring authority associated with the
IASP has created unintended inefficiencies and inequities such as
limiting the applicant pool to students who can complete internships,
limiting the appointment term of the graduates, or causing individuals
to have to compete for hiring to fulfill their service payback.
Creating a simplified and easily understood hiring authority for IASP
students would greatly smooth the transition of these students to DoD.
DoD supports draft IASP direct hire authority legislation contained in
H.R. 2647, sec. 1103 which would resolve this issue.
Direct Hire Authority.
Whenever the IT job market demand increases for new skill sets or
additional personnel, it is difficult for most DoD Components to
respond quickly as the private sector. Most are not adequately funded
to provide recruitment and retention incentives, and as a further
complication, Components must comply with the long, onerous recruiting
process. DoD (and the rest of the Federal Government) has limited
direct hire authority for IT personnel which is targeted solely to
``select'' information security individuals as described below. To be
effective, this authority must be granted to address all the IT
occupations that support the critical missions of DoD.
Information Assurance (IA) Direct Hire. This authority is limited
to those individuals performing managerial information security
functions in grades GS-9 and above within the 2210 series. Those
individuals comprise a small number of DoD's full-time civilian Cyber
Security (IA) workforce. Not covered under this authority are key
individuals performing technical IA functions including systems
administrators and network services providers or individuals performing
Cyber Security (IA) functions in other occupation series.
The DoD CIO supports the availability of a comprehensive, expedited
IT hiring authority such as that afforded to the Acquisition Workforce
in the FY09 National Defense Authorization Act, which modified Section
1705 of title 10, United States Code. Such an authority, judiciously
implemented through consultation and direction from the Under Secretary
of Defense for Personnel and Readiness, would enable DoD to move more
quickly to address challenges such as standing up its new Cyber
Command, finding replacement personnel for individuals in IT-intensive
commands who will not relocate in conjunction with BRAC, addressing
insourcing initiatives, or responding to other Component-level hiring
issues.
Special Salary Rates.
At DoD, three IT occupations currently have special salary rates
for individuals in the general schedule who are not in pay banded
salary programs: IT Specialists, Computer Scientists and Computer
Engineers. Although the Special Salary Rates (SSR) were originally
designed to be greater than locality pay rates, annual increases to the
locality pay tables have outstripped increases to the SSR in many
locations, causing significant erosion and even discontinuation of IT
SSR for many individuals, both within DoD and across the Federal
Government. For example, a GS-9, Step 5, IT Management Specialist in
Columbus, Ohio, received a $7,535 salary differential in 2002 due to
SSR; that benefit has eroded to $6,210 in 2009. A GS-11, Step 5, in the
Washington metropolitan area received $4,025 additional in special
salary compensation in 2002. That benefit is gone in 2009 as a result
of locality pay outstripping the IT SSR.
Reinstatement of a stronger IT special salary rate would largely
impact the GS-2210 series (GS-12 and below) as only 34 percent of DoD
2210 population was in a pay-banded compensation plan at the end of
FY2008. Significantly smaller numbers of Computer Scientists and
Computer Engineers would be impacted as more of these individuals are
in pay banded and demonstration projects already established, providing
more comparable salary rates with the private sector. The eroding IT
SSR impacts some of DoD's most critical IT workers, including systems
administrators, applications software personnel, network services
providers, and IT project managers, many of whom are also part of the
Cyber Security (IA) workforce.
Lifelong Learning. The rate of change in information technology
requires robust professional development programs that provide
continuous learning opportunities for DoD IT personnel. These include
traditional education and training programs at DoD technical
schoolhouses and academic institutions such as the Naval Postgraduate
School, the Air Force Institute of Technology and the Information
Resources Management College at the National Defense University;
tuition reimbursement programs; a commercially aligned certification
program for the Cyber Security (IA) segment of the IT workforce; and a
retention-focused facet of the Information Assurance Scholarship
Program. At the Component level, several organizations have implemented
internship programs to attract and develop younger talent to the IT
workforce as part of their strategic human capital planning. The goal
is to grow these programs to ensure that a continuous pool of skilled
IT professionals is available to meet DoD's diverse mission critical
requirements.
The biggest differences between DoD and the private sector is the
emphasis that the private sector places on the need for pay
differentials within the IT sector and their greater flexibility to
offer necessary targeted incentives. For instance, while DoD and the IT
private sector have offered comparable salary increases of 3.5% in the
recent past, average salary increases for select IT positions in the
private sector, such as Security Analysts (one of the harder IT jobs to
fill) have been as high as 7.7%. The average signing bonus for a
private sector IT Manager is typically about $1,000 higher, however,
few in DoD actually receive one. For example, only 55, or 3% of new IT
Specialists (which include Cyber Security (IA) personnel, IT project
managers, enterprise architects and other critical roles), received a
recruitment bonus in FY2007 and less than 70 IT Specialists were
enrolled in DoD's loan repayment program that year. Approximately 800
IT Specialists (3% of the 28,000 individuals in the 2210 occupational
series) received a retention bonus. These low numbers in DoD are also
reflective of the low usage of incentives in federal workforce at
large. Many federal Chief Human Capital Officers, when surveyed, have
cited lack of funding as hampering their ability to use incentive
programs.
Both DoD and the private sector value IT certification programs
which have been shown to be particularly attractive to employees under
age 35, a key demographic to fill behind retiring baby boomers. If DoD
can gain momentum in certifying its Cyber Security (IA) workforce, this
is a significant area where DoD may gain traction in attracting and
retaining mission critical employees. Recognizing the importance of
this certification program to both individuals' career development and
to DoD mission readiness, the DoD CIO, in a May 2009 report to Congress
on the DoD Civilian IT Workforce, recommended new legislation which
would establish a Department-wide incentive program to encourage
individuals to obtain key Cyber Security credentials.
A strong training program and consistently applied incentives,
properly resourced, would separate DoD from its civilian counterparts
during this recession. In a recent Gartner IT salary survey, 31% of the
population surveyed indicated IT training budgets were dropping;
another 58% reported their budget would be stagnant. Gartner cautioned
that failure to adequately staff and develop IT personnel during this
economic downturn could result in significant organizational turnover
and loss of critical IT talent as the economy improves.
Mr. Andrews. What incentives does the DoD have to attract and
retain quality skilled IT personnel? How do these incentives compare
with the private sector?
Dr. Nielsen. I'm happy to answer this based on my experiences in
the government and since leaving the government. I'd like to make it
clear that I am not speaking for the Department of Defense. In
addition, I left government service in 2004 and I'm sure some personnel
programs have changed since that time.
The largest incentive DoD has to attract and retain quality skilled
IT personnel is that the work DoD does is important to our country.
During my time as the commander of the Air Force Research Laboratory
(2000-2004), we recruited scientists and engineers at all levels--men
and women just completing their bachelors' degrees as well as senior,
well-experienced, well-proven, professionals. Inevitably, they would
mention a desire to serve their country as one of the key reasons, if
not the primary reason, for why they joined our uniform or civilian
workforce.
Among the more senior men and women who joined us, they would also
mention the ability to shape and lead research and acquisition programs
that were important to them professionally. By working for the
government, they thought they could have more control over the
direction of key programs and therefore have more impact to the country
and their profession. In general, these individuals were very
conscientious and hard working with clear ideas for the strategic
impact of their work.
The government has been an especially good employer for scientific
and technical men and women with respect to continuing education. The
government supports the development of their IT personnel via short
courses, attendance at professional conferences, and graduate
education. These are all highly valued by IT personnel as well as all
scientific and engineering professionals and lead to greater technical
depth as well as technical and managerial breadth. This is true for
both uniformed and civilian IT personnel.
DoD professionals also often cite the strong sense of mission and
camaraderie as a reason for their continued service and retention.
Often people think this is only true of the uniformed members, but
throughout most of my career in research and development, most of my
colleagues and subordinates were civilian government workers. I can say
unequivocally that these civil service workers felt the same commitment
to mission, the same dedication to their colleagues, the same passion
for service to their country. I believe this plays a large role in
retention of talented men and women who could have higher salaries
elsewhere.
Having mentioned salaries, it is true, in general, that government
salaries are not usually as high as industry salaries, especially for
the top performers. Industry has more latitude on financial
incentives--larger bonuses, stock and stock options--than the
government has. In general, industry can advance top performers faster
than the government can and this can be frustrating for a top
performing government worker.
This has been addressed to some extent in the various personnel
demonstrations programs that have been authorized over the past 10-15
years. I am, of course, most familiar with the laboratory demonstration
program implemented by the Air Force Research Laboratory in 1997.
Instead of the well known civil service grades and steps, the civilian
scientific and engineering workforce at AFRL was managed in four large
groups with broad pay bands. Within broad guidance for overall salary
growth, individuals were assessed annually on their contributions and
their salary was adjusted based on the extent of their contributions.
Under this system a new engineer who caught fire could receive
substantial pay raises early in his or her career. Conversely, an
individual who was not performing as expected might receive no raise at
all, not even a cost of living adjustment--a clear sign that better
performance was expected.
One topic I addressed in my oral testimony that relates to
recruitment was the difference in the way the government and industry
can respond to an applicant for a job. During my AFRL days, we
occasionally lost a great applicant to industry because we could not
make a firm offer as fast as industry could. When you're looking for
that first job or if you are an established IT professional who is
looking for a career change, a quick and responsive offer might make
the difference in which job you will accept. The government has
improved its processes for making employment offers, but is usually not
as quick and agile as industry is.
Overall, I believe DoD has the tools in place to recruit, retain,
and develop its IT and acquisition workforces. It is a large and
complex organization with a unique and challenging mission for our
country. The expectations of the men and women it seeks to recruit and
retain continue to evolve and, consequently, it must continue to evolve
its processes to compete in the marketplace. It can do this through a
thorough analysis of its work force goals, benchmarking against other
organizations that manage their people well, and an honest assessment
of its existing processes.
We ask our DoD IT and acquisition men and women to shoulder
significant responsibilities and we need to reciprocate with the
processes and infrastructure that support them.
Mr. Andrews. One of your recommendations is ``selecting an
effective leadership team.'' What are the critical skills or attributes
needed by acquisition personnel overseeing IT programs? What questions
should we be asking of leaders during the confirmation process to
ensure we get the right people in key acquisition positions?
Dr. Kerber. These responses do not necessarily reflect the position
of the Department of Defense and in some cases do not reflect the
position of the Defense Science Board. I have tried to clearly identify
those positions which are my own.
A. The Department should select individuals that have exhibited
proven success in leading and managing IT programs and acquisition or
product development. Although DoD possesses a pool of talented
individuals it does not have a sufficient number to meet all of its
needs. DoD compensates for this shortfall with short assignments and
inadequate screening of individuals by sometimes equating certification
with competence. Certification can not be used as the sole factor for
assigning an individual as a Program Manager. In my view, the private
sector is the best model for finding this talent. The private sector
encourages clear accountability and can only survive by having
individuals that can develop and utilize state of the art technology.
These two factors make it easy for the private sector to identify
successful Program Managers. The Government often lacks clear
accountability, drags programs on for years and therefore identifying
the successful Program Manager becomes much more difficult.
B. In addition to the traditional political vetting process,
appointments should be accompanied with references of former
supervisors and peers just like they are in the private sector. These
references should include the typical areas such as leadership ability,
teamwork skills, specific relevant key accomplishments, limitations,
etc. Without references, one does not know if the experience listed by
any potential employee, government or private sector, was successful or
not.
Mr. Andrews. What incentives does the DoD have to attract and
retain quality skilled IT personnel? How do those incentives compare
with the private sector?
Dr. Kerber. The Department has many interesting and challenging
programs to attract and retain quality skilled IT individuals. Quite
often the work itself is so unique that it is its own incentive and DoD
should do a better job of emphasizing the unique nature of its work.
The Interagency Personnel Agreement (IPA) and other special programs
for individuals of special talent are available that either offer
monetary incentives or mobility. Our studies have shown that these
programs are underutilized. Consistently our studies have shown that
the best performance is when individuals have a lot of accountability
and authority like at DARPA, Special Operations Command (SOCOM) or
other special programs with small select staff.
I submitted 3 reports during my testimony. I would call your
attention to a fourth DSB report ``Management Oversight in Acquisition
Organizations, March, 2005.'' This report covers topics associated with
ethics in acquisition and other personnel issues. To acquire
individuals with experience from the private sector, one by necessity
needs to consider individuals that work in the industry that supplies
the Department. While we all are concerned about improper behavior,
corruption and revolving door issues, the private sector effectively
manages these issues as people change companies sometimes moving from
suppliers to procurers and from one competitor to the other. The
Congress needs to remove onerous requirements placed on individuals
moving from the private sector to government while keeping in place
processes that prohibit one from making any decision that could impact
their personal wealth or that of relatives and former colleagues. There
is a large reservoir of recently retired, experienced and successful
talent that is underutilized in the country.
When one compares the incentives for government service versus the
private sector, for all but political appointees, job security is a big
incentive. It is also a negative for the government since poor
performers are hard and often impossible to remove. The positive
incentives for individuals in the private sector are: 1) The customer
can be clearly identified. 2) Decision authority is clearer and
decisions are made relatively quickly and decisively. 3) Accountability
is clearer. 4) Financial rewards are more closely tied to performance.
4) Incentives are clear. 5) Career planning is more interactive with
the employer. Personal freedoms are encouraged and supported.
|
NEWSLETTER
|
|
Join the GlobalSecurity.org mailing list
|
|
|
