[House Hearing, 111 Congress]
[From the U.S. Government Publishing 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









                                     

                         [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

                                     




                                _______

                  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, [email protected].  













                  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

=======================================================================




=======================================================================


                   DOCUMENTS SUBMITTED FOR THE RECORD

                              July 9, 2009

=======================================================================




=======================================================================


              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.

                                  
