Schedule or Event Driven? How Do I Know?

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

Author: Mark Husband, Dr.Eng.

Acquisition professionals know that program schedules should be established via “event-driven” planning. But what is the distinction between a schedule- versus an event-driven program? The author proposes that schedule-driven programs are distinguished not by whether they are behind schedule or have little margin, but by how management sets and controls schedules.

Schedules for event-driven programs are created by mapping out the entire set of activities that must be accomplished and determining their reasonable durations, while considering linkages and interdependencies between activities. In other words, an event-driven schedule is “built-up” by considering the time required to accomplish all the program’s activities. In contrast, a program can be considered “schedule driven” if, for a fixed content, the schedule is determined and event durations are established based on fixed time constraints associated with the project’s deliverables. One can conceive of schedule-driven programs in two categories: programs in which time constraints are imposed from the outset, and those in which revised time constraints are imposed during execution to “buy back” schedule slips or respond to externally imposed mandates. While the contrast between event- and schedule-driven programs is clear in theory, in practice all programs are subjected to fixed time constraints; otherwise each issue encountered would result in schedule slips corresponding to the time required to resolve that issue. Program managers (PMs) must continuously challenge their teams and industry partners to execute on schedule, even (or especially) when issues arise.

“Good” Versus “Bad” Schedule Goals

How might one distinguish between “bad” schedule-driven practices that harm programs and “good,” aggressive program management that yields more efficiency and productivity? Schedule goals can be thought of as having one of two broad purposes: They are established either to ensure a given capability is delivered in accordance with a fixed timeline (e.g., the warfighter requires the system by a certain date or mission failure will result), or they are established based on considered planning and used as a management and statusing tool to ensure effective program execution. While actual schedule goals generally have a combination of these purposes, considering them separately allows one to make a value judgment: Goals established to accomplish a given content within a fixed timeline are “bad,” as they yield a schedule-driven program. Such “bad” schedule goals may be imposed at program initiation (e.g., to meet a delivery timeline), or may be imposed on a well-planned program during execution as a response to schedule slips or externally imposed stimuli, thereby changing the program’s character from event- to schedule-driven.

article-1-secondary-2Of course, a fixed fielding date may be imposed on a program for legitimate reasons. During his tenure as Under Secretary of Defense for Acquisition, Technology and Logistics (USD[AT&L]), Dr. Ashton Carter said PMs sometimes need to consider a deadline as inviolable: “Think of it like a NASA planetary probe that has to rendezvous with the planet in 2017; if you don’t make that date you have to wait another 50,000 years.” Meeting treaty requirements is an example of a timeline that may be externally imposed on Department of Defense (DoD) programs (e.g., the Assembled Chemical Weapons Assessment program). Carter’s Sept. 14, 2010, Better Buying Power memo decried “the leisurely 10–15 year schedule of even the simplest and least ambitious Department programs” and included an Initiative to “Manage Program Timelines.” Negative consequences of extended program schedules are documented: substantial cost growth, late delivery of capability to the warfighter, and delivery of outdated technology and capabilities.

Just because a program is required to deliver capability on a fixed timeline does not automatically make it schedule-driven. Based on DoD’s evolutionary acquisition construct, acquisition professionals should make trades between cost, schedule and performance to design programs delivering blocks of capability that satisfy needs incrementally, meeting users’ timelines with an intermediate capability if full capability is unachievable. Also, in the author’s view, the mere fact that a program has little schedule margin, or even has burned through its available margin and now is behind schedule, does not mean it is schedule driven. A schedule-driven program is one in which, for a fixed content, time constraints established for the deliverables are used to establish durations of the project’s activities.

The mere fact that a program has little schedule margin, or even has burned through its available margin and now is behind schedule, does not mean it is schedule driven.

Establishing Dates for Program Deliverables

If a program were purely event driven, dates established for fielding its capability would be determined based on the system’s performance requirements and the associated required development and production times. In practice, DoD programs never are structured with such unconstrained fielding timelines. Instead, programs compete for initiation via the Planning, Programming, Budgeting and Execution (PPBE) system; those programs with the most urgent requirements to fill a capability gap or replace a legacy system are selected for funding in the president’s budget. Other prospective programs must wait until their associated need becomes more “urgent.” That programs are selected for initiation based on a process in which “urgency” provides a competitive advantage is a hint that the programs selected likely have an inherent schedule-driven character. This “self-selection of the most urgent programs for initiation” phenomenon might be a good screening criterion for identifying schedule-driven programs. Programs promoted as the most urgent by the Service or Component are most likely to be schedule driven.

Ironically, some programs that are promoted as urgent and designed with a schedule-driven acquisition strategy don’t appear in hindsight to have been as urgent as advertised. For instance, the Air Force and the Navy have commendably found ways to extend the service life of their tactical air fleets in the face of delays in the F-35 program, and the Army similarly has accommodated cancellation of the Comanche Helicopter and the Armed Reconnaissance Helicopter (ARH) through modifications and upgrades of its existing helicopter fleets. The Air Force tanker program was believed to be extremely urgent in the early 2000s, with claims that legacy tankers would soon “fall out of the sky” and that rising ­operations and maintenance costs of aging aircraft represented a crisis. Neither claim proved true; the latter was disproven by the Air Force’s own analysis. None of this implies that recapitalization and introduction of new and advanced capabilities are not vital to military effectiveness—because they are. However, programs designed with a schedule-driven acquisition strategy are much likelier to experience cost and schedule growth than if they are designed based on event-driven principles.

Before the 2009 Weapon Systems Acquisition Reform Act, DoD’s institutional incentives favored adopting an optimistic program baseline. Doing so allowed the DoD to initiate more programs with its given resources, and some officials believed that adopting a challenging baseline put pressure on the program to execute more efficiently. However, there is a difference between being aggressive and being unrealistic. Being aggressive can be good: It challenges people to put forth their best efforts and ideas, to innovate, and to engage in continuous process improvement. However, aggressive but unrealistic goals frequently have negative consequences. They may cause people to take ill-advised shortcuts or give less than their best effort, because “the expectations are impossible anyway.”

Schedule Compression

During a recent Defense Acquisition Executive Summary (DAES) review, USD(AT&L) Frank Kendall was briefed on a DoD Business System program that had encountered a 4-month slip of its contract award date. Rather than extend the period of performance to account for the delayed contract award, the program compressed its remaining schedule, which pressured the contractor to complete activities 4 months earlier than originally scheduled. Was this an example of schedule-driven behavior? Or good, aggressive program management?

In discussing the situation with the PM, the author learned that schedule pressures came not from acquisition leadership but from functional sponsors whose users are counting on the capability. According to the PM, the program was “schedule driven, with deliveries based on a schedule that wasn’t executable.” Stakeholders outside the program office argued that because the program baseline was issued before the contract award, extending the schedule would have necessitated changing the established baseline. To an acquisition professional, compressing a schedule as a result of a late contract award seems foolish—a clear indication of schedule-driven behavior. However, from the functional community’s perspective, they have an approved capability requirement with an associated fixed timeline—in this case, the system is a part of efforts to achieve auditability in accordance with congressionally mandated timelines. In short, different interests and expectations among stakeholders lead to different perspectives about the best course of action (COA). Acquisition professionals are responsible for advocating COAs that posture the program for success, while recognizing that external stakeholder considerations (e.g., user-needs, policy, congressional or public interest concerns) may trump acquisition rationales.

While there are times when delivery dates are inviolable (rendezvousing with a planet) and times when external stakeholder considerations carry the day, acquisition professionals should recognize indicators of schedule-driven programs and advocate for event-driven strategies. The next section describes examples of programs initiated with schedule-driven constraints, while the following section discusses indicators that a program with an event-driven plan has adopted schedule-driven strategies in response to schedule slips or external mandates.

Constraints Imposed at Program Initiation

As an analyst in the Cost Analysis Improvement Group (CAIG) of the Office of the Secretary of Defense (OSD), the author observed several programs that appeared to be schedule driven at initiation. By far the most frustrating were instances in which knowledgeable program office personnel—e.g., engineers, cost analysts, contracting specialists and PMs—acknowledged privately that the planned program schedule was too optimistic, but explained that “their leadership” required it to be done that fast. During discussion of the cost estimates, analysts in the OSD often described the program as “schedule driven” or “overly optimistic,” while the Service analyst described it as “aggressive” or “success oriented.” A few examples will show how decision makers, with good intentions, can negatively influence a program through the desire to deliver capability faster.

article-1-secondary-1In 2005, during initiation of the ARH, which was intended to replace the Bell OH-58 Kiowa helicopter, the program management team presented a plan to Army leadership to conduct a relatively rapid development effort of approximately 3 years (from Milestone [MS] B to MS C). Army leadership was not satisfied that the timeline adequately met warfighters’ needs and pushed for faster fielding. Ultimately, the program was baselined in July 2005 with a 20-month development plan—much faster than any helicopter development program in the CAIG database. In October 2008, the ARH program was terminated following multiple schedule breaches and cost breaches exceeding 40 percent. To date, despite several attempts, the Army has not initiated a follow-on replacement program for the OH-58.

Also in 2005, the Presidential Helicopter VH-71 program was baselined based on the Navy’s cost position, which predicted a significantly shorter timeframe for development than the CAIG estimate. According to a 2011 Government Accountability Office report, VH-71 was “knowingly initiated with a high-risk business case … the Navy adopted a two-step acquisition approach and initiated production at the same time it began development … the program had a high-risk schedule because of concurrent design and production efforts.” As with ARH, senior decision makers had good intentions to replace aging VH-3D and VH-60N helicopters and meet extremely challenging requirements on a very streamlined timeline. According to the 2007 Selected Acquisition Report by the program office, “The Increment 1 strategy purposely acknowledged a high schedule risk to meet urgent needs for safe and reliable Presidential transport.” They could just as well have written “this program is schedule driven with an extremely low probability of success.” VH-71 was canceled after an expenditure of nearly $3 billion and multiple schedule and cost breaches, and a follow-on program has yet to be initiated.

In the nonattribution environment of Defense Acquisition University, PMs frequently share experiences describing how unrealistic expectations are imposed on them by leaders or external stakeholders. The author has heard variations of the same story many times: A cost estimate and corresponding acquisition strategy are presented to flag officers or senior executives during the program initiation process, and the PM is given two great pieces of management wisdom: Lower the estimate and shorten the program timeline. In one particularly vivid example, a PM recounted how, during restructuring of the Space-Based Infrared System-High satellite surveillance program after its critical Nunn-McCurdy breach, the Secretary of the Air Force was presented three COAs and chose the one that had a 3 percent confidence level—i.e., a 3 percent chance of coming in at or below cost. According to program office personnel, the Secretary had been assured by a senior industry official that the aggressive launch date could be met. The bet didn’t pay off, as the program experienced another schedule breach and was rebaselined.

“The Increment 1 strategy purposely acknowledged a high schedule risk to meet urgent needs for safe and reliable Presidential transport.” They could just as well have written “this program is schedule driven with an extremely low probability of success.”

Migrating from Event- to Schedule-Driven

Programs originally planned and initiated based on event-driven principles may become schedule-driven in response to delays or external mandates. The author proposes that indicators of schedule-driven behavior for such programs fall into one of several categories, skipping steps (or compressing the time for those steps); slipping content to the right, or adding content without appropriately recognizing schedule consequences.

The possibilities for engaging in schedule-driven behavior by skipping or compressing steps is limited only by one’s imagination. Some examples:

  • Curtailing tests
  • Lowering standards or specifications (for products or processes)
  • Increasing concurrency (concurrency may be planned at program initiation or may be introduced during execution in response to issues or mandates)
  • Cutting analyses or assessments
  • Reducing or eliminating reviews or oversight functions, including quality assurance or inspections
  • Deleting or delaying reliability, cost-reduction, or sustainability efforts

Again, a few actual program examples will suffice to demonstrate schedule-driven behaviors.

Curtailing Tests. The Joint Tactical Radio System (JTRS) Handheld, Manpack and Small Form (HMS) Rifleman Radio (RR) program encountered unexpectedly poor reliability during Governmental Developmental Testing (GDT) that caused it to fall behind schedule and complete only 33 percent of the GDT that was planned to support the Initial Operational Test and Evaluation (IOT&E) readiness assessment. As a result, the Deputy Assistant Secretary of Defense for Developmental Test and Engineering DASD(DT&E) recommended the program resolve reliability issues and complete GDT before entering IOT&E. However, the program’s IOT&E was part of a large Network Integration Exercise (NIE) involving multiple systems and operational units. Completing GDT and resolving the reliability issues would have required obtaining revised commitments from the test range and operational units, both of which are difficult to schedule.

The absence of JTRS-HMS RR also would have negatively affected the planned NIE, which was created to test compatibility and interoperability of multiple systems. As a result, Army decision makers chose to proceed to IOT&E before completing GDT and, not surprisingly, poor reliability was one of the findings in the resulting assessment by the director, OT&E. In recognition that recommendations based on poor DT results often are too late to affect decisions to enter IOT&E (because IOT&E budgets are set, ranges are reserved and operational units engaged), the ODASD(DT&E) has initiated efforts to obtain quality DT information earlier, to provide better, more timely information to decision makers.

Lowering Process Standards. The Capability Maturity Model Integration (CMMI) is a set of standards developed by Carnegie Mellon University, originally as a guide to software development, but more recently applied to assess business processes. During a discussion at DAU, a PM described how, after encountering schedule challenges, a program relaxed the required CMMI standards for software development, to speed up the work and regain schedule. If applying CMMI standards has value when the program is conceived and planned, then relaxing or rescinding those standards when the program encounters schedule challenges is clearly a sign of a schedule-driven program.

Increasing Concurrency. The VH-71 Kestrel Helicopter and F-35 jet fighter programs are examples in which excessive concurrency was part of a program’s original acquisition strategy, making the programs schedule driven from the outset. The GAO Schedule Assessment Guide (May 2012) says “a schedule that contains many concurrent activities, unrealistic activity durations or logic, or a significant number of constrained start or finish dates is a common indicator of poor program performance.” Alternatively, a program may become schedule driven by increasing concurrency of its activities. A program’s schedule may be compressed as a result of well-intentioned efforts to improve efficiency, such as through Should Cost management.

The CH-53K and B-2 Defensive Management System (DMS) programs developed plans to deliver capability sooner by compressing their schedules based on Should Cost approaches. However, their efforts were unsuccessful for different reasons—technical challenges prevented CH-53K from compressing its time to first flight and completing IOT&E as planned, while B-2 DMS had to lengthen its desired schedule because of near-term funding constraints.

Slipping Content. This may indicate schedule-driven behavior. In some cases, slipping content indicates good management—e.g., when intractable issues are encountered and the PM has authority to make trades between cost, schedule and performance. In other cases, slipping content indicates poor management, such as when delivered products don’t meet user needs.

Because it may occur for legitimate reasons, content slippage alone does not equate to schedule-driven behavior. Some instances in which content slippage may be associated with schedule-driven behavior include:

  • Proceeding to IOT&E with nonproduction representative articles
  • Executing tasks out of sequence in an attempt to maintain schedule, even when doing so results in significant scrap, rework or retrofits.

Adding Content Without Recognizing Schedule Consequences. You don’t need much experience, just common sense, to realize that adding content to a program without adding schedule would be foolish. However, when content is added (be it “requirements creep” or an increase in program scale), it opens the opportunity for schedule-driven behaviors of the types already described—i.e., at initiation via the imposition of fixed timelines, or during execution whereby the consequences of the added content are not appropriately recognized. Program examples familiar to the author tend to involve disconnects or misunderstandings between the government and contractor concerning exactly what the added content entails. In such cases, the schedule consequences were arguably recognized by the government but inadequately communicated to the contractor or translated into contractually binding documents.


Schedule slips are important in assessing a program’s progress and performance. However, schedule slips alone are not evidence of “schedule-driven” programs. Slips could be due to variations inherent in schedule estimation and the simple fact that “stuff happens.” Instead, the author asserts that schedule-driven behavior is more specific: It consists of goal-setting choices management makes as programs are planned and initiated or while programs are executed. A program can be considered schedule driven if (1) its schedule is mandated at initiation; (2) it attempts to accelerate or “buy-back” schedule by compressing or skipping activities; (3) it detrimentally slips content solely to maintain schedule; or (4) it adds content without adding schedule.

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

Husband is the senior advisor for root cause analyses in the Office of the Under Secretary of Defense for Acquisition, Technology and Logistics, Peformance Assessments and Root Cause Analyses. He is a retired Air Force officer with a doctorate in chemical engineering from Germany’s Karlsruhe Institute of Technology. He is grateful to Gary Bliss, Bob Jennings, Mike Ginter, John Mueller and Ed McDermott for helpful discussions and for providing examples of schedule-driven practices they have observed.

The author can be reached at



Leave a Reply

Your email address will not be published. Required fields are marked *