Defense Market

Earned Value Management für Verteidigungssoftwareprogramme

Von Corvus Intelligence Engineering Team · Über das Team →

25. Juni 2026 12 Min. Lesezeit

Earned Value Management steht an der Schnittstelle von Kostenrechnung, Terminmanagement und Programmsteuerung -- und ist eines der anspruchsvollsten Compliance-Regime, dem ein Verteidigungssoftwareauftragnehmer begegnen wird. Ein Programm ohne glaubwürdiges EVMS kann keine Erstattungsverträge über dem DoD-Schwellenwert gewinnen. Ein Programm, das EVM-Daten nachlässig meldet, löst DCMA-Überwachung, Korrekturmaßnahmen und letztendlich Konsequenzen für die Vergangenheitsleistung aus. Ein Programm hingegen, das EVM als echtes Managementwerkzeug nutzt -- nicht als Berichtspflicht -- verfügt über quantitative Frühwarnung bei Kosten- und Terminproblemen, Monate bevor diese zu Krisen werden.

Dieser Leitfaden behandelt den vollständigen EVMS-Lebenszyklus für softwareintensive Verteidigungsprogramme: die Mathematik, die jeder CAM beherrschen muss, die 32 ANSI/EIA-748-Kriterien, die die EVMS-Compliance strukturieren, den WBS-Aufbau nach MIL-STD-881, die IBR-Vorbereitung und -Durchführung, den CAM-Berichtsrhythmus und die Abweichungsanalyse, EAC-Berechnungsmethoden sowie das Tool-Ökosystem für die staatliche Datenübermittlung. Für den breiteren Kontext der Vertragsausführung siehe das Defense Market Playbook Teil 4: Ausführung und EVM. Zu Preisstrukturen, die bestimmen, welche Vertragsarten EVMS erfordern, siehe Preismodelle für Verteidigungssoftware. Zum Beschaffungsweg, der zu EVMS-pflichtigen Verträgen führt, siehe Verteidigungsbeschaffung: vom RFP zum Vertrag.

EVM-Grundlagen für Programm-Manager im Verteidigungsbereich

EVM stützt sich auf sechs Kennzahlen. Jeder Control Account Manager, Programm-Manager und staatliche Prüfer liest diese sechs Metriken in jedem monatlichen Statuszyklus. Das Verständnis ihrer Bedeutung -- und ihrer Grenzen -- ist die Grundlage der gesamten Disziplin.

Planned Value (PV) -- früher BCWS (Budgeted Cost of Work Scheduled) -- ist das zeitlich gestaffelte Budget: der kumulierte Betrag, den das Programm bis zum Statusdatum für genehmigte Arbeiten geplant hatte auszugeben. PV ist die Baseline. Sie wird einmalig während der Planung festgelegt, in der Performance Measurement Baseline verankert und ändert sich nur durch formale Basisänderungskontrolle. Jeder Vertragsdollar ist von Beginn bis zum Vertragsabschluss einer PV-Kurve zugeordnet.

Earned Value (EV) -- früher BCWP (Budgeted Cost of Work Performed) -- ist der Budgetwert der tatsächlich abgeschlossenen Arbeit, gemessen an der gleichen Baseline. EV gibt nicht an, was die Arbeit gekostet hat; es gibt an, was die abgeschlossene Arbeit laut Plan kosten sollte. Ein Softwaremodul, das mit 200.000 Dollar budgetiert ist, erzielt 200.000 Dollar EV bei Fertigstellung, unabhängig davon, ob es tatsächlich 180.000 oder 240.000 Dollar kostete.

Actual Cost (AC) -- früher ACWP (Actual Cost of Work Performed) -- sind die tatsächlichen Programmausgaben für die durchgeführten Arbeiten. AC stammt aus dem Finanzbuchhaltungssystem, nicht aus Schätzungen. Er umfasst direkte Arbeit, direktes Material, sonstige Direktkosten und angewendete indirekte Sätze.

Aus PV, EV und AC leiten sich die beiden primären Abweichungsmetriken ab:

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

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

Ein negativer CV bedeutet Kostenüberschreitung (die Arbeit hat mehr gekostet, als sie eingebracht hat). Ein negativer SV bedeutet Terminverzug (weniger Arbeit wurde abgeschlossen als geplant). Beide Abweichungen werden in Dollar und als Prozentsätze ausgedrückt -- die prozentuale Form wird für Schwellenwertvergleiche verwendet.

Die beiden Performance-Indizes sind die Metriken, die staatliche Prüfer als Erstes heranziehen:

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

Ein CPI über 1,0 bedeutet, dass das Programm effizienter als budgetiert arbeitet; unter 1,0 bedeutet es Kostenüberschreitung. Die empirische Beobachtung von Humphreys -- dass sich der CPI am 20-Prozent-Fertigstellungspunkt über die Laufzeit eines Programms selten wesentlich verbessert -- ist der Grund, warum staatliche Auftraggeber einen anhaltenden CPI unter 0,9 als strukturelles Problem und nicht als behebbare Anomalie betrachten. Ein SPI über 1,0 bedeutet, dass das Programm dem Zeitplan voraus ist; unter 1,0 liegt es zurück. Beachten Sie, dass der SPI bei Programmabschluss unabhängig von der Terminleistung gegen 1,0 konvergiert (weil EV bei Abschluss aller Arbeiten schließlich dem PV entspricht) -- weshalb der Terminleistungsindex allein für die Terminbewertung in späten Programmstadien unzureichend ist und durch den Integrated Master Schedule ergänzt werden muss.

Die sechste Kennzahl, die jeder CAM beherrschen muss, ist die Estimate at Completion (EAC) -- die voraussichtlichen Gesamtkosten aller Programmarbeiten. EAC = AC + Estimate to Complete (ETC). Das Verhältnis zwischen EAC und Budget at Completion (BAC) erzählt die Geschichte: VAC = BAC - EAC. Ein negativer VAC ist eine prognostizierte Überschreitung. VAC wird monatlich im CPR Format 1 gemeldet und ist einer der wichtigsten Auslöser für die Aufmerksamkeit des staatlichen Programmbüros.

ANSI/EIA-748-Richtlinien: die 32 Kriterien

ANSI/EIA-748 ist der Konsensnorm, der definiert, was ein konformes EVMS leisten muss. Es schreibt keine spezifischen Softwaretools oder Berichtsformate vor -- es legt 32 Kriterien fest, die in fünf Richtliniengruppen gegliedert sind. Die EVMS-Systembeschreibung eines Auftragnehmers muss darlegen, wie jedes Kriterium umgesetzt wird, und DCMA validiert diese Umsetzung durch Überwachung und IBR.

Gruppe 1: Organisation (Kriterien 1-5). Das EVMS muss um einen Projektstrukturplan (WBS) organisiert sein, der 100 % des genehmigten Arbeitsumfangs abdeckt, wobei jedes Element einer einzelnen verantwortlichen Organisationseinheit zugewiesen ist. Interne Unteraufträge und wesentliche Unterauftragnehmer müssen in das EVMS auf einem Niveau integriert sein, das eine sinnvolle Kosten- und Terminüberwachung ermöglicht. Die Organisationsstruktur muss dokumentiert und im EVMS-Tool abgebildet sein. Kriterium 5 -- die Integration des WBS mit der Organizational Breakdown Structure (OBS) zur Definition von Control Accounts -- ist der Dreh- und Angelpunkt: Ein Control Account ist die Schnittmenge von WBS und OBS, und jeder Dollar des Programmbudgets liegt in genau einem Control Account.

Gruppe 2: Planung, Terminierung und Budgetierung (Kriterien 6-14). Dies ist die größte Gruppe und diejenige, die bestimmt, ob die PMB glaubwürdig ist. Alle genehmigten Arbeiten müssen von Vertragsbeginn bis Vertragsabschluss zeitlich gestaffelt werden. Kurzfristige Arbeiten befinden sich in Arbeitspaketen mit objektiven Start-/Abschlusskriterien; langfristige Arbeiten verbleiben in Planungspaketen, bis sie in den rollierenden Horizont eintreten. Management Reserve wird auf Programmebene gehalten und nur für neu entstandene, im Umfang enthaltene Arbeiten freigegeben. Undistributed Budget deckt genehmigte Arbeiten ab, die noch keinen Control Accounts zugewiesen sind. Änderungen der Budgetbasis erfordern eine formale Dokumentation im Budgetprotokoll. Kriterium 12 -- die Ausrichtung der indirekten Kostenstruktur am Buchhaltungssystem -- ist der Punkt, an dem Softwareprogramme am häufigsten Schwierigkeiten haben, da mehrere indirekte Kostenstellen (Sozialleistungen, Gemeinkosten, G&A) zwischen EVMS und Finanzsystem konsistent aufsummiert werden müssen.

Gruppe 3: Buchhalterische Überlegungen (Kriterien 15-18). Tatsächliche Kosten müssen auf Ebene des Control Accounts, im gleichen Zeitraum wie die durchgeführten Arbeiten und unter Verwendung der gleichen WBS-Elementstruktur erfasst werden. Die Kriterien verbieten die Schätzung tatsächlicher Kosten (d. h. Rückstellungen oder Schätzungen anstelle tatsächlicher Rechnungen dürfen nicht länger als eine Berichtsperiode reale Kostendaten ersetzen). Materialkosten müssen beim Eingang oder Verbrauch erfasst werden -- je nachdem, was mit dem Kostensystem des Programms übereinstimmt -- und konsistent angewendet werden.

Gruppe 4: Analyse und Managementberichte (Kriterien 19-27). Diese Gruppe regelt die Analyseausgaben: Abweichungsschwellenwerte, VAR-Berichte, EAC-Methoden, Unterauftragnehmerüberwachung und staatliche Datenberichterstattung. Kriterium 22 -- die Identifikation wesentlicher Abweichungen und die Erstellung von Abweichungsanalyseberichten -- ist das operativ intensivste Kriterium für CAMs. Kriterium 27 -- die Entwicklung einer EAC mindestens vierteljährlich oder häufiger, wenn Abweichungen den Schwellenwert überschreiten -- ist der Punkt, an dem die Glaubwürdigkeit der Programmprognose begründet oder verloren geht.

Gruppe 5: Revisionen und Datenpflege (Kriterien 28-32). Baseline-Änderungen müssen formal und zeitnah eingearbeitet werden. Das Budgetprotokoll verfolgt jede Dollar-Budgetbewegung, genehmigt durch das Management, mit Grundcodes. Rückwirkende Änderungen am EV -- Anrechnung von Leistungen nach dem Statusdatum -- sind verboten. Die Systembeschreibung selbst muss aktuell gehalten werden. Kriterium 32 -- das Verbot rückwirkender Anpassungen, die keine Leistung widerspiegeln -- ist das Kriterium, das am häufigsten in DCMA-Korrekturanfragen zitiert wird, da die rückwirkende EV-Manipulation der verlockendste kurzfristige Ausweg bei negativen Abweichungen ist.

Projektstrukturplan für Verteidigungssoftware

Der WBS für ein softwareintensives Verteidigungsprogramm ist keine Aufgabenliste und keine Projektmanagementhierarchie. Es ist eine produktorientierte Zerlegung des gesamten Vertragslieferobjekts, ausgerichtet an MIL-STD-881, damit die Berichterstattung direkt auf das Kostenmodell des Programmbüros abgebildet wird.

MIL-STD-881 stellt Standard-WBS-Elementdefinitionen für Verteidigungssystemprogramme bereit. Für ein softwareintensives System umfassen die relevanten Elemente in der Regel: System (Ebene 1), Software (SE 03 auf Ebene 2), zerlegt in Computer Software Configuration Items (CSCIs) auf Ebene 3. Jedes CSCI entspricht einer wichtigen Softwarekomponente -- einer Missionsystemsoftware-Suite, einem Kommunikationsverarbeitungselement, einem Datenverwaltungsdienst -- entsprechend der zugewiesenen Baseline-Architektur. Control Accounts werden normalerweise auf Ebene 3 (CSCI) oder Ebene 4 (Computer Software Component, CSC) eingerichtet, je nach Programmgröße und Softwarekomplexität.

Rolling-Wave-Planung ist der Mechanismus, der den WBS über ein mehrjähriges Programm hinweg realistisch hält. Arbeiten innerhalb der nächsten 90 Tage (oder zwei bis drei Berichtsperioden) werden in diskrete Arbeitspakete mit objektiven Kriterien zerlegt. Arbeiten jenseits des Rolling-Wave-Horizonts existieren als Planungspakete -- budgetiert, aber noch nicht vollständig zerlegt. Im Programmlauf werden Planungspakete durch einen formalen Umwandlungsprozess in Arbeitspakete umgewandelt, der den IMS aktualisiert, das Arbeitserlaubnisdokument erstellt und die Umwandlung im Budgetprotokoll festhält.

Häufige WBS-Fehler bei Softwareprogrammen:

Organisation nach Sprint oder agilem Team statt nach Produktelement. Agile Lieferung kann mit EVM koexistieren, aber die Control-Account-Struktur muss dem WBS (Produkt) folgen, nicht dem Lieferrhythmus (Prozess). Agile Arbeitspakete verdienen Wert beim Sprint-Abschluss gegen objektive Abnahmekriterien.
Fehlendes Systems Engineering und Integrationsarbeit. Systems Engineering (SE 01), Integration/Montage/Test und Abnahme (SE 10) sowie Programmmanagement (SE 12) sind separate MIL-STD-881-Elemente, die jeweils eigene Control Accounts haben müssen. Programme, die diese in Softwarekonten zusammenfassen, schaffen Control Account Manager mit gemischter Verantwortung und nicht auflösbaren Abweichungen.
Fehlende WBS-Erweiterung auf Unterauftragnehmer. Bedeutende Unterauftragnehmer sind gemäß ANSI/EIA-748-Kriterium 4 verpflichtet, EVM-Daten auf einem Niveau zu melden, das die Überwachung durch den Hauptauftragnehmer ermöglicht. Ein Hauptauftragnehmer, der einen wichtigen Software-Unterauftrag als einzelnes Zeilenposition-Arbeitspaket mit Meilenstein-EV führt, erfüllt Kriterium 4 nicht.

Das WBS-Wörterbuch ist das Dokument, das den WBS operativ macht: Für jedes Element definiert das Wörterbuch Arbeitsumfang, verantwortlichen CAM, verantwortliche Organisation, Budget und Bewertungsmethode. Das Wörterbuch wird bei Vertragsbeginn als Baseline festgelegt, durch den Änderungskontrollprozess aktualisiert und während IBR-Walkthroughs überprüft.

Vorbereitung des integrierten Baseline-Reviews (IBR)

Das IBR ist die formale Validierung durch den Staat, dass die PMB des Auftragnehmers glaubwürdig ist -- dass Arbeitsumfang, Zeitplan und Budget konsistent und erreichbar sind. Für Programme über dem EVMS-Schwellenwert ist ein IBR innerhalb von 180 Tagen nach Vertragsabschluss erforderlich (DoD Instruction 5000.02 legt die Richtlinie fest; einzelne Programmbüros können dieses Fenster verkürzen). Das IBR ist kein einmaliges Ereignis: Es wiederholt sich nach wesentlichen Vertragsänderungen und nach jeder formalen Neubasierung.

IBR-Ziele aus staatlicher Perspektive. Das staatliche IBR-Team bewertet vier Aspekte: technische Vollständigkeit (deckt der WBS 100 % des Vertrags-SOW ab?), Terminerreichbarkeit (können die Meilensteine mit den zugeteilten Ressourcen erreicht werden?), Budgetrealismus (sind die Budgets auf legitimen Schätzungen basiert und nicht auf Werte angepasst, die die Vertragssumme ergeben?) und Managementeffektivität (besitzen die CAMs tatsächlich ihre Konten und verstehen ihre Arbeit?).

Terminalrisikoanalyse. Vor dem IBR sollte der Auftragnehmer eine quantitative Terminrisikoanalyse des IMS durchführen -- typischerweise eine Monte-Carlo-Simulation mit Primavera Risk Analysis oder ähnlichem. Die Terminrisikoanalyse identifiziert den kritischen Pfad, die nahezu kritischen Pfade und den Konfidenzgrad für wichtige Meilensteindaten. Staatliche IBR-Teams fragen gezielt nach Terminpuffer: Wie hoch ist der Float bei den Liefermeilensteinen, und welche Risiken könnten diesen Float aufzehren? Programme, die zum IBR mit null Float auf dem kritischen Pfad und ohne Terminreserve erscheinen, haben ein Glaubwürdigkeitsproblem.

CAM-Risikowalkthroughs. Den Kern des IBR bildet der Einzelwalkthrough zwischen jedem CAM und dem staatlichen IBR-Team. Der CAM präsentiert seinen Control Account: Arbeitsumfang, Zeitplan, Budget, Ressourcenauslastung, wesentliche Risiken und Estimate to Complete. Das staatliche Team hinterfragt die Annahmen des CAMs und sucht nach Lücken. Die sechs Fragen, die jeder CAM ohne Zögern beantworten können muss:

Was genau liegt im Umfang meines Control Accounts, und was ist ausdrücklich ausgeschlossen?
Was sind die objektiven Abschlusskriterien für meine Arbeitspakete?
Welche Bewertungsmethode verwende ich, und warum ist sie für diese Arbeit geeignet?
Was sind die zwei oder drei Risiken, die am wahrscheinlichsten Kosten- oder Terminabweichungen in meinem Konto verursachen?
Ist mein Budget ausreichend, um die Arbeit abzuschließen? Falls nicht, wo würde ich mehr beantragen?
Was ist mein ETC, und wie habe ich ihn berechnet?

Staatliche IBR-Checkliste. Das staatliche Team bewertet typischerweise: (1) WBS-zu-SOW-Rückverfolgbarkeitsmatrix; (2) IMS-Netzwerklogik -- keine offenen Aktivitäten, keine Einschränkungen, die den Zeitplan künstlich beschleunigen; (3) ressourcenbelasteter Zeitplan -- stimmen die Stunden im IMS mit dem Arbeitsbudget im EVMS überein?; (4) Risikoregisterintegration -- sind identifizierte Risiken auf Terminpuffer oder Management Reserve rückverfolgbar?; (5) IBR-Status des Unterauftragnehmers -- haben Unterauftragnehmer über dem Weitergabe-Schwellenwert ihre eigenen IBRs abgeschlossen?; (6) Aktualität der Systembeschreibung -- spiegelt die EVMS-Systembeschreibung die tatsächlich verwendeten Tools und Prozesse wider?

Das IBR erzeugt eine Liste von Action Items (AIs) und Significant Variances (SVs). AIs sind spezifische Lücken, die während Walkthroughs identifiziert wurden und die der Auftragnehmer in der Regel innerhalb von 30-60 Tagen schließen muss. SVs sind schwerwiegender -- sie deuten darauf hin, dass ein Teil der Baseline möglicherweise nicht erreichbar ist -- und können eine formale Neuplanung erfordern. Ein sauberes IBR (wenige AIs, keine SVs) ist der wichtigste Glaubwürdigkeitsindikator in der frühen Programmphase für das staatliche Programmbüro.

Control Account Manager (CAM)-Reporting

Der CAM ist die grundlegende Einheit der EVMS-Ausführung. In einem Softwareprogramm besitzt ein typischer CAM 3-8 Arbeitspakete, die Design, Code, Einheitentest und Integrationsaktivitäten seiner Softwarekomponente abdecken. Der monatliche Zyklus des CAMs bestimmt die gesamte EVM-Datenqualität des Programms.

CAM-Statusbesprechungsrhythmus. Best Practice für Softwareprogramme ist ein wöchentlicher 30-minütiger CAM-Status-Touchpoint: Der Program Control Analyst (PCA) geht die aktuellen Ist-Kosten jedes Kontos durch, der CAM bestätigt oder korrigiert Fertigstellungsschätzungen, neue Risiken werden markiert und aufkommende Abweichungen werden besprochen, bevor sie im Monatsbericht erscheinen. Die monatliche Abschlussbesprechung (typischerweise in der ersten Woche nach dem Buchungsperiodenabschluss) ist der Zeitpunkt, an dem der formale EV-Anspruch gesperrt, Abweichungen berechnet und Abweichungsanalyseberichte an CAMs zugewiesen werden, die den Schwellenwert überschreiten. Programme, die all dies in eine einzige monatliche Statusbesprechung komprimieren, produzieren Daten niedrigerer Qualität und verfehlen den Frühwarnzweck des wöchentlichen Rhythmus.

Abweichungsanalyse-Schwellenwerte: die 10%/10-Regel. Die häufigste Vertragsschwellenwert-Konvention erfordert einen schriftlichen Abweichungsanalysebericht (VAR), wenn die kumulative Kostenabweichung 10 % des kumulativen EV oder die kumulative Terminabweichung 10 % des kumulativen PV übersteigt. Die meisten Verträge legen auch einen absoluten Dollarbetrag fest (z. B. 10.000 Dollar auf Control-Account-Ebene, 100.000 Dollar auf Programmebene), damit kleine Konten mit großen prozentualen Abweichungen aber geringen Dollarbeträgen keine Pflichtberichte erzeugen. Wenn ein Control Account den Schwellenwert bei Kosten- und Terminabweichungen gleichzeitig verletzt, ist ein einziger VAR, der beide abdeckt, akzeptabel, aber die Ursachenanalyse muss jede Abweichung gesondert behandeln.

VAC-Bericht (Variance at Completion). Über die periodenweisen und kumulativen Abweichungen hinaus verlangt ANSI/EIA-748-Kriterium 27, dass die EAC mindestens vierteljährlich aktualisiert wird, und CPR Format 1 verlangt monatlich VAC-Berichte auf Control-Account-Ebene. Wenn der VAC eines CAMs negativ wird (prognostizierte Überschreitung), muss der VAR-Bericht nicht nur den aktuellen Zeitraum, sondern den gesamten Lebenszyklus des Kontos ansprechen. Was ist passiert, warum ist es passiert, was sind die projizierten Auswirkungen bis zum Vertragsabschluss, und was unternimmt der CAM konkret zur Abhilfe -- oder, falls eine Abhilfe nicht möglich ist, welche Umfangsreduzierung, Terminanpassung oder Entnahme aus der Management Reserve wird vorgeschlagen. VAC-Berichte, die als Kopien des Vormonatsberichts wirken, sind der häufigste Auslöser für staatliche Anfragen nach einem persönlichen Programmüberprüfungsgespräch.

Wesentliche Erkenntnis: Staatliche Prüfer erwarten nicht, dass Programme keine Abweichungen aufweisen. Sie erwarten CAMs, die verstehen, warum Abweichungen existieren und realistische Pläne zu deren Behebung haben. Ein CAM, der eine negative Kostenabweichung von 40.000 Dollar mit einer spezifischen Ursache, einem glaubwürdigen Erholungszeitplan und einem nachvollziehbaren ETC erklären kann, ist in einer weit stärkeren Position als ein CAM, der eine positive Kostenabweichung von 5.000 Dollar ohne Bericht meldet -- denn der erste CAM demonstriert ein Management mit Kontrolle; der zweite wirft die Frage auf, ob die positive Abweichung real oder ein Datenqualitätsartefakt ist.

Methoden zur Abschlusskostenschätzung (EAC)

Die EAC ist die am stärksten geprüfte Ausgabe des EVMS. Sie ist die beste Schätzung des Auftragnehmers für die Gesamtkosten des Programms, die monatlich dem Staat in CPR Format 1 übermittelt wird. Eine EAC, die anhaltend optimistischer ist als CPI-Trends nahelegen, ist ein Datenintegritätssignal, das staatliche Anfragen auslöst. Monatlich sollten mehrere EAC-Methoden berechnet werden, um die vertretbarste Zahl zu triangulieren.

EAC = BAC / CPI (effizienzbasierte Methode). Die einfachste und statistisch oft vertretbarste EAC für Softwareprogramme: Budget at Completion durch den aktuellen kumulativen CPI dividieren. Wenn BAC 10.000.000 Dollar und der kumulative CPI 0,87 beträgt, dann EAC = 10.000.000 / 0,87 = 11.494.253 Dollar. Diese Methode geht davon aus, dass die aktuelle Kostenleistungseffizienz bis zum Vertragsabschluss andauert. Untersuchungen in großen Programmdatenbanken zeigen konsistent, dass diese Methode nach 20-25 % Programmfortschritt die Managementschätzungs-EACs übertrifft.

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-Verbundmethoden (CPI x SPI). Für Programme, bei denen Terminverzug selbst ein Kostentreiber ist -- weil anhaltender Terminverzug Arbeitskosten über zusätzliche Zeiträume verlängert -- wendet die Verbundmethode sowohl CPI als auch SPI als Effizienznenner an: EAC = AC + (BAC - EV) / (CPI x SPI). Diese Methode ist aggressiver als die CPI-only-Methode (sie erzeugt eine größere EAC) und wird häufig von staatlichen unabhängigen Kostenkalkulatoren als Gegenprobe verwendet. Die Verbundmethode neigt dazu, die EAC für Programme zu überschätzen, bei denen Terminverzug eine Vorabregelung von Risiken widerspiegelt und keine systematische Ineffizienz.

Abgleich mit der unabhängigen Kostenschätzung der Regierung (IGCE). Das Programmbüro unterhält eine IGCE -- ihre unabhängige Sicht auf die Programmkosten -- entwickelt durch den Vertreter des beauftragenden Beamten oder ein dediziertes Kostenkalkulationsteam. Wenn die Regierung eine IGCE veröffentlicht oder eine aus Regierungsaussagen in Programmüberprüfungen abgeleitet werden kann, sollte der Auftragnehmer seine EAC gegen die IGCE abgleichen und die Unterschiede dokumentieren. Eine EAC des Auftragnehmers, die ohne eine dokumentierte, substantielle Begründung deutlich optimistischer als die IGCE ist, ist ein Glaubwürdigkeitsproblem. Die Abstimmungsdarstellung sollte konkret erklären, warum die Kostenschätzungsbasis des Auftragnehmers von der der Regierung abweicht -- unterschiedliche Lohnsätze, unterschiedliche Produktivitätsfaktoren, unterschiedliche Unterauftragnehmer-Kostenprojektionen -- und nicht einfach behaupten, dass die EAC des Auftragnehmers korrekt ist.

Der To Complete Performance Index (TCPI) ist die interne Konsistenzprüfung: TCPI gegen BAC = (BAC - EV) / (BAC - AC). Wenn TCPI gegen BAC 1,15 und der aktuelle CPI 0,88 beträgt, prognostiziert das Programm eine 31-Punkte-Effizienzverbesserung ohne nachgewiesene Grundlage. Das ist die mathematische Signatur einer unrealistischen EAC, und staatliche Prüfer werden dies sofort markieren. Die praktische Regel: Wenn TCPI gegen BAC 1,10 übersteigt, benötigt der Auftragnehmer entweder einen Bottom-up-ETC, der die Verbesserung erklärt, oder eine überarbeitete EAC, die den Überschreitungstrend anerkennt.

EVMS-Toolauswahl und Datenübermittlung

Die Wahl des EVMS-Tools bestimmt nicht nur die Analysefähigkeit, sondern auch die praktische Einfachheit der staatlichen Datenübermittlung. Die Regierung verlangt jetzt IPMDAR (Integrated Program Management Data and Analysis Report) in strukturiertem digitalem Format, und das Tool muss konforme Dateien exportieren.

Deltek Cobra. Das dominante EVMS-Tool für DoD-Programme. Cobra übernimmt PMB-Management, Konfiguration der Bewertungsmethoden, Abweichungsberechnung, Budgetprotokollpflege und CPR/IPMDAR-Export. Cobra integriert sich nativ mit Primavera P6 für die Zeitplan-Kosten-Integration und mit Deltek Costpoint für den Ist-Kosten-Import. Seine primäre Stärke ist das native IPMDAR-Exportmodul, das das behördlich geforderte JSON-Datenpaket direkt aus der Cobra-Datenbank erzeugt. Für Programme über dem IPMDAR-Schwellenwert (Erstattungsverträge über 20 Mio. Dollar) ist Cobra praktisch der Standard.

Microsoft Project mit EVM-Erweiterungen. Bei kleineren Programmen (unter 20 Mio. Dollar, Festpreisverträge mit freiwilligem EVM oder für interne Zwecke) ist Microsoft Project mit einem EVM-Modul (Steelray oder die nativen EVM-Felder in Project) weit verbreitet. MS Project erzeugt nativ keine IPMDAR-konformen Exporte und erfordert für die staatliche Übermittlung zusätzliche Tools oder manuelle Datentransformation. Sein Vorteil ist die Vertrautheit -- nahezu jeder Programm-Manager kennt es -- und die enge Integration mit Microsoft-365-Umgebungen, die in Verteidigungsauftraggeberumgebungen verbreitet sind.

Oracle Primavera P6. P6 ist die Terminautorität bei den meisten großen Programmen. Es ist kein natives EVMS-Tool -- es handhabt Budgetierung, EV-Ansprüche oder Abweichungsanalyse nicht nativ in der Tiefe, die ANSI/EIA-748 erfordert -- aber es ist die Integrated Master Schedule-Plattform, die Cobra oder andere EVMS-Tools mit Termindaten versorgt. Die P6-zu-Cobra-Integration, richtig konfiguriert, ermöglicht IMS und EVMS, einen einzigen autoritativen Terminplan zu teilen und eliminiert so den „entkoppelten Zeitplan"-Fehler, der einer der häufigsten DCMA-Auditbefunde ist.

IPMDAR- und CPR-Datenformate. Der Contractor Performance Report (CPR) hat fünf Formate:

Format 1 -- WBS-Elementleistung: PV, EV, AC, BAC, EAC, VAC nach WBS-Element
Format 2 -- Organisationsleistung: die gleichen Daten nach Organisationselement geordnet
Format 3 -- Budgetprotokoll: eine Aufzeichnung aller PMB-Änderungen während der Berichtsperiode
Format 4 -- Personalbesetzung: tatsächliche und geplante Arbeitsstunden nach Disziplin
Format 5 -- Erläuterungen und Problemanalyse: der Narrativabschnitt zu wesentlichen Abweichungen, EAC-Begründung und Risikoerörterung

Das IPMDAR ersetzt das veraltete IPMR-Format und wird als strukturiertes JSON/XML-Paket übermittelt. Die IPMDAR-Schema-Validierung ist vor der Übermittlung erforderlich -- Tools, die nicht-konforme Schema-Ausgaben erzeugen, führen zur Ablehnung durch staatliche Datensysteme. Die Übermittlung erfolgt in der Regel über das Wide Area Workflow (WAWF)-System oder das EVM-Central-Portal des DoD, je nach dem im Programm festgelegten Datenempfangsbüro. Die Vertrags-CDRL (Contract Data Requirements List) legt die Fälligkeitstermine fest -- typischerweise 25 Tage nach Periodenabschluss für die monatliche Berichterstattung.

Die Tool-Auswahl sollte von drei Faktoren geleitet werden: staatliche Akzeptabilität (die EVMS-Systembeschreibung muss das Tool beschreiben und DCMA muss Einblick in seine Konfiguration haben), Integration mit bestehenden Finanz- und Terminierungssystemen (manueller Datenwiedereintrag zwischen Finanzsystem, Terminierungstool und EVMS ist eine Fehlerquelle und ein Überwachungswarnsignal) und organisatorische Expertise (ein Team, das Cobra gut kennt, übertrifft ein Team, das ein theoretisch überlegenes Tool mitten im Programm erlernt). Für neue Programmstarts rechtfertigt die Investition in die Cobra + Primavera P6-Integration durch die Reduzierung des monatlichen Berichterstattungsaufwands und die Qualität der erzeugten IPMDAR-Exporte sich selbst.

Häufig gestellte Fragen

Was ist Earned Value Management (EVM) und warum ist es bei Verteidigungsprogrammen erforderlich?

Earned Value Management ist eine quantitative Kosten-Termin-Integrationsmethodologie, die die Programmleistung misst, indem sie die budgetierten Kosten der geplanten Arbeiten (PV), die budgetierten Kosten der durchgeführten Arbeiten (EV) und die tatsächlichen Kosten der durchgeführten Arbeiten (AC) vergleicht. Die Differenz zwischen EV und AC ist die Kostenabweichung; die Differenz zwischen EV und PV ist die Terminabweichung. Das DoD verlangt EVMS-Compliance nach DoDI 5000.02 und DFARS 252.234-7002 für Erstattungsverträge über ca. 20 Millionen Dollar auf Programmebene. Die Anforderung resultiert aus jahrzehntelanger Erfahrung, die zeigt, dass Programme ohne strukturierte Kosten-Termin-Integration Überschreitungen konsequent spät entdecken, wenn Korrekturmaßnahmen am teuersten sind. Die EVMS-Compliance wird gegen die 32 Kriterien von ANSI/EIA-748 durch ein formales EVMS-Systembeschreibungs-Review und den IBR-Prozess validiert.

In welche Gruppen sind die 32 Kriterien von ANSI/EIA-748 gegliedert?

ANSI/EIA-748 gliedert die 32 EVMS-Kriterien in fünf Richtliniengruppen. Die Organisationsgruppe (Kriterien 1-5) umfasst WBS-Zerlegung, Organisationsstruktur, Integration von Kostenkonten und Identifikation der EVM-Anforderungen von Unterauftragnehmern. Die Planungs-, Terminierungs- und Budgetierungsgruppe (Kriterien 6-14) regelt, wie die Performance Measurement Baseline festgelegt wird, einschließlich Zeitplan-Netzwerklogik, Budgetzuweisung und Management Reserve. Die Gruppe Buchhalterische Überlegungen (Kriterien 15-18) befasst sich mit der Erfassung tatsächlicher Kosten und zeitlich gestaffelten Ist-Daten. Die Analyse- und Managementberichtsgruppe (Kriterien 19-27) umfasst Abweichungsanalyse-Schwellenwerte, EAC-Methoden und staatliche Berichtsformate. Die Revisionen- und Datenpflegegruppe (Kriterien 28-32) regelt, wie Baselines geändert, Budgetprotokolle gepflegt und rückwirkende Anpassungen kontrolliert werden. Die staatliche Überwachung konzentriert sich am intensivsten auf die Gruppen 2, 4 und 5, weil diese Gruppen die Verhaltensweisen aufdecken, die Überschreitungen verbergen.

Was ist das Integrated Baseline Review (IBR) und was löst eines aus?

Das Integrated Baseline Review ist ein formales staatliches Review der Performance Measurement Baseline des Auftragnehmers, das gemeinsam vom Vertreter des beauftragenden Beamten, dem Programmbüro und den Control Account Managern des Auftragnehmers durchgeführt wird. Ein IBR wird ausgelöst durch Vertragsabschluss über dem EVMS-Schwellenwert (typischerweise innerhalb von 180 Tagen nach Vertragsabschluss), eine wesentliche Vertragsänderung, die den Umfang oder den Wert materiell ändert, oder ein Neubasierungsereignis nach einem formalen Verstoß der Abschlussabweichung. Das IBR validiert, dass die Baseline technisch vollständig, terminerreichbar und ordnungsgemäß mit Ressourcen ausgestattet ist -- das bedeutet, dass Arbeitsumfang, Zeitplan und Budget intern konsistent sind und dass CAMs ihre Control Accounts verstehen und besitzen. Ein gescheitertes IBR führt zu einer Korrekturmaßnahmenanfrage und verzögert die Fähigkeit des Programms, zuverlässige EVM-Daten an die Regierung zu melden.

Was ist ein Control Account Manager (CAM) und welche EVM-Verantwortlichkeiten hat er?

Ein Control Account Manager ist die Person, die für die Verwaltung eines bestimmten Control Accounts -- der Schnittstelle eines WBS-Elements und einer Organisationseinheit -- innerhalb des EVMS verantwortlich ist. CAM-Verantwortlichkeiten umfassen die Definition des Arbeitsumfangs für ihren Control Account in einem Arbeitspaket oder Planungspaket, die Festlegung des zeitlich gestaffelten Budgets (die geplante Wertkurve), die Erfassung oder Überprüfung tatsächlicher Kosten, die Verdiensterfassung mit der genehmigten Bewertungsmethode (Fertigstellungsgrad, 0/100, 50/50, Level of Effort oder Meilensteine), die Analyse von Kosten- und Terminabweichungen gegen den Schwellenwert der 10%/10-Regel und die Erstellung schriftlicher Abweichungsanalyseberichte, wenn Abweichungen den Schwellenwert überschreiten. CAMs müssen auch für jeden Berichtszeitraum einen Estimate to Complete für ihr Konto erstellen und als primäre Fachexperten für ihren Umfang am IBR teilnehmen. In Softwareprogrammen besitzen CAMs typischerweise 3-8 Arbeitspakete über Softwarekomponenten, Integration und Test.

Was ist der To Complete Performance Index (TCPI) und wie wird er zur Validierung der EAC-Glaubwürdigkeit verwendet?

Der To Complete Performance Index ist das Effizienzverhältnis, das für die verbleibende Arbeit erforderlich ist, um ein Ziel (entweder BAC oder eine bestimmte EAC) zu erreichen. TCPI gegen BAC = (BAC - EV) / (BAC - AC). TCPI gegen EAC = (BAC - EV) / (EAC - AC). Wenn TCPI gegen BAC den aktuellen CPI deutlich übersteigt -- zum Beispiel CPI von 0,85 aber TCPI von 1,15 -- prognostiziert das Programm eine Leistungsverbesserung, die es nicht nachgewiesen hat, was die EAC unglaubwürdig macht. Staatliche Kostenkalkulator verwenden TCPI, um EACs anzufechten: Wenn TCPI 1,10 übersteigt, verlangen sie in der Regel eine detaillierte Bottom-up-Schätzung, um den Anspruch zu unterstützen, dass die Leistung sich verbessern wird. TCPI ist eine der ersten Metriken, die während der Contractor Performance Report-Analyse und während IBR-Walkthroughs der CAM-Estimate-to-Complete-Logik überprüft werden.

Was ist der Unterschied zwischen EAC, ETC und VAC im EVM-Reporting für Verteidigungsprogramme?

In der EVM-Terminologie ist EAC (Estimate at Completion) die voraussichtlichen Gesamtkosten aller genehmigten Arbeiten -- was das Programm von Anfang bis Ende kosten wird. ETC (Estimate to Complete) sind die erwarteten Kosten aller verbleibenden genehmigten Arbeiten. Die Beziehung lautet EAC = AC + ETC. VAC (Variance at Completion) ist die Differenz zwischen Budget at Completion und EAC: VAC = BAC - EAC. Ein negativer VAC zeigt eine Überschreitung bei Abschluss an. EAC wird vom Auftragnehmer im Contractor Performance Report Format 3 übermittelt; die Regierung entwickelt unabhängig eine IGCE und vergleicht sie mit der EAC des Auftragnehmers. Eine EAC des Auftragnehmers, die deutlich optimistischer als die IGCE ist, löst staatliche Überprüfung aus und kann zu einem formalen Anfechtungsgespräch führen.

Welche EVMS-Tools werden für das Reporting bei Verteidigungsprogrammen verwendet?

Das dominante EVMS-Tool-Suite für DoD-Programme ist Deltek Cobra, das nativ die Performance Measurement Baseline, das Management von Bewertungsmethoden, Abweichungsberechnungen und den CPR/IPMDAR-Export übernimmt. Oracle Primavera P6 ist die Terminautorität, die Cobra mit IMS-Daten versorgt. Microsoft Project mit EVM-Erweiterungen wird bei kleineren Programmen unter dem IPMDAR-Schwellenwert eingesetzt. Das IPMDAR-Format -- das 2019 das veraltete IPMR abgelöst hat -- ist ein strukturiertes JSON/XML-Schema, das an die DoD-Datensysteme übermittelt wird. Der Contractor Performance Report (CPR) hat fünf Formate: WBS-Leistung (Format 1), Organisationsleistung (Format 2), Budgetprotokoll (Format 3), Personalbesetzung (Format 4) und Erläuterungen/Problemanalyse (Format 5). Alle müssen gemäß Vertrags-CDRL innerhalb von 25 Tagen nach Periodenabschluss übermittelt werden.

Was ist eine Neubasierung und wann ist sie nach ANSI/EIA-748 zulässig?

Eine Neubasierung ist ein formaler Reset der Performance Measurement Baseline, genehmigt durch den beauftragenden Beamten, der die aktuelle PMB durch einen neuen zeitlich gestaffelten Budgetplan ersetzt. ANSI/EIA-748-Kriterien 28-32 regeln Baseline-Änderungen: Routineumfangsänderungen werden durch ein Budgetprotokoll per Vertragsänderung gehandhabt; Over-Target-Baselines (OTB) werden genehmigt, wenn die kumulative EAC des Programms den BAC überschritten hat und die ursprüngliche Baseline keine sinnvollen Managementinformationen mehr liefert. Ein OTB ist ein bedeutendes Ereignis -- es signalisiert dem Programmbüro und der Aufsichtsbehörde, dass die ursprüngliche Kostenschätzung des Programms nicht erreichbar war. DCMA und das Programmbüro verlangen in der Regel einen formalen Wiederherstellungsplan und ein Re-IBR, bevor ein OTB genehmigt wird. Auftragnehmer müssen zwischen formalen Neubasierungen (die eine Genehmigung des beauftragenden Beamten erfordern) und internem Replanning innerhalb des genehmigten Budgets (das nach Kriterium 27 ohne Genehmigung des beauftragenden Beamten zulässig ist) unterscheiden.

Wie wirkt sich die MIL-STD-881-Ausrichtung auf den WBS für Software-EVM aus?

MIL-STD-881 liefert Standard-WBS-Elementdefinitionen für Verteidigungssystemprogramme. Für softwareintensive Programme umfassen die relevanten Elemente Software (SE 03), zerlegt in Computer Software Configuration Items (CSCIs), die mit der Systemarchitektur übereinstimmen und die natürliche Ebene darstellen, auf der Control Accounts eingerichtet werden. Die Ausrichtung des EVMS-WBS an MIL-STD-881 stellt sicher, dass CPR-Berichte direkt dem vom Programmbüro verwendeten Programm-WBS zugeordnet werden, dass Kostendaten über Programmphasen hinweg konsistent aggregiert werden und dass IGCE-Vergleiche ein gemeinsames Wörterbuch verwenden. Programme, die nach Sprint oder Team statt nach CSCI organisiert sind, müssen Zuordnungstabellen bereitstellen, die ihre interne Struktur zum Zeitpunkt der Berichterstattung dem Vertrags-WBS gegenüberstellen.

Was sind häufige EVMS-Fehler bei softwareintensiven Verteidigungsprogrammen?

Die häufigsten EVMS-Fehler bei Softwareprogrammen umfassen: Gummi-Baseline -- die PMB wird rückwirkend angepasst, um Abweichungen zu absorbieren statt sie zu melden, ein Verstoß gegen Kriterien 28-32; Fertigstellungsgrad-Inflation -- CAMs melden optimistische Zahlen ohne objektiven Nachweis, was eine EV-Illusion erzeugt, die bei der Lieferung zusammenbricht; übermäßige LOE-Nutzung -- die Anwendung von Level-of-Effort-Bewertung auf diskrete Softwareaufgaben macht diese Aufgaben für die Abweichungsanalyse unsichtbar; entkoppelter Zeitplan -- der IMS wird separat vom EVMS gepflegt, sodass Terminabweichungen nicht im EVM-System erscheinen; und CAM-Unerfahrenheit -- die Zuweisung von EVMS-Control Accounts an nicht in EVM ausgebildete Ingenieure führt zu Berichtsqualitätsfehlern und ETC-Schätzungen, die nicht auf tatsächlichen Restarbeitsbewertungen basieren. Alle fünf Muster sind durch DCMA-Überwachung identifizierbar und werden regelmäßig in Programmüberschreitungsbenachrichtigungen nach dem Nunn-McCurdy-Amendment zitiert.