To print a PDF copy of this article, click here.
In 1986, I started keeping a list of profound lessons I had learned as an operational test director, defense contractor, government project engineer, and government program manager (PM) for mostly non-major acquisition programs (i.e., ACAT [Acquisition Category] III, IV) and a couple of ACAT I programs. I would jot them down on a special page in my “paper brain” as they occurred to me, sometimes in the heat of the moment, but usually during quiet periods of retrospection. In defense acquisition, we get a lot of education and training in managing research and development, much of which is the best in the world. But most of it is nuts and bolts, driven by the numerous laws and regulations that govern federal programs and contracts. The lessons below aren’t necessarily driven by anything more than common sense, experience and, as W. Edwards Deming put it, “Profound Knowledge” of the system.
These lessons generally fall into four areas: Program Teams; Contract Architecture; Design and Engineering; and Sponsors and Money. Over the years, I’ve provided these to my colleagues, both inside the government and outside such as at the Marine Technology Society’s Underwater Interventions conference, and usually received positive reviews. So I’m providing them here in the hopes that readers will be able to glean some nuggets of value.
Start Each Briefing with a Picture
A wisely chosen picture or two will set the scene and get the audience focused and in sync. They can be used to explain complex relationships or systems. Pictures help an audience unfamiliar with the topic quickly understand and grasp the context of the rest of the presentation.
Gather the Best People You Can Find, Then Listen to Them and Smooth Their Paths
Management in high-technology programs usually involves more coaching and less directing. Program offices most often consist of skilled specialists in engineering, finance, logistics and government contracting (an arcane science unto itself). An acquisition PM acts more like a coach than a traditional military leader. He may develop the strategy and send out individual plays to be executed but relies on the specialists in the field to execute. A good manager will run interference with outside stakeholders and look down the road for issues and obstacles that will face the team.
Develop a Network of Capable People
As you journey through your career, take note of the exceptionally capable people you come in contact with. Then work to cultivate continuing relationships with them. Many of us engineers are introverts, so cultivating relationships may not come naturally. Drop by these people’s offices occasionally, send them periodic e-mails, or reach out to them on Facebook or LinkedIn. By building and maintain a network of competent people that you can call on, you’ve multiplied your own capability.
Make the Program Fun
- It attracts good people.
- It keeps good people.
- Everyone else will be envious.
Developing new military systems and products is inherently cool. We get to see new stuff years before the military at large or the public. But many people working in the trenches of a program management office or acquisition command are insulated by their jobs from experiencing the new products as those products are designed, built and tested. Work to break down that insulation. Techniques I’ve used: Celebrate achievements and milestones whenever possible, post large pictures and drawings on the walls, share test videos with the staff online, exhibit or demonstrate prototypes at the command, give rides on prototype vehicles to the program team and acquisition command staff when feasible, use Defense Connect Online to the builder’s site to let staff members see the systems as the systems are being built. In addition to making a program more enjoyable, providing a firsthand experience to a comptroller or capability assessment staffers can provide dividends during the Program Objectives Memorandum and budget process.
Keep Your Prime Happy or Be Miserable
In many ways, the relationship between the government program management team and a prime contractor is like marriage. Generally there are long courtships and competing suitors. There always is a big party at the beginning and hopes for a long, successful relationship. There are competing interests and demands, and a necessary give and take between the partners (we even call them our “industry partners” now). Almost always there is some conflict, and resolving conflict together can make the relationship stronger. Sometimes conflicts don’t get worked out, and the relationship ends prematurely. And sometimes events beyond either party’s control destroy the relationship. But if your prime contractor is unhappy, you’re going to end up being unhappy too.
Don’t Put Design and Production on Opposite Sides
As anyone who actually has read one knows, a U.S. Government contract is a hodgepodge of unrelated requirements, statements, policies and procedures. Much of it is not directly related to the task at hand but is designed to promote societal goals. Also, it includes numerous mandated “fixes” for prior problems, bad acts and failures that have been regulated or legislated into existence, many of which conflict with each other. Additionally, government contracts are difficult to establish, difficult to change and intolerant of unknown risks. System Design and Development are iterative creative processes—i.e., a journey of discovery which requires intense communication, close cooperation, give and take and tradeoffs between the engineers, technicians, logisticians, suppliers, etc., to achieve a satisfactory product. I have occasionally seen successful high-tech products such as the SEAL Delivery Vehicle Mark 8 designed by the government and produced by the government. I have seen numerous successful high-tech products designed by industry and produced by industry. But I haven’t seen successful high-tech products that have been designed by the government and then produced by industry. Usually these programs end up being canceled once industry comes back with all the necessary changes to make them producible. Or else industry redesigns the product prior to production, which ends up invalidating much of the previous testing. So the lesson is that it’s better to have either government labs, engineering centers, or shipyards/depots design and manufacture the system or have private industry design and manufacture the system.
Don’t Get Between a Prime and Its Subcontractor
There’s a tremendous desire on the part of government managers to dictate to a company how to design or build a system. Much of this desire is based on the technical experience of the government’s engineers on other programs. Contractors, as a rule, will try to comply with their customers’ desired process, but may need additional time and money to deviate from their planned programs. With a well-organized prime contractor and a good prime-government relationship, the responsibility to address cost and scheduled impacts can be quickly analyzed, negotiated and allocated. However, when the government and subcontractor technical personnel work together without the involvement of the prime, it ends up as a three-party negotiation, which is very challenging. With the prime’s personnel excluded, it becomes much more difficult to allocate fairly the responsibility for schedule/cost growth. In such cases, the government unwittingly ends up assuming the liability for most of the cost and schedule increases.
Contract for the Whole Program Up Front
Include production, full life-cycle sustainment, and maybe even disposal (if unusual) as options. You can always fine-tune the contract during execution, or decide not to exercise a contract option if better opportunities arise (e.g., government life-cycle sustainment). The Special Operations Craft Riverine (SOCR) contract (ACAT III) included two years of design and development, 10 years of production options, and 14 years of sustainment engineering, parts, planned maintenance and modifications. It was built on the success of the 1996 Naval Special Warfare Rigid-Hull Inflatable Boat contract (also ACAT III), which included design, development and fixed-price production options. The SOCR contract was awarded in 2001. It’s still a fully utilized contract and serves as the model for newer contracts. The big “if” is technical complexity. If the product is not overly complex, or if multiple competitive prototyping is used to reduce risk in more complex programs, this technique allows the majority of the production price to be set during the initial competition.
Have Reprocurement Rights, Just in Case
When a new system is being developed, the builder often brings his own intellectual property (IP) into the program. In many cases that’s why the government has competitively selected the builder. As part of the competition, include within the last priced production option period a priced option for a contract line item to license the builder’s IP for additional production. This enables the government to recompete for additional production or just provides leverage needed to get a better price with the original equipment manufacturer (OEM) for additional production.
Design And Engineering
Well-meaning government engineers and operators can unintentionally cause a design program to become much more difficult, expensive and lengthy than intended. Design goals meant to be traded off if necessary can easily slip into becoming non-negotiable requirements. Engineering margins have a way of building on each other, adding to all levels of the systems engineering and design process and multiplying the complexity tremendously. I worked one memorable urgent aviation program whose mission equipment requirements were growing uncontrollably from “good ideas.” Late in the manufacturing cycle, it was realized that every 10 pounds of weight was reducing on-station time by about 1 percent. We ended up stripping off all the nice-to-haves, got the system through production and deployed operationally. We then worked to prioritize and reincorporate a few of the highest-priority nice-to-haves.
Independent Operational Test and Evaluation (OT&E)—Do It Early and Often
Remember, actual combat/operational usage will always surface all the issues you didn’t fix first, and the consequences are always bad. OT&E uncovers real operational issues when it’s easy to fix them. Also, early OT&E lets the program manager get a fix on what’s important to the OT&E agency. Frequently that’s not obvious at the beginning of the program. Whenever possible when designing a program acquisition strategy, schedule in two full sets of OT&E before the production decision. That way if there are major issues from the first set, there will be time to fix them and retest. And if you get lucky and pass most or all of the tests the first time, you can cancel the second set of testing and accelerate the program.
Dress Rehearse OT&E During Developmental Test and Evaluation (DT&E)
During DT&E, it’s wise to “dress rehearse” for OT&E. In the 1980s, I was Commander, Operational Test and Evaluation Force’s (COMOPTEVFOR’s) operational test director for the Gas Management System. Naval Sea Systems Command (NAVSEA), after completion of its DT&E testing and while certifying the system for OPEVAL, made a last-minute decision to run our OT&E plan as a final part of DT&E while the submarine was on patrol. That simple test uncovered what turned out to be a simple software error that had dramatic safety implications. Because the event occurred during DT&E instead of OT&E, NAVSEA was able to correct the problem. If it had been discovered during OT&E—or worse yet, after initial operational capability—the political dynamics of the resulting uproar would have likely caused cancellation of the entire program.
If It Ain’t Broke, Don’t Fix It
Don’t change something just because someone thinks it would be a good idea to change it. Change inevitably costs money. Even change to save money can end up costing more money. However, if that someone wanting the change is Chuck Yeager, this rule may not apply.
If It Breaks, Redesign It Against a Second Fix
Contrary to the common Department of Defense (DoD) doctrine, I have come to believe that good reliability is more important than good maintainability or good availability. If a system or part doesn’t break, you don’t need corrective maintenance personnel, a parts supply chain, maintenance training, repair manuals, etc. If you have a choice on where to invest limited sustainment funds, improving reliability generally is the best place.
Two Years After Initial Operating Capability,
Operational Availability Will Dip
Many programs experience a surprising drop in operational availability two years after initial operating capability. The root cause turns out to be the normal rotational process for military personnel. Key military operators and maintainers will get assigned to programs during their development, participating in design reviews, acting as operators during government testing, and becoming expert members of the systems’ fleet introduction team/cadre. Finally, after a couple of years of successful operation, most or all of these experts will rotate out of the assignment, taking all of their unwritten knowledge and experience with them. The apparent result noticeable at the program management office is a drop in operational availability, increased failure and increased repair times. The solution is to capture the unwritten expert knowledge from these departing key personnel as much as possible and increase training of new personnel.
It’s always better to estimate on the high side and finish a program below cost and schedule as opposed to estimating low and finishing a program over cost or late or not finishing at all.
Sponsors and Money
Can It Be Done?
If an old smart guy says it can be done, it can be done. If an old smart guy says it can’t be done, and a young smart guy says it can be done, you may be able to do it. If you can’t find a smart guy to say it can be done, it can’t be done.
Coming up with new ideas is one of the easiest parts of solving a problem or attaining a goal. Figuring out a plan on achieving the goal, then executing the plan is the hardest part. Many ideas look great in concept but can’t be executed because some of the basic building blocks aren’t there. Sometimes good ideas are just ahead of their time. In the space race, it’s important to remember that President Kennedy set our sights on the moon only after Sputnik, Russia’s Yuri Gagarin and America’s Alan Shepherd succeeded in taking the first steps.
Give the Customers Their Sticker Shock Early
If the customer can’t deal with the cost, don’t do the program. And a corollary: As a government PM, it’s always better to estimate on the high side and finish a program below cost and schedule as opposed to estimating low and finishing a program over cost or late or not finishing at all.
In a Program Management Office, Time is Money
The time a decision spends waiting in an in basket is just as expensive as time spent planning. Be aware of the cost of time. In a typical government research, development and acquisition setting, an engineer costs about $220,000 a year, $1,000 a day, $120 per hour, $2 per minute. For industry, wasted time comes right out of profit. For government, for every dollar devoted to a project, there’s easily another dollar in overhead costs elsewhere. Be aware of your costs and don’t procrastinate unnecessarily. Multimonth delays in deciding the acceptability of a design feature on the critical path can cause program costs to spiral out of control.
In DoD, If You Spend Your Money Early and Get Recognized Value—They Give You More Money!
Over and over, we see programs fail because their managers acted miserly with their money, doling it out quarterly, hoarding it because it gave them power. However, starving a contractor or supporting agency for funds causes undesired actions. To minimize expenses, the contractor or agency will postpone hiring or assigning necessary staff and subcontractors. Talented staff will leave for better-funded projects. Eventually this will show up first as schedule slips and then as cost overages. It’s wiser to spend your project’s funds quickly and achieve recognizable milestones. Within a defense agency or Service, there’s always some other program that is not spending its funds, so it becomes the “bill payer.”
The Navy Department in 1986 issued a manual on “Best Practices” that called the defense acquisition process “The World’s Most Complicated Technical Process.” Since then it has only gotten more complicated. There are many pitfalls and traps along the way. I use the mountain climbing analogy a lot when describing defense research, development and acquisition. It took mankind 32 years, numerous false starts, and significant improvements in climbing gear to summit Mount Everest. So, as you’re climbing your personal summit, I hope that these hard-won lessons will help you blaze a successful trail.