Change request: making changes a decision instead of an argument

A change request is a documented proposal to alter something already agreed — scope, timeline, budget, requirements, or a system in production. Its purpose is not bureaucracy: it is to make sure that a change is decided by someone accountable, with the consequences visible, rather than absorbed by whoever happened to be asked.

The reason change processes fail is almost always the same. They are slower than the alternative. If logging a change takes two days and doing the work takes twenty minutes, people will do the work — and they are being reasonable. A change process has to be fast enough to be the path of least resistance.

What a change request needs to capture

• Who is asking, and who the change is ultimately for. These differ more often than expected.
• What is being requested, described concretely enough to estimate.
• Why — the reason behind it, which sometimes reveals a cheaper way to achieve the same thing.
• Priority, and specifically whether it can wait for the next phase.
• Impact on schedule, cost and other work, assessed by whoever will do it rather than by whoever wants it.
• What is displaced if it goes ahead. Every accepted change costs something already planned, and naming that is what makes a decision real.
• The decision — approved, rejected, deferred — with who decided and when.
• For anything touching a live system: the rollback plan and who is on hand if it goes wrong.

Always state what the change displaces. "This adds three days" invites a shrug; "this adds three days, which moves the launch or drops the reporting screen" produces a decision. Requesters are rarely trying to break the plan — they simply cannot see the trade-off unless you show it, and the person who shows it stops being an obstacle and becomes useful.

Running it fast

1. Use one intake route — a form, not messages to individuals — and publish it where people would otherwise ask.
2. Keep the form to the minimum: what, why, who, how urgent. Estimation is your job, not the requester's.
3. Acknowledge within a day, even if the answer is that it will be assessed next week. Silence is what drives people around the process.
4. Triage on a fixed rhythm — twice a week is enough for most teams — rather than whenever someone remembers.
5. Assess impact with the person who would do the work, in hours and in what gets displaced.
6. Decide at a named level: small changes by the project lead, anything above a stated threshold by the sponsor or client.
7. Record the decision against the request, including rejections and the reason, and tell the requester.
8. For approved changes, update the plan, the budget and the agreed scope document — a change approved but not reflected anywhere reappears as a dispute.
9. Review the log monthly: volume, common sources, how many were rejected. A high rejection rate usually means requirements were gathered badly.

Emergency changes need their own path

Some changes cannot wait for triage — a production fault, a regulatory deadline, a customer outage. Pretending otherwise means the process gets bypassed in exactly the situations where a record matters most. Define an emergency route explicitly: who can authorise it on the spot, what minimum information is captured at the time, and that it is documented retrospectively within a day. That way the audit trail survives the emergency, which is the whole point of having one.

In Ettex, the intake is a form in Ettex Forms — the four fields above plus a file upload for screenshots or specifications, with every submission landing timestamped in one searchable inbox and a live summary of what is outstanding. From there the approved changes become cards in Ettex Board with owners, due dates and the label that keeps them distinguishable from original scope; the register of requests with decisions and dates fits Ettex Records as a typed table with revision history; the scope document that must be updated afterwards lives in Ettex Docs with version history; and where a change alters price, the revision goes out through Ettex Invoices and is signed in Ettex Signature.

Plainly: Ettex has no change-control workflow. There is no routing by value or type, no approval chain, no automatic impact assessment, no linkage between a request and the plan, and no reminders when a request has been sitting untriaged. Forms collects, Records keeps the register, Board carries the work — the rhythm and the decisions are yours to run. For formal change control under a standard, use software built for it. Where the change affects a controlled document, it enters the document approval workflow rather than being edited in place.

Most self-inflicted incidents start as a change nobody reviewed. IT service desk software keeps that route next to requests and incidents, so the three are separated in the data rather than merged into one queue.

Why change processes get bypassed

• Slower than doing the work, which is a design failure rather than a discipline failure.
• No acknowledgement, so requesters assume nothing is happening.
• The form asks the requester to estimate effort, which they cannot do.
• Decisions made without saying what gets displaced.
• No emergency route, so urgent changes happen off the record.
• Rejections without reasons, which teaches people to route around the process next time.
• Approved changes never reflected in the plan or the scope document.
• The log never reviewed, so recurring sources of change are never addressed.

On construction and engineering work the same thing travels under a different name and with money attached. A variation order changes the scope and the price of an existing contract, which is why it needs a signature from someone who can commit funds, not only from whoever owns the schedule.

A change request works when the route is faster than the workaround, the impact names what gets displaced, and the decision is recorded either way — including the emergencies, written up the next day.