Project Management Journal in the paper Causal inferences on the cost overruns and schedule delays of large-scale U.S. federal defense and intelligence acquisition programs provides some interesting data on cost and schedule overruns in USG programs:

For example, statistical data from a recent Government Accountability Office (GAO) report (2008a) on 95 weapons systems found that the total cost growth on these programs was $295 billion, and the average schedule delay was 21 months. These large numbers represent a growing trend in cost overruns and schedule delays since the GAO began tracking these metrics in 2000. For comparison, the estimated total cost growth in the year 2000 of 75 DOD programs was $42 billion, normalized to fiscal-year 2008 dollars.

 The author indicates three reasons for the overruns ineffective human resources policies and practices, consolidation of the aerospace industry, and too many stakeholders:

A study was undertaken to understand why cost overruns and schedule delays have occurred and continue to occur on large-scale U.S. Department of Defense and intelligence community programs. Analysis of data from this study infers the causes of cost overruns and schedule slips on large-scale U.S. federal defense and intelligence acquisition programs to ineffective human resources policies and practices, consolidation of the aerospace industry, and too many stakeholders. 

Specifically, he posits that ineffective human resource policies lead to inexperienced personnel both in contractors and customers, people rotate through jobs too frequently, and there are too many contractors involved.  I can imagine that most of these are realities of the current economic and cultural environment.  Just as Toyota found out, these come from inability for R&D management tools and processes to deal with that environment and increasing complexity.

The author also posits that too many stakeholders lead to frequent changes in requirements.  I am not sure if the environment that leads to requirement changes is going to change any time soon.  I guess that means that the R&D managers need to come up with processes to deal with requirements changing effectively – without adding cost overruns and schedule slips…

The block diagrams that the author came up with look interesting.  However, I am not sure if I am able to agree with them fully.  It appears that he had his conclusions made first and then fit the analysis to support them…

Overall, a great article – well worth reading.