Basis Document
The accuracy of the IMS as a model for the program depends on the mutual understanding of all stakeholders of the schedule’s structure, use, and underlying assumptions. Thorough documentation is essential for validating and defending a baseline schedule. A well-documented schedule can present a convincing argument for a schedule’s validity and can help answer decision makers’ and oversight groups’ probing questions. A well-documented schedule is essential if an effective independent review is to ensure that it is reliable.
A schedule basis document is a single document that defines the organization of the IMS, describes the logic of the network, describes the basic approach to managing resources, and provides a basis for all parameters used to calculate dates. As noted in Best Practice 1, the government program management office is responsible for integrating all government and contractor work into one comprehensive program plan. Therefore, the government program management office creates and approves the schedule basis document once the schedule baseline is approved. While the basis document is not updated as often as the schedule narrative described in Best Practice 9, it should be considered to be a living document in that it reflects updates to the baseline schedule. Both the baseline schedule and basis document should be referenced and updated in accordance with the established change process as the program progresses. At a minimum, the basis document should include the following.
A program overview or a general description of the program, including general scope and key estimated life-cycle dates, and descriptions of each stakeholder, including the program owner, prime contractor and subcontractors, and key stakeholder agencies.
A general description of the overall execution strategy, including the type of work to be performed, and contracting and procurement strategies.
A description of the overall structure of the IMS, including the scope and purpose of projects, staff responsible for each project, the relationship between projects, a WBS dictionary, the status delivery dates for each project, and a list of key handoff products and their estimated dates. In addition, it refers to relevant contract data requirements lists and data item descriptions associated with schedules.43
A description of the settings for key options for the relevant software, such as criticality threshold, progress override contrasted with retained logic, and the calculation of critical paths and whether work progresses with duration updates.
A definition and justification in the basis document of all ground rules and assumptions used to develop the baseline, including items specifically excluded from the schedule. If rolling wave planning is used, key dates or milestones for detail and planning periods are defined.
A justification of each use of a lag and date constraint that is clearly associated with the activities that are affected. Missing successor or predecessor logic is also justified.
The documentation of each project, activity, and resource calendar, along with a rationale for workday exceptions (holidays, plant shutdowns, and the like), working times, and planned shifts.
An appropriately detailed explanation or rationale for the basic approach to estimating key activity durations and justification of the estimating relationship between duration, effort, and assigned resource units.
A justification of each use of a long-duration activity in the near-term.
A description of how LOE activities are identified and statused.
Definitions of all acronyms and abbreviations.
A table of the purposes of custom fields.
A description of resources used in the plan and the basic approach for updating resource assignments, along with schedule updates and average and peak resource demand projections. The document defines all resource groups used in the schedule and justifies planned overallocations in appropriate detail. In addition, key material and equipment resources are described in the context of their related activities.
A description of critical paths, longest paths, and total float. A discussion of the critical paths, including justification for the criticality threshold, rationale for single or multiple critical paths, and justification for any gaps in a noncontinuous critical path. If the schedule has date constraints, a description of the longest path is included. In addition, abnormally large amounts of total float are justified.
A description of the critical risks as prioritized in a quantitative schedule risk analysis, along with a discussion of the appropriate schedule contingency.
A detailed description of the updating and schedule change management processes. Any additional documentation that governs them is referenced.
Thorough documentation helps with analyzing changes in the program schedule and identifying the reasons for variances between estimates and actual results. In this respect, basis documentation contributes to the collection of cost, schedule, and technical data that can be used to support future estimates.
A contract data requirements list is part of a procurement contract. A data item description describes the standardized format and instructions for preparing and delivering the data.↩︎