Changes after go-live,
and how to ask for them.

A contractor learns what it needs from its software in the first months of using it. By then the contract has already decided how changes are paid for, who makes them and how they are tested. Those terms shape the system in year three more than the feature list shaped it on day one.

Configuration and development are different requests

Configuration uses settings the system already has. A new field on a form, a different approval route, a document template, a pay type, a permission granted to a supervisor. It is quick, carries little risk, and is often something the firm's own administrator can do.

Development changes what the system does. A new calculation, a new screen, a report that joins records the product never joined, a link to another system. It needs somebody who can change the code, and it needs testing.

The distinction matters because the two are charged, scheduled and staffed differently. Ask for each request to be classified in writing before any work starts. A request quoted as development that turns out to be a setting is money spent on nothing.

The day-rate trap

Where development after go-live is priced at a day rate, each change becomes a purchasing decision. It needs a specification, an estimate, an approval and an order before anybody writes a line.

The effect is predictable. Small improvements are never raised, because the paperwork costs more than the problem. Larger ones wait for a budget. The software stays as it was on the day it went live while the business moves on, and the gap fills with spreadsheets and retyping.

A change that needs a purchase order to ask for is a change nobody asks for.

The incentives point the wrong way too. Under a day rate, the supplier earns more when a change takes longer. Under a fee that includes change, the supplier has every reason to build it cleanly once.

There are other arrangements: a prepaid budget of days, a yearly allowance, or change included in the fee. Whichever applies, write it into the contract before go-live. The first request is when the question gets expensive.

How to specify a change so it is built right

A change that disappoints was often built exactly as asked. The request described a screen when it should have described a job.

1. Describe the job, not the screen. Who does it, when, on what device, and what they are trying to decide.
2. Attach a real example: the paper form, the spreadsheet, the email the client sent. A real document answers questions nobody thought to ask.
3. Name the record that should exist afterwards, and who needs to find it in a year.
4. List the awkward cases. The night shift, the subcontractor, the job split across two cost codes, the week that crosses a month end.
5. Say who approves it and who will use it. They are often different people.
6. Write down what done looks like before anybody starts building.

A request written this way takes longer to send. It saves the second round of changes, which is the round that costs the most.

Test it in a sandbox, not on the live system

A sandbox is a separate copy of the system, ideally mirroring the live database, where a change is tried without touching a real order, timesheet or client. Testing on live means the first mistake lands on somebody's pay or a client's invoice.

Test with real names and a real week of records. Test on the device the change will be used on: a site manager's phone at the gate, not a director's desktop. Check the reports, exports and permissions around the change as well as the change itself, because that is where side effects surface.

One precaution deserves a deliberate decision. A sandbox refreshed from live holds real personal data, including pay rates and absence reasons. Decide whether it should be anonymised on refresh, and who can reach it.

Accepting a change, and switching it on

Acceptance belongs to the person who will use the change, not the person who asked for it. Hand them the written definition of done and let them try to break it.

When it passes, set a date for switching it on and tell the people it affects once, clearly. If it replaces an old way of working, close the old route on that date. A new process left running beside the old one is how field rollouts stall in week three, and a change is no different.

Keep a log of what changed and when. When an auditor or a client asks why a figure looks different after March, the log is the answer.

What to agree before you sign

The questions are short. The time to ask them is before the contract, not at the first request.

• Are changes after go-live included in the fee, capped, or charged at a day rate?
• Who decides whether a request is configuration or development?
• How is a request logged, acknowledged and tracked to done?
• Is a change built into the core platform, so it survives upgrades, or maintained separately for us?
• Is there a sandbox, and who refreshes it?
• Do we speak to somebody who can change the code, or somebody who passes the request on?

Where to start, on Monday

List every workaround running beside your current system. The spreadsheet next to it, the form filled in twice, the report rebuilt by hand each month. Each one is a change request nobody raised.

Take the three that cost the most hours, write each one up as a job rather than a screen, and send them to your current supplier. What comes back, how fast, and at what charge tells you whether the system can still move with the business.