An EVMS planning package is a logical grouping of future work within a control account that has defined scope, schedule, and budget but is not yet planned in enough detail for execution. The team later converts it into one or more work packages before the work begins.
A planning package is not an undefined placeholder. It represents authorized scope inside the Performance Measurement Baseline (PMB). However, it does not yet have the detailed activities, resources, and earned value technique needed to measure performance objectively.
EVMS Planning Package Definition
The Department of Energy defines a planning package as a logical aggregation of work within a control account, usually for future effort that can be identified and budgeted but is not yet planned at the work package or task level. The current DoD IPMDAR Implementation Guide uses a similar definition: future work within a control account that cannot yet be planned in detail.
Therefore, a valid planning package has three core elements:
- Scope: A recognizable portion of the authorized control account scope.
- Schedule: Planned start and finish dates or another time-phased schedule representation consistent with known program requirements.
- Budget: A time-phased budget assigned to the identified scope.
However, a planning package does not have an earned value technique. The team cannot claim earned value directly against it because the package does not define the detailed accomplishments used to measure progress.
Where a Planning Package Fits in the Baseline
The control account is the management control point where scope, schedule, and budget come together. Within that control account, the Control Account Manager (CAM) divides the authorized work into work packages and planning packages.
Work packages cover work that the team can plan in sufficient detail. Planning packages hold the remaining future scope. Together, their budgets should reconcile to the control account budget. For more context on this hierarchy, see control accounts versus work packages.
Planning packages also form part of the Performance Measurement Baseline. Their time-phased budgets contribute to planned value, even though the program cannot earn value against the packages themselves.
Why planning packages are necessary
Many programs cannot credibly define every future task when they establish the baseline. For example, detailed integration planning may depend on a design review, supplier selection, test result, or Government decision that will occur later.
Without planning packages, teams often choose between two poor options. First, they may create speculative detail that will require extensive rework. Alternatively, they may leave authorized scope and budget outside the control account plan. A planning package provides a controlled middle ground.
Planning Package vs Work Package
The primary difference concerns execution detail and performance measurement.
Planning package
- Represents future work within a control account.
- Has identifiable scope, schedule, and budget.
- Has not been decomposed into executable detail.
- Does not have an earned value technique.
- Cannot earn value or receive performance credit.
- Must be converted before work begins.
Work package
- Represents near-term or otherwise detail-planned work.
- Defines specific tasks, products, or measurable accomplishments.
- Has scheduled start and completion dates.
- Has an assigned budget and earned value technique.
- Provides the level at which the team measures performance.
- Supports work authorization and, where applicable, charge-number assignment.
A planning package is therefore not a less important work package. Instead, it is an intermediate planning construct that protects the baseline until the team can develop credible execution detail.
Do Not Confuse Planning Packages With Other Budget Categories
Several EVMS terms appear similar but serve different purposes.
Undistributed budget
Undistributed budget holds authorized scope and budget that the program has not yet distributed to a control account or summary-level planning package. By contrast, a planning package already belongs to a specific control account.
Summary-level planning package
A Summary-Level Planning Package (SLPP) contains far-term scope that the program can associate with higher-level Work Breakdown Structure and organizational elements but cannot yet assign to a control account. Once the program identifies the responsible control account, the ordinary planning package may become an appropriate planning vehicle.
Management reserve
Management reserve is budget held outside the PMB for management control of unknown but in-scope work. A planning package sits inside the PMB and covers identified, authorized scope. Teams should never use planning packages as informal management reserve.
Estimate to complete
A planning package budget describes the baseline value assigned to future scope. An Estimate to Complete (ETC), however, forecasts the expected cost of completing remaining work. The two values may differ. See Estimate to Complete explained for a detailed discussion of that distinction.
How a Planning Package Appears in the IMS
A planning package should retain enough schedule definition to support the control account plan and the Integrated Master Schedule (IMS). Its representation should show when the work must occur and how it connects to other program events.
For example, a planning package for environmental qualification testing might logically follow test-article fabrication and drive a qualification complete milestone. The package may use one or several summary-level activities until the test sequence becomes clear.
The appropriate level of detail depends on the contractor’s EVMS description, scheduling procedures, program complexity, and reporting requirements. A scheduling convention does not become a universal regulatory requirement merely because one program uses it.
Still, sound practice includes:
- Identifying planning package activities separately from work package activities.
- Assigning the correct control account, WBS, and organizational codes.
- Connecting the package to valid predecessor and successor logic.
- Using dates that agree with the time-phased control account budget.
- Reviewing the package during each rolling-wave planning cycle.
- Avoiding unexplained constraints that conceal missing logic.
The DOE Planning and Scheduling Guide identifies planning package and work package coding as useful IMS information. In addition, the IPMDAR guide states that planning packages must be identified separately from work packages when the Contract Data Requirements List requires planning package data.
This schedule integration matters because a far-term package can still sit on a driving or critical path. The scheduler should not ignore it simply because detailed performance measurement has not started. See how the IMS supports earned value management for the broader relationship between schedule activities and EVMS data.
Converting a Planning Package Into Work Packages
Programs usually convert planning packages through rolling-wave planning. The CAM, scheduler, cost analyst, and technical leads progressively define the work as requirements mature.
The DOE EVMS Interpretation Handbook states that planning packages should be detail planned at the earliest practical point and before work begins. It also expects conversion before the planned start enters the organization’s baseline freeze period.
A disciplined conversion process generally follows these steps:
- Confirm the scope. Review the planning package description, WBS dictionary, technical baseline, and control account plan.
- Define measurable products. Identify the documents, hardware, software, tests, decisions, or other outcomes that demonstrate accomplishment.
- Create work packages. Divide the scope into manageable units assigned to responsible performing organizations.
- Develop schedule detail. Add executable activities, logic, durations, milestones, and resource assumptions to the IMS.
- Select earned value techniques. Assign methods appropriate to the nature and duration of each work package.
- Reconcile the budget. Ensure the new work package budgets equal the amount removed from the planning package unless an authorized baseline change also applies.
- Complete required approvals. Process the conversion according to the contractor’s work authorization and baseline change-control procedures.
The conversion should preserve the identity of the original scope. It should not provide an opportunity to move budget to unrelated work, erase unfavorable performance, or revise historical baseline data.
Fictional Program Example
Consider a communications payload development program. The payload integration control account includes a $2.4 million planning package called “System-Level Environmental Qualification.” The work will occur 18 months after the baseline date.
The program knows the scope will include vibration, thermal-vacuum, electromagnetic compatibility, and post-test inspections. However, engineers cannot finalize the detailed sequence until the Critical Design Review and test-facility selection are complete.
The CAM assigns the planning package a planned start, planned finish, budget profile, and logical position between payload assembly and qualification approval. No earned value technique or charge number supports execution at this stage.
Nine months later, the test strategy matures. The team converts the planning package into four work packages:
- Develop and approve qualification procedures.
- Prepare the payload and test facility.
- Conduct environmental qualification testing.
- Analyze results and close qualification actions.
The scheduler adds detailed activities and logic. Meanwhile, the cost analyst distributes the original $2.4 million among the four work packages. The CAM assigns suitable earned value techniques and completes the required authorization before any work starts.
This conversion adds execution detail without changing the authorized scope or creating new budget.
Common Planning Package Failure Modes
Using vague scope descriptions
Labels such as “future engineering” or “remaining integration” do not establish traceable scope. The description should identify the intended technical effort and expected outcome, even when task-level detail remains unavailable.
Allowing the start date to pass
A planning package with a start date in the past indicates that rolling-wave planning failed or the schedule does not reflect actual execution. The team should convert the package before personnel begin work.
Taking earned value against the package
A planning package has no earned value technique. Therefore, the program cannot claim performance directly against it. Performance measurement begins after the team establishes authorized work packages.
Charging actual costs without executable work packages
Actual work should not occur under an unconverted planning package. Doing so weakens the relationship among authorization, budget, earned value, and actual cost.
Treating the budget as a funding pool
The planning package budget belongs to its identified scope. A CAM should not use it to cover overruns or unrelated control account work.
Leaving the package disconnected from schedule logic
A date-only bar provides little forecasting value. Logical integration allows the IMS to show whether predecessor delays will affect planning package dates and downstream milestones.
Creating false precision too early
Some teams build hundreds of speculative activities years before execution. That approach creates maintenance effort without improving decision quality. The planning package should contain enough definition to support credible baseline planning, but not invented detail.
Contract Requirements vs Program Practice
A planning package is an EVMS planning construct, not a standalone FAR clause. Whether a contract requires an EVMS depends on the applicable acquisition regulations, agency policy, contract type, value, clauses, and approved tailoring.
FAR 34.201 addresses EVMS application for major acquisitions for development and allows agencies to require EVMS for other acquisitions under their procedures. For DoD contracts, DFARS Subpart 234.2 provides DoD-specific applicability criteria and directs the use of the relevant DFARS provisions and clauses.
Those regulations require an applicable EVMS to comply with the governing EVMS criteria. However, the contract, Contract Data Requirements List, contractor system description, and approved procedures determine the detailed reporting and implementation approach. For example, the IPMDAR guide conditions separate planning package reporting on whether the CDRL requires that data.
As a result, teams should verify contract-specific requirements rather than assuming every customer expects the same planning package fields, conversion window, approval form, or reporting format.
Why Planning Packages Matter to Program Controls
A well-managed planning package protects baseline credibility. It gives the program enough structure to integrate future scope without pretending that every execution detail is known.
It also gives management visibility into future budget and schedule demand. CAMs can monitor when planning decisions must occur, while schedulers can assess whether far-term work remains logically achievable. In addition, proposal teams can use the concept to separate credible near-term detail from responsibly planned future effort.
However, the package only adds value when the team actively manages it. A forgotten planning package becomes a warning sign that scope, schedule, budget, or authorization may no longer align.
EVMS Planning Package FAQ
Can a planning package earn value?
No. A planning package does not have an earned value technique. The team must convert it into one or more work packages before measuring performance.
Can a planning package contain planned value?
Yes. Its time-phased budget contributes to the baseline plan. However, the program must convert the package before execution so that measurable work packages can earn value against that plan.
How long can a planning package remain open?
No single duration applies to every program. The package may cover far-term work, but the organization should review it regularly and convert it before its start enters the defined planning or baseline freeze window.
Is planning package conversion a baseline change?
Conversion is normally a controlled baseline-maintenance action that replaces future planning-package detail with work-package detail. The team should document it under approved procedures. If the action also changes authorized scope, control account budget, or committed schedule objectives, additional change control may be necessary.
Can a planning package exist outside a control account?
An ordinary planning package belongs within a control account. Far-term scope that cannot yet be assigned to a control account is generally handled as a summary-level planning package, subject to the organization’s approved EVMS approach.