A change request process for software projects

Direct answer

A change is fine; an unrecorded change is the problem. Every software project changes as people see working screens and realise what they actually need. What creates disputes is not the change itself but the fact that nobody wrote down what it was, what it affected and who agreed. A change request process is a short routine that does that: describe the change, say what it does to scope, price and order of work, get a named person to approve or decline, and file the result. It can fit on one page. Agree it before the build starts, alongside the scope checklist, and it becomes the way both sides keep the original agreement true. For how the commercial model shapes this, see fixed price vs time and materials.

What counts as a change

Define the term so the same event is not argued about each time. A useful working definition is anything that alters what was agreed in the scope document: a new feature, a different behaviour for an existing one, an extra user type, another integration, a new report, a different data source. Clarifications of how the agreed feature should work are usually not changes, provided they follow what the scope already implies. Where the boundary is unclear, the process below is how you decide, in writing, rather than after the work is done.

The request form

The form should be short enough that people actually use it. Anyone with authority on your side can raise a request, and the same fields apply every time.

• A short title and a description in the requester's own words
• The business reason: what problem this solves or what decision it supports
• Who asked, and on what date
• Which agreed scope item or screen it relates to
• How urgent it is and why, including any external date it depends on
• What should happen if it is not done

Impact on scope, price and order

Before anyone approves a request, the supplier states its effect on three things. This is the step that makes the process worth having, because it turns an informal wish into a visible trade-off.

• Scope: what is added, altered or removed, and whether any agreed item is affected
• Price: what the change costs under the contract you agreed, stated in writing before work begins
• Order: what it delays or displaces if it is done now, and what happens if it waits until later
• Risk: any new dependency, technical constraint or testing burden it introduces

Approval

Name who can approve on your side, ideally one person, with a named backup. Approval is a recorded yes, no or later, with the date. Avoid verbal approval in a meeting that no one writes down; a short message confirming the decision is enough. If different people can approve different kinds of change, for example budget on one side and functional on another, write that down up front. The role of the person who decides is covered in client-side product owner role.

Bug versus change

This distinction causes more friction than any other. A bug is where the delivered work does not do what the agreed scope and acceptance criteria said it would do. A change is where the work does what was agreed but you now want something different. Decide who classifies a disputed item and how. The cleanest method is to compare against the written scope and acceptance criteria: if the behaviour is described there and the software departs from it, it is a bug; if the behaviour was never described, it is a change. That is another reason to write testable criteria in advance.

The parking lot

Not every idea deserves a formal request today. Keep a parking lot: a simple list of ideas raised during the project that are neither approved nor rejected. Review it at agreed points, such as before a release or at the end of a phase. Many items resolve themselves once real usage begins, and the rest can be turned into proper requests with clear reasons. The parking lot protects the current work from constant interruption without making anyone feel ignored.

The record

Keep one running change log that both sides can see. Each entry shows the request, the impact statement, the decision, the date and who decided. At the end of the project the log is the honest history of how the software differs from the original scope and why. It is also the best input for the next phase of work and for any later handover, alongside the documents described in software handover checklist.

Ending scope arguments

Most scope disputes share one shape: two people remember an agreement differently. The process removes the shape. When a disagreement appears, the questions are simple and answerable from the record: was this in the agreed scope, was a change request raised, and was it approved. If the answers are recorded, the discussion is short. If they are not, treat the gap as a lesson about the process, agree what to do about this instance fairly, and tighten the routine for next time.

How LATYNEX works on this

We agree one scope and one price in writing before work starts, and any later change is stated in writing with its effect on price and order before it is done. We do not publish a rate card for changes; they are quoted against your specific scope. See Web Application Development for how projects are delivered.