The Optimal Program Structure
This article first appeared in the July-August issue of Defense AT&L Magazine (http://www.dau.mil/pubscats/Pages/DefenseAtl.aspx).
Not too long ago, I was asked during a Q&A session with one of the courses at DAU what I thought the optimal program structure was. The question itself suggests a misunderstanding of how programs should be structured, and more importantly, it may be an example of a type of behavior that I’ve seen too much of in the past two years since I came back to government service.
The answer to the question is either: (A) There is none, or (B) There are an infinite number. There is no one best way to structure a program. Every program has its own best structure, and that structure is dependent on all the many variables that contribute to program success or failure. To paraphrase and invert Tolstoy, happy programs are each happy in their own way, and unhappy programs tend to be unhappy in the same ways.
As I went around the country a year ago to discuss the Better Buying Power initiatives with the workforce, one thing I tried to emphasize repeatedly was that the BBP policies were not set in stone. All were subject to waiver. The first responsibility of the key leaders in the acquisition workforce is to think. One of the many reasons that our key leaders have to be true professionals who are fully prepared to do their jobs by virtue of education, training, and experience is that creative, informed thought is necessary to optimize the structure of a program. The behavior I’m afraid I’ve seen too much of is the tendency to default to a “school solution” standard program structure. I’ve seen programs twisted into knots just to include all the milestones in the standard program template.
Every program has its own best structure, and that structure is dependent on all the many variables that contribute to program success or failure.
I’m guessing that there are two reasons our leaders would do this: first, because they don’t know any better, and second, because they believe it’s the only way to get their program approved and through the “system.” Neither of these leads to good outcomes, and neither is what I expect from our acquisition professionals.
So how does one determine how to best structure a program? Whether you are a PM, or a chief engineer, or a contracting officer, or a life cycle support manager, you have to start in the same place. You begin with a deep understanding of the nature of the product you intend to acquire. The form of the program has to follow the function the program will perform: developing and acquiring a specific product. The nature of the product should be the most significant determiner of program structure. How mature is the technology that will be included in the product? What will have to be done to mature that technology, and how much risk is involved? In addition to the technology that is included, how complicated will the design be? Is it like other designs that we have experience with, or is it novel? How difficult are the integration aspects of building the product? Is the manufacturing technology also mature, or will work have to be done to advance it prior to production?
These questions on a large scale will begin the process of determining if a technology development phase is needed prior to the start of engineering and manufacturing development. They will also affect the duration of these phases, if used, and the number of test articles and types of testing that will have to be performed to verify the performance of the design.
Beyond a deep understanding of the product itself and the risk inherent in developing and producing it, one must consider a range of other factors that will influence program structure. How urgently is the product needed? How prepared is industry to design and produce the product? How much uncertainty is there about the proper balance of cost and capability? What are the customer’s priorities for performance? What resource constraints will affect program risk (not just financial resources, but also availability of competitors, time, and expertise in and out of government)? Is cost or schedule most important, and what are the best ways to control them on this program? What is the right balance of risk and incentives to provide to the contractors to get the results the government wants?
We are not in an easy business. This is, in fact, rocket science in many cases. As I look at programs coming through the acquisition process, my fundamental concern is that each program be structured in a way that optimizes that program’s chances of success. There is no one solution. What I’m looking for fundamentally is the evidence that the program’s leaders have thought carefully about all of the factors that I’ve mentione—and many others. I look for that evidence in the nature of the product the program is acquiring and in the structure the program’s leaders have chosen to use. The thinking (and the supporting data) that went into determining that specific and often unique structure is what I expect to see in an acquisition strategy, and it is what I expect our leaders to be able to explain when they present their program plans.
- FRANK KENDALL is the Under Secretary of Defense for Acquisition, Technology, and Logistics. He has more than 40 years’ experience in engineering, management, defense acquisition, and national security affairs in private industry, government, and the military. A Distinguished Graduate of the United States Military Academy at West Point, Kendall also holds a master’s degree in aerospace engineering from the California Institute of Technology, an M.B.A. from the C.W. Post Center of Long Island University, and a J.D. from Georgetown University Law Center. Kendall is a former member of the Army Science Board and the Defense Intelligence Agency Science and Technology Advisory Board, and has been a consultant to the Defense Science Board and a Senior Advisor to the Center for Strategic and International Studies. Kendall spent 10 years on active duty with the Army, serving in Germany, teaching engineering at West Point, and in research and development positions.