The Scenario

You are three weeks past your Preliminary Design Review. The design baseline is documented. Your team is deep into detailed design. Your supplier has started building test fixtures against your derived requirements. Then your customer sends an email: a system-level requirement has changed. Performance margin just went up. The compliance threshold just tightened. Or a use-case scenario was added that your architecture didn’t account for.

This happens on almost every program of meaningful complexity. The question is not whether it will happen, but whether your team has the process and tooling to handle it without chaos.

Here is the complete process — what to do, in what order, and why each step matters.

Step 1: Do Not Touch the Design Yet

This sounds obvious. It is violated constantly.

The moment a change request arrives — from a customer, from a systems engineer on your own team, from a supplier — the instinct is to start adapting. Someone opens the CAD file. Someone marks up the ICD. Someone sends a revised spec to the supplier.

None of that should happen until the change has cleared a formal Change Control Board (CCB) review. Informal change absorption is how programs end up with multiple versions of the truth, diverging baselines, and test campaigns that verify a design that no longer matches any approved requirement.

Freeze the current baseline. Document the incoming change request. Begin the formal process.

Step 2: The Change Control Board Process

A CCB is a structured review body — typically including systems engineering, program management, design leads, verification leads, and often a customer representative — that evaluates proposed changes to a baselined document or artifact before they are approved, deferred, or rejected.

For post-PDR changes, the CCB process typically runs as follows:

1. Change Request (CR) Submission The change must be formally documented. This is not an email thread. A CR document captures: what is changing, what is the source of the change, what is the proposed new requirement text or parameter, and what is the urgency justification.

2. Preliminary Impact Assessment Before the CCB convenes, systems engineering performs an initial triage: which requirements are directly affected, which design artifacts reference those requirements, and whether there are any immediate schedule conflicts (e.g., a test that is scheduled next week that would now need to be rewritten).

3. CCB Review The board reviews the CR and the preliminary impact assessment. They evaluate: Is the change technically feasible within the current architecture? What is the cost and schedule impact? Does the change require customer approval or does it fall within program authority? Is the change urgent enough to approve now, or should it be deferred to a future baseline revision?

4. Disposition The CCB issues one of three dispositions: approved, deferred, or rejected. An approved change moves into the formal change incorporation process. A deferred change is documented and held for a future baseline revision. A rejected change is formally closed with rationale.

5. Re-Baselining Once a change is approved, the affected documents are revised under configuration management control, version incremented, and re-released. Every downstream document that derives from the changed requirement must be flagged for review.

This is not bureaucracy for its own sake. The CCB process is what maintains the integrity of your design baseline as a single source of truth. Without it, you cannot answer the question: “What are we actually building?”

Step 3: Impact Assessment — Where Most Teams Fall Short

Impact assessment is the hardest part of post-PDR change management, and the place where most teams rely too heavily on memory and informal knowledge rather than structured traceability.

A requirements change at the system level does not affect only that requirement. It ripples downstream through a chain of derived requirements, design specifications, interface control documents, test cases, and supplier statements of work. A complete impact assessment must cover all four layers:

Derived Requirements Which child requirements were derived from the changed parent? If a system-level performance requirement changes, every allocated subsystem requirement that flows from it may need to be revisited. Did your allocation model assume margin that no longer exists?

Design Artifacts Which design documents, models, ICDs, or trade study conclusions were justified against the old requirement? A change in thermal requirement might invalidate a material selection. A change in interface timing might invalidate a bus architecture decision. These are not always obvious — they depend on how thoroughly your design was traced back to requirements at PDR.

Verification Artifacts Which test cases, test procedures, or analysis methods are written to verify the old requirement? A tightened performance threshold may mean existing test cases now have incorrect pass/fail criteria. An added use case may mean entirely new test cases must be written. Any test that has already been run to the old criteria must be evaluated for whether it needs to be repeated.

Supplier Requirements Which requirements have been flowed to external suppliers? If a supplier is building to a derived requirement that traces back to the changed parent, they must be notified formally. This triggers their own internal change process, and potentially impacts their schedule and cost commitments to you.

The output of a complete impact assessment is a structured change impact report that enumerates all affected artifacts by category, identifies which ones require rework versus which ones require only re-review, and assigns owners.

Step 4: The Cost Drivers of Late Requirements Changes

Program managers need concrete numbers, not vague warnings about risk. Here are the four primary cost drivers of post-PDR requirements changes:

Rework Cost Any design work already performed against the old requirement must be evaluated and potentially redone. At PDR+3 weeks, this is usually contained. At CDR-minus-two-months, rework costs can be severe.

Re-Verification Cost Verification activities are expensive. Rewriting test procedures, re-running environmental test campaigns, or repeating qualification tests represent real labor and facility time. For hardware-in-the-loop or environmental test, this is often the largest cost driver.

Schedule Impact Post-PDR changes rarely fit into existing schedule float. If the change requires a design iteration, the CDR timeline slips. If CDR slips, manufacturing release slips. Each downstream event moves.

Supplier Re-Negotiation If the change flows to a supplier, they have a legitimate basis to issue a Request for Equitable Adjustment. Supplier change orders carry not just the direct cost of their rework but also their overhead and margin on that rework. This is frequently the most expensive and least predictable element.

A credible impact assessment quantifies all four of these — even as rough order-of-magnitude estimates — before the CCB votes on approval.

Step 5: Communicating Change Impact to Customers and Program Managers

This is where technical discipline intersects with stakeholder management, and where many systems engineering teams lose credibility by handling it poorly.

The wrong approach: defensive posturing, vague statements about impact, or requests to “hold on while we figure it out.” Customers and PMs interpret vagueness as a loss of control.

The right approach: lead with the impact summary, state your confidence level, and propose a process for working through it together.

A clear change impact communication includes:

  • What changed: the specific requirement, the old text, the new text or parameter
  • What is affected: a structured list of downstream artifacts by category
  • Cost and schedule estimate: even rough, with explicit confidence bounds
  • What you need from the customer: timeline flexibility, contract adjustment, or a decision on scope trade
  • What you will deliver and when: the change incorporation plan with milestones

A customer that sent you a change request already expects impact. They do not expect surprise. Your job is to make the impact legible and manageable, not to minimize it or fight it.

How Modern Tooling Changes This Calculus

The process described above is sound. The execution bottleneck, in most organizations, is the impact assessment step. Manually tracing a changed requirement through a requirements document, a design specification, an ICD, a test plan, and a supplier SOW — especially when each lives in a different document in a different tool — takes days. By the time the impact assessment is complete, informal changes have already started propagating anyway.

This is where graph-based traceability fundamentally changes the economics of post-PDR change management.

Flow Engineering models requirements, design elements, test cases, and system interfaces as nodes in a connected graph. Every traceability link between a requirement and a downstream artifact — whether that is a derived child requirement, a design specification clause, a test case, or an interface definition — is a live edge in that graph. When a requirement changes, the graph immediately surfaces every node that is downstream of it.

In practice, this means a systems engineer can open the changed requirement in Flow Engineering, trigger an impact propagation query, and receive a structured list of every affected artifact in seconds: which child requirements were derived from it, which design elements reference it, which test cases verify it, and which supplier-facing documents include it. Each artifact is shown with its current status — whether it has been reviewed since the last baseline, whether it was already flagged as needing attention.

This collapses the preliminary impact assessment from a multi-day manual exercise into a same-day deliverable. The CCB can meet with a complete impact picture. The cost and schedule estimates are grounded in an actual artifact count, not a guess. The customer communication is backed by specific data rather than hedged language.

Flow Engineering is purpose-built for hardware and systems engineering teams that live in this kind of connected requirement-to-design-to-test-to-supplier environment. It does not attempt to replace configuration management systems or document vaults — it sits at the traceability layer, keeping the connections between artifacts live and queryable as the program evolves.

For teams that are still managing traceability through a manually maintained Requirements Traceability Matrix in a spreadsheet, a post-PDR change event is the most direct proof-of-concept for why that approach breaks down at scale. An RTM can tell you what was linked at the moment the spreadsheet was last updated. A live graph tells you what is linked right now.

Honest Assessment

Post-PDR change management is a process discipline problem before it is a tooling problem. No tool compensates for a program that is not running a real CCB, not maintaining baseline configuration control, or not flowing requirements to suppliers in a traceable way. The process described here is the foundation.

Within a sound process, tooling determines execution speed. A team managing traceability manually will execute the right process slowly, with high error rates on impact completeness. A team using graph-based traceability will execute the same process faster, with higher confidence that the impact assessment is complete.

The practical decision: if your program is complex enough to have a CCB and a supplier chain, it is complex enough to justify structured traceability tooling. The cost of a missed downstream impact — a supplier builds to an obsolete requirement, a test campaign runs to the wrong pass criteria, a CDR is held against a partially-changed design — exceeds the cost of the tooling on the first occurrence.

Handle the change formally. Assess it completely. Communicate it clearly. And make sure your tools can keep up with the speed the program actually runs at.