What is a change request?

Change request: definition and purpose

A change request arises when it becomes clear during a project that something different or more is wanted than was agreed—an additional function, a changed process or another system that is to be connected. It makes changes visible instead of letting them slip into implementation on the side.

It serves to keep scope, costs and deadlines under control. Without a clear procedure, “scope creep” occurs: the scope grows gradually, budget and schedule start to slip, and in the end both sides argue about what was actually agreed. With fixed-price projects, this risk is especially high.

How the procedure works

The process is usually simple: the request is described, with a reason and urgency. The contractor assesses effort, cost, schedule and effects on other functions. The client decides whether to approve, postpone or reject. Only then does implementation begin, and the new status is documented.

Not every change is a change request: an error where the software deviates from what was agreed is a defect and is fixed, not billed again. In agile projects, prioritization in the backlog partly replaces the procedure: new requests go into the backlog, and in return something else moves back or drops out.

• Description of the requested change with reasons
• Impact on functional scope and other areas
• Effort estimate in hours or days, including cost
• Impact on schedule and acceptance
• Decision with date and name of the approver

Real-world example: a configurator for a carpentry shop

A carpentry shop has an online furniture configurator developed for a fixed price. Midway through the project, the managing director realizes that orders should be passed directly to the accounting software. That was not in the functional specification, and the interface is no small detail.

The developer records the request as a change request, estimates two days of extra effort and points out that go-live moves back by a week. The carpentry shop approves the change. Both sides know what was agreed in addition, and acceptance goes ahead without discussion.

Common mistakes and imple­menta­tion

Typical mistakes are verbal promises, changes squeezed in “just quickly” without naming the consequences for schedule and testing, and no responsible person on the client side to approve them. It helps to describe the procedure already in the quote: who submits changes, how quickly they are assessed and which rates apply.

Nano Concepts anchors the change process in the quote, assesses requests transparently and records approvals in writing, so that scope, price and schedule remain traceable at all times. That leaves room for new ideas without the project getting out of hand. Clients keep control over costs, and contractors avoid unpaid extra work.