A View of How We Manage

Edmund H. Nowinski and Robert J. Kohler

“Every major space program in acquisition today is suffering from cost overruns
and is behind schedule.”

This article picks up a conversation on the subject of management of national reconnaissance that has been conducted in this journal and in National Reconnaissance Office (NRO) journal National Reconnaissance: Journal of the Discipline and Practice since Studies published a critique by Mr. Kohler in 2002 (Volume 46, Number 2) entitled “The Decline of the National Reconnaissance Office.” NRO Deputy Director Dennis Fitzgerald’s reply appeared in a later issue. Last year the conversation resumed in (2005-U1) with Mr. Kohler’s “Recapturing What Made the NRO Great: Updated Observations on ‘The Decline of the National Reconnaissance Office.’” Mr. Fitzgerald’s counterpoint appeared in the same issue. A number of the points Mr. Kohler made in “Update” are addressed here as well.

Since leaving federal service, Messrs. Nowinski and Kohler have continued to work on development issues in private industry, including some used to illustrate points in this article. Mr. Nowinski was the program manager at Boeing for the Future Imagery Architecture program until 2005, when the federal contract with Boeing was restructured and a significant portion of the work was transferred to Lockheed Martin. Mr. Kohler was a consultant for Boeing on the project.

The authors thank Gary Zeigler, retired vice president of Lockheed Martin, and James Frey, retired president of TASC, Inc., for many helpful suggestions and comments on drafts of this paper.

Consider some of the great achievements of the past. During World War II, the Manhattan Project was completed in 30 months; the first photographic reconnaissance satellite (CORONA) achieved its first launch within 12 months of contractor selection; the Apollo Program put a man on the moon in less than eight years; and the first near-real-time imaging system was launched in a little more than five years after a contractor was selected. Compare these accomplishments to more recent efforts on the Future Imagery Architecture (FIA) Program, the Space-Based Infrared (SBIRS) Program, and other classified programs. Today, major space programs typically take 10 or more years to achieve their first launch and seriously exceed planned costs.

During the past decade, a good deal of attention has been given to these problems, and specifically to the issue of inadequate program management of both white and black (classified) space programs. Several studies (notably the Young Panel[1]), many journal articles, and numerous congressional committees have lamented our inability to effectively manage such complex programs. It is a fact that every major space program in acquisition today is suffering from cost overruns and is behind schedule. The difficulties encountered on the FIA program, including a completion delay of several years and a multi-billion dollar cost growth, is just one example of this situation.

 

The founders and pioneers of the NRO—from intelligence, academia, the military and industry—met the Cold War challenge with the boldness, persistence, teamwork and sheer enthusiasm that have been the secrets of its success ever since. Your NRO trailblazers have told me that their sense of urgency, excitement, and commitment to Mission was so high that they could hardly wait to get to work each day. They dreamed the impossible. They dared the impossible. And they did the impossible—day in and day out.
—George Tenet at the National Reconnaissance Office 40th Anniversary Gala, 27 September 2000.

While much criticism has been directed at national security space acquisition, from our perspective, we see hardly any major acquisition in the Intelligence Community that is managed well. With a few exceptions in CIA, no organization in the Intelligence Community (IC) effectively manages complex and complicated acquisitions. That costs are overrun may be bad enough, but even more serious are years-long delays in delivery of capabilities that are now badly needed or the complete failure to deliver such capabilities.

In this article we will review the problems we believe are leading to inadequate program management in the Department of Defense (DOD) and the IC. We will also suggest that the community needs to get “back to basics” on a number of fronts in order to recover its ability to successfully manage projects that are essential to the delivery of new capabilities in collection, analytical tools, automation, and better integration and interaction of IC components.

[Top of page]

The Fundamental Issues

We find it ironic that the Intelligence Community, and in particular the NRO, is in such a dire situation only 20 years after it was seen as the leader in managing large projects. In 1986, the Presidential Blue Ribbon Commission on Defense Management (the Packard Commission) undertook a study of incipient problems in DOD’s management of the development of large-scale systems. A key theme of that commission’s report was that NRO was the model for management of such projects in the national security apparatus. The report said the NRO struck a near optimum balance of systems engineering, rational budgeting, aggressive personnel development, and organizational accountability.[2] How did things deteriorate so badly in just two decades—a relatively short period in the world of systems development?

Studies over the past five years have tried to answer this question. While each of these efforts—ranging from the Young Panel in 2003 and 2004 to a recently-completed Rand Study— have focused on different elements of the problem, they have reached similar conclusions about its underlying nature.[3] In general, we concur in the overall findings of these studies, which we list below as fundamental issues:

Budget – Program costs for all major space programs have been and continue to be seriously underestimated, leading to disastrous results during the development process. These underestimations are the result of an overarching desire of program proponents to obtain congressional appropriations, a drive by industry to win cost-driven proposals (at any cost!!), and the inexperience of government and industrial program teams.

Workforce – Commercial and other national security demands (and opportunities) for skilled engineers, scientists, and analysts, coupled with limited incentives, have seriously eroded the number of workers available and relevant to given projects. These people are the base from which competent program managers for IC and national space programs emerged in the past. While the overall technical workforce in the country is adequate, many of the best and brightest are no longer motivated to seek careers in the national security arena. The lack of serious long-term succession planning and career development throughout both the government and industrial elements of the community has significantly compounded this problem.

Systems Engineering – Inadequate budget allocations for systems engineering and the lack of experienced leaders in systems engineering in government and industry have substantially impeded critical front-end system engineering trades, studies, and planning on most major new developments. These shortcomings have resulted in unanticipated design and test issues late in development cycles, leading to extraordinary effects on costs and schedules.

Program Manager Authority – As the Young Panel pointed out, “government capabilities to lead and manage the space acquisition process have seriously eroded.”[4] Some of this can be traced to the ill-advised Total System Performance Responsibility (TSPR) policy of the past decade in which significant personnel reductions took place in government positions (part of the putative peace dividend) and responsibilities transferred to the industrial sector. Congressional intrusions into the specifics of individual programs have also had a major effect. The weakened ability of program managers to move quickly to resolve technical issues has further added to ill-effects on costs and schedules.

Industry Motivation – Contractor teams across the aerospace industry are strongly motivated to succeed. However, more and more frequently cost has become a major element—if not the major element—of that success. Likewise, cost-dominated fee structures have become the rule. Both of these factors have forced contractor teams to adopt overly optimistic perspectives on the state of their respective program developments. This too often results in simplistic and technically corrupt reporting and oversight processes.

Parts Quality – The rapid and unexpected decline in the commercial communications space market following the DotCom collapse late in the 1990s has had a significant impact on the quality of parts design in developing systems, which often goes unrecognized, again, until late in the development cycles. The government’s (and prime contractor’s) lack of attention and budget allocation to maintaining critical space technologies, including parts and processes, appears to us to be largely unabated.

Modest progress has been made over the past two years on some of these program management issues, but it has largely been a matter of “three steps forward and two steps back,” and in many cases, the situation has continued to deteriorate.

For reasons that are unclear to us, the IC and the national space community simply cannot find the wherewithal to come together and truly attack these issues robustly and in durable fashion. For example, in early 2005, Rep. Terry Everett, Chairman of the House Armed Services Subcommittee on Strategic Forces, noted that: “Despite the fact that numerous problems have been identified within the acquisition process, the Air Force continues to initiate space programs that accept extreme levels of technology risk.”[5] Months later, a comprehensive Lexington Institute study on the space sector and military goals, concluded that: “Every one of the next-generation constellations being developed has encountered unanticipated cost growth, schedule slippage, and technical difficulties. The problems are so pervasive that they raise doubts about whether government and industry can successfully execute military plans for space.”[6]

Further, a Rand study, focused on FIA and SBIRS-High and completed in late 2005 for the NRO, investigated a number of structural issues affecting these troubled programs and found that, among other things, “the lack of well-articulated technical requirements has plagued both programs.” This was due in part to the “loss of institutional knowledge and process management expertise” as well as “the increased politicization of the IC and the DOD community.”[7]

Recognizing these continuing issues, Undersecretary of the Air Force Ron Sega at the October 2005 Conference on Strategic Space said that it is “time to get back to basics.”[8] The question is what are the basics as they apply to these fundamental issues and is there a way back?

[Top of page]

Back to Basics

The corrective actions implied in the above review of problem areas have small chance of success if even more basic environmental issues are not considered. Many of these issues are not under the control of the program(s) directly but, they nevertheless influence performance. In the following, we will discuss four such issues:

• the art of program management;

• the impact of the organization in which a program resides;

• the “people” influences on the program manager;

• the requirements process.

As we consider these environmental issues, we will refer to the “old days” of NRO program management, not out of nostalgia, but because we believe there are lessons to be learned from an era—and an environment—that fostered successful program management.

[Top of page]

The Art of Program Management

Effective program management relies on many factors, among them the following six:

• acquisition readiness,

• management of critical technology,

• government and contractor teambuilding,

• risk reduction,

• program initiation discipline, and

• oversight.

Increasingly, we believe, the drive to get new programs started has overtaken the need to get programs done right. Even worse, up-front system engineering to assess the community’s needs, to evaluate alternatives, and to make trade-offs in performance, cost, and schedules are more often than not simply not done. In part, this is the result of the present inability of the government to do systems engineering analysis independently, the overwhelming desire to get new programs going, and excessive influence of contractors in pushing parochial solutions in both the administration and Congress. As a result, programs are poorly constructed. A recent example of this failing is the Space Radar (SR) program that fixed on a technical solution and architecture well before all the alternatives had been explored. Fortunately, Congress recognized this and has consistently refused over the past several years to fund the acquisition program.

In the “old days,” we (i.e., the government) contracted for and led the development of the technologies critical to a program’s success. We often selected the winner and turned that winner over to prime contractors for implementation. Furthermore, we often carried more than one supplier for these critical technologies through the preliminary design review phase to ensure we got the best solutions, not only technically, but in terms of achievability. The government no longer does this and typically leaves the management of critical technologies to the primes. There are, in our view, two reasons for this:

• The government, in the main, no longer has staffs sufficiently experienced to manage such programs.

• The government now prefers to allocate such responsibilities to prime contractors and relieve itself, as much as possible, of accountability for the performance of programs. This erosion of government responsibility is a legacy of the TSPR concept noted above.

But there is, in our view, a more insidious problem at work here. In general, contractors are not good at managing other contractors, particularly other contractors’ technology developments. In many cases, the prime and the technology subcontractors are competitors, and, as a result, “proprietary rights,” long-standing rivalries, and other competitive issues get in the way. Even in trying to manage other contractors who are not competitors, prime contractors often fail, as they tend not to have technical experts to truly oversee the products of subcontractors. Thus, subcontractor and supplier mismanagement has contributed significantly to problems on many of today’s major programs.

In the “old days,” contractors often accused us (government program managers) of being the real primes on programs. In a sense, this was true: We did directly manage critical technology developments, and we took responsibility for their success.

As these technologies matured into subsystems for implementation, we maintained government “managers” who worked with counterparts at the prime to oversee these activities. While we certainly expected prime contractors to do their jobs, the overall programs were ours to manage (including subcontractors and suppliers), and a program’s success or failure was our responsibility.

Another important element of success is building teamwork between contractors and government. No business can be run effectively when important partners act like adversaries. Today, we hear statements from the government such as, “we need to hold the contractors feet to the fire,” “we paid the contractor to do this, it’s not the government’s responsibility,” “we need to enforce the contract,” and “we’ll get them at award fee time.” Likewise, we hear contractors saying things like, “the award fee was unfair” and “we don’t understand the government’s priorities.” These statements may feel good to those making them at the time, but they reflect a hands-off approach in government to program management, and the threatening tone of “holding the contractor responsible” is counterproductive. In the end, the government is responsible for program success and performance: if the contractor is not performing, then it is the government’s responsibility to work with contractors to “fix” problems so they can perform. Often, this can be as simple as establishing an environment in which teams can work together toward common objectives.

The government’s current approach to awarding fees is frequently counterproductive, particularly when awards are used as weapons rather than as incentives. Anyone in authority who thinks an award fee of 72.3 percent communicates anything is kidding himself. In the “old days” we had a simple policy: if a contractor did essentially what we wanted, he got 100 percent. If the contractor did not do what we wanted, he got 50 percent and a warning. If the warning was ignored, he was penalized with an award fee of zero until the situation was remedied. In the final analysis, however, if the contractor did essentially what the government wanted and the program still failed, the government was just as accountable as the contractor. The contractor should not be punished for bad government management.

In this regard, the importance of competent and experienced government program officers cannot be underestimated. A combination of a really competent government program office and a really competent contractor program management team would be ideal, but this rarely happens. The fact is that a really competent government program office can make a mediocre contractor team perform above its apparent capability. The reverse, however, is not true.

Inattention to risk reduction is a major flaw in today’s environment. Risk reduction takes time and money, which, in the rush to get new programs approved, many organizations do not want to undertake. In the “old days”, in the process of leading up to the nation’s first near-real-time imaging satellite, the risk reduction effort took approximately five years and $1 billion (in today’s dollars) plus the evaluation of several alternative technical approaches. Even after acquisition had begun, multiple contractor efforts were maintained in several critical technologies to insure the highest confidence in the selection. As noted earlier, the distinction was that we made the selection for the critical technologies (not the prime), and we accepted responsibility for that selection.

One thing missing today in our view is a disciplined process for initiating programs. Bureaucratic milestones, review steps, independent review teams, and acquisition manuals seem to have replaced the disciplined process we used to use. We had— in a bit of an oversimplification— eight steps in our process:

• An overarching need was identified and, from this need, the program office generated a high-level set of requirements and an initial concept of operations (CONOPS).

• Potential technologies to satisfy the need were identified.

• The government contracted directly to develop the critical technologies.

• System studies were performed by the government, potential acquisition contractors, and support contractors in order to get ideas on architectural approaches. The government selected the approach it judged best, based on performance, cost, and schedule trade-offs.

• Critical technologies and alternatives were selected.

• The system performance specification was generated.

• The program office decided what cost and schedule it would commit to, based on contractor inputs, independent cost estimates (ICE), and experience.

• The program office determined how the program teams would be aligned (who was prime and subcontractor(s), who was an associate, etc.)

This eight-step process allowed us to continually make trade-offs in performance and schedule and cost. In the end, the performance expected of a program was embodied in the System Performance Document. This performance promise then had to be put in the context of cost and schedule commitments. We built margins into our schedules and cost commitments to insure that teams had reasonable chances of success, with reasonable risk.

Schedule and cost commitments— we considered them promises— were derived from contractor inputs, ICEs, and, most important, our experience. No single input drove our commitments more clearly than our experience and what we believed could be accomplished. The important point here is that schedule and cost margins were included in our program estimates, not only to protect against unforeseen events and issues, but also to give program managers the ability to protect performance promises as well. With today’s emphasis on cost as the driving issue, schedule and performance are guaranteed to suffer.

An additional thought on program fiscal management is in order. It is an oversimplification to say everything will be all right if we give the program manager adequate fiscal margin. Equally important is who controls what in the program budget and how resources are allocated. Increasingly, Congress, the DNI staff, DOD and others control sub-line-item budgets. This results in program managers having no real margin, i.e., no ability to shift baseline dollars without some “overseer’s” approval. This process not only further weakens the program manager’s authority, but it also hampers his ability to manage a program effectively and efficiently.

Finally, there is the issue of oversight and its impact on the program manager. One of the things that has been said about the reasons for the successes we enjoyed in the “old days” was the lack of oversight. In a quantitative sense this is true, however, in a qualitative sense, it is not. It is certainly true that there is more oversight today than in the old days. The Office of the Secretary of Defense, the DNI staff, and Congress (six committees) all exert oversight over IC programs. The problem is that today’s oversight is less competent than it was in the old days. In our day, the administration expected the D/NRO to manage programs, and it held the director accountable. The director, in turn, held the directors of Programs A, B, and C accountable for their programs. Congress interacted with top NRO leadership but almost never with the NRO program managers. The program managers were allowed to do their jobs, i.e., manage programs. Today, a significant part of a program manager’s time is devoted to interacting with, responding to, and catering to overseers. One might observe that the more oversight IC program managers have been the “beneficiaries” of, the worse the management of IC programs has become, and as IC programs worsen, more oversight is required. This is a spiral from which we believe IC program managers need to be extracted.

Oversight in and of itself is neither good nor bad. It can be very good if it helps (provides resources, technical solutions and advice, ideas, etc.), but it can really be bad if the overseers have agendas of their own that work against the success of programs. This, in our judgment, was certainly the case in FIA where some overseers were unhappy with the contractor selection and, unfortunately, were happy to see a contractor fail. In the end, however, the program manager should not have to spend a significant percentage of his or her time responding to overseers. Management should protect them from this encroachment on their time and resources.

Of all the above factors, the most important may well be the fostering of strong and effective government/contractor teams. A key ingredient of our success in Program B was our ability to build this kind of teamwork. We wanted the contractor to succeed, and we structured business deals to foster success. Contracts were negotiated with contractor’s business models in mind and accounted for. Further, all the contractors (primes, subcontractors, associates) were expected to be part of a team and often helped each other solve problems. Some of the tools we used to help the contractors succeed were:

• Offsite meetings with the government/contractor team to build relationships, share experiences and motivate the team.

• Government briefings to work forces across the country on the importance of programs they were working on.

• Government-directed cash awards for exceptional performance to individual contractor employees (allowable as a direct charge to the contract).

• Government/contractor working lunches and dinners, allowed as direct charges to the contract.

• Unilateral addition of 5 percent to contracts after negotiations were completed to give program managers additional margin.

• Minimization of the participation of Federally Funded Research and Development Centers (FFRDCs) and System Engineering and Technical Assistance (SETA) contractors to those individuals who could make real technical contributions to programs.

• Use of award fees as incentives, not as whips.

It is important that every participant in a program have some “skin in the game.” Today, the proliferation of FFRDCs and SETAs—often more numerous than involved government program offices—has created large contingents of people who have no real stake in a process in which they participate and which they criticize.

We should point out that in Program B—and, to a large extent, in Program A as well— there was great stability in the program office during major portions of our acquisition. It is hard to build a team when the program manager changes every year (as was the case with SBIRS) and/or a significant part of the program office staff changes every year, as is the case with most programs today. Stability of government and contractor teams is critical.

[Top of page]

The Organizational Impact on the Program Manager

The culture of the organization in which the program manager (and the program office) resides is critical. In most IC program organizations today, leaders emphasize spending on new initiatives rather than on funding programs already in acquisition. As a result, the latter are deliberately underfunded because if they were properly funded little or no money would be left for new programs. Resultant delays in these acquisitions in turn lead to greater expense than if the acquisitions had been funded correctly to begin with. The irony is that the more acquisitions are delayed, the more acquisition costs climb, and the more hampered is the ability to start something new. This cycle is resulting in the IC developing fewer new capabilities and, in the end, delivering old technologies that have been under “stretched out” development for years due to lack of adequate funding. Something has to give.

Also crucial are other elements in the culture of program management organizations, including:

Pride in work. In the Program B days, we were extremely proud of our record in successfully managing programs. While we liked to “win” new programs in competition with Program A (as they did against Program B), our belief was that, if we did our work well, we would be assigned new programs. And that is how it actually worked. “Excellence in all we do” became our motto and we were proud of it. During a congressional hearing one year, a staffer wanted to cut one of our programs, but a member said, “leave them alone, they do what they say.” It was the best compliment we could have received.

Sense of being part of a larger enterprise. In the Program B days, we were part of CIA. As such, we saw ourselves as part of a larger enterprise of intelligence officers, not just acquisition “pukes.” Many of the engineers and analysts that comprised Program B came from the analytical side of the CIA, bringing with them understanding of fundamental intelligence needs. This larger context gave us a bigger reason for being. We didn’t just deliver collection devices; we delivered collection devices that produced information of critical importance to our colleagues in the Directorate of Intelligence. The NRO today is largely detached from the “bigger enterprise.” It is, strictly speaking, neither DOD nor IC. It is no longer part of an intelligence agency but rather an organization that builds classified collection systems for somebody else’s use. This disconnect keeps program managers and their staffs from gaining full, end-to-end, views of the intelligence cycle.

Creativity and an innovative atmosphere. Successful organizations know how to foster and reward creativity and innovation. There is no IC organization today that is really good at this, in our judgment. There are many reasons. The requirements process beats creativity and innovation out of programs. The budget process no longer encourages it, and the culture of the IC has become increasingly risk averse. When it comes to programs and program management this is particularly harmful. Truly creative and innovative programs are destined to have some problems. While poor program performance should not be the rule, a modest level of failure must be tolerated if we are to encourage creative solutions to many of today’s IC challenges. What is particularly detrimental to people willing to undertake management of such programs today is that many of their overseers have never managed such programs and would not know how to if they tried.

Clear priorities. Successful organizations have clear priorities and act on them, and fiscal and human resources are aligned with the priorities. Today, few IC organizations (and particularly the NRO) manage by priorities. Again, the FIA example is relevant. The program was, arguably, the NRO’s number one priority, yet it was not treated as such, in our view. It was not adequately funded; funding was year-to-year and barely closed every year. And while some good people worked on FIA in the NRO program office, NRO management never took the steps to insure that the best people they had were assigned to the program. For example, FIA never had a first- class system engineering team assigned to the program, and deputy program managers came and went after only months on the assignment. But this is typical in a community (largely DOD-based) that prefers movement of people over stability and accountability.

Product lines have priority over staff. Successful businesses emphasize their product lines, not their infrastructures. They focus on how the product is to be made and minimize the “overhead” needed to support the product lines. The NRO is the easiest of the IC elements to assess in this regard, as it has only one task: managing the development, delivery, and operation of satellites to collect information. In this context, program managers are the “product line” managers. Yet today, the infrastructure (staff) of the NRO is larger than the components that manage programs. The budget staff is bigger than any single program office, and the security staff is bigger than it was when the NRO was a black organization. One can question if the high ratio of administrative personnel (security, contracts, finance, etc.) to engineers that CIA provides to NRO is the right one. Compounding the imbalance we see has been the growth in the number of people involved from FFRDCs and SETAs, as we noted above.

If at First You Don’t Succeed . . .

And if anybody today thinks that the exhilarating early days of the CORONA program were not also nerve-wracking, frustrating, and occasionally heartbreaking, imagine the persistence it took to endure 12 successive launch failures. What could go wrong did. One launch was aborted when a humidity sensor reported 100 percent. Inspection revealed that a member of the crew, four mice, had relieved itself on the sensor. That was one of the first leaks to plague the NRO.

—George J. Tenet at the NRO 40th Anniversary Gala

As we pointed out earlier, the impact on program managers of the imbalance can be serious. There are many more people who can “interfere,” and the manager has lost control over the full range of resources needed to do the job. In short, their accountability and authority have been degraded. Moreover, the situation sends a message that staff is more important than the line business. No commercial venture could afford such an approach and stay in business for long. In the “old days,” we were proud of the fact that the NRO staff was small, less than 140 people.

Dependence on excessively large support staffs has another insidious effect in our view: It has become significantly more difficult for government personnel to get the experience they need to fully develop program management skills. Instead of doing the work themselves, they have become overly reliant on support staffs. The NRO would be better served by significantly reducing staff sizes and FFRDC and SETA participation.

In sum, questions that organizational managers need to consider with respect to their programs include:

• Is the organization structured to foster program success?

• Does the organization’s staff see its job as helping or controlling the program manager?

• Are adequate resources allocated to the program manager (dollars and people) or has the organization overcommitted itself?

• Are organizational processes enabling or stifling?

• Can decisions be made rapidly when speed is needed?

• Is accountability and responsibility clear?

On the question of human resources, high-risk, highly complex technology programs need top-notch government teams to manage and execute them. One can ask how many such programs the NRO (or any acquisition organization) can successfully execute at any one time. In the NRO, as presently structured, the answer is probably no more than one or two. When an organization agrees to do more than it is institutionally capable of, good talent is spread too thin and nothing gets done well. Program managers in such organizations are usually destined to fail.

[Top of page]

The Human Element

A cadre of experienced and capable people managing programs is, arguably, the most important ingredient in a successful program. This may sound like a platitude, but it is an area that we think does not get adequate attention. In our judgment, this is principally because the work of building a top-notch cadre is hard, i.e., it requires difficult personnel decisions and takes time. Instead, the community has stopped giving people needed program-management experience in favor of providing “soft” training and certification programs. No training or certification program is going to replace real experience—the school of hard knocks—in the development of a first-class program manager.

We also question whether in today’s environment, people can be motivated to become first-line program managers. At a very personal level, people are motivated by many things, but certainly important among these are knowing that:

• good performance will be rewarded and a good career assured.

• career paths are available and knowing how to advance along those paths.

• exceptional performance will be rewarded but also knowing that failure in a very risky enterprise will not be punished.

• the organization takes care of its people, that it has good succession planning so that people know that opportunities to get to the top exist and that management is actively working to help them get there (job assignments, training/education, rotations, etc.).

In the Program B days, there was an unofficial, but nonetheless rigorous, career development program. It went something like this:

Step 1 – Individuals started as engineers in a Development Segment, using and developing their technical skills.

Step 2 – In this process they were most likely to be assigned to more than one segment to broaden their technical base and knowledge.

Step 3 – The demonstration of good technical and communication skills got people promoted to Segment Manager (responsible for delivering something that worked).

Step 4 – Demonstration of good technical skills, plus ability to work effectively with other people and organizations and the ability to see the big picture, led to promotion to Chief Systems Engineer (CSE). Leadership skills were especially important here.

Step 5 – The really good CSEs were assigned to program management positions at the earliest opportunity.

Obviously this whole process took time, often many years, but, by the time an individual advanced to the program management level, he had extensive experience with technical, cost and schedule issues, had solved difficult interface problems, worked constructively with others, and demonstrated solid leadership capabilities. Such people were ready to be program managers.

People simply cannot have two-to-four–year tours in an acquisition organization and have anybody believe they are prepared to take on big acquisition responsibilities.

Finally, considerable attention (as noted above) has been paid to the lack of system engineering capability in this business. This is a very serious, not easily rectified, problem. More training and certification will not produce good system engineers, although added training will improve good ones. As we’ve suggested above, development of a first-rate system engineer takes time, a variety of experiences, patience, and judicious mentoring. We suggest that really good system engineers have the following characteristics:

• They have solid technical foundations and have effectively practiced their technical skills early in their careers. In our experience we have found no technical discipline that seems especially well-suited to producing good system engineers.

• They are good communicators, able to communicate up, down and across a program (organization).

• They can see the big picture, understand the vision (goals, objectives, priorities) of a program (organization), and help program management achieve that vision.

• They are able to sort out what is important from that which is not. The good system engineer drives risk, performance, schedule, and cost trades across the enterprise and seeks the best value solution regardless of contracts, requirements, specifications or politics.

• They work aggressively across technologies that may actually not be in their fields; they do not try to do the jobs of segment managers; and they avoid unnecessary details.

• They keep customers informed.

• They constantly look for issues to be addressed and resolved, and, when they find them, they force rapid resolution.

• They are willing to work programs from beginning to end. It is lots of fun to work the up-front system engineering— developing the architecture, allocating the requirements, cutting ICDs (interface control documents), etc.—but the payoff of a good system engineer is in the longer-term requirements validation, readiness and transition activities, all of which are not nearly as much fun but are equally critical to success.

[Top of page]

The Tyranny of the Requirements Process

Do the best you can in the shortest possible time.

The above were the simple watchwords of our program managers and engineers as they worked on CORONA, the nation’s first photographic satellite system; it was issued in an era in which it was expected that the U-2 would have a limited life for use above the USSR and that something would be needed to fill the gap. The time from contract go-ahead to the first, albeit unsuccessful, launch was 12 months.

The requirements document for the nation’s first near real-time digital imaging system was a page-and-a-half memo from the United States Intelligence Board, written from the point of view of what could be done, and the system was delivered in five years.

The requirements for the follow-on to CORONA were outlined in a one-page memo from the DCI to the D/NRO. This system was delivered in four years.

The requirements for the follow-on to the first near-real-time imaging system were a set of viewgraphs and a short paper prepared by the chairman of COMIREX (DCI Committee on Imagery Requirements and Exploitation) that described the desired performance of the system. This system was delivered in five years.

Each of the highly successful programs we identified above were driven by urgent mission needs established at the national level. The acquisition offices did not invent the missions; they created the solutions. As a result, they started with broad support in the executive and legislative branches and tended to attract the other attributes of good management we set out in this paper. Whether the mission was to beat the Germans to the atomic bomb, evaluate the status of Soviet missile development, or meet President Kennedy’s challenge to land a man on the moon in a decade, the successful programs of the past shared a national commitment to success.

Programs that are driven by the desire of acquisition organizations and contractors to grow, achieve technology advancement for its own sake, or to support the industrial base invariably start without the broad support they need to succeed. For example, the FIA program, despite having gone through a three-year DOD and IC requirements process, never had universal support.

All NRO systems of the 60s, 70s and 80s were developed under similar, very simple requirements processes and had national level support. All these systems not only performed well, but they also satisfied needs that even today’s requirements processes would not have envisioned. It is not obvious to us that today’s tortuous requirements processes produces systems any better, relatively speaking, than those of yesteryear. In fact, it can be argued that the present requirements process hampers rational program development. The process today requires so many interested parties to “buy in” that the really important national needs get lost and/or marginalized in a myriad of desires that have to be reconciled to get everybody on-board. The result is that there are too many “critical” requirements, which drastically limit a program manager’s ability to balance performance, costs, and schedules.

Once a high-level need has been established, success requires an effective program requirements process. Experience tells us that it is very important that the top-level system requirements be defined before a prime implementing contractor is selected and that they be as specific and as simple as possible. The Apollo program, CORONA, and the first near-real-time imaging program all met these criteria.

In recent years a different philosophy has been promulgated, one in which the government decides at an abstract level what it wants, and then selects a contractor team to work as a partner to define specific requirements and implementation. This may make sense in theory, in that it makes the capabilities of the contractor team available to the government to accomplish the trades necessary to design the optimum solution and then build it. This approach has been tried on NSA’s Trailblazer, IC Map, and NGA’s Geoscout program. On each of these programs, a concept was defined to support the selection of the contractors and, once selected, the primes were charged with developing the specific requirements and structuring acquisition schedules in conjunction with the government.

However, none of these programs is viewed as being particularly successful. Using this approach, the contractors often end up trying to respond to an overwhelming set of diverse interests from within the government, resulting in overly complex and poorly coordinated development requirements. Translating mission needs, or high-level abstract concepts into specific acquisition requirements requires different types of people than those who do the design, development, and deployment phases.

But the problem does not stop there. In the program management world, “paper” has become king and the driving requirement on the programs. Today, nearly every decision, be it about requirements, design or technical features, or schedules, must be reviewed on paper by FFRDCs, SETAs, committees, and any person who lays claim to an interest. This requirement has established a counterproductive environment, as we pointed out earlier, in which many more people can say no and nobody has the authority to override the negatives. What’s more, the requirement to complete all such documentation before the next step is undertaken is unnecessary and causes significant schedule delays.

Specifications and specification validation has gotten out of control. Programs insist that all subsystems meet their specifications —and prove that they do—even if there is margin at the system level to tolerate an out-of-spec condition. Verification has become an onerous and, again, counterproductive process. The purpose of test programs has evolved from “does the system work” to “have we verified every last requirement.” We suggest that answering the former question is far less costly and quicker than answering the second and, with modest attention to critical linkages, is more effective in the long run. The “verification of the specs” test program provides no value-added to programs except to satisfy the inflated paper process.

Acquisition reform of the past few years has focused on how we can be smarter in procuring systems. The more pertinent question, in our view, is how can we manage programs smarter? The real problem is that today’s acquisition process has created an environment in which very few people are willing to take even worthwhile risks in program management. People have forgotten that the space business (even today) is inherently risky. If we are required to eliminate all risk in launching systems, then we will launch no systems.

Lastly, perhaps what is missing today is the right balance between community needs, technology advancement, program cost, and community-wide buy-in. In many ways, in the old days, we were lucky. Nobody doubted the need for collection, especially real-time imaging, from space. People argued over how to accomplish such missions but not the basic need for them. So it was relatively easy to align the administration and Congress around a strategy and funding. Many programs in trouble today lack this balance. Many people were opposed to FIA (or the contractor selection) from the outset for a variety of reasons, so it was constantly under review and attack. SR lacked technical coherence, architectural integrity, and suffered from weak support within the IC. Such an imbalance causes more oversight, criticism at every step, and turns the program manager’s job into a nightmare.

[Top of page]

Ideas

We believe that unless a process for improving program management is started soon, programs will just continue to take longer and cost considerably more than necessary, and the IC will fall farther and farther behind in delivering needed new capabilities. This problem will take time to correct, and action is needed now.

We know many people in and out of government are concerned about this issue and many ideas about what should be done exist and need to be considered. To aid in creating a framework for discussion and action we offer the following ideas for consideration.

Establish a professional acquisition corps in the IC. Acquisition is a skill that should be treated with the same respect and discipline as apply to intelligence analysts and DO operatives. People cannot keep moving into and out of the acquisition field and hope to develop the needed skills. In the days of Programs A and B people stayed in the business and, as a result, by training and experience became true acquisition professionals. One can argue whether the careers of such people should be managed by their agencies or at the DNI level; we prefer managing them at the agency level, but a process should be established to allow acquisition professionals to move between agencies, not only as the needs dictate, but to give them diverse and relevant experience as well.

How the NRO is staffed needs to be studied. To provide for the longevity needed to develop sound acquisition professionals, the Air Force model of people serving two- to four-year tours in the NRO should be discarded. In contrast, CIA people in the NRO should have the opportunity to spend their careers in acquisition and provide a stable acquisition corps. The current staffing model is just the reverse of what is needed: We need a higher proportion of CIA people in program management and technical jobs, where longevity counts. Those who cycle in and out over two-to-four year periods can more readily serve in the support organization, where longevity and continuity are not as important.

Remove all IC agencies from the JROC (Joint Requirements Oversight Council) process. The DNI should consider establishing a high-level body (much like the old COMIREX and SIGINT Committees) to adjudicate IC and DOD needs to be addressed by major system acquisitions. In 2004, the President’s Foreign Intelligence Advisory Board recommended the recreation of an EXCOM for the NRO; this deserves consideration.

The D/NRO should commission an independent study of the program management processes, procedures, documentation requirements, and infrastructure in order to find opportunities for simplification. This group should consist of current and past government and contractor personnel.

Effective system engineering must be reestablished as a critical capability in the IC. Every study of the NRO over the past few years has bemoaned the loss of systems engineering in industry and in government. This problem is one of the most serious root causes of poor program management, an issue that has become even more serious with the loss of any semblance of an “end-to-end” view and an “end-to-end” system responsibility. The DNI should establish an independent team to assess this issue across the IC and make recommendations for corrective actions.

The DNI should commission an independent study of the interfaces between the NRO, NGA, and NSA. This is a topic about which we could write another article. Suffice it to say here that, in our judgment, relationships between these organizations and how they interact are not as they should be, in part because the current interfaces are the result of history and perceived, possibly outdated, prerogatives. Effective interfaces need to be established in terms of what makes technical and fiscal sense today. Hopefully such a restructuring will make it easier for program managers to manage across organizations.

[Top of page]

Footnotes:

[1]A. Thomas Young, et al., Joint Task Force on Acquisition of National Security Space Programs, May 2003 (available at www.isn.ethz.ch/pubs).

[2]David Packard, William Perry, et al., in A Quest for Excellence, President’s Blue Ribbon Commission on Defense Management, June 1986. (Available at www.ndu.edu/library/pbrc.)

[3]Leslie Lewis et al., Acquisition Program Management Assessment of Selected Defense and Intelligence Community Programs (Santa Monica , CA: Rand Corporation, 2005).

[4]Young, et al., 3.

[5]“Space Acquisition Reform,” Aviation Week and Space Technology, 30 May 2005.

[6]Loren B. Thompson, Can the Space Sector Meet Military Goals in Space? (Washington, DC: Lexington Institute, 2005) Available at www.lexingtoninstitute.org docs/662.pdf.

[7]Leslie Lewis et al.

[8]Lou Rains, “Sega Pushes Back-to-Basics Approach to Cure Military Space Acquisition Woes,” C4ISRJournal.com, 21 October 2005.

 
All statements of fact, opinion, or analysis expressed in this article are those of the author. Nothing in the article should be construed as asserting or implying US government endorsement of an article’s factual statements and interpretations.

[Top of page]