“Add a second approval; it is only a button.” A request can look small on screen while changing who may complete a transaction and what happens to pending items, reports and notifications. When assessing the cost of changing a software project's scope, you need an explanation of the change before deciding whether its price and timing make sense.
Start with the approved scope version, then record the requested difference and why it emerged. Avoid turning the discussion into an immediate judgment against the buyer or supplier: sometimes a gap in understanding appears, and sometimes the need genuinely changes. A change sheet separates these situations and helps compare alternatives that achieve the same purpose with different burdens.
First, which reference are we comparing against?
Attach the requirement number, acceptance scenario or approved drawing, identifying its version and date. “We agreed in the meeting” is hard to verify when each side remembers a different outcome. Put the previous and proposed descriptions together, adding a practical case that shows the difference without real customer data.
If current behavior contradicts a written acceptance condition, record the discrepancy and evidence. If the condition is ambiguous, record the clarification needed. Adding a role or workflow absent from the reference requires a clear impact statement. These are review categories, not an automatic judgment about who pays; that depends on the actual agreement and what the parties approve.
A fictional example: approving branch expenses
A maintenance company uses a portal where a branch manager submits an expense request for finance approval. After reviewing the demonstration version, the company asks for regional-manager approval before finance. This educational example does not describe a Nextwave project. The request goes beyond adding a button: who substitutes for an absent manager, and should existing requests enter the new workflow?
Compare applying the workflow to every request, limiting it to a particular expense category, or deferring it while using a documented manual procedure for a defined period. Do not assume the manual option is automatically suitable: examine its owner, control implications and workload, then record why it was accepted or rejected.
An impact sheet for the review meeting
| Item | Record before approval | Evidence that resolves it |
|---|---|---|
| Change boundary | The approval step, the categories it covers and what remains outside it. | A marked difference against the previous workflow. |
| Data and states | Open requests, rejection, resubmission and substitution during absence. | Test cases with expected outcomes. |
| Price | Analysis, development, testing and recurring expenses, with assumptions. | A detailed change quotation and its approval method. |
| Timing and acceptance | Affected delivery, buyer inputs and the person reviewing the result. | An updated plan and change acceptance conditions. |
This is an editorial template, not a list of services included in every contract. Mark unresolved items explicitly, assigning an owner and next step. A precise number based on an unknown input does not become a reliable estimate merely because it appears in a table.
Ask about additional work and its place in the schedule
Request an explanation of work created by the change: adjusting permissions, migrating a state, updating a message or testing an older workflow, for example. Then ask whether this work replaces a deferred item or adds to the current commitment. Removing a function to retain a deadline is a scope decision to record, not a way to hide the change's impact.
Atlassian's guidance places impact assessment before approval, including resources, cost and timing. The Scrum Guide allows scope renegotiation as learning develops without endangering the Sprint Goal or reducing quality. We draw on these principles; neither proves that your change is free or that a supplier's estimate is correct without explanation.
Do not close the request when the invoice arrives
After deciding, retain an approved version stating the chosen alternative, price or calculation method, timing and owner. At delivery, test the new request and an existing case that should remain unaffected, then inspect the resulting data. Name any outstanding exception instead of giving general approval that conceals remaining work.
If the issue concerns the original requirements, revisit the requirements guide. Before contracting, use the software quotation comparison sheet. A change discussion with Nextwave's custom software team starts with a previous reference and a verifiable difference, rather than a new feature name alone.
Sources and limits
The change control guide and Scrum Guide were opened on 4 November 2026. The example and sheet are editorial material, without market pricing or binding contract interpretation. AI tools assisted preparation, with meaning and source review.
