Verteidigungsmarkt-Playbook, Teil 4: Vertragsausführung nach Zuschlag — EVM, Meilensteinprüfungen und Sustainment

Teil 1–3 hat den Pfad vom Beschaffer-Discovery über das RFP-Capture bis zur Pricing- und Compliance-Posture beschritten. Teil 4 schließt die Serie damit ab, was nach Eintreffen des Zuschlagsschreibens geschieht — die Vertragsausführungsdisziplin, die entscheidet, ob ein Programm pünktlich, im Budget und mit einer Past-Performance-Aufzeichnung endet, die den nächsten Bid gewinnt. Earned Value Management, Überstehen von Meilensteinprüfungen, Engineering-Change-Proposal-Workflow, Konfigurationsmanagement-Disziplin, CPARS-Bewertungen, Wachstum durch Sustainment-Verträge und der Lessons-Learned-Zyklus, der einen Vertrag schließt, während er das nächste Capture speist.

Der Pillar-Rahmen ist in Der vollständige Leitfaden zur Verteidigungsbeschaffung; der vorherige Bid-to-Award-Bogen in Vom RFP zum Vertrag.

Schritt 1: Vom Zuschlag zum Kick-off

Das Zuschlagsschreiben ist nicht die Ziellinie — es ist der Beginn des 90-Tage-Fensters, das den Rest des Programms prägt. Anbieter, die den Zuschlag als Sieg behandeln und im ersten Quartal langsamer werden, verbringen die nächsten zwei Jahre mit der Erholung. Anbieter, die ab Woche eins sprinten, setzen eine Baseline, die sich über die Vertragslaufzeit verstärkt.

Die First-90-Days-Disziplin:

Vertrags-Baseline-Lock-in. Die technische Baseline, die Kosten-Baseline und die Zeitplan-Baseline werden unterzeichnet, versionskontrolliert und an jeden Stakeholder verteilt. Mehrdeutigkeiten in der Vertragssprache werden der Vergabestelle vorgelegt und schriftlich gelöst — niemals aufgeschoben. Die Baseline ist die Wahrheit des Vertrags; alles Spätere wird daran gemessen.

Integrated Baseline Review (IBR). Für Programme über der EVM-Schwelle ist das IBR der formelle Regierungs-Review der integrierten Kosten-Zeitplan-Baseline innerhalb von etwa 90–180 Tagen nach Zuschlag. Das IBR validiert, dass die Baseline realistisch, erreichbar und angemessen ressourciert ist. Ein gescheitertes IBR löst Re-Planning aus; ein bestandenes IBR setzt den Messrahmen für den Rest des Programms.

Team-Mobilisierung. Das Capture-Team rollt aus; das Execution-Team rollt ein. Die Übergabe ist strukturell — Capture-Phasen-Entscheidungen, Kundenbeziehungs-Geschichte, technische Verpflichtungen, Risikoregister — alles überträgt sich schriftlich, nicht im Flurgespräch. Ein Programm, das beim Übergang Capture-Wissen verliert, verliert sechs Monate beim Wiederausfechten bereits getroffener Entscheidungen.

Sicherheitsfreigabe-Staging. Für klassifizierte Arbeit ist die Freigabeverarbeitung die lange Stange. Ingenieure ohne Clearance-Status können klassifizierten Code nicht berühren, an klassifizierten Sitzungen nicht teilnehmen oder freigegebene Einrichtungen nicht betreten. Freigabeanträge, die am Tag eins eingereicht werden, schließen die Verarbeitung in Monat vier bis neun ab; Ingenieure, die durch Freigabe-Verzögerungen zurückgehalten werden, kosten echten Zeitplan. Siehe Sicherheitsfreigabe für Software-Teams.

Aufbau klassifizierter Arbeitsplätze. SCIFs, freigegebene Entwicklungsumgebungen, klassifizierte Netzwerkverbindungen, Akkreditierung der Engineering-Umgebung selbst — diese haben Vorlaufzeiten in Monaten. Das Programm, das sie in Woche eins plant, hat sie in Monat vier; das Programm, das sie aufschiebt, fügt sie später dem kritischen Pfad hinzu.

Schritt 2: Earned Value Management (EVM)

EVM ist die Kosten- und Zeitplandisziplin, die Regierungsbeschaffer nutzen, um die Programmgesundheit quantitativ zu messen. Es ist über Vertragswertschwellen verpflichtend (ANSI/EIA-748-Konformität ist typischerweise über ungefähr $20M kostenerstattungsfähig erforderlich, mit nationalen Variationen) und unterhalb davon als Management-Disziplin unabhängig vom Mandat empfohlen.

Die drei Metriken, die alles antreiben:

BCWS (Budgeted Cost of Work Scheduled) — der Plan. Was das Programm bis zu diesem Datum zu geben plante, akkumuliert über die Work-Breakdown-Structure. Die zeitphasierte Baseline.

BCWP (Budgeted Cost of Work Performed) — der Earned Value. Der Budgetwert der tatsächlich abgeschlossenen Arbeit, gemessen gegen dieselbe Baseline. Abgeschlossene Arbeit verdient ihren Budgetwert unabhängig davon, was sie kostete.

ACWP (Actual Cost of Work Performed) — die Ausgabe. Was das Programm tatsächlich für die geleistete Arbeit bezahlt hat.

Aus diesen drei Werten die beiden Indizes, die Beschaffer zuerst lesen:

CPI = BCWP / ACWP (Cost Performance Index). Über 1,0 bedeutet unter Budget; unter 1,0 bedeutet Kostenüberschreitung. CPI unter 0,9, anhaltend über Berichtsperioden, löst Aufmerksamkeit der Vergabestelle aus. CPI unter 0,8 löst Re-Baseline-Gespräche aus.

SPI = BCWP / BCWS (Schedule Performance Index). Über 1,0 bedeutet vor dem Zeitplan; unter 1,0 bedeutet zurück. SPI unter 0,9 löst Zeitplan-Recovery-Planung aus.

Die Berichtskadenz, die Beschaffer tatsächlich lesen: monatlicher Cost/Schedule Status Report (CSSR) oder Integrated Program Management Report (IPMR), mit Varianzerklärungen für jedes Element, das außerhalb der Schwelle tendiert. Beschaffer lesen die Zahlen nicht isoliert — sie lesen die Trendlinien und die Glaubwürdigkeit der Varianzerklärungen. Ein CPI von 0,92 mit einem kohärenten Recovery-Plan liest sich besser als ein CPI von 0,98 ohne Narrativ.

Wenn EVM wirklich optional ist (Firm-Fixed-Price unterhalb der Schwelle, Time-and-Materials mit kleinem Wert), ist es trotzdem die richtige Entscheidung, es intern zu betreiben. Die Disziplin selbst fängt Probleme früh ab; die Daten sind in Anspruchs- oder Kündigungsszenarien unbezahlbar.

Schritt 3: Meilensteinprüfungen — PDR, CDR, TRR überstehen

Verteidigungsprogramme haben formelle technische Reviews, in denen die Regierung entscheidet, ob die Fortsetzung der Arbeit autorisiert wird. Die drei, die für softwarelastige Programme am meisten zählen:

Preliminary Design Review (PDR). Die Architektur wird zur Regierungsprüfung präsentiert — Hauptschnittstellen, Hauptdesignentscheidungen, Hauptrisikobereiche. Die Regierung entscheidet, ob das vorläufige Design reif genug ist, um detailliertes Design zu autorisieren. Erforderliche Artefakte: Systemspezifikation, Interface Control Documents, vorläufige Designdokumentation, Risikoregister, Anforderungs-Rückverfolgbarkeitsmatrix.

Critical Design Review (CDR). Das detaillierte Design wird vor Fertigung oder Full-Scale-Coding präsentiert. Die Regierung entscheidet, ob das Design reif genug ist, um Build/Code zu autorisieren. Erforderliche Artefakte: detaillierte Designdokumente, aktualisierte Schnittstellenspezifikationen, Testpläne, Konfigurations-Baseline, alle PDR-Aktionspunkte geschlossen.

Test Readiness Review (TRR). Das System wird als bereit für formale Qualifikationstests präsentiert. Die Regierung entscheidet, ob die Testkampagne autorisiert wird. Erforderliche Artefakte: Testpläne, Testverfahren, Testumgebungsbereitschaft, frühere Testergebnisse, Exit-Kriterien.

Was Review-Board-Kritik tatsächlich bedeutet: Review-Board-Mitglieder werden dafür bezahlt, Probleme zu finden. Null Probleme zu finden bedeutet, dass das Board seine Arbeit nicht gemacht hat. Anbieter, die jeden Aktionspunkt als Niederlage behandeln, erschöpfen sich; Anbieter, die die Aktionspunkte als Beitrag des Boards zur Programmqualität behandeln, schließen sie effizient und gehen weiter.

Wann zurückdrücken vs. wann einknicken: drücken Sie zurück, wenn die Kritik des Boards auf einem Missverständnis des Designs beruht — präsentieren Sie klärendes Material und bitten Sie um Neuüberlegung. Knicken Sie ein, wenn die Kritik eine echte Lücke identifiziert, auch wenn es Zeitplan oder Nacharbeit kostet. Zurückzudrücken bei echten Lücken konvertiert sie später zu Discovery-Items zu höheren Kosten.

Schritt 4: Engineering Change Proposals (ECP)

Jedes langlaufende Programm erlebt Wandel — aufkommende Anforderungen, Technologie-Refresh, Bedrohungsentwicklung, Umfangsentdeckungen. Der vertragliche Mechanismus, der Wandel handhabt, ist das Engineering Change Proposal.

Klasse-I-ECPs betreffen die Vertrags-Baseline — Kosten, Zeitplan oder vertraglich vereinbarte Leistung. Sie erfordern formelle Vertragsänderung, Regierungsgenehmigung und (typischerweise) Verhandlung über Preis- und Zeitplan-Auswirkung. Klasse-I-ECPs sind Umsatzereignisse für den Auftragnehmer; sie erweitern aber auch die Exposition, wenn der Preis falsch ist.

Klasse-II-ECPs sind intern — sie ändern Implementierungsdetails, die die vertraglich vereinbarte Leistung, Kosten oder Zeitplan nicht beeinflussen. Sie erfordern Zustimmung des Konfigurations-Kontrollgremiums, aber keine Vertragsänderung. Klasse-II-ECPs halten Programme agil.

Das Change-Control-Board ist dort, wo ECPs evaluiert werden. Das Board umfasst Engineering, Programm-Management, Verträge, Qualitätssicherung und (für Klasse I) den Regierungsvertreter. Die Disziplin des Boards verhindert auf der einen Seite, dass Scope-Creep Margen zerstört, und schützt Anbieter auf der anderen Seite davor, unkompensierte Arbeit zu leisten.

Wie man ECPs so abgrenzt, dass sie Umsatz hinzufügen, ohne Beschafferbedenken auszulösen: jedes ECP an eine dokumentierte Anforderungsquelle binden — eine Kundenanfrage, ein Bedrohungs-Update, einen Testbefund. ECPs aus Auftragnehmer-Bequemlichkeit lesen sich als Scope-Padding; ECPs aus Kundenbedarf lesen sich als professionelle Antwort auf sich entwickelnde Nachfrage. Die Formulierung auf dem Deckblatt zählt.

Schritt 5: Konfigurationsmanagement auf Vertragsniveau

Konfigurationsmanagement-Disziplin (CM), ausgerichtet an MIL-STD-973 oder ISO 10007, ist das Rückgrat jedes langlaufenden Verteidigungsprogramms. CM, das nur als Schlagwort existiert, scheitert beim ersten Audit; CM als Engineering-Praxis übersteht die Lebenszeit des Vertrags.

Die Disziplinen:

Baseline-Lock. Drei Baselines existieren parallel — funktional (auf Systemspezifikationen zugewiesen), allocated (auf Subsystem-Specs heruntergebrochen) und Produkt (die As-Built-Konfiguration). Jede ist versionskontrolliert und audit-rückverfolgbar.

Change-Impact-Analyse. Jede vorgeschlagene Änderung wird auf Auswirkung über die betroffenen Baselines analysiert. Eine Änderung an einer Subsystem-Spec löst Impact-Analyse auf jeden abhängigen Test, jedes Dokument und jede Schnittstelle aus.

Rückverfolgbarkeit von Anforderung zu Lieferung. Jede vertraglich vereinbarte Anforderung verfolgt vorwärts zum Designelement, das sie umsetzt, zum Test, der sie verifiziert, und zum Lieferartefakt, das sie demonstriert. Audits, die gebrochene Rückverfolgbarkeit finden, finden systemisches CM-Versagen.

Konfigurations-Audits — Funktional und Physisch. FCA verifiziert, dass das System gemäß der allocated Baseline funktioniert; PCA verifiziert, dass das gelieferte Produkt der dokumentierten Produkt-Baseline entspricht. Beide sind formelle Regierungs-Audits; beide haben Fehlermodi, die Monate kosten.

Schritt 6: Past-Performance-Aufbau

Die während der Ausführung aufgebaute Past-Performance-Aufzeichnung ist das wichtigste einzelne Asset für den nächsten Bid. In den USA ist die formelle Aufzeichnung CPARS (Contractor Performance Assessment Reporting System); andere Nationen haben analoge Systeme. Die CPARS-Bewertungen treiben das Past-Performance-Scoring in zukünftigen Evaluierungen — manchmal mit 25–40% der technischen Evaluierung gewichtet.

Die Hebel, die Anbieter tatsächlich kontrollieren:

Qualität des Produkts oder Service. Erfüllt die Lieferung die Spezifikation? Wird sie bei erster Einreichung oder nach Nacharbeit akzeptiert? Werden Defekte im Test oder im Feld entdeckt?

Zeitplan. Werden Meilensteine erreicht? Wenn Verschiebungen auftreten, werden sie früh mit glaubwürdigen Recovery-Plänen kommuniziert?

Kostenkontrolle. CPI-Trends, Varianzmanagement-Disziplin, Genauigkeit der Kostenprognose.

Management. Reaktionsfähigkeit des Programmmanagers, Eskalationsdisziplin bei Problemen, Kundenbeziehungsqualität.

Small Business / Subkontrahierung / Regulatorisch. Einhaltung von Subkontrahierungsplänen, Small-Business-Zielen, regulatorischen Verpflichtungen.

Schritt 7: Sustainment und Wachstumspfade

Der Vertrag, der die Plattform liefert, ist selten der Vertrag, der die Rechnungen bezahlt. Sustainment — die mehrere Jahrzehnte umfassende Betriebs-, Wartungs-, Upgrade- und Refresh-Phase — repräsentiert typischerweise 60–80% der Lebenszeitkosten eines Systems. Anbieter, die sich ab Tag eins für Sustainment positionieren, reiten auf dem Schwungrad; Anbieter, die das nicht tun, verlieren die Sustainment-Arbeit an Amtsinhaber.

Die Wachstumspfade:

Performance-Based Logistics (PBL). Der Anbieter wird für Ergebnisse (Verfügbarkeit, Einsatzbereitschaft) bezahlt, statt für Teile oder Arbeitsstunden. PBL-Verträge belohnen Anbieter, die Sustainment-Kosten reduzieren — starke Anreizausrichtung.

Contractor Logistics Support (CLS). Der Anbieter erbringt definierte Logistikdienste — Reparatur, Versorgung, Training, technische Unterstützung — unter einer Sustainment-Vertragsstruktur.

IDIQ-Task-Orders. Indefinite-Delivery-, Indefinite-Quantity-Verträge geben der Regierung ein vorverhandeltes Vehikel, um Task Orders dagegen auszustellen. Eine IDIQ-Position ist beschaffungsstarker Hebel; Task Orders fließen ohne Re-Wettbewerb.

Follow-on-Ausschreibungen. Der Amtsinhaber auf dem aktuellen Vertrag hat strukturelle Vorteile beim nächsten — vergangene Leistung auf genau dem Auftrag, tiefe Kundenbeziehungen, gesunkene-Kosten-Vertrautheit. Ein Follow-on zu verlieren ist schmerzhafter als einen initialen Bid zu verlieren.

Das Schwungrad: einzelner Vertrag → starkes CPARS → IDIQ-Position → Task-Order-Strom → Multi-Award-Contract-(MAC)-Vehikel → Portfolio aus Programmen. Jede Stufe verstärkt. Anbieter, die auf der Einzelvertrags-Ebene stecken bleiben, schuften; Anbieter, die die MAC-Vehikel-Ebene erreichen, skalieren. Siehe Battle-Tested vs. Lab-Tested für das Glaubwürdigkeits-Schwungrad, das diesem kommerziellen parallel verläuft.

Schritt 8: Closeout — Finales Audit, Lessons Learned

Die Closeout-Phase ist unglamourös und strukturell wichtig. Ein Vertrag, der sauber schließt, bewahrt die Past-Performance-Aufzeichnung; ein Vertrag, der sich über Jahre mit ungelösten Problemen hinzieht, beschädigt sie.

Die Disziplin:

Incurred-Cost-Submission. Für kostenerstattungsfähige Verträge schließen die finalen indirekten Sätze und die Incurred-Cost-Submission das finanzielle Bild ab. Einreichungen, die sich in Jahre nach dem Vertragsenddatum hinziehen, ziehen Audit-Aufmerksamkeit und Rückstellungsverpflichtungen nach sich.

Finale Rechnung und Zahlung. Die finale Rechnung wird mit aller geforderten Dokumentation eingereicht; die Zahlung der Regierung schließt die finanzielle Baseline.

Contract-Closeout-Paket. Property Accountability gelöst, klassifiziertes Material gemäß Sicherheitsplan entsorgt, Lieferungen formell akzeptiert, Garantien dokumentiert, geistige Eigentumsrechte bestätigt.

Interne Lessons Learned. Was funktionierte, was scheiterte, was echtes Geld kostete, was anders gemacht würde. Das Lessons-Learned-Dokument speist das nächste Capture — es ist das Bindeglied zwischen der Erfahrung dieses Vertrags und dem Bid des nächsten Vertrags. Anbieter, die Lessons Learned überspringen, wiederholen ihre Fehler; Anbieter, die sie institutionalisieren, verstärken ihre Vorteile.

Abschluss der Serie — und der Bibliothek

Vor vier Teilen eröffnete diese Serie mit der organisatorischen Logik des Verteidigungsbeschaffers. Wir kartierten die ineinandergreifenden Büros und Entscheidungs-Rhythmen des Beschaffers. Wir arbeiteten die RFP/RFI-Mechanik von der Ausschreibung bis zur Angebotsmechanik durch. Wir bauten die Preis- und Compliance-Posture, die eine Evaluierung übersteht. Wir schließen hier mit der Ausführungsdisziplin, die ein Zuschlagsschreiben in ein sustainment-fähiges Geschäft konvertiert.

Dieser Artikel schließt auch einen größeren Bogen. Die Corvus-Engineering-Bibliothek umfasst nun fünf Engineering-Pillar-Paare (C2-Systeme, Verteidigungs-Datenfusion, KI in der Verteidigung, NATO-Interoperabilität, Cybersicherheit in der Verteidigung) plus dieses geschäftsseitige Pillar-Paar — den Vollständigen Leitfaden zur Verteidigungsbeschaffung gepaart mit diesem vierteiligen Verteidigungsmarkt-Playbook. Sechs Pillar+Serien-Paare, vierundzwanzig Implementierungs-Walkthrough-Teile und die umgebenden Engineering-Essays, die sie kontextualisieren. Die Architektur der Bibliothek ist vollständig.