Proposals can be hundreds of pages long; reflect brilliant ideas and policies; be replete with ambitious goals, objectives, and milestones; packed with the most talented people; display nicely designed organizational relationships; deftly cross all “T” s and dot all “I” s; and contain a cost proposal intent on spending every available penny—and then some.
However, strong proposals do not always become successful programs. Program managers in the private sector measure a program’s success or failure in two ways:
- Results as measured by cost control, meeting contractual requirements, on-time delivery, and within-budget performance; and
- Managerial performance, as measured by overall program effectiveness, organization, direction, leadership, and team performance
These concepts form the foundation of many books on project management, not to mention certification as a project management professional (PMP). However, some PMPs must come into a program midway—and not all will be successful. There are steps that can be taken to recognize a failing Department of Defense (DoD) program; how to fix it (if possible), and how to know when it is time to cancel.
The Duck Test
Consider the expression, “If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.” Sometimes, a program can be accurately evaluated simply by observing its physical characteristics.
If a program is fixable, there is an obligation to report its condition as factually as possible and revise the approach. If it is not fixable, there is an equal—if not greater—obligation to report that finding and an attendant obligation to cancel the program before it exacts an unacceptable toll in funds or lives.
Here, it is important to consider the approach. The program may require some new faces around the table, such as DoD or contractors.
The figure below submits the DoD program to the Duck Test. All inputs must be scrupulously audited, and each block involves action for both DoD and the contractor.
Only the integrity of the program is sacred. The problems identified must be fixable; and the fixes must be actionable.
Identify the Root Causes
Program managers must isolate the source of the program’s failure—not just ancillary troubles, whose correction will improve but not correct the situation.
Root cause analysis (RCA) is a method of problem solving used to identify the root causes of faults or problems. A factor or issue is a root cause if its removal from the problem-fault sequence prevents the final undesirable outcome from recurring. Meanwhile, a causal factor is one that affects an event’s outcome but is not a root cause. RCA is applied to methodically identify and correct the root causes of events, rather than to simply address the symptomatic results.
To focus on correction of root causes is to prevent their recurrence. Alternately, root cause failure analysis recognizes that complete prevention of recurrence by only one corrective action is not always possible. A thorough review must result in actionable intelligence and measurable solutions, identifying all threats and their potential effect on the mission of the product or service.
Supporting considerations include:
- Revised risk and needs assessments
- Revised goals and objectives and key performance indicators (KPI)
- Potential synergies and innovations—measured against a baseline
- Scheduling, problem solving, and the relationship of smaller, supporting projects
RCA typically is a reactive method of identifying event(s) causes, revealing problems, and solving them. Analysis is done after an event has occurred. However, RCA also can be a preemptive strategy to forecast or predict probable events before they occur.
Revise the Program
Verify, Then Trust
Rescuing a program in the wake of an actual or near failure means unvarnished assessments of people as well as specific, measurable, product goals and objectives. The program needs fully qualified executors and scrupulous documentation by competent evaluators/auditors with the power to act decisively.
Audit the Available Funding
Most funding issues arise from overspending in the beginning. This may be obvious, or it may be hidden by moving funds between lines; for example, using money programmed for training, mockups/simulators, software, or replacement parts to cover more immediate shortfalls. Many combat systems are launched without training simulators, technical manuals, or robust logistic support and reach-back because funds earmarked for them were diverted earlier. Figure 2 describes tracking the funding of a program in trouble.
DoD should never raid a sound program to throw money at an unsound one—but, unfortunately, it has done so in the past. I have been involved in DoD acquisition in one capacity or another since 1981 and have never known this approach to work for the good of sailors on the deckplates or soldiers in the trenches.
Team and Stakeholder Restructure
The quantitative aspects of the program or project describe how much money is left, how much time is left, what are the threats/risks, who is in charge, and the like. The findings reflect reputable metrics and performance indicators. It also is important to consider the more qualitative aspects. These concern the players more than the score.
For these purposes, a stakeholder is a person, or group with an interest or concern in an organization. Stakeholders can affect or be affected by the organization’s actions, objectives, and policies. Some key stakeholders are creditors, directors, employees, government (and its agencies), owners (shareholders), suppliers, unions, and the community from which the business draws its resources.
External Stakeholders
DoD often finds itself no longer in control when Congress steps in and tells DoD to “fix it” or “put it back.” The DoD response is often the infusion of more money, usually from one or more sound programs that either get postponed, reduced, or eliminated. The only stake Congress should have in the program is the enhanced combat readiness and security of the United States. The fact that a ship, vehicle, missile, or combat system is being built in their district should not figure in. Unfortunately, it does.
Internal Stakeholders
Major projects are often steppingstones for DoD employees, who may find themselves boxing above their weight class. Assignment as a project manager, contracting officer, lead engineer, and so on should go to the person with the best qualifications. While individual team members may be trying their level best, a struggling program can indicate those involved are not up to the challenge. Thus, program or project restructuring should include a scrupulous internal and external stakeholder identification, justification, and/or replacement.
Conflict Resolution and Changing of the Guard
In his book Project Management: A Systems Approach to Planning, Scheduling, and Controlling (Van Nostrand Reinhold Company, Inc, 1984), Dr. Harold Kerzner describes five approaches to conflict resolution: Confrontation, Compromise, Facilitation, Force, and Withdrawal. Figure 3 suggests how they may apply in a program.
The “Win-Win” is ideal, but it has probably been tried already without success. Thus, it may be too late for Facilitation or Compromise.
Next come Confrontation and Force. This is the “Win-Lose” and somebody always loses. It cannot be DoD, because the actual loser would be the sailor on the deckplates or the soldier in the trenches. Program managers have an ethical imperative to put the right person in the job—even if he or she is a replacement.
That does not mean every struggling program needs a bloodbath. It does mean that preoccupations with personal relationships, promotability, and the like may need to take a back seat. The goal must be safe troops, not happy staffers.
Withdrawal from the contract and the program is a “Lose-lose.” It may be inevitable. However, if all reasonable steps have been taken to work with a worthy contractor without success, or a pattern of provable corruption, deception, and incompetence has been uncovered, it probably is time to fully document the findings and recommendations and pull the plug.
Even if the program is in trouble, every bit of the design, structure, operation, and manning must be wire-brushed. Questions of staff legitimacy, qualifications, authority, responsibility, and accountability must be asked. Conflicts of interest or stakeholder interest must be addressed.
Looking Forward
Nothing is off limits when reworking a failing program. As a sign over my boss’s desk once read, “Sacred cows make the best hamburger.” Problems must be fixable, and fixes must be actionable. Numbers must be scrubbed, threats and risks identified, objectives kept realistic, reports meaningful, and accountability established. Nothing else will work.
In other words, if it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck. If it is late, over-budget, unsafe, and/or fails in form or function, it is probably a dead duck.
A version of this article was previously published in my sixth book: Make It Work or Make It Go Away: A Handbook for DoD Program Managers (AuthorHouse, 2021) and Defense Acquisition magazine.