How is earned value calculated for software work packages?

Earned value for software work packages is calculated using one of several approved earning methods, selected during baseline planning and locked in the EVMS system description. For discrete work with objective milestones -- such as completion of a software design document or delivery of a tested module -- the milestone-weighted method assigns EV credit at predefined completion points (for example, 20% at design complete, 50% at unit test complete, 100% at integration test complete). For continuous effort such as software development sprints without hard milestones, percent complete with objective evidence (lines of code, function points, test cases passed) is used. The 50/50 method applies to short-duration work packages where 50% credit is earned at start and 50% at completion. Level of effort is reserved for true overhead activities that cannot be discretely measured. Mixing methods within a single work package is not permitted under ANSI/EIA-748 criteria 16.

What is the 10%/10 rule for variance analysis, and how do CAMs respond to a breach?

The 10%/10 rule is the most common variance threshold convention in EVMS reporting: a control account requires a written variance analysis narrative when its cost variance or schedule variance exceeds 10% of the cumulative earned value or $10,000 (or $100,000 at the program level -- thresholds vary by contract). The narrative must address four elements: what happened (the objective description of the variance condition), why it happened (root cause analysis, not symptoms), what the impact is on the remaining work and on the estimate at completion, and what corrective action the CAM is taking. Government reviewers score narratives on the credibility and specificity of the corrective action: generic language such as 'increase resource allocation' is a red flag; specific actions tied to schedule dates and named individuals are the standard. Persistent variance without believable corrective action triggers a formal CAR (Corrective Action Request) from the program office.

What EVMS tools are used for defense program reporting, and what data formats does the government require?

The dominant EVMS tool suite for US DoD programs is Deltek Cobra, which handles the performance measurement baseline, earning method management, variance calculations, and CPR/IPMDAR export. Microsoft Project with the EVM add-in is used on smaller programs below the IPMDAR threshold. Oracle Primavera P6 is used for schedule-critical programs and integrates with Cobra for schedule-cost integration. Government reporting is primarily in two formats: the Contractor Performance Report (CPR), which has five formats covering WBS performance, organizational performance, baseline log, staffing, and problem analysis; and the Integrated Program Management Data and Analysis Report (IPMDAR), which is the successor digital format that combines CPR and IMS data in a structured JSON/XML schema and is submitted to the DoD's Analysis of Alternatives cost database. IPMDAR replaced the legacy IPMR format in 2019 and is now required on all new DoD acquisitions above the EVMS threshold.

How does the Defense Contract Management Agency (DCMA) surveil EVMS compliance?

DCMA surveils EVMS compliance through three mechanisms. First, the EVMS System Description review: before a contractor can report EVM data on a new program, DCMA must accept the contractor's written system description documenting how all 32 ANSI/EIA-748 criteria are implemented. Second, the Integrated Baseline Review: DCMA participates as co-chair on all government-conducted IBRs and uses the CAM risk walkthrough to assess baseline credibility. Third, ongoing surveillance: DCMA analysts review each monthly CPR/IPMDAR submission for internal consistency (variances that are not explained, EACs that are inconsistent with CPI trends, TCPI anomalies), conduct surveillance visits to review the contractor's EVMS in operation, and issue Corrective Action Requests when deficiencies are found. A contractor with an EVMS that fails DCMA surveillance on a current program may have the deficiency reflected in its past-performance record and may be required to obtain a new system description acceptance before bidding on future EVMS-required programs.

Defense Market

Earned value management for defense software programs

By Corvus Intelligence Engineering Team · About the team →

June 25, 2026 12 min read

Earned value management sits at the intersection of cost accounting, schedule management, and program control -- and it is one of the most demanding compliance regimes a defense software contractor will encounter. A program without a credible EVMS cannot win cost-reimbursable contracts above the DoD threshold. A program that reports EVM data carelessly triggers DCMA surveillance, Corrective Action Requests, and eventual past-performance consequences. But a program that runs EVM as a genuine management tool -- not as a reporting burden -- has quantitative early warning of cost and schedule problems months before they become crises.

This guide covers the full EVMS lifecycle for software-intensive defense programs: the mathematics every CAM must command, the 32 ANSI/EIA-748 criteria that structure EVMS compliance, WBS construction aligned to MIL-STD-881, IBR preparation and conduct, CAM reporting cadence and variance analysis, EAC calculation methods, and the tool ecosystem for government data submission. For the broader contract execution context, see the defense market playbook part 4 execution EVM. For pricing structures that determine which contract types require EVMS, see defense software pricing models. For the acquisition pathway that leads to EVMS-bearing contracts, see defense procurement RFP to contract.

EVM fundamentals for defense program managers

EVM rests on six numbers. Every control account manager, program manager, and government reviewer reads these six metrics at every monthly status cycle. Mastering what they mean -- and what they do not mean -- is the foundation of the entire discipline.

Planned Value (PV) -- formerly BCWS (Budgeted Cost of Work Scheduled) -- is the time-phased budget: the cumulative amount the program planned to spend on authorized work through the status date. PV is the baseline. It is set once during planning, locked in the Performance Measurement Baseline, and changes only through formal baseline change control. Every contract dollar is allocated to a PV curve from day one through contract completion.

Earned Value (EV) -- formerly BCWP (Budgeted Cost of Work Performed) -- is the budget value of the work that has actually been completed, measured against the same baseline. EV is not what work cost; it is what the completed work was planned to cost. A software module budgeted at $200,000 earns $200,000 of EV when it is complete, regardless of whether it actually cost $180,000 or $240,000.

Actual Cost (AC) -- formerly ACWP (Actual Cost of Work Performed) -- is what the program actually spent on the work performed. AC comes from the financial accounting system, not from estimates. It includes direct labor, direct materials, other direct costs, and applied indirect rates.

From PV, EV, and AC, the two primary variance metrics derive:

Cost Variance (CV)     = EV - AC
Schedule Variance (SV) = EV - PV

CV% = CV / EV × 100
SV% = SV / PV × 100

A negative CV means cost overrun (the work cost more than it earned). A negative SV means schedule slip (less work was completed than planned). Both variances are expressed in dollars and as percentages -- the percentage form is used for threshold comparisons.

The two performance indices are the metrics government reviewers reach for first:

Cost Performance Index (CPI)     = EV / AC
Schedule Performance Index (SPI) = EV / PV

CPI above 1.0 means the program is performing more efficiently than budgeted; below 1.0 means it is running over cost. The Humphreys empirical observation -- that CPI at the 20% completion point rarely improves significantly over the life of a program -- is the reason government buyers treat sustained CPI below 0.9 as a structural problem, not a recoverable anomaly. SPI above 1.0 means the program is ahead of schedule; below 1.0 means it is behind. Note that SPI converges to 1.0 at program completion regardless of schedule performance (because EV eventually equals PV when all work is complete) -- which is why the schedule performance index alone is insufficient for late-program schedule assessment and must be supplemented by the Integrated Master Schedule.

The sixth metric every CAM must own is the Estimate at Completion (EAC) -- the total expected cost of all program work. EAC = AC + Estimate to Complete (ETC). The relationship between EAC and the Budget at Completion (BAC) tells the story: VAC = BAC - EAC. A negative VAC is a projected overrun. VAC is reported monthly in CPR Format 1 and is one of the primary triggers for government program office attention.

ANSI/EIA-748 guidelines: the 32 criteria

ANSI/EIA-748 is the consensus standard that defines what a compliant EVMS must do. It does not prescribe specific software tools or reporting formats -- it specifies 32 criteria organized into five guideline groups. A contractor's EVMS System Description must demonstrate how each criterion is implemented, and DCMA validates that implementation through surveillance and IBR.

Group 1: Organization (criteria 1-5). The EVMS must be organized around a Work Breakdown Structure that covers 100% of the authorized work scope, with each element assigned to a single responsible organizational unit. Internal subcontracts and significant subcontractors must be integrated into the EVMS at a level that permits meaningful cost and schedule surveillance. The organizational structure must be documented and reflected in the EVMS tool. Criterion 5 -- integrating the WBS with the Organizational Breakdown Structure to define control accounts -- is the linchpin: a control account is the intersection of WBS and OBS, and every dollar of program budget lives in exactly one control account.

Group 2: Planning, Scheduling, and Budgeting (criteria 6-14). This is the largest group and the one that determines whether the PMB is credible. All authorized work must be time-phased from contract start through contract completion. Near-term work is in work packages with objective start/completion criteria; far-term work lives in planning packages until it enters the rolling wave. Management Reserve is held at the program level and authorized only for emergent in-scope work. Undistributed Budget covers authorized work not yet assigned to control accounts. Budget baseline changes require formal documentation in the budget log. Criterion 12 -- indirect cost structure alignment with the accounting system -- is where software programs most often struggle, because multiple indirect rate pools (fringe, overhead, G&A) must roll up consistently between the EVMS and the financial system.

Group 3: Accounting Considerations (criteria 15-18). Actual costs must record at the control account level, in the same time period as the work performed, using the same WBS element structure. The criteria prohibit estimating actual costs (i.e., accruals or estimates-in-lieu of actual invoices may not substitute for real cost data beyond a single reporting period). Material costs must be recorded at receipt or consumption -- whichever aligns with the program's cost system -- consistently applied.

Group 4: Analysis and Management Reports (criteria 19-27). This group governs the analysis outputs: variance thresholds, VAR narratives, EAC methods, subcontractor surveillance, and government data reporting. Criterion 22 -- identifying significant variances and preparing variance analysis reports -- is the most operationally intensive criterion for CAMs. Criterion 27 -- developing an EAC at least quarterly, or more frequently when variances exceed threshold -- is where program forecasting credibility is established or lost.

Group 5: Revisions and Data Maintenance (criteria 28-32). Baseline changes must be incorporated formally and timely. The budget log tracks every dollar of budget movement, authorized by management, with reason codes. Retroactive changes to EV -- claiming credit for work after the status date -- are prohibited. The system description itself must be kept current. Criterion 32 -- prohibiting retroactive adjustments that do not reflect performance -- is the criterion most frequently cited in DCMA Corrective Action Requests, because retroactive EV manipulation is the most tempting short-term fix for negative variances.

Work breakdown structure for defense software

The WBS for a software-intensive defense program is not a task list and is not a project management hierarchy. It is a product-oriented decomposition of the total contracted deliverable, aligned to MIL-STD-881 so that reporting maps directly to the program office's cost model.

MIL-STD-881 provides standard WBS element definitions for defense system programs. For a software-intensive system, the relevant elements typically include: System (level 1), Software (SE 03 at level 2), decomposed into Computer Software Configuration Items (CSCIs) at level 3. Each CSCI maps to a major software component -- a mission system software suite, a communications processing element, a data management service -- corresponding to the allocated baseline architecture. Control accounts are normally established at level 3 (CSCI) or level 4 (Computer Software Component, CSC) depending on program size and software complexity.

Rolling wave planning is the mechanism that keeps the WBS realistic across a multi-year program. Work within the next 90 days (or two to three reporting periods) is decomposed to discrete work packages with objective criteria. Work beyond the rolling wave horizon exists as planning packages -- budgeted but not yet fully decomposed. As the program progresses, planning packages are converted to work packages through a formal conversion process that updates the IMS, creates the work authorization document, and records the conversion in the budget log.

Common WBS mistakes on software programs:

Organizing by sprint or agile team rather than by product element. Agile delivery can coexist with EVM, but the control account structure must follow the WBS (product), not the delivery cadence (process). Agile work packages earn value at sprint completion against objective acceptance criteria.
Missing the systems engineering and integration work. Systems engineering (SE 01), integration/assembly/test and checkout (SE 10), and program management (SE 12) are separate MIL-STD-881 elements that must each have their own control accounts. Programs that lump these into software accounts create control account managers with blended responsibility and unclearable variances.
Failing to extend the WBS to subcontractors. Significant subcontractors are required by ANSI/EIA-748 criterion 4 to report EVM data at a level that permits prime contractor surveillance. A prime that carries a major software subcontract as a single line-item work package with milestone EV is not meeting criterion 4.

The WBS dictionary is the document that makes the WBS operational: for each element, the dictionary defines work scope, responsible CAM, responsible organization, budget, and earning method. The dictionary is baselined at contract start, updated through the change control process, and reviewed during IBR walkthroughs.

Integrated baseline review (IBR) preparation

The IBR is the government's formal validation that the contractor's PMB is credible -- that the work scope, schedule, and budget are consistent and achievable. For programs above the EVMS threshold, an IBR is required within 180 days of contract award (DoD Instruction 5000.02 sets the policy; individual program offices may compress that window). The IBR is not a one-time event: it recurs after significant contract modifications and after any formal re-baseline.

IBR objectives from the government's perspective. The government IBR team is assessing four things: technical completeness (does the WBS cover 100% of the contract SOW?), schedule achievability (can the milestones be met with the resources allocated?), budget realism (are the budgets grounded in legitimate estimates rather than plugged to make the total equal the contract value?), and management effectiveness (do the CAMs actually own their accounts and understand their work?).

Schedule risk assessment. Before the IBR, the contractor should run a quantitative schedule risk analysis on the IMS -- typically a Monte Carlo simulation using Primavera Risk Analysis or similar. The schedule risk analysis identifies the critical path, the near-critical paths, and the confidence level for key milestone dates. Government IBR teams will ask specifically about schedule margin: what is the float on the delivery milestones, and what risks could consume that float? Programs that arrive at IBR with zero float on the critical path and no schedule reserve have a credibility problem.

CAM risk walkthroughs. The core of the IBR is the one-on-one walkthrough between each CAM and the government IBR team. The CAM presents their control account: work scope, schedule, budget, resource loading, key risks, and estimate to complete. The government team challenges the CAM's assumptions and probes for gaps. The six questions every CAM must be able to answer without hesitation:

What exactly is in my control account's scope, and what is explicitly excluded?
What are the objective completion criteria for my work packages?
What earning method am I using, and why is it appropriate for this work?
What are the two or three risks most likely to drive cost or schedule variance in my account?
Is my budget sufficient to complete the work? If not, where would I go for more?
What is my ETC, and how did I calculate it?

Government IBR checklist items. The government team typically evaluates: (1) WBS-to-SOW traceability matrix; (2) IMS network logic -- no open-ended activities, no constraints that artificially accelerate the schedule; (3) resource-loaded schedule -- are the hours in the IMS consistent with the labor budget in the EVMS?; (4) risk register integration -- are identified risks traceable to schedule margin or management reserve?; (5) subcontractor IBR status -- have subcontractors above the flow-down threshold completed their own IBRs?; (6) system description currency -- does the EVMS system description reflect the tools and processes actually in use?

The IBR outputs a list of Action Items (AIs) and Significant Variances (SVs). AIs are specific gaps identified during walkthroughs that the contractor must close, typically within 30-60 days. SVs are more serious -- they indicate that a portion of the baseline may not be achievable -- and may require formal re-planning. A clean IBR (few AIs, no SVs) is the single most important early-program credibility indicator for the government program office.

Control account manager (CAM) reporting

The CAM is the fundamental unit of EVMS execution. On a software program, a typical CAM owns 3-8 work packages covering their software component's design, code, unit test, and integration activities. The CAM's monthly cycle drives the entire program's EVM data quality.

CAM status meeting cadence. Best practice for software programs is a weekly 30-minute CAM status touchpoint: the program control analyst (PCA) walks through each account's current period actuals, the CAM confirms or corrects percent complete estimates, new risks are flagged, and emerging variances are discussed before they appear in the monthly report. The monthly close-out meeting (typically in the first week after the accounting period closes) is where the formal EV claim is locked, variances are calculated, and variance analysis narratives are assigned to CAMs who must exceed threshold. Programs that compress all of this into a single monthly status meeting produce lower-quality data and miss the early warning purpose of the weekly cadence.

Variance analysis thresholds: the 10%/10 rule. The most common contractual threshold convention requires a written variance analysis report (VAR) when the cumulative cost variance percentage exceeds 10% of cumulative EV, or when the cumulative schedule variance percentage exceeds 10% of cumulative PV. Most contracts also specify an absolute dollar floor (e.g., $10,000 at the control account level, $100,000 at the program level) so that small accounts with large percentage variances but small dollar values do not generate mandatory narratives. When a control account breaches threshold in both cost and schedule variance simultaneously, a single VAR covering both is acceptable, but the root cause analysis must address each variance separately.

Variance at Completion (VAC) narrative. Beyond the period-to-date and cumulative variances, ANSI/EIA-748 criterion 27 requires that the EAC be updated at least quarterly, and the CPR Format 1 requires VAC reporting at the control account level each month. When a CAM's VAC turns negative (projected overrun), the VAR narrative must address not just the current period but the full life of the account. What happened, why it happened, what the projected impact is through contract completion, and specifically what the CAM is doing to recover -- or, if recovery is not possible, what scope reduction, schedule adjustment, or management reserve draw is being proposed. VAC narratives that read as copies of the prior month's text are the most common trigger for government requests for a face-to-face program review meeting.

Key insight: Government reviewers do not expect programs to have zero variances. They expect CAMs who understand why variances exist and have realistic plans to address them. A CAM who can explain a negative $40,000 cost variance with a specific root cause, a credible recovery timeline, and a believable ETC is in a far stronger position than a CAM who reports a positive $5,000 cost variance with no narrative -- because the first CAM demonstrates management in control; the second raises the question of whether the positive variance is real or a data quality artifact.

Estimate at completion (EAC) methods

The EAC is the most scrutinized output of the EVMS. It is the contractor's best estimate of what the program will cost in total, submitted monthly to the government in CPR Format 1. An EAC that is persistently more optimistic than what CPI trends would suggest is a data integrity signal that triggers government inquiry. Multiple EAC methods should be calculated each month to triangulate the most defensible figure.

EAC = BAC / CPI (the efficiency-based method). The simplest and often most statistically defensible EAC for software programs: divide the Budget at Completion by the current cumulative CPI. If BAC is $10,000,000 and cumulative CPI is 0.87, then EAC = $10,000,000 / 0.87 = $11,494,253. This method assumes the current cost performance efficiency will persist through contract completion. Research across large program databases consistently shows this method outperforms management judgment EACs after the program is 20-25% complete.

EAC (CPI-only)      = BAC / CPI
EAC (CPI x SPI)     = AC + (BAC - EV) / (CPI x SPI)
EAC (bottom-up)     = AC + Sum(CAM ETCs)
EAC (management)    = AC + ETC based on manager judgment

TCPI (vs BAC)       = (BAC - EV) / (BAC - AC)
TCPI (vs EAC)       = (BAC - EV) / (EAC - AC)
VAC                 = BAC - EAC

EAC composite methods (CPI x SPI). For programs where schedule slip is itself a driver of cost growth -- because sustained schedule slip extends labor costs across additional periods -- the composite method applies both CPI and SPI as the efficiency denominator: EAC = AC + (BAC - EV) / (CPI x SPI). This method is more aggressive than the CPI-only method (it produces a larger EAC) and is frequently used by government independent cost estimators as a cross-check. The composite method tends to overstate the EAC for programs where schedule slip reflects front-loading of risk rather than systematic inefficiency.

Independent Government Cost Estimate (IGCE) reconciliation. The program office maintains an IGCE -- their independent view of what the program will cost -- developed by the contracting officer's representative or a dedicated cost estimating team. When the government releases an IGCE, or when one can be inferred from government statements during program reviews, the contractor should reconcile its EAC against the IGCE and document the differences. A contractor EAC that is substantially more optimistic than the IGCE without a documented, substantive rationale is a credibility problem. The reconciliation narrative should explain specifically why the contractor's basis of estimate differs from the government's -- different labor rate assumptions, different productivity factors, different subcontract cost projections -- not simply assert that the contractor's EAC is correct.

The To Complete Performance Index (TCPI) is the internal consistency check: TCPI against BAC = (BAC - EV) / (BAC - AC). If TCPI against BAC is 1.15 and the current CPI is 0.88, the program is projecting a 31-point efficiency improvement with no demonstrated basis. That is the mathematical signature of an unrealistic EAC, and government reviewers will flag it immediately. The practical rule: when TCPI against BAC exceeds 1.10, the contractor needs either a bottom-up ETC that explains the improvement or a revised EAC that acknowledges the overrun trend.

EVMS tool selection and data submission

The choice of EVMS tool determines not only analytical capability but also the practical ease of government data submission. The government now requires IPMDAR (Integrated Program Management Data and Analysis Report) in structured digital format, and the tool must export compliant files.

Deltek Cobra. The dominant EVMS tool on DoD programs. Cobra handles PMB management, earning method configuration, variance calculation, budget log maintenance, and CPR/IPMDAR export. Cobra integrates natively with Primavera P6 for schedule-cost integration and with Deltek Costpoint for actuals import. Its primary strength is its native IPMDAR export module, which produces the government-required JSON data package directly from the Cobra database. For programs above the IPMDAR threshold ($20M+ cost-reimbursable), Cobra is effectively the standard.

Microsoft Project with EVM add-ins. On smaller programs (below $20M, firm-fixed-price with voluntary EVM, or internal use), Microsoft Project with an EVM module (Steelray, or the native EVM fields in Project) is widely used. MS Project does not natively produce IPMDAR-compliant exports and requires additional tooling or manual data transformation for government submission. Its advantage is familiarity -- virtually every program manager knows it -- and its tight integration with Microsoft 365 environments common in defense contractor environments.

Oracle Primavera P6. P6 is the schedule authority on most large programs. It is not a native EVMS tool -- it does not handle budgeting, EV claiming, or variance analysis natively at the depth ANSI/EIA-748 requires -- but it is the Integrated Master Schedule platform that feeds Cobra or other EVMS tools with schedule data. The P6-to-Cobra integration, properly configured, allows the IMS and the EVMS to share a single authoritative schedule, eliminating the "decoupled schedule" failure mode that is one of the most common DCMA audit findings.

IPMDAR and CPR data formats. The Contractor Performance Report (CPR) has five formats:

Format 1 -- WBS element performance: PV, EV, AC, BAC, EAC, VAC by WBS element
Format 2 -- Organizational performance: the same data organized by organizational element
Format 3 -- Baseline log: a record of all PMB changes during the reporting period
Format 4 -- Staffing: actual and planned staff-hours by discipline
Format 5 -- Explanations and problem analysis: the narrative section covering significant variances, EAC rationale, and risk discussion

The IPMDAR replaces the legacy IPMR format and is submitted as a structured JSON/XML package. IPMDAR Schema validation is required before submission -- tools that produce non-conformant schema output result in government data system rejection. Submission is typically through the Wide Area Workflow (WAWF) system or the DoD's EVM Central portal, depending on the program's designated data receiving office. The contract CDRL (Contract Data Requirements List) specifies due dates -- typically 25 days after period close for monthly reporting.

Tool selection should be driven by three factors: government acceptability (the EVMS system description must describe the tool and DCMA must have visibility into its configuration), integration with existing financial and schedule systems (manual data re-entry between financial system, schedule tool, and EVMS is a source of errors and a surveillance red flag), and organizational expertise (a team that knows Cobra well outperforms a team learning a theoretically superior tool mid-program). For new program starts, the investment in Cobra + Primavera P6 integration is justified by the reduction in monthly reporting burden and the quality of IPMDAR exports it produces.

Frequently Asked Questions

What is earned value management (EVM) and why is it required on defense programs?

Earned Value Management is a quantitative cost-schedule integration methodology that measures program performance by comparing the budgeted cost of work scheduled (PV), the budgeted cost of work performed (EV), and the actual cost of work performed (AC). The difference between EV and AC is the cost variance; the difference between EV and PV is the schedule variance. DoD requires EVMS compliance under DoDI 5000.02 and DFARS 252.234-7002 for cost-reimbursable contracts above roughly $20 million at the program level. The requirement derives from decades of experience showing that programs without structured cost-schedule integration consistently discover overruns late, when corrective action is most expensive. EVMS compliance is validated against the 32 criteria of ANSI/EIA-748 through a formal Earned Value Management System Description review and Integrated Baseline Review process.

What are the 32 criteria of ANSI/EIA-748 organized into?

ANSI/EIA-748 organizes the 32 EVMS criteria into five guideline groups. The Organization group (criteria 1-5) covers WBS decomposition, organizational structure, integration of cost accounts, and identification of subcontractor EVM requirements. The Planning, Scheduling, and Budgeting group (criteria 6-14) governs how the performance measurement baseline is established, including schedule network logic, budget allocation, and management reserve. The Accounting Considerations group (criteria 15-18) addresses actual cost recording and time-phased actuals. The Analysis and Management Reports group (criteria 19-27) covers variance analysis thresholds, EAC methods, and government reporting formats. The Revisions and Data Maintenance group (criteria 28-32) governs how baselines are changed, budget logs are maintained, and retroactive adjustments are controlled. Government surveillance focuses most intensively on groups 2, 4, and 5 because those groups surface the behaviors that hide overruns.

What is the Integrated Baseline Review (IBR) and what triggers one?

The Integrated Baseline Review is a formal government review of the contractor's Performance Measurement Baseline, conducted jointly by the contracting officer's representative, the program office, and the contractor's control account managers. An IBR is triggered by contract award above the EVMS threshold (typically within 180 days of award), a significant contract modification that changes the scope or value materially, or a re-baseline event following a formal variance at completion breach. The IBR validates that the baseline is technically complete, schedule-achievable, and properly resourced -- meaning the work scope, schedule, and budget are internally consistent and that CAMs understand and own their control accounts. A failed IBR results in a corrective action request and delays the program's ability to report reliable EVM data to the government.

What is a control account manager (CAM) and what are their EVM responsibilities?

A Control Account Manager is the person responsible for managing a specific control account -- the intersection of a WBS element and an organizational unit -- within the EVMS. CAM responsibilities include defining the work scope for their control account in a work package or planning package, establishing the time-phased budget (the planned value curve), recording or verifying actual costs, earning value using the approved earning method (percent complete, 0/100, 50/50, level of effort, or milestones), analyzing cost and schedule variances against the 10%/10 rule threshold, and producing written variance analysis narratives when variances exceed threshold. CAMs must also produce an estimate to complete for their account each reporting period and participate in the IBR as the primary subject-matter expert for their scope. In software programs, CAMs typically own 3-8 work packages across software components, integration, and test.

What is the To Complete Performance Index (TCPI) and how is it used to validate EAC credibility?

The To Complete Performance Index is the efficiency ratio required on remaining work to achieve a target (either BAC or a given EAC). TCPI against BAC = (BAC - EV) / (BAC - AC). TCPI against EAC = (BAC - EV) / (EAC - AC). When TCPI against BAC significantly exceeds the current CPI -- for example, CPI of 0.85 but TCPI of 1.15 -- the program is projecting performance improvement it has not demonstrated, which makes the EAC non-credible. Government cost estimators use TCPI to challenge EACs: if TCPI exceeds 1.10, they typically require a detailed bottom-up estimate to support the claim that performance will improve. TCPI is one of the first metrics reviewed during Contractor Performance Report analysis and during IBR walkthroughs of CAM estimate-to-complete logic.

What is the difference between EAC, ETC, and VAC in defense EVM reporting?

In EVM terminology, EAC (Estimate at Completion) is the total expected cost of all authorized work -- what the program will cost from start to finish. ETC (Estimate to Complete) is the expected cost of all remaining authorized work. The relationship is EAC = AC + ETC. VAC (Variance at Completion) is the difference between the Budget at Completion and the EAC: VAC = BAC - EAC. A negative VAC indicates an overrun at completion. EAC is submitted by the contractor in the Contractor Performance Report Format 3; the government independently develops an IGCE and compares it against the contractor EAC. A contractor EAC that is significantly more optimistic than the IGCE triggers government scrutiny and may lead to a formal challenge meeting.

What EVMS tools are used for defense program reporting?

The dominant EVMS tool suite for DoD programs is Deltek Cobra, which handles the performance measurement baseline, earning method management, variance calculations, and CPR/IPMDAR export natively. Oracle Primavera P6 is the schedule authority that feeds Cobra with IMS data. Microsoft Project with EVM add-ins is used on smaller programs below the IPMDAR threshold. The IPMDAR format -- which replaced the legacy IPMR in 2019 -- is a structured JSON/XML schema submitted to the DoD's data systems. The Contractor Performance Report (CPR) has five formats: WBS performance (Format 1), organizational performance (Format 2), baseline log (Format 3), staffing (Format 4), and explanations/problem analysis (Format 5). All must be submitted within 25 days of period close per the contract CDRL.

What is a re-baseline and when is it permitted under ANSI/EIA-748?

A re-baseline is a formal reset of the Performance Measurement Baseline, approved by the contracting officer, that replaces the current PMB with a new time-phased budget plan. ANSI/EIA-748 criteria 28-32 govern baseline changes: routine scope changes are handled through a budget log via contract modification; over-target baselines (OTB) are approved when the program's cumulative EAC has exceeded the BAC and the original baseline no longer provides meaningful management information. An OTB is a significant event -- it signals to the program office and oversight community that the program's original cost estimate was not achievable. DCMA and the program office typically require a formal recovery plan and re-IBR before approving an OTB. Contractors must distinguish between formal re-baselines (requiring CO approval) and internal replanning within authorized budget (permitted under criterion 27 without CO approval).

How does MIL-STD-881 alignment affect the WBS used for software EVM?

MIL-STD-881 provides standard WBS element definitions for defense systems programs. For software-intensive programs, the relevant elements include Software (SE 03) decomposed into Computer Software Configuration Items (CSCIs), which align with the system architecture and are the natural level at which control accounts are established. Aligning the EVMS WBS to MIL-STD-881 ensures that CPR reports map directly to the program WBS used by the program office, that cost data rolls up consistently across program phases, and that IGCE comparisons use a common dictionary. Programs organized by sprint or by team rather than by CSCI must provide mapping tables that reconcile their internal structure to the contract WBS at reporting time.

What are common EVMS failure modes on software-intensive defense programs?

The most common EVMS failure modes on software programs include: rubber baseline -- PMB adjusted retroactively to absorb variances rather than reporting them, a violation of criteria 28-32; percent complete inflation -- CAMs report optimistic figures without objective evidence, creating an EV illusion that collapses at delivery; level of effort overuse -- applying LOE earning to discrete software tasks makes those tasks invisible to variance analysis; decoupled schedule -- the IMS is maintained separately from the EVMS, so schedule variances do not appear in the EVM system; and CAM inexperience -- assigning EVMS control accounts to engineers untrained in EVM leads to narrative quality failures and ETC estimates not grounded in actual work remaining assessments. All five patterns are identifiable through DCMA surveillance and are regularly cited in program breach notifications under the Nunn-McCurdy Amendment.