To print a PDF copy of this article, click here.
For those not familiar with Norman Augustine’s laws, they are a collection of 52 observations first published in 1983 by Augustine, former president and chief operating officer of Martin Marietta Corp. While the laws are humorous, they also offer interesting insights into the tough realities of defense acquisition.
“Although most products will soon be too costly to purchase, there will be a thriving market in the sale of books on how to fix them.” —Norman Augustine’s 19th law
“What did you do to deserve this?”
“Didn’t anyone tell you how messed up this program is?”
“Why did you accept this assignment?”
If questions like these are the first things you hear from your new team on Day One of your new program manager (PM) job, chances are you might be managing a “Red” program. PMs work hard to keep their programs on track and executing, but many PMs will encounter the dreaded Red program. You may even inherit one as part of your new job assignment, like I did. This article will look at some of the dynamics of these programs and discuss some of my experiences and the lessons I learned during my career when trying to fix a troubled program.
What exactly is a Red program? According to the Defense Acquisition Executive Summary (DAES) Charts Standards definitions, a Red program is defined as follows:
Some aspects of the program (contracts, approved Acquisition Program Baseline) are not met for performance, schedule, cost and funding requirements. There is insufficient trade space to close the issues or mitigate risk. The program may require restructuring and/or additional funding. Any Red indicator will require a closure plan within 30/60/90 days to return to Green.
As the definition highlights, a Red program is one that is not executable without help. It either needs additional funding, time, relief from performance requirements or a combination of changes to these program thresholds.
“If a sufficient number of management layers are superimposed on each other, it can be assured that disaster is not left to chance.” —Norman Augustine’s 26th law
While each program has its own set of unique circumstances, unhealthy programs often have some common threads. We can learn valuable lessons from examining these programs, including the specific root causes of the problems. Some Red Major Defense Acquisition Programs (MDAPs) have incurred a significant and/or critical Nunn-McCurdy cost breach.
As part of the Weapon System Acquisition Reform Act of 2009, these critical cost growth breaches now trigger a review by the Performance Assessments and Root Cause Analyses (PARCA) Office in Under Secretary of Defense for Acquisition, Technology, and Logistics (USD[AT&L]). A summary of PARCA’s findings and other relevant acquisition performance information is addressed in the June 28, 2013, “Performance of the Defense Acquisition System, 2013 Annual Report” (http://www.defense.gov/pubs/PerformanceoftheDefenseAcquisitionSystem-2013AnnualReport.pdf). In reviewing PARCA’s root cause assessments of these breach programs, two common areas stand out in nearly all the reports: unrealistic estimates (cost, schedule, and performance) and poor management performance.
The analysis suggests that overly optimistic program estimates often are driven by unrealistic assumptions at the inception of a program. These assumptions then are carried forward into the estimating and program structure that lays the foundation for execution. Note that cost- and schedule-estimating models were not identified as the problem. The estimating methods and models are only as good as the input data and assumptions that drive the outputs.
One lesson learned highlights the importance of a rigorous program start-up, planning and estimating effort and suggests that a program’s basic planning assumptions should be updated and tested periodically as the program evolves.
Overly optimistic assumptions can affect all acquisition category programs, including very small ones. One lesson learned highlights the importance of a rigorous program start-up, planning and estimating effort and suggests that a program’s basic planning assumptions should be updated and tested periodically as the program evolves. This is consistent with language in the “Director, Cost Assessment and Program Evaluation (CAPE) FY 2012 Annual Report on Cost Assessment Activities.”
The CAPE report highlights how CAPE satisfies the confidence-level statutory requirement used in establishing a cost estimate of an MDAP or a Major Automated Information System program by ensuring that all its cost estimates are built on a product-oriented Work Breakdown Structure, based on historical, actual cost data whenever possible and, most importantly, based on conservative assumptions consistent with demonstrated performance for a series of successful programs.
Poor management performance is associated with program execution and is broken down further into systems engineering, contractual incentives, risk management and situational awareness issues. While the lessons learned vary for each program, the report highlights the importance of effective program management in keeping a program on track.
My Experiences and Lessons
“The last 10 percent of performance generates one-third of the cost and two-thirds of the problems.” —Norman Augustine’s 15th law
Many of us may have heard that the 80 percent solution is good enough. PMs working to recover a Red program may find that a rebaselining of their program presents an opportunity to revisit some of the technical requirements that are not fully met and difficult to achieve. The requirements community recently addressed this subject in a Vice Chairman of the Joint Chiefs of Staff Memorandum, “Key Performance Parameter [KPP] Relief,” Jan. 23, 2013 (https://acc.dau.mil/CommunityBrowser.aspx?id=633908). The memorandum states that “KPP relief should be considered especially appropriate in cases where significant cost savings may be achieved with marginal impact to operational capability (i.e., spending 15 percent of a program’s budget to get the last 3 percent of KPP performance).”
A few years ago, I inherited a major weapon system upgrade program that was restructured after significant technical issues, delays and cost overruns. This program was rebaselined with new cost, schedule and technical thresholds. A new joint contractor and government team was brought in and was determined to deliver this product. The upgrade included a new airborne mission computing system that was software intensive and very complex due to the required integration of multiple sensors and communications systems.
Despite significant doubts from key stakeholders, the development of the restructured program was tracking very close to the new program baseline. We were concerned about how the system would perform in full-up system-level developmental and operational testing. The size of the software program was much larger than originally planned, and we could not afford to re-engineer the supporting hardware architecture given our budget and schedule constraints.
Our team knew going in that the mission computing architecture was an issue because it often crashed or locked up if it was stressed too heavily during test missions. It was stressed similar to a personal computer when a user opens many menus and applications simultaneously. If the system’s memory and throughput can’t support the demand, the system will lock up or crash and then must be rebooted. Obviously, an unstable system is unacceptable for the user and casts doubt on its reliability to complete the assigned missions.
Given that a new mission computing architecture would take significant time and funding to re-engineer and test, we explored potential work-arounds that would improve system stability. The simplest work-around was to limit the applications the system concurrently ran. While this was not optimal, it did solve the immediate problem within our limited budget and also enabled users to complete their mission. We worked hard with the test and user communities to manage their expectations with this limitation. After careful deliberations, they agreed to accept the operational work-arounds but only after operational testing demonstrated the system was workable.
Knowing we had laid out a credible plan to upgrade the system helped obtain the user and test communities’ buy-in to move forward. We also would receive the benefit of operational deployment feedback that could be incorporated in the next increment. Our 80 percent solution kept the program moving forward and delivered a significant operational capability. I firmly believe that if we had tried to resolve everything in the first increment, we would have breached our budget and schedule again and faced a potential program termination.
“Fools rush in where incumbents fear to tread.” —Norman Augustine’s 33rd law
PMs managing a Red program also may face team morale, trust and relationship challenges. The stress of working on a troubled program can result in behavior changes that are detrimental to a good working relationship. Failure of the joint Defense Department and contractor team to work together effectively can render success difficult.
The following are some additional actions I have observed that can help teams get their programs back on track. One of the first items to consider is a replacement of key personnel, including the PM for both the Defense Department and contractor teams. This enables a fresh look at the issues and can help recharge the teams’ energies. Obviously, the transition should not be an assignment of blame but rather an opportunity to transition to new leadership with new ideas. Bringing in new, emotionally unencumbered functional experts also may prove helpful.
The new program leadership will want to assess the organizational climate and may conduct anonymous surveys to gauge how the team assesses the program. It’s important for the PMs to share the survey results with the team and to secure buy-in on actions that address the predominant issues. Empowering the team to develop action plans is a good way to get them to buy in, since they will have come up with the ideas.
A plan to follow up and track the specific actions will send the message that this effort is important. Likewise, the lack of follow-up suggests that the issues identified are not a priority and that the event was a poor use of valuable time and resources. Issues such as communications, trust and clear processes often are identified for action. These issues often can be attributed to the overall culture of the program office teams.
Changing the culture of the organization may be necessary. This can be a difficult path to pursue, especially with staff members who may have been entrenched for a long time and resist change. Based on my experience, this kind of change will take time, and leaders should not expect significant changes overnight. Numerous models and training courses can be leveraged to help effect organizational and strategic changes. PMs should consider expert assistance before attempting this kind of effort.
Years ago as a more junior PM, I observed a senior program office PM as he dealt with significant technical challenges on a Red program. This individual had excellent business and technical skills but was under significant stress due to the program issues. He had strong ideas on what needed to occur to correct the issues but was not receptive to feedback and collaboration from his staff. Needless to say, the team’s morale and communications suffered while the program issues remained unresolved.
The new PM who took over was concerned not only with the program issues but with the team’s welfare. He took the time to establish good working relationships with the contractor and the government team. It was enlightening to observe how trusting relationships and communications improved morale and the team’s commitment. One of the changes the PM implemented was to create a culture of credibility. This meant we were careful about what we signed up for, but when we did sign up we would make sure we delivered as promised.
Executing and meeting our targets started a cycle in which success bred more success. It also was very satisfying to know we turned the program around and eventually delivered the system to the warfighter, despite significant doubts about whether it would ever happen.
Since Red programs are stressful and often tough work environments, it can be difficult to fill vacancies and retain staff. Word spreads fast about “sinking ships!” Similar to the success spiral, bad results lead to more bad outcomes and this can be a tough cycle to break. Ensuring that the team has the needed resources and expertise is a great start to getting back on track. While vacancies are common, PMs must give priority to continually assessing their personnel and work to resolve lingering shortfalls.
I once observed a program office team that was so accustomed to personnel shortages that they would plan and structure programs around reduced manpower. As a result they did not plan for or perform important tasks, took shortcuts, and assumed greater risks. This approach may be well-intentioned, but it is not a good recipe for success. An alternative to working an understaffed program is to turn away new work. This is exactly what one agency I worked for did for a short period when reviewing new work that was beyond what the agency could reasonably support.
Obviously, not all Red programs will recover. And some programs, including healthy ones, will be terminated or restructured into different efforts. DAU and Service experts have addressed smart shutdown of programs with a Special Interest Area (https://acc.dau.mil/smartshutdown) within the Acquisition Community Connection portal. Also available are a guidebook, best practices and other useful information.
“Ninety percent of the time things will turn out worse than you expect. The other 10 percent of the time you had no right to expect so much.” —Norman Augustine’s 37th law
The stress of working on a healthy acquisition program can be significant, and it only gets worse with a Red program. PMs and their teams working on a Red program should navigate very carefully through their get-well plans. Recovery to an executable program that delivers acceptable operational capability to the user may require some significant changes in the program structure, requirements, staffing and even organizational culture.
The get-well journey will often be difficult but can also be very rewarding. Hard work, commitment and teamwork with the contractor will be great attributes to overcome the challenges. The sense of pride and accomplishment in recovering a Red program and delivering capability to the warfighter will make it all worthwhile!