Software projects
Change control for custom software projects
Every custom software project changes once people see working screens. That is healthy. Problems start when changes are agreed in passing and nobody records their cost. Change control is the lightweight discipline that prevents this.
Start with a scope you can test
A good statement of work describes what the system must do in terms of acceptance criteria — for example, “a reseller sees only their own price level and balance” — rather than vague goals. Anything not covered by the criteria is, by definition, a change.
A simple change process
- Request: anyone can raise a change, in writing, describing the need and why it matters.
- Assess: the delivery team estimates the effort, the impact on timeline and any risk to existing work.
- Decide: a named person on the client side approves, defers or rejects it.
- Record: approved changes update the scope, the acceptance criteria and the budget.
Why this protects both sides
Clients keep control of cost and can see the effect of each decision. Developers are not pushed to absorb unplanned work, which is how quality quietly declines. Disputes at acceptance are rare when every change is in writing.
Changes to financial logic
Pricing, balances, commissions and ledgers deserve extra care. Changes to these rules should include worked examples, automated tests and confirmation from whoever owns the business rule, because errors can be costly before anyone notices them.