Project Change Request Customer Approval Lag

A project team sends a customer a change proposal and waits. The work affects a near-term milestone, yet the decision may remain with the customer for weeks.

Project change request customer approval lag measures the elapsed time from a properly submitted decision-ready proposal to verified authorized customer acceptance or rejection. Define the start as the delivery of a complete agreed submission, since a draft estimate still circulating internally is not ready for customer decision.

Define the end as the approved form or person, because a casual yes in a meeting may not satisfy the contract authorization route. PMI integrated change-control description covers review, approval and communication of change decisions, and its vendor-project guidance illustrates that the end-user may not be the party authorized to approve added scope; these are project examples, and actual authority depends on the contract.

Identify the customer role, since a sponsor, procurement officer and site manager can have different powers. Link the proposal version, because price, work and delivery date may change during negotiation and each revised proposal needs a clear clock rule, and track supersession by recording whether age restarts under the stated rule when a new quote replaces the old one.

Preserve scope too, as a customer can approve only part of a requested change and the remainder should be recorded. Do not start wallet-bearing or reputationally significant work on an assumed approval, and track status, because awaiting customer review, clarification requested, internal revision and withdrawn are distinct states.

Pause rules carefully, since if the customer needs missing information from the vendor, the entire interval should not be blamed on customer delay. Show open age, because closed-only averages conceal proposals still awaiting a decision, and label whether calendar or working time is used, as customer teams in different time zones can have different workweeks.

Check the deadline, since the proposed decision may need to arrive before procurement or a contractual notice window. Record delivery, because a proposal saved in an internal system is not submitted to the authorized customer route, and an email sent to a wrong or inactive address cannot reliably start a customer-review clock.

Document authority by preserving customer approval evidence linked to the exact final terms, and handle conditional approval carefully, since subject to budget or legal review is not unconditional acceptance. Avoid pressure, because a slow decision does not let the vendor impose scope or price by default unless the actual contract says so, and protect customer trust by not implying approval where there is only discussion.

Separate internal time and implementation: estimating and routing the proposal before submission belong to vendor turnaround, and an approved change can still take months to deliver on another clock. If a customer rejects or withdraws the request, that is a final decision under the stated rule, not a slow approval, and a missing reply is not consent unless the applicable contract expressly establishes that mechanism, so record the exact clause; use counts and proposed values together with change priority for context, audit the request-to-plan trail, and use lag to follow up respectfully and keep project decisions from disappearing.