13-655-lead-image

Time Is Money


To print a PDF copy of this article, click here.

Author: Roy L. Wood

Program managers typically focus on controlling costs and delivering a quality product. The acquisition stool’s third leg—program schedule—appears to be a resource that can be slipped to accommodate unstable funding or technical difficulties. Despite studies linking high program cost and long schedules, few major defense acquisition programs are completed in less than a decade. Programs with longer schedules experience further schedule slips, exacerbating the problem. This article is based on research presented at the 2012 Naval Postgraduate School’s 9th Annual Research Symposium. It includes a review of the extant literature on cost and schedule relationships, presents analysis of a survey of program manager perceptions and master schedule usage, and examines why schedules may be problematic to acquisition success.


Program success is traditionally measured by cost, schedule, and performance. When issues arise, trade-offs between these three are made; conventional wisdom, however, says the program manager (PM) can generally preserve only two of the three. For example, if current budgets are cut, then programs are forced either to give up some “bells and whistles” in performance, or lower the spend rate and stretch out the program schedule. If the program schedule is delayed for reasons such as lagging technology readiness or testing failures, then program costs will rise or the scope of the program’s content will have to be sacrificed.

When making such trade-offs, reasonably good tools and techniques are available for estimating cost impacts and performance trades are usually understandable. However, when it comes to program schedules, trade-offs can be much less clear and the impacts more difficult to determine. “Working harder” or placing more “management emphasis” on an area are often viewed as ways to improve performance and “compress” schedules to remain on track. These ideas can lead to an overly optimistic attitude that, unlike money, time is somehow elastic and forgiving. This also leads to a skewed perception about the value of program time in the future versus the present. Resource problems in the near term are often “solved” by pushing work into the future, moving milestones forward while keeping the program end date static, while simultaneously compressing all the activities in between. This forces activities to become more concurrent and increases the complexity of coordinating and synchronizing program activities.

Purpose

This article explores the relationship between program time and cost. While most of us have heard the truism that “time is money,” little evidence has emerged that PMs perceive aggressively managing time and schedules can help control costs. As an exploratory effort, this research examined the literature on program scheduling, reasons program schedules were not adhered to, and the relationship of program schedules to cost and program performance. Using a survey of 73 PMs attending senior courses at the Defense Acquisition University in February 2012, this article also examines PM uses and attitudes toward their own program schedules.

Length of a Program Contributes to Program Cost

The Packard Commission noted in 1986 that, “an unreasonably long acquisition cycle . . . is a central problem from which most other acquisition problems stem” (p. 8). Echoing this sentiment 20 years later, the Defense Acquisition Performance Assessment report recommended that, instead of waiting decades for 100 percent performance, programs be held to a “time-certain development” period of 6 years from the initial milestone (MS-A) to delivery of a militarily useful capability (Kadish, 2006, p. 12). The report enumerates some of the benefits of shorter development cycles:

  • Operators with a basic capability in hand would gain a better understanding of full requirements to be inserted in future increments.
  • Technology in the initial design would be at a higher readiness level, and would mature during the period between first deliveries and subsequent increments.
  • New requirements and technologies would be intentionally inserted in later increments, removing the temptation to perturb the current development and adding stability to the acquisition.
  • Reducing time in development would also help add funding stability across the entire program portfolio (Kadish, 2006, pp. 12–13).

In a dissertation study at the Massachusetts Institute of Technology of 154 defense projects, McNutt (1998) found that cost increased on a 4th power scale with development time. Figure 1 shows a derivation of McNutt’s “best fit” power relationship on a linear plot. One can observe that the “knee in the curve” where costs begin to escalate significantly is around 6.5 years, indicating that costs for programs with schedules that extend beyond this point risk quickly becoming unaffordable.

Figure 1. Development Cost Versus Time (Linear Scale for Clarity)

More recently, the Under Secretary of Defense for Acquisition, Technology and Logistics issued an update—Better Buying Power 2.0—that recognizes, and proposes to reduce, some of the factors that increase program development (Kendall, 2012). According to the memorandum, these include “oversight activities, funding stability, contracting lead time, requirements processes, technical complexity, use of risk reduction factors, and testing requirements” (p. 5). Some of those factors are examined in this article.

Complex Technical Requirements

A number of reasons may explain why the length of a program impacts its cost so dramatically. First, a longer schedule may be an acknowledgement of complex technological requirements that contribute to a program’s developmental challenges. Programs like the F-35 Joint Strike Fighter or the DDG-1000 naval destroyer with substantial capability needs, advanced technology, unique features, or with significant integration or interdependencies with other programs, can be expected from the outset to take longer to develop, cost more, and have greater risk.

Evolving requirements and technology advancements. Programs with long timelines may also be subject to more requirements changes as threats and technologies evolve over time. As new threats emerge during a program’s development, there would be a need to try to address those threats by adding or refining the delivered system’s capabilities.

Requirements changes during a program’s lifetime can have substantial impact on schedule and cost. In a recent Center for Strategic and International Studies analysis, $37 billion of cost overruns in the major defense acquisition program portfolio are linked to schedule, and the report notes that defense contractors cite requirements changes late in a program as a major cause of schedule impacts (Berteau, Hofbauer, Sanders, & Ben-Ari, 2010).

Requirements changes during a program’s lifetime can have substantial impact on schedule and cost.

Similarly, a recent industry white paper noted, “frequent and ‘inside lead time’ changes to program requirements and production schedules are major obstacles to successful cost and schedule attainment for most aerospace and defense programs” (Archstone Consulting, 2012). This assertion is backed up by the 2008 Government Accountability Office (GAO) analysis of defense weapons systems, which states that “63 percent of the programs we received data from had requirements changes after system development began. These programs encountered cost increases of 72 percent, while costs grew by 11 percent among those programs that did not change requirements” (p. 5).

When requirements changes occur during development, replanning and rework follow. New requirements must be flowed down as allocated functions via the systems engineering process. This becomes particularly challenging after Critical Design Review when a system’s baseline is approved and the system is deemed ready to proceed to fabrication, demonstration, and test. Any new requirements must be engineered and integrated as well as possible into existing program plans. This adds complexity and takes time and care. Drawings and specifications must be revised, schedules and task budgets altered, test plans modified, and resources allocated or shifted to attend to new or modified tasks. In almost any conceivable circumstance, wasted prior effort will be scrapped and rework will be required to accommodate new changes, exacerbating the delay and disruption created by the new requirements.

Also, given the relatively few new program starts, the temptation is ever present for requirements managers and technologists to demand more capabilities in each new program. The need to meet forecasted future threats can also drive an appetite among users toward ever greater technical capabilities. Stressing requirements for the Air Force’s fifth-generation fighter, the F-22 Raptor, for example, included stealthy titanium and composite structure, advanced avionics, active-array radar, supersonic cruise, and other enabling technologies. Likewise, the Navy’s Zumwalt-class destroyer included requirements for reduced crew size, advanced active-array radar, integrated power system, electric drive, stealthy hull, integrated superstructure, 155 mm gun, and peripheral launching system. Many of these technologies were developed and matured concurrently during the program engineering and manufacturing development phases (Francis, 2005; GAO, 1998).

Schedule and cost uncertainty are high for new technology development, but this uncertainty becomes a substantial risk when overlaid on program milestones that depend upon successful delivery of the technology to support testing and fielding a new system. When several new technology developments are ongoing, as in the case of the F-22 and the Zumwalt destroyer, this uncertainty multiplies, and orchestration of technology insertion becomes extremely challenging. It should be of little surprise that both these programs delivered substantially late and over budget (Bolkcom, 2009; O’Rourke, 2012).

Budget churn. Unstable funding has often been blamed for program schedule and cost issues. Langbein (2004) cites three different types of funding instability that impact programs. The first is perhaps the most obvious—quantity of dollars. These are programs with insufficient total funding to perform the required tasks to deliver the system. Underfunded programs can be caused by poor cost estimating for the funding that is needed by the program, unforeseen and unbudgeted changes, or overly optimistic cost targets. In defense acquisition, two other, less obvious pitfalls—“color” of money and timing of money—can create program instability and schedule problems.

In every program, defense managers must break down total funding into its constituent functions and categories of funding for specific portions of the program. Research and development, procurement, operations and maintenance, shipbuilding and conversion, and other “colors” of money must be appropriately aligned to fund the associated tasks in the program. At times, a program may have sufficient overall funding, but an incorrect allocation within the colors of money. The PM may find shortfalls in some areas and surpluses in others, but not have the authority to move the Congressionally appropriated dollars from one account to another. These shortfalls can stop activities in parts of the program and create overall delays. Timing of funding can also create similar problems. Program budgets are closely aligned with planned work in any given year. If challenges or opportunities arise within the year of execution, current year funding may not be sufficient to accommodate new funding requirements, again creating potential delay and disruption to the program schedule.

In each of these cases, program schedules must be replanned to accommodate different funding realities. Reprogramming or repurposing current year funding is generally not simple or quick. Requests for more, or different, funding can take up to 2 years to realize through the Planning, Programming, Budgeting, and Execution system. Tasks must be trimmed in the current year and work adjusted so the financial impacts can be addressed over the longer term. The results may be that key events and milestones are missed, concurrency increases, and opportunities are lost.
Longer programs potentially suffer greater budgetary churn. Each new fiscal year presents an opportunity for decision makers outside the program to make funding “adjustments” that perturb the program’s overall performance. Likewise, longer programs with large budgets can be tempting targets for comptrollers or Congress.

Developing Schedules

The Scheduling Process

The schedule development process itself may be a culprit in program cost overruns. Ideally, program schedules are developed in a rational and linear manner. Program requirements are analyzed and developed through the iterative systems engineering process, allocating required functions to be performed by the system’s hardware, software, and operators. A work breakdown structure (WBS) is created, assigning those functions to subsystems and components. At the lowest level of the WBS, work packages are developed that allow accurate estimation of the resources—dollars, time, and manpower/expertise—required to build, test, and deliver the hardware or software widget. Rolling up these detailed resource requirements to higher levels of the WBS, then, allows the program management team to create an overall program budget estimate, resource-loaded schedule, and program manpower estimate. The resource-loaded schedule will show each task with its estimated duration and linkages to other tasks to show dependencies (e.g., Task B cannot start until Task A is complete), major milestones where tasks culminate in a defining program event, the calculated program end date, and associated critical path. If each task is then given the appropriate resources and completes within its estimated timeframe, then the program execution proceeds from start to finish with nary a problem.

Unfortunately, this is generally not how program schedules are constructed. Project end dates are more often arrived at from a capability “need date” established early in the program by the user or sponsor. In the survey of program management students at the Defense Acquisition University in 2011, only 18 percent reported that their program end date was determined through a roll-up of task level schedules, while 58 percent reported end dates determined by need.

Apparently, herein lies the source of some inherent program problems. In this method of program end date determination, the need date or end date is fixed and the program milestones are “backed out” from there. Other project tasks are fitted into the milestone scheme, along with whatever concurrency and optimism are needed to make the schedule “work.” Fully 82 percent of the program management students participating in the DAU survey reported that their program schedules contained some to significant concurrency with moderate to high schedule risk.

In execution, to stay on schedule programs must accept risks, and, as the GAO has noted in its annual Assessments of Selected Weapons Programs, proceed through milestones before achieving requisite design and engineering maturity (GAO, 2009, 2010, 2011). This results in programs being, “at a higher risk for cost growth and schedule delays” (GAO, 2011).

Ninety-six percent of those polled reported that having an integrated and up-to-date schedule is critical to running their programs, and two-thirds express confidence in the accuracy of their master schedules.

Scheduling processes are not well understood or executed. The process of scheduling itself is difficult and may not always be as useful as it could be as a key project management tool. The National Defense Industrial Association (NDIA)’s Industrial Committee for Project Management recognized that the art of scheduling for complex projects was problematic for government programs and chartered the Program Planning and Scheduling Subcommittee to create the Planning and Scheduling Excellence Guide (NDIA, 2012). This guide was designed to assist government and industry in creating more useful, consistent, and standardized integrated master schedules (IMS) using the principles of the internationally recognized standard, Generally Accepted Scheduling Practices. The guide emphasizes practical skills and application of sound scheduling principles to create a schedule that models the acquisition plan, provides tips for schedule maintenance, and advice for project managers to use the IMS more appropriately to manage a complex government program.

The survey of PMs at the Defense Acquisition University revealed some insights into how schedules are viewed by current managers. Ninety-six percent of those polled reported that having an integrated and up-to-date schedule is critical to running their programs, and two-thirds express confidence in the accuracy of their master schedules. However, less than half reported that their schedule is accurately resource-loaded, and only 51 percent are confident their schedule includes all the work required to be done by government and contractors. These results seem to be inconsistent and perhaps contradictory. Only half responded that their schedules are complete and accurate, yet most have confidence in the schedule and overwhelmingly affirm its importance to their program’s success! The Table shown here summarizes these views.

Table. Program Manager Views of Their Schedules

Statement Agree or Strongly Agree Neutral, Disagree, or Strongly Disagree
Having an integrated and up-to-date schedule is critical to running my program 96% 4%
I have confidence in the accuracy of my master schedule 65% 35%
My schedule is accurately resource-loaded 45% 55%
My program schedule is realistic and achievable 56% 44%
My schedule includes all required work, including that of government organizations, all contractors, and subcontractors 51% 49%

Similarly, in execution, 56 percent responded that their schedule is realistic and achievable, while 40 percent report that their programs are behind schedule. When faced with hypothetical budget cuts, 48 percent indicated they would defer requirements or capabilities, while only 20 percent would slip schedule as a preferred method to manage overruns. However, the PMs assigned the highest priority for their programs as ensuring quality and performance of their products, and they ranked controlling program scope last in relative priority. Again, while their responses to questions of importance align closely with current policies of adjusting scope to budget, the practical priorities on performance and scope, as reported by the PMs, would seem contradictory.

Finally, when the statement is posed, “Maintaining an accurate detailed schedule is too labor-intensive and costly for the value,” fewer than 10 percent agreed or strongly agreed. When asked about current program issues, respondents reported difficulty in synchronizing schedules among players second only to unstable funding. Again, this seems to indicate the importance PMs place on the theoretical value of their IMS, and a recognition that large program scheduling is, in practice, challenging.

Program problems can be created when program teams and stakeholders underestimate the challenges and overestimate their abilities to deliver on “success-oriented,” aggressive schedules.

Overoptimism can lengthen program schedules and increase costs. Given that many program end dates are set well before any of the work begins, perceived necessity, concurrency, and optimism drive milestone schedules and tasks. Once the analysis of the work that must be accomplished is underway, tremendous pressure is pervasive in keeping to original agreements and promises to deliver, however unrealistic. In the “Conspiracy of Optimism” white paper, the International Centre for Complex Project Management (ICCPM, 2010) authors explain:

Once initial project budgets and schedules are set, based on such estimates, they have immense staying power, driven by collective unrealistic expectations, even to the extent that over time, system functionality and project resources are sacrificed in order to achieve what was unobtainable in the first place.

Program problems can be created when program teams and stakeholders underestimate the challenges and overestimate their abilities to deliver on “success-oriented,” aggressive schedules. This optimistic thinking necessarily flows down from the government to the system contractors. Once the government team has fallen into its own overly optimistic decision trap, contract requests for proposal are written based on the ill-conceived plan, and contractors then come to the table hoping to have the most attractive bid to meet the government’s ill-conceived expectations. Unfortunately, this also often creates an environment where realistic assessments of cost and schedule are undervalued, and contractors who refuse to join in on the conspiracy risk losing the job (Eden, Ackermann, & Williams, 2005):

It is common for commercial considerations to lead to “doctoring” of the estimate in order to drive estimated costs down—particularly where there are strategic reasons for wanting to win that particular bid. Later, at the planning stage, this “doctoring” is forgotten and unrealistic plans are made. As the project unfolds, this lack of realism is very likely to play one of the most significant and unattributed roles in increased costs. Underestimating at the planning stage is one of the most common triggers for cost escalation . . . . (p. 19)

Kahneman (2011) argues that the optimism bias is inherent and pervasive in individuals and teams taking risks under conditions of uncertainty or ambiguity. He offers that remedies to this bias are often gained through using a comparison of timelines for similar prior projects as a baseline for the current one, or getting an outside view from a third party who may be able to assess the reasonableness of project estimates. He also encourages the practice of “pre-mortems,” where the project team envisions future project failure and offers all the things that might have caused it (p. 264). This exercise may empower the team to bring to light issues that have not been previously considered (or ignored), help break groupthink, and encourage the team to accept evidence of overoptimism in the project’s planning.

Conclusions

While the quantitative evidence linking schedule to cost is murky, most of the literature agrees qualitatively that longer programs incur greater costs and cost overruns. Longer programs tend to be more complex and include significant technology development efforts. They are more susceptible to requirements changes and budget churn. Longer programs seem to have an affective component where time is undervalued and decisions can be deferred. Pushing work into the future can create a bow wave of work that must then be accomplished with more concurrency, thereby generating the need to apply additional resources in an attempt to meet the program delivery date. This limits the program’s cost-schedule-performance trade-space and can lead to even greater churn.

Several potential remedies have been suggested by the literature. First, where possible, shorten program timelines from inception to delivery of a usable capability (a goal should be no longer than 6-1/2 years). This would expose higher risk requirements and technology development that could be done within a program and reduce the opportunities for requirements changes. Shortened programs would facilitate more accurate cost and schedule estimates, and fewer budget cycles would limit the opportunities for comptrollers and Congress to change program funding profiles.

Next, artificial program “need dates” should be compared with a rational bottom-up schedule derived from the WBS and systems engineering process. The bottom-up analysis should then inform a more reasonable program delivery date and moderate the amount of program concurrency. Similarly, overoptimism must also be tempered by objectively comparing current plans and schedules with similar past programs. Further, from the survey of senior defense PMs, it appears, at least in principle, that they value and appreciate the utility of good integrated schedules. However, it appears equally likely that inconsistencies and contradictions exist in how PMs use schedules in actual practice. These results imply that there may be a need for better training and a renewed focus on schedule development and management. Finally, PMs and acquisition leaders must understand and appreciate the linkage of cost and schedule, and the value of time to program success. Time, after all, is money.


To print a PDF copy of this article, click here.

Author Biography

wood-headshotDr. Roy L. Wood is dean of the Defense Systems Management College at the Defense Acquisition University, and an adjunct professor in the School of Advanced Studies (Doctoral Program) at the University of Phoenix. He has served as a U.S. Navy Engineering Duty Officer and acquisition professional, PM, businessman, and Department of Defense executive.

(E-mail address: roy.wood@dau.mil)


References

Archstone Consulting. (2012). Delays, delays: A roadmap for improving performance across the aerospace and defense supply chain. Retrieved from http://www.archstoneconsulting.com/industries/manufacturing/white-papers/delays-roadmap-for-improving-performance.jsp

Berteau, D., Hofbauer, J., Sanders, G., & Ben-Ari, G. (2010). Cost and time overruns for major defense acquisition programs. Center for Strategic and International Studies (CSIS). Retrieved from http://csis.org/files/publication/100611_DIIG_CATO_MDAP .pdf

Bolkcom, C. (2009). F-22A Raptor. Congressional Research Service. Retrieved from http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA496273

Eden, C., Ackermann, F., & Williams, T. (2005). The amoebic growth of project costs. Project Management Journal, 36(2), 15–27.

Francis, P. (2005). Progress of the DD(X) destroyer program (Report No. GAO-05-752R). Retrieved from http://www.gpo.gov/fdsys/pkg/GAOREPORTS-GAO-05-752R/pdf/GAOREPORTS-GAO-05-752R.pdf

Government Accountability Office. (1998). Best practices: Successful application to weapon acquisitions requires changes in DOD’s environment (Report No. GAO/NSIAD-98-56). Retrieved from http://www.gao.gov/assets/160/156088.pdf

Government Accountability Office. (2008). Assessments of selected weapon programs (Report No. GAO-08-467SP). Retrieved from http://www.gpo.gov/fdsys/pkg/GAOREPORTS-GAO-08-467SP/content-detail.html

Government Accountability Office. (2009). Assessments of selected weapon programs (Report No. GAO-09-326SP). Retrieved from http://www.gao.gov/new.items/d09326sp.pdf

Government Accountability Office. (2010). Assessments of selected weapon programs (Report No. GAO-10-388SP). Retrieved from http://www.gao.gov/new.items/d10388sp.pdf

Government Accountability Office. (2011). Assessments of selected weapon programs (Report No. GAO-11-233SP). Retrieved from http://www.gao.gov/new.items/d11233sp.pdf

International Centre for Complex Project Management. (2010). The conspiracy of optimism [Roundtable findings white paper]. Retrieved from http://www.iccpm.com

Kadish, R. (2006). Defense acquisition performance assessment report (Assessment Panel of the Defense Acquisition Performance Assessment Project). Retrieved from https://acc.dau.mil/CommunityBrowser.aspx?id=18554

Kahneman, D. (2011). Thinking, fast and slow (1st ed.). New York: Farrar, Straus, and Giroux.
Kendall, F. (2012). Better buying power 2.0: Continuing the pursuit for greater efficiency and productivity in defense spending [Memorandum]. Retrieved from http://www.defense.gov/news/BBPWorkforceMemo.pdf

Langbein, G. L. (2004). An assessment of funding delay in government project. Retrieved from https://acc.dau.mil/adl/en-US/106355/file/23903/HW1_DE_LangbeinG.pdf

McNutt, R. (1998). Reducing DoD product development time: The role of the schedule development process (Doctoral dissertation). Massachusetts Institute of Technology, Boston.
National Defense Industrial Association. (2012). Planning and scheduling excellence guide. Retrieved from http://www.ndia.org/Divisions/Divisions/Procurement/PMSC/Documents/PMSCCommittee/CommitteeDocuments/PASEG/Planning_and_SchedulingExcellenceGuide_PASEG_v2.pdf

O’Rourke, R. (2012). Navy DDG-51 and DDG-1000 destroyer programs: Background and issues for Congress. Congressional Research Service. Retrieved from http://www.fas.org/sgp/crs/weapons/RL32109.pdf

Packard, D. (1986). A formula for action: A report to the President on Defense acquisition (The Packard Commission Report: President’s Blue Ribbon Commission on Defense Management). Retrieved from http://babel.hathitrust.org/cgi/pt?id=pur1.32754078697780;view=1up;seq=1

Padgett, M. (2010). Decision-making models: A case study of an international military technology mining center location decision (Unpublished doctoral dissertation). Phoenix, AZ: University of Phoenix, School of Advanced Studies.

Comments

comments