The Small Change That Rewrote the Project
“No problem” was the expensive part
“Can we add one more part number? It is almost the same as the existing one.”
That request sits at the centre of a manufacturing example shared on LinkedIn by Paul Vender. In his account, an automated CNC machining cell was progressing towards assembly when the customer requested an additional part. The initial assessment was a small fixture modification and roughly two days of work. The project manager agreed without a formal change or a complete impact review.
The post reports a different outcome: changes to clamping, sensors, PLC logic and safety validation, followed by a three week delay and $45,000 in additional cost. Those figures describe an unverified individual account, not an industry benchmark. The mechanism deserves attention even without treating the numbers as representative.
The technical answer was given before the project question had been asked.
A technical estimate becomes a business commitment
A customer request arrives during a meeting. An engineer considers the feature feasible. The project manager wants to preserve momentum. Someone says yes, and the team moves on.
Each person may believe they have agreed to something different. Engineering has confirmed feasibility. The customer has heard a commitment. Finance still expects the original margin. Planning still carries the original delivery date.
The new work enters the project, but its consequences do not enter the baseline.
Change itself is not the enemy. A useful late request may improve the equipment, remove an operating problem or protect the customer's business case. The failure is accepting that value without agreeing who pays for it, which obligations change and what evidence will prove completion.
A workable process must make a considered yes possible. Otherwise, teams will bypass it whenever a request feels urgent or commercially important.
The estimate stops at the first changed component
The person closest to the request often estimates the work they can see. A mechanical engineer sees a fixture. Controls sees an additional sequence. Quality sees another test condition.
None of those views necessarily includes the whole change.
An additional part variant may alter the gripping envelope, sensor coverage, fault recovery, cycle time and acceptance test. A released drawing may already be with a supplier. A component order may no longer be cancellable. Test equipment may need modification before the revised design can be verified.
The right question is not simply how long the first modification takes. It is what must now be reconsidered because that modification exists.
Impact review should follow the affected interfaces until it reaches an unchanged condition. That does not require every department to attend every review. It requires the right functions to confirm whether their obligations are affected.
Core Insight: The size of a change is the reach of its consequences, not the size of the first edit.
Helpful people have authority they were never given
A project manager may coordinate delivery without authority to give away margin. An engineer may approve a design without authority to change an acceptance criterion. A sales lead may negotiate a relationship without owning the installation window.
Yet a customer can reasonably interpret an unqualified yes from any of them as company agreement.
The practical control is a clear boundary between acknowledging a request, assessing it and authorizing it. “We can assess that” is different from “We will include that.” Teams need permission to make that distinction without appearing obstructive.
Approval authority should reflect the consequence. A reversible adjustment inside an agreed allowance can follow a short route. A change affecting safety, committed delivery, performance guarantees or commercial terms needs the appropriate owners involved.
A price threshold alone is insufficient. A low cost component can still invalidate a test or miss the only available shutdown window.
Core Insight: Authority to solve a technical problem is not authority to change the business commitment.
The change is approved, but the old promise survives
Even a signed change order can leave the project carrying two incompatible versions of reality.
The customer has accepted a new feature. Engineering updates the design. Procurement receives revised information. The schedule, test plan and milestone payment conditions remain unchanged because nobody explicitly owns those updates.
The team is then measured against the old promise while building the new scope.
A change is not fully incorporated when approval arrives. It is incorporated when affected people are working from the same revision of the obligation. That includes suppliers, installation teams and whoever will sign the acceptance record.
Preserve the original baseline for comparison. Record the approved revision and its reason. Keep the current forecast visible as well. These serve different purposes: what was promised, what was formally changed and what is now expected.
Core Insight: An approved change is unfinished until every affected commitment has been reconciled.
Count the cost without counting it twice
The reported $45,000 LinkedIn example is a prompt to investigate, not a number to copy into a business case.
Consider a separate illustrative calculation. A change requires 120 additional engineering and testing hours at a fully loaded rate of $150 per hour, plus $6,000 in supplier modification charges. The direct incremental estimate is $24,000.
Suppose the revised sequence also moves production availability by ten working days. At an assumed 200 units per day and $40 contribution per unit, that represents $80,000 of contribution timing exposure. It is not automatically lost profit. Production may be recovered later, demand may be served elsewhere, or the constraint may lie outside this equipment.
Do not add that exposure to the $24,000 and call the sum a confirmed loss. Identify what is incremental, what is deferred and what is genuinely unrecoverable.
Then assess resource displacement. Which other release loses the controls engineer or test slot? Additional labour and elapsed delay are different quantities. A modest amount of work can consume a scarce calendar window.
Put a decision between the request and the promise
Sarga II's proposed diagnostic approach starts with a recent change that surprised the team. Trace when the request arrived, what was said, when impact became visible and which commitments were updated. The gap between those events usually reveals the control that is missing.
For future requests, use a short change record with five practical elements:
Define the delta. Identify the current approved requirement and the exact addition, removal or substitution being requested.
Trace the impact. Check affected design interfaces, purchased material, supplier work, controls, safety, testing, documentation and site activities. Record unknowns rather than converting them into zero impact.
Offer a decision. Show options such as accepting revised cost and timing, exchanging existing scope, deferring the feature or declining it. Include the date by which the decision is needed.
Obtain authority. Record internal authorization and the required customer agreement under the contract. State which commercial and delivery terms change and which remain intact.
Incorporate and verify. Update controlled documents, orders, acceptance criteria and the schedule. Confirm that affected recipients received and understood the revision.
Scale the review to risk. Establish an agreed allowance for genuinely minor changes, with explicit exclusions. Keep urgent safety action available through a defined emergency route, followed by prompt documentation and reconciliation. Neither urgency nor a light process should mean an invisible commitment.
How the pattern plays out
The following is an illustrative, anonymized scenario, not a reported Sarga II client engagement.
A packaging equipment project is approaching factory acceptance testing. The customer requests a second container format and describes it as a tooling adjustment. Mechanical engineering agrees that the guide rails can be changed quickly.
A bounded impact review finds that the new container also affects sensor positioning, recipe selection, reject logic and the agreed test matrix. The revised test would use the same controls engineer booked for another customer's commissioning.
The team presents two options: retain the original acceptance date with the original format and add the second format later, or move acceptance and include both formats together. Each option states price, resource assumptions and acceptance conditions.
The customer chooses deliberately. The project may still become longer or more expensive. The difference is that the consequence is agreed before the work is treated as included.
A change can be visible without becoming a bureaucracy
A healthy project does not need a meeting for every edit. It needs a reliable answer to four questions: what changed, who authorized it, which commitments moved and who must act differently?
Engineers can distinguish feasibility from inclusion. Project managers can explain the options without inventing certainty. Customers can see the trade between capability, price and timing before choosing it.
Useful measures include the proportion of affected changes assessed before commitment, time from request to decision, work started before authorization and the time required to incorporate an approved change. Review exceptions to improve the process, not merely to assign blame.
The aim is a short, proportionate route from request to informed agreement. When that route works, the team can accept valuable change without quietly spending margin or promising the same delivery date twice.
Before the next “yes”
Take the last three customer changes that caused friction. Compare the first commitment with the first complete impact assessment. Then check when the schedule, price and acceptance criteria caught up.
If the business committed before it understood the consequences, another reminder to communicate better will not fix the pattern. The decision boundary needs to move.
If this pattern is familiar, we should talk. Visit www.sarga-ii.com.
Comments