Change requests from an integrator: what to check before signing

Change requests are normal and most are legitimate. The problem is that they arrive individually, under time pressure, and get assessed on whether the change is needed rather than on whether the price and the premise are right.

1. Was this foreseeable when the contract was signed?

The central question. If the requirement was knowable at the time — it was in a document, it was discussed in workshops, it is standard for this kind of implementation — then it is a gap in the original scope rather than a change to it, and who pays is a negotiation.

If it genuinely arose from a business change since, it is a change and you should expect to pay.

2. What does it assume you will do?

Most change requests contain obligations on your side: data provided in a format, people available for testing, a decision by a date. Those are commitments, and missing one usually converts into a further change request later. Read them as carefully as the price.

3. Does the price include the retest?

A change to a built component means retesting what it touches. Many change requests price the development and omit the regression testing, the updated documentation, the retraining and the extra deployment. Ask what is in the number and what will come separately.

4. What does it do to the critical path?

A change that is cheap in money can be expensive in sequence. If it displaces something on the critical path, the cost is the date, and the date usually costs more than the change.

5. Is this the third one on the same topic?

Grouping matters. Three separate change requests around the same area of the solution often mean the original design was wrong, and the right conversation is about the design rather than about the third increment of a price.

6. What is the trend of the open balance?

Count the change requests raised against those closed, over time. A rising balance means scope is being agreed faster than it is being delivered, and the gap gets settled at the end — in cost, in date, or in scope quietly dropped.

7. Who benefits from the ambiguity?

If the original statement of work is vague in the area a change request covers, note who wrote the vagueness. Contracts drafted by the integrator will be clearer about what they will do than about what is included in doing it. That is not bad faith; it is how the document was written, and it is why the pre-signature review matters more than the post-signature argument.

8. Are you signing because of the date?

The most common reason a change request is approved without scrutiny is that refusing it stops work. That pressure is real, and it is also how the remaining phases get priced. Where the date is the reason, say so out loud in the approval, and take the commercial conversation separately rather than never.

The structural fix

Change requests should be reviewed by someone who is not responsible for the delivery date. The person under pressure to keep the project moving is not in a position to challenge the premise, and being unable to challenge the premise is how a fixed-price implementation becomes an open-ended one.