An IPMDAR schedule dataset is a structured electronic representation of an Integrated Master Schedule (IMS) submitted under the Integrated Program Management Data and Analysis Report. Its formal name is the Schedule Performance Dataset (SPD). It contains schedule data in a standardized, machine-readable format so the Government can validate, organize and analyze the program’s schedule without relying only on reports or screenshots.
However, the SPD is only one part of the schedule delivery. When required by the contract, the contractor generally delivers both the SPD and the schedule’s native file, such as an MPP or XER file. The native file preserves software-specific detail, while the SPD supports consistent, repeatable analysis across scheduling platforms.
Where the IPMDAR schedule fits in program reporting
The Integrated Program Management Data and Analysis Report replaced the older Integrated Program Management Report reporting framework for applicable contracts. According to the DoD IPMDAR Implementation and Tailoring Guide, IPMDAR reporting has three major components:
- Contract Performance Dataset (CPD): Cost, budget, estimate and earned value data from the contractor’s management systems.
- Schedule delivery: The Schedule Performance Dataset and the native schedule file.
- Performance Narrative Report (PNR): Executive-level and detailed narrative analysis of program performance.
The CPD and SPD serve different purposes, but they should connect. For example, identifiers in the schedule may map activities to control accounts and work packages represented in the cost dataset. Therefore, analysts can evaluate whether the timing of scheduled work aligns with the program’s budget and forecast data.
That connection is central to effective schedule-to-cost integration. It also supports the broader role of the IMS in earned value management.
What is included in an IPMDAR Schedule Performance Dataset?
The SPD packages schedule information as standardized data tables encoded in JavaScript Object Notation, or JSON. The exact fields, file structure and validation rules come from the applicable IPMDAR File Format Specification and Data Exchange Instructions. Those technical specifications may change, so a program should use the versions identified by its contract and current reporting environment.
At a practical level, the dataset represents the elements needed to understand and analyze the schedule network. Depending on the contract’s tailoring and the applicable specification, those elements include:
- Schedule and submission metadata
- Tasks, activities, milestones and summary elements
- Unique schedule identifiers
- Planned, baseline, forecast and actual dates
- Durations and remaining durations
- Task status and completion information
- Predecessor and successor relationships
- Relationship types and lag values
- Working and nonworking calendars
- Constraints, deadlines or related date controls
- Work breakdown structure and organizational mappings
- Control account, work package and planning package associations
- Resources and other data required by the applicable specification
- Contractor-defined codes used for schedule organization and analysis
This list describes the general content, not a universal checklist for every contract. The contractual data item description, Contract Data Requirements List (CDRL), tailoring instructions and approved specifications determine the actual submission requirement.
SPD versus the native schedule file
The SPD and native schedule file represent the same underlying program schedule, but they are not interchangeable.
The Schedule Performance Dataset
The SPD standardizes schedule information for automated processing. Government systems can load the data, test its structure and compare it with current or prior submissions. Analysts can also flatten portions of the dataset into tables for tools such as spreadsheets and business intelligence platforms.
Standardization reduces dependence on one scheduling application. For example, a Government analyst can apply common checks to data produced from Microsoft Project, Primavera P6 or another approved source tool, provided the contractor creates a compliant SPD.
The native schedule file
The native file is the working schedule in the format produced by the contractor’s scheduling software. The IPMDAR guide gives MPP and XER as examples. Unlike the standardized SPD, the native file can preserve application-specific fields, settings, calculation behavior and other details that may not transfer fully into an exchange format.
The native delivery also includes a data dictionary when required. That dictionary defines contractor-created fields, code structures and abbreviations that a reviewer may not otherwise understand.
For Microsoft Project programs, the native file may contain custom fields, filters and identifiers used to manage the IMS. Those features make disciplined field governance essential. The distinction between Microsoft Project Unique ID and Task ID, for example, can affect period-to-period traceability and downstream interfaces.
Why both files matter
The SPD gives the customer a consistent dataset. Meanwhile, the native file provides access to the schedule as maintained in the source application. Reviewers may use the SPD for portfolio-level analytics and the native file for detailed schedule diagnostics.
A valid SPD does not prove that the native IMS is credible. Likewise, a healthy-looking native schedule does not guarantee that the exported SPD is complete or properly mapped. Program controls teams must validate both.
What makes the dataset useful?
A schedule dataset becomes useful when its identifiers, logic, status and coding remain reliable across reporting periods. The Government can then compare submissions and investigate changes rather than rebuilding the schedule’s structure each month.
For example, analysts may use the data to:
- Identify movement in contract milestones and major events.
- Trace critical and near-critical paths through the network.
- Review missing logic, relationship types, leads and lags.
- Analyze negative float, high float and long-duration activities.
- Compare baseline dates with current forecasts.
- Find actual dates or incomplete work on the wrong side of the status date.
- Evaluate changes in task coding or control account mapping.
- Connect schedule activities with cost and earned value data.
- Compare the current schedule with prior reporting periods.
The SPD is therefore more than a customer reporting file. It can provide a repeatable quality-control layer for the contractor as well. However, teams should not treat automated validation as a substitute for critical path analysis, schedule review meetings or discussions with control account managers.
A practical IPMDAR schedule example
Assume the fictional Falcon Ridge communications program maintains its IMS in Microsoft Project. The schedule contains 8,000 activities across engineering, software development, integration, test and deployment. Each detailed activity maps to one work package and one responsible control account.
At the end of the July accounting period, the scheduling team updates actual starts, actual finishes and remaining durations. It then recalculates the schedule using the approved status date. After the program completes its schedule review, the reporting process produces two schedule deliverables:
- The current Microsoft Project MPP file, including the contractor’s custom fields and code definitions.
- An SPD package that converts the required task, relationship, calendar, resource and mapping information into the prescribed IPMDAR structure.
During validation, the team finds that 60 activities have valid control account codes in the MPP file but blank control account references in the SPD. The schedule itself calculates correctly. However, the export mapping failed because a custom field name changed during a template update.
If the team submitted that file, cross-dataset analysis could fail or place the activities outside the correct control accounts. Therefore, the scheduler corrects the mapping, regenerates the dataset and repeats validation before delivery.
This example shows why teams must review the delivered data rather than assume that a successful export created a complete submission.
Contract requirements versus good practice
IPMDAR reporting is not automatically required on every federal contract or every DoD schedule. The enforceable requirement comes from the contract, including the applicable clauses, data item description, CDRL and tailoring instructions.
DFARS Procedures, Guidance and Information 234.201 points acquisition personnel to the IPMDAR Implementation and Tailoring Guide when applying and tailoring earned value management reporting. In addition, the DFARS earned value management system clause, when included, establishes EVMS-related contractor obligations. Neither source should replace a review of the awarded contract.
Programs may tailor reporting frequency, submission timing, data content and other delivery details. Requirements can also vary by agency and acquisition strategy. Therefore, proposal and execution teams should avoid copying an IPMDAR CDRL from another program without reviewing the actual need.
By contrast, the following are strong operating practices even when the contract does not prescribe each step:
- Assign stable unique identifiers and protect them from unnecessary reuse.
- Reconcile the SPD against the approved native schedule before submission.
- Validate control account and work package mappings against the cost system.
- Compare current and prior datasets for unexplained structural changes.
- Retain the exact files delivered for each reporting period.
- Document export settings, transformations and interface rules.
- Resolve validation warnings before customer delivery or explain accepted exceptions.
Common IPMDAR schedule failure modes
Confusing the SPD with the IMS
The IMS is the program’s integrated scheduling model. The SPD is a standardized delivery of data from that model. Calling the SPD “the IMS” can obscure problems introduced during conversion or export.
Validating only the native file
A team may complete an extensive IMS review before customer delivery but never inspect the resulting SPD. Broken mappings, missing fields or relationship conversion errors can remain hidden until Government validation.
Changing identifiers without control
Uncontrolled identifier changes weaken period-to-period traceability. They can also make unchanged work appear new or deleted in comparative analytics. Schedulers should distinguish permanent identifiers from row numbers or display IDs generated by the scheduling tool.
Ignoring cross-file consistency
The schedule and cost datasets should use compatible references where integration is required. A control account called “SW-230” in the CPD should not appear as “230-SW” in the SPD unless an approved transformation provides the necessary mapping.
Treating software validation as schedule analysis
File-format validation can find missing or structurally invalid data. It cannot determine whether the execution strategy is realistic, whether a logic path reflects actual technical dependencies or whether the forecast incorporates known risk.
How schedulers should prepare the delivery
- Read the contract first. Confirm the DID, CDRL, reporting period, due date, tailoring and approved specification versions.
- Complete the normal status cycle. Collect progress, apply actuals, update remaining work and calculate the schedule using the correct status date.
- Review schedule quality. Analyze logic, constraints, float, durations, out-of-sequence progress and driving paths. A structured set of schedule health checks can support this review, although health-check thresholds are not substitutes for contract requirements.
- Freeze the reporting version. Control the approved native file used to produce the submission.
- Generate the SPD. Apply the documented export and transformation process.
- Run structural and cross-file validation. Check the SPD against the applicable format rules and reconcile schedule mappings with the CPD.
- Perform reasonableness checks. Compare activity counts, relationship counts, key dates, calendars and coding between the native file and the exported data.
- Archive the delivered package. Retain the native file, SPD, validation output and supporting reconciliation evidence.
Frequently asked questions
Is the IPMDAR schedule an XML file?
The current IPMDAR SPD uses JSON-encoded data tables under the applicable File Format Specification and Data Exchange Instructions. Legacy Integrated Program Management Report interfaces commonly used XML. Conversion utilities may support legacy formats, but the contract and current IPMDAR specifications control the required delivery.
Does an SPD replace the native Microsoft Project or P6 file?
No. The IPMDAR schedule delivery generally includes both the standardized SPD and the native schedule file when specified by the contract.
Can a proposal team create an SPD before contract award?
Yes, if the solicitation requests one or the team wants to test its proposed reporting architecture. However, proposal teams should not assume that IPMDAR is required unless the solicitation identifies the requirement. They should also verify whether the proposed scheduling software and program-controls interfaces can produce compliant data without extensive manual processing.
Who should own SPD validation?
Ownership varies by organization. Typically, scheduling verifies the native model and schedule content, while program controls or an IPMDAR reporting team manages dataset generation and formal validation. Cost, EVMS and system-administration personnel may also support cross-file reconciliation. Regardless of organization, one accountable process owner should control the final delivery.
The practical takeaway
An IPMDAR Schedule Performance Dataset translates the IMS into standardized, machine-readable data for Government analysis. It does not replace the native schedule, and successful file validation does not prove that the schedule is executable.
For schedulers, the central challenge is traceability. The native IMS, SPD, cost dataset and prior reporting periods must tell a consistent story. When identifiers, logic, status and mappings remain controlled, the IPMDAR schedule becomes a useful program-management dataset rather than a reporting artifact created only for monthly delivery.