Capturing All Effort

The IMS should reflect all effort necessary to successfully complete the program, regardless of who performs it. Failing to include all work for all deliverables, regardless of whether they are the government’s responsibility or the contractor’s, can hamper program members’ understanding the plan completely and the program’s progressing toward a successful conclusion. If activities are missing from the schedule, then other best practices will not be met. Unless all necessary activities are accounted for, no one can be certain whether all activities are scheduled in the correct order, resources are properly allocated, the critical path is valid, or a schedule risk analysis will account for all risk.

Because the schedule is used for coordination, the absence of necessary elements will hinder coordination, increasing the likelihood of disruption and delay. A comprehensive IMS should reflect all a program’s activities and recognize that uncertainties and unknown factors in schedule estimates can stem from, among other things, data limitations. A schedule incorporates levels of detail that depend on the information available at any point in time through a process known as rolling wave planning. Rolling wave planning is described in Best Practice 3.

A program IMS is not simply the prime contractor’s schedule; it is a collection point for all work scopes executed by the program. That is, it is a comprehensive plan of all government, contractor, subcontractor, and key vendor work that must be performed. Along with complete contract life-cycle effort, the schedule must account for related government effort such as design reviews, milestone decisions, receipt of government-furnished equipment, and testing. It is also important to include the government effort that leads to the final acceptance of a product or service—for example, certain activities that only the government can perform, such as reviewing and accepting deliveries, obtaining permits, and performing program reviews.

Schedulers should be aware of how long these government activities take because they often have a clear effect on schedules; for instance, a program phase cannot begin until a government review is complete. In addition, if risk mitigation plans have been determined and agreed on, then mitigation activities should also be captured in the schedule.2 In particular, risk mitigation activities with scope and assigned resources should appear as discrete activities in the schedule.

Case Study 1: Attempts in Varying Degrees to Capture All Effort, from DOD Business Transformation, GAO-11-53

GAO analyzed four enterprise resource planning system schedules and found that none of the programs had developed a fully integrated master schedule as an effective tool to help in the management of the programs. In particular, the schedules differed in the extent to which they captured all activities, as well as in their integration of government and contractor activities. For example, the Defense Enterprise Accounting and Management System Program Management Office did not have a schedule that integrated government and contractor activities. It maintained internal schedules that reflected government-only activities, but these activities were not linked to the contractor’s activities. While the Army’s Global Combat Support System schedule identified contractor activities, it contained only key government milestones for the program. Other government activities, such as testing events and milestones beyond December 2010, were not captured in the schedule. Instead, they were displayed in isolated, high-level illustrated documents. The Expeditionary Combat Support System program schedule contained detailed activities associated with government effort and contractor effort. However, the government activities were not fully linked to contractor activities, so that updates to government activities did not directly affect scheduled contractor activities. Finally, while the General Fund Enterprise Business System schedule captured government and contractor activities, key milestones in deployment, software release, and maintenance were not fully integrated, precluding a comprehensive view of the entire program.

In scheduling, best practices are interrelated so that deficiencies in one best practice cause deficiencies in other best practices. For example, if the schedule does not capture all activities, then there will be uncertainty about whether activities are sequenced in the correct order and whether the schedule properly reflects the resources needed to accomplish the work.

A contractor project schedule, as a subset of the overall government program effort, includes only contractually authorized work because contractors are obligated to plan activities required by, and limited to, the contract. It is therefore the responsibility of the government program management office to integrate all government and contractor work—contractually authorized or not—into one comprehensive program plan that can be used to reliably forecast key program dates.

Moreover, everyone who is affected by the schedule should clearly agree on the final actions that constitute the completion of the program. For instance, if the scope includes financial closeout, contract disputes, and final payment activities, these should be completed before the finish milestone. Case study 1 gives examples of partially integrated schedules.

Milestone, Detail, and Summary Activities

Planned effort and events are represented in a schedule by a combination of milestones, detail activities, and summary activities. Milestones are points in time that have no duration but that denote the achievement or realization of key events and accomplishments such as program events or contract start dates. Because milestones lack duration, they do not consume resources. Two important milestones that every schedule should include are the project’s start and its finish. No work should begin before the start milestone, and all project scope must be completed before the finish milestone. A project plan that does not emanate from a single start milestone activity and terminate at a single finish milestone activity is not properly constructed and may produce an erroneous critical path. Figure 2 is an example of a milestone.

Figure 2: A Milestone’s Dates
Tip: Click the figure to view a larger version in a new browser tab.

A best practice is to include milestones only to reflect major events or deliverables.3 A milestone should have clear conditions for completion. Examples of milestones include the start and finish of the design stage, start and finish of subcontractor work, and key hand-off dates between parties. The presence of too many milestones in a schedule may mask the activities necessary to achieve key milestones and may prevent the proper recording of actual progress. That is, when too many milestones are introduced into a schedule, the activity sequences that are most likely to delay milestone achievement may become increasingly difficult to identify. If work is represented by milestones, actual progress recorded in the schedule cannot be used to forecast the dates of key events.

Detail activities are at the lowest level of the WBS and represent the performance of actual discrete work that is planned in the program. They are measurable portions of effort that result in a discrete product or component. They are also logically linked to other preceding and succeeding activities to form logical sequences and parallel paths of work that must be accomplished to complete the program. Logically related paths of detail activities are linked to milestones to show the progression of work that is planned. Detail activities have an estimated duration—that is, a planned estimate of the time it will take to complete the work—and are assigned resources. The status of detail activities is examined regularly to record actual progress. Figure 3 shows an example of a sequence of activities necessary to complete framing in a house construction project.4

Figure 3: Detail Activities
Tip: Click the figure to view a larger version in a new browser tab.

Some scheduling software packages include summary activities as an option. Summary activities are grouping elements that are useful for showing the time that activities of lower levels of detail require. Summary activities derive their start and end dates from lower-level activities. Because the work is done at the level of detailed activities, summary activities should never be linked to or from other activities. Figure 4 shows a summary activity, rolling up the time and effort required to complete framing.

Figure 4: Summary Activities
Tip: Click the figure to view a larger version in a new browser tab.

Level-of-Effort Activities

In addition to detailed work activities and milestone events, other activities in schedules represent effort that has no measurable output and cannot be associated with a physical product or defined deliverable.5 These level-of-effort (LOE) activities are typically related to management and other oversight that continues until the detailed activities they support have been completed. Progress on LOE activities is based on the passage of time, not the accomplishment of some discrete effort. In schedules, they should be seen as contributing to the comprehensive plan of all work that is to be performed.

LOE is represented by summary activities in certain scheduling software packages, and some schedulers represent LOE effort with detailed activities of estimated long duration. When represented as summary or long-duration detailed activities in a fully networked schedule, LOE activities may inadvertently define the length of a project or program and become critical. LOE activities should never be on the critical path because they do not represent discrete effort. A way to circumvent issues associated with including LOE in a schedule is to represent the effort as an activity that has been designed specifically for that purpose—that is, one that derives its duration from detailed activities. These types of activities, used specifically to represent LOE, are known as “hammock” activities, and they are included in certain scheduling software packages.6


  1. More information on formal risk assessment is available in Best Practice 8, as well as in GAO, Cost Estimating and Assessment Guide, GAO-09-3SP (Washington, D.C.: Mar. 2009).↩︎

  2. For example, Federal Aviation Administration (FAA) service organizations employ standard program milestones when planning, executing, and reporting progress on investment programs. The standard program milestones are documented along with a description, completion criteria, WBS reference or crosswalk, and the decision authority.↩︎

  3. Detail activities can be defined in different ways in an earned value management (EVM) system. Appendix III provides an overview of schedules and EVM.↩︎

  4. In terms of earned value management, a third type of activity in addition to detail work and level-of-effort activities is called apportioned effort. See appendix III for more information.↩︎

  5. In the absence of hammock activities, certain techniques allow for the use of LOE-type long-duration activities in a schedule without their interfering with critical path calculations. For example, schedulers may choose to avoid the use of logic links on LOE activities or they may create LOE activities that are one day shorter than the actual planned project length. Because these techniques are used to circumvent the impacts of long-duration activities on traditional critical path calculations, their use and implications should be thoroughly documented in the schedule narrative and basis documents (described later in the guide).↩︎