good morning welcome to the panel we're 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 that exists between cost and value for our uniformed personnel and their support personnel 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 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 to in the two thousand and eleven armed services authorization bill morning we're going to focus on a critical hypothesis about the difference between cost and value and that is questions and answers from members of the panel harper is the deputy assistant secretary of defense for three i s r n i t acquisition mr harper is responsible for the review of major acquisition programs for command control communications intelligence surveillance reconnaissance and information technology programs in addition he leads reviews of major defense acquisition programs in major automated information systems as chairman of the command control communications and intelligence overarching integrated product team in support of the defense acquisition board information technology acquisition board mr harper bachelor of science and business administration from penn state university the nittany lion and a masters of business administration degree and financial management from the george washington university as a defense acquisition workforce integrity level three certified in program management business cost estimating and financial management acquisition logistics awards include the defense meritorious civilian service medal the defense exceptional civilian service medal and the defen any more than no more than three or four words quite a bit of money in business cards dr paul nielsen is director and chief executive officer of the software engineering institute a federally funded research and development center operated and the increasing overlap 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 thirty two years of distinguished service for which we thank him in two thousand and four dr nielsen became a fellow of the american institute of aeronautics and served as president from two thousand and seven to two thousand and eight he serves on the air force scientific advisory board as a member of the board of directors for the hertz foundation a nonprofit that awards graduate school fellowships and the applied sciences thank you dr nielsen for your service serving with morning by only dr ronald kerber is an experienced executive with a successful record of leading and growing domestic and global business leadership responsibilities of included general management innovation product development cost reduction  profitability and diverse global organizations the currently splits his time among a variety of entrepreneurial and pro bono activities as president of a small consulting firm the challenges fact of acquisition and management of information technology systems in my written statement as you mentioned for the record and when i briefly highlight a few key points specifically i'd like to point out some challenges within the information technology environment to differentiate information technology acquisition from the major weapons systems experience throughout my career as a weapons system acquisition professional i would like to contrast to my recent experience over the different phases of the acquisition process as set forth for weapons systems are ill suited for information technology intended to mature technology yet our underlying information technologies are not only not largely matured in the commercial sector is intended to ready a program for production yet information technologies typically aren't produced in quantity production phase which again is generally not relevant to information technology that is not produced in quantity the term lifecycle has also become ambiguous because similar to the b fifty two experience where we build an airframe and then updated the pieces over time rather than build a full replacement modularity in dynamics of information technology and the pace of commercial information technology development allow us to build or adopt information technology level of an airframe and continue to modify it indefinitely rather than replace an entire system in a pretty term and period of time as noted by the recent report acquisition reform studies have been ongoing almost continuously goldwater nichols legislation was passed in one thousand nine hundred most often acquisition related problems in those reports have been attributed to requirements creep and funding instability with regard to information technology requirements more as a lot of hypothesis of the technology will double every eighteen months has proven to be valid with regard to the information technologies that we have  acquired this puts pressure on information technology acquires change the system level requirements during the design process to enable feeling of relevant technology in addition combat operations are being conducted in a rapidly changing s circumstances placing pressure to change requirements during information acquisition to respond to adversary tactics also our customers of war fighters are information technology savvy often turn digital  with expectations to leverage innovation in the commercial market to enhance our information systems and capability in terms of agility flexibility responsiveness and effectiveness adding to the requirements pressure the combination of these three very real forces lead to significant requirements change pressure on information technology process we should begin to embrace the concept that changing requirements might actually be desirable for information technology acquisitions rather follow the inherent weapons system acquisition process assumption of stable requirements over time funding stability in this dynamic environment is also significant challenge to information technology acquisition a large portion of  department discretionary funding is allocated to acquisitions within the acquisition accounts information technology programs are relatively more flexible because unlike weapons programs information technology programs typically do not have significant out y tends to drive drive a degree of funding instability the requirement to build ensure the weapons system acquisition process is optimized to manage production risk and doesn't really information technology acquisition that defense science board recognizes the unique aspects of information technology and addresses the requirements and funding challenges to the application of agile processes and exploitation of the inherent modular nature of the information technology to build smaller capability acquisition process and we look forward to working with this panel in the future to great effect of acquisition and management construct for information technology we also appreciate the committee's inclusion of section eleven eleven which would allow us to bring industry  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 and we would say that it doesn't address the root causes of the problem problems appear to be caused by immature technology requirements creep funding instability but we would argue most of that is caused by inexperience and unproven leadership and programs are not structured and initiated in a way that can be successfully completed there's no simple silver bullet to solving this problem it's really a  commonsense approach we also think the problem is beyond the scope of the undersecretary of defense for acquisition technology and logistics it's really a problem of the scope of the secretary defense and it should be because many of those players that perform in the acquisition arena don't report to the undersecretary of acquisition so what is needed 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 aqua's execution we also need your support in helping the department do this and we need to instill a sense of urgency just a couple of comments on the buying the right things that seem simple but we really need a resource balance business plan concept that includes funded acquisitions we need to specify the capability needs to support our national strategy then we need to also effectively represent the combat and commanders in the process of determining what we buy and then we need to use comprehensive systems engineering analysis early and throughout the process to determine what we're buying and how we're buying it we need to avoid hard requirements without extensive analysis and trade off 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 size of poor leadership include poorly designed product development strategies for management of technical risk selection of end experience contractors for contract incentives and reward for change orders skills and program administration are often confused in the acquisition community with management ability managers manage what the understand proven experience should lead to better judgment and execution another point that is equally important to secretary of defense has many offices that contribute to the decision process and acquisition and their constructive input should be early and continuous not just a decision milestones we need to improve acquisition process is for major systems commercial derivative information technology and services services we need to establish more streamlined processes with in depth analysis upfront planned spiral development and block upgrades and the use of competitive prototypes for i t acquisition continued to grow both in size and content in all but national security systems that is important but the department needs processes and capability to do that we have recommended for the acquisition process a new streamlined decision process and we've also recommended how and when to use it we also want to point out that as has been mentioned earlier systems don't satisfy the laws of physics and so we don't always know what we're buying so we need to minimize the  system vulnerabilities we need to adopt a strategy that compounds 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 identify clearly who has oversight countability for all systems as the growth of systems continues that percentage of the total acquisition will grow and we feel that that needs to be managed under the office of  a and finally 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 a clear count of building authority for everyone finally we need to develop process for all that we do just one final comment  the private sector there are different characteristics for acquisition the customer is clearly defined the decision authority is more clear accountability is more clear and incentives are more clear yet it's very difficult to do this  process even in the private sector and private companies really do it well and especially it's very difficult to do this kind of process on a public stage well thank you very much we appreciate statements from each of the witnesses will begin the questioning mr harper made reference to the language that would authorize pilot programs or an alternative acquisition process which the committee has supported  can you give us some thoughts about what principles you might rely on in that pilot process what kinds of differences you would institute in the acquisition process as we look to the inventory systems that were w assuming there seem to be four natural types of systems we have some systems where we're buying commercial off the shelf hardware and that's consider and system that doesn't require the same process as a system where we are actually developing and writing software code and developing and writing code another type of acquisition that we do is we buy software that's already this commercial software and we put it together and we build the interfaces between the system so we develop a system of systems if you will using cots so that would be a different approach as well so we're looking at some different templates on how we might approach that but some of this become i mention the b fifty two model if you get to a system where you don't really need to replace the core system there's been studies that show that up to when you build a new system up to sixty percent of the code you have to right to make it work doesn't modules of that system and the interfaces the commercial or standards that exist for those modules to talk together and approach each module as if it were a separate release or a separate part of the system rather than waiting for all the modules to be developed before we go to test 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 often times we'll have several modules under development in parallel and we can't get to the final test until we complete the final module and other modules that could be used i think it was your testimony that said that the average time to get to the finish line reduce conceivably you could reduce it to twelve eighteen months but again you're not talking about delivering the same thing eighty one months is a large system with several releases several modules living at the same lot of people who wanted to come to work for the government there are lots of people in our country who commitment and they want to do provide some service for our country whether it's a farm or a civilian but there are some impediments and one of the impediments that i think this committee is trying to address is when we tried to hire people to take nine to twelve months we could bring them on board and even if they were committed to us if they were staring an offer from another from a company that was ready to respond in two or three months hard for them to wait kind of people who want to provide some service to our country you're out of the real world 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 a strong recognition w several special programs to hire a specialist if you will and we've looked at those programs have really been underutilized and you can also also have a bonus structure that you can ward bonuses for outstanding performance so between bonuses recognition and giving challenging problems you have an opportunity managed right and effectively special hiring capability to do that the personnel we're trying to build up for cyber security and that kind of thing so if we could expand that provision to include i t workforce that would be helpful and we have a parallel challenge in the culture that we have a need mentioned in the acquisition called we need to bring them both both along at the same time so if we could get that expanded to the workforce that would be helpful i will feel that there are some examples of where the weapons systems have successfully embraced the commercial technology our submarine we have a submarine combat system that is based on commercial technology only hardware components in there that are not commercial are the transducers and the and the racks the racks have to be special because they have to be water cooled because the fans and air cooled too much noise for the submarine but other than that all the cables all the screens all the circuit cars everything in that system and eighty percent of the software in that system is commercially procured and the  program has a lab like environment program office that they've been running for almost ten years now that that watches over the commercial industry and follows commercial industry when one of those companies has upgraded they bring that they bring the piece in and test it and make sure that it does what it says it will do and it has all the right requirements for our environment and want to get a green light then they plan on which some arena will go in next and they 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 and area now there are not there are some challenges of that model and we're looking at that but that's the kind of thing that we're trying to move towards to address in the weapons system ruth could you talk a little bit more about you made a comment about quick change to confound the enemy and i know it's just it goes against everything we're talking but it's counterintuitive to what we're saying that did one study where we said that the information management system of the department needs to be considered part of a weapons system because of the importance of it in managing combat and managing our troops and  the issue you have when you change systems to 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're not careful about how you manage training along with the introduction of new systems but i would argue whether it's in a fighter aircraft or any other 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 doesn't 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'd like with  versus the public sector is that in the in the world of professional we need to move this process along is that movement  of that expertise in house versus having it available on a contractual basis as needed is that movement going to hurt or help  well this argument is interesting in the i t world because in the world what we outsourced largely were people who were writing code and what we're trying to bring in our system are software system engineers that can manage contracts where the vendor is writing the code but they understand the necessary points to make sure that it's done right and fits into the open environment we're trying to develop so we are bringing back t same skill set that we outsource and we're bringing them back in a lesser quantity and we will still be depending upon industry to do the code writing in the things that are more dynamic we maintain a  inability to understand what we're asking for and understand what they're delivering so that balance we're trying to achieve but we have a ways to go i think you have really no alternative but to have people in the government who are educated at some level perhaps don't have to be the design engineer but they have to have engineering awareness if they're making complex decisions they're managing programs that have engineering challenges and they have to know you clearly need the leadership in the department that understands the problem has actually done it well and can provide oversight and guidance and understand when things are in trouble and how to start and and manage programs so you certainly need that within the department if you talk about as as was mentioned creating code or creating even new ideas i think you're really going to have to rely on the private sector for that because that's where that really comes and i  not invented here and there were very resistant to the ideas that come from outside and so you need a capability to reach out because if you don't reach out you'll never keep up with the private sector so i would say there is a danger of having too much whereby the issue about requirement changes would come out that 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 the person in charge of that i can't remember his name but anyway he froze basically frozen requirements and brought in the system and then opened it up for improvement and we would argue that the smart way to do that is at some point freeze requirements i don't like the word freeze capabilities introduce the system make a list then do a spiral development or block upgrade and have that plan from the from the get go then you have an orderly way of bringing in new ideas and you can't continually just dribble a man you've got to bring them in and blocks and maybe in a twelve or eighteen months sequence you blank bring in the new ideas you have a very orderly way to do it you can train your workforce you can deliver the systems capability much quicker and it's always essentially current in 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 into people or saying i can't wait for this i've got to do it now to get my job done and they work around you and that's where some of that requirements churn comes in so in freezing you need to freeze it at some point but you don't want to freeze it for a period of time so that when you do deliver it it's obsolete in the end you've got a huge cost to fix it and implement it so there's a balance there and again it argues back to the d s p model that says deliver have shorter smaller programs deliver things in modules rather than raising an entire capability until you get the entire capability built right so for each module you might see until you build it in a short period of time that is a more has more chance of success than freezing the entire capability until you deliver the entire system capability and vulnerability as any system attackable and dr nelson mentioned when they be nice to have diverse cultures you know we are so wedded to chips made primarily white in mainland china is not getting the best that the private sector has and that we're having difficulty recruiting the best to join the government service and i know there are a lot of wonderful people who've been patriotic enough to join it is survive the nine to twelve month hiring and all the bureaucratic rules but i think we should be working as training possible to make it much easier for the best to come work for uncle sam and say working for uncle sam can be larger than we can imagine and things like that but there's got to be a way that we feel the urgency of the struggle is when the pentagon thirty five thousand times a day when there's an allegation that someone's already stolen f twenty two  d various government departments just two or three days ago you know we're dangerously somnolent about this and i've talked to our defense friends asking what kind of computer they have a more difficult for them to think of than biological warfare and things like that that are also exotic but at least people have a sense of disease they're less aware of viruses computer viruses so it's more of  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 world where if you're in a proprietary environment it's very difficult to do that one of in the technology if you say i want to have an acquisition baseline in five years later i'm going to develop i want to deliver something five years later you can deliver something that the warfighter think is totally broken from an acquisition perspective because because it was successful we that 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's part of what we're trying to develop here as part of this effort  and i guess i'll just leave it at that i think that the financial metrics and i think the milestone metrics for our big program are the wrong match i know we've been successful you'll see a correlation between a successful programs we find in mention and size smaller programs are more successful if we're if we're delivering we can deliver we can compete with industry delivering programs of seventy five thousand lines of code or less when you start getting up into the million lines of code even industry