An effective IMS WBS structure uses the Work Breakdown Structure (WBS) to organize schedule scope by product or deliverable. Detailed activities sit beneath the applicable WBS elements and work packages, while schedule logic connects the work across that hierarchy.
The WBS answers what scope must the program deliver? The Integrated Master Schedule (IMS) adds how and when will the team execute that scope? Therefore, the schedule should preserve traceability to the WBS without treating the WBS as a substitute for activity definition, network logic or responsibility assignment.
This approach helps schedulers confirm scope coverage, roll up dates by product and connect schedule performance to cost and technical data. It also gives control account managers (CAMs) and program managers a consistent view of execution.
What an IMS WBS Structure Should Accomplish
The WBS decomposes the program’s total scope into successively smaller elements. A product-oriented WBS typically starts with the end item and divides it into subsystems, components, services and other deliverables.
The IMS uses that framework to organize the activities needed to produce those deliverables. The GAO Schedule Assessment Guide states that a comprehensive schedule should reflect the activities defined by the program WBS. At the detailed level, the schedule should define the work required to produce and deliver each product.
A useful structure should allow the program team to:
- Trace every detailed activity to authorized scope.
- Summarize schedule dates and performance by WBS element.
- Identify omitted, duplicated or misplaced work.
- Connect activities to control accounts and work packages.
- Assign responsibility without turning the WBS into an organization chart.
- Analyze product-level critical paths, interfaces and risks.
- Reconcile schedule data with earned value management and cost systems.
If the hierarchy only groups activities by department, contract phase or reporting month, it does not provide strong product traceability. Those dimensions may still matter, but the scheduler should normally manage them through separate activity codes or custom fields.
How to Build the IMS WBS Structure
1. Establish the governing WBS before building the hierarchy
Start with the approved Program WBS, Contract WBS or other scope hierarchy applicable to the effort. Confirm which structure governs the schedule and obtain its WBS dictionary.
The dictionary matters because a code and title rarely define enough scope on their own. It should clarify what each element includes, what it excludes and how adjacent elements differ. Without those definitions, planners may schedule the same work under multiple branches or omit interface work because no team recognizes ownership.
For a proposal, the final Contract WBS may not exist yet. In that case, develop a proposed WBS from the solicitation, Statement of Work (SOW), system architecture, deliverables and applicable customer instructions. Mark assumptions and remain prepared to reconcile the structure after award.
Do not assume that one WBS convention applies to every federal contract. Agency policy, the solicitation, contract clauses, Contract Data Requirements List (CDRL), Data Item Description (DID), program tailoring and the contractor’s approved management system may affect the required structure.
2. Load the WBS as the schedule’s summary framework
Create summary levels that mirror the governing WBS. The schedule hierarchy should retain the official element codes and titles rather than using informal abbreviations that only one team understands.
For example, a fictional Tactical Relay Upgrade program might begin with:
- 1.0 Tactical Relay Upgrade
- 1.1 Systems Engineering
- 1.2 Mission Computing Subsystem
- 1.3 Communications Subsystem
- 1.4 Integration, Verification and Validation
- 1.5 Training and Technical Data
- 1.6 Program Management
Next, the team would extend each element to the level needed for planning and control. Under 1.3, for example, lower-level elements could identify the radio assembly, antenna assembly, embedded software and subsystem qualification products.
The objective is not to create the deepest possible outline. Instead, create enough WBS detail to segregate scope, assign accountability and support useful reporting.
3. Identify control accounts and work packages
On an Earned Value Management System (EVMS) program, the WBS and Organizational Breakdown Structure (OBS) intersect at the control account. A CAM accepts responsibility for the technical scope, schedule and budget assigned to that control account.
However, a WBS element is not automatically a control account. The control account structure depends on both the WBS and OBS, as well as the program’s management-control design. Several organizations may perform work within one higher-level WBS branch, while one organization may manage control accounts across several WBS branches.
Within each control account, define work packages for near-term scope that the team can plan and measure. Planning packages may represent future scope that lacks enough detail for work-package planning. As planning matures, the team should detail that scope through its controlled planning process.
The schedule should identify the applicable control account and work package for each performance activity. This mapping supports the connection between the IMS and the Performance Measurement Baseline.
4. Develop activities beneath the applicable work packages
Activities represent executable work. They should describe the actions and outcomes needed to complete each work package rather than repeat its title.
For example, a work package named Antenna Prototype Fabrication might contain these activities:
- Release prototype antenna drawings.
- Procure long-lead antenna materials.
- Fabricate antenna housing.
- Assemble prototype antenna.
- Perform workmanship inspection.
- Deliver prototype to the integration laboratory.
These activities explain the execution plan. In contrast, one activity named Complete Antenna Prototype would hide procurement, fabrication and inspection dependencies.
Use activity names that combine an action with a specific object. Also, assign durations that support meaningful status and forecasting. Excessively long activities obscure progress, while microscopic tasks create unnecessary maintenance. The appropriate level depends on technical complexity, risk, reporting cycles and management needs.
For a broader development process, see how to build an Integrated Master Schedule.
5. Add logic across WBS branches
The WBS organizes scope, but it does not define execution sequence. Therefore, the scheduler must build horizontal logic between activities, including relationships that cross summary branches, organizations and subcontractors.
In the Tactical Relay Upgrade example, completion of communications software may drive subsystem integration under WBS 1.4. Antenna qualification may also drive the same integration event. These relationships should connect the detailed activities directly. Linking only the summary elements would conceal the actual handoffs.
A sound network should show:
- Internal dependencies within each work package.
- Handoffs between products and organizations.
- Government-furnished property or information dependencies.
- Subcontractor deliveries and required need dates.
- Review, approval and test dependencies.
- Relationships to contractual and program milestones.
Most relationships should reflect real technical or execution dependencies. Avoid using hard constraints to force activities onto desired dates when logic should calculate those dates.
6. Validate vertical traceability
Vertical integration allows users to trace detailed execution through intermediate and management-level views. Dates shown in a summary schedule should agree with the detailed network that supports them.
However, summary bars should generally calculate from their children rather than carry independent constraints or logic. Otherwise, the program can produce conflicting dates for the same WBS element.
Check that each activity has the correct WBS code and that all authorized WBS elements appear where needed. NASA documented a lesson in which inconsistent WBS nomenclature made it difficult to integrate schedules and confirm scope coverage. Consistent coding also allows the team to summarize schedule data without relying only on visual indentation.
Use Codes for Dimensions Other Than the WBS
A common mistake is forcing every reporting requirement into one outline. A schedule may need to report by WBS, OBS, CAM, work package, Contract Line Item Number (CLIN), Integrated Master Plan event, subcontractor, risk, location and contract deliverable. These dimensions rarely form one clean hierarchy.
Keep the primary outline aligned with the approved WBS. Then use separate fields for other management views. Useful activity-level fields may include:
- WBS code.
- Control account identifier.
- Work package or planning package identifier.
- Responsible organization and CAM.
- CLIN or SOW reference.
- Integrated Master Plan event or accomplishment.
- Contract deliverable identifier.
- Risk or opportunity identifier.
- Subcontractor or external interface code.
- Schedule visibility task classification.
This coding model lets analysts group and filter the same network without rebuilding it. It also supports integration with other program-control systems.
Applying the Structure in Microsoft Project and Deltek Tools
Microsoft Project
Microsoft Project uses outline levels to build a task hierarchy. It can also store a WBS value for each task. According to Microsoft’s WBS field documentation, the default WBS code reflects the task’s outline position, although users can define a WBS coding format.
Do not rely on outline position alone if the approved WBS code must remain stable. Inserting or moving tasks may alter outline numbers. Instead, establish controlled fields for the official WBS, control account and work package identifiers. Then test groupings, filters and exports before baseline approval.
Deltek Open Plan and Cobra
For Open Plan and Cobra integration, Deltek recommends using code or user-character fields to identify the WBS, OBS and work package. Its Open Plan schedule preparation guidance also notes that these fields provide more stable integration keys than activity identifiers that may change when activities are inserted.
Before loading schedule data into Cobra, confirm that each activity maps to the intended control account or work package. Also, reconcile calendars, status dates, baseline dates and coding conventions. A structurally correct WBS will not prevent integration errors if those other elements differ between systems.
Contractual Requirements Versus Recommended Practice
Using the WBS as the IMS scope framework is a strong scheduling and program-controls practice. However, do not describe every implementation detail as a universal federal requirement.
For example, DFARS 252.234-7002, when included in a contract, addresses use of an EVMS and management procedures that generate required performance reports and IMS information. It also states that an Integrated Baseline Review assesses areas such as complete SOW coverage, logical scheduling, adequate resourcing and inherent risks.
The clause does not, by itself, prescribe every summary level, naming convention or software field in the IMS. Those details may come from the contract, applicable data requirements, WBS direction, program tailoring and the contractor’s accepted system description.
Therefore, schedulers should separate three questions:
- What does the contract require? Review the clauses, SOW, CDRLs, DIDs and incorporated instructions.
- What does the approved management system require? Review the EVMS description, scheduling procedure and change-control process.
- What practice produces a useful schedule? Apply sound WBS traceability, critical path method logic and coding discipline.
Common IMS WBS Structure Mistakes
Organizing the schedule by department
Engineering, supply chain and test may provide convenient headings, but they do not necessarily represent end products. Use the product-oriented WBS as the primary scope structure and identify organizations through OBS or responsibility fields.
Confusing WBS elements with activities
A WBS element defines a portion of scope. An activity defines an executable step. Copying the WBS titles into the schedule without developing activities produces a scope list, not a logic-driven IMS.
Stopping the WBS above the work package
If activities cannot map to control accounts and work packages, cost and schedule integration becomes difficult. Extend or code the structure to the level required by the program’s control model.
Creating logic only within each WBS branch
Programs execute through cross-product handoffs. An IMS with isolated WBS branches may look organized while failing to calculate a valid program critical path.
Using indentation as the only traceability method
Visual hierarchy helps users read the schedule, but controlled codes support data validation, integration and repeatable reporting. Use both.
Allowing summary tasks to control detailed dates
Detailed logic should drive summary dates. Constraints or relationships on summary tasks can distort float and create inconsistent forecasts.
Failing to reconcile changes
When authorized scope changes, update the WBS dictionary, schedule activities, work packages and cost system through the applicable change-control process. Otherwise, the program may report different scope in each system.
Final Validation Checklist
Before approving or baselining the schedule, confirm that:
- The IMS contains every applicable WBS element and the required work scope.
- Each detailed activity maps to one appropriate WBS element.
- Performance activities map to valid control accounts and work packages when EVMS applies.
- WBS codes match the approved WBS and dictionary.
- Separate codes support OBS, CAM, CLIN, deliverable and risk reporting.
- Detailed logic connects work across WBS branches.
- Summary dates calculate from the underlying activities.
- External deliveries and customer dependencies connect to the relevant product scope.
- The structure supports critical path, variance and schedule risk analysis.
- Schedule and cost-system mappings have been tested.
A disciplined IMS WBS structure creates a common thread from authorized scope to detailed execution. As a result, the program can evaluate schedule movement by product, connect dates to cost performance and identify where technical problems affect delivery.
The WBS provides the framework, but the network makes the schedule executable. Programs need both. For additional context on the role and content of the schedule, see the complete guide to the Integrated Master Schedule for DoD programs and the comparison of an Integrated Master Schedule versus an Integrated Master Plan.