How are requirement changes controlled and charged during a project?
Classify before charging. Behaviour that misses an agreed acceptance criterion is a defect; necessary clarification of existing scope follows the contract; a new business rule, platform, or change of direction is normally additional work. Wavesteam presents the impact and price, then proceeds only after the client records a choice to exchange scope, extend time, add budget, or defer.
A public rule such as “changes under two days are free” is unsafe. Repeated small requests can transform a project, while one apparent half-day field may affect migration, interfaces, and reports. Charging depends on original scope, cause, and any support or change allowance in the contract—not only the estimate for one task.
| Classification | Basis | Typical treatment |
|---|---|---|
| Defect | Implementation does not meet confirmed requirements or acceptance | Usually corrected by Wavesteam without treating it as new scope |
| Clarification or omission | The function is in scope but a detail is ambiguous | Resolve responsibility and impact under the contract, then add the rule and test |
| Client addition or direction change | New role, workflow, platform, or changed confirmed rule | Price separately or exchange unstarted scope; update milestones |
| Third-party or policy change | Platform API, review policy, law, or supplier changes | Reassess necessity, deadline, alternative, and contractual risk allocation |
| Necessary technical repair | Security, compatibility, or stability requires action | Handle as warranty, maintenance, or a scoped upgrade according to cause |
A request records the business reason, target user, current and expected behaviour, acceptance scenarios, deadline, and consequence of not acting. Wavesteam adds affected UI, backend, data, permissions, interfaces, testing, migration, store submission, and documentation. The estimate includes assumptions, risk, and schedule impact—not merely “three development days.”
The client then makes one explicit decision: replace comparable work that has not begun; retain scope and add budget and time; move the idea to a later release; or cancel it. Replacing a feature is not automatically cost-neutral when completed data models or third-party commitments are affected. The authorized approver records the choice in the project system, email, or change order; a casual group-chat idea does not become an instruction to build.
Pricing should match uncertainty. Fixed price works with stable scope and separately priced changes. A change allowance suits a limited expected volume and must show consumption. Time and materials suits exploratory long-running work but needs a budget cap, periodic objectives, and transparent time records. A project cannot reasonably combine a fixed total with unlimited scope movement.
Responsibility relies on evidence. Clear requirements implemented incorrectly indicate a defect. An obvious exception omitted within Wavesteam's agreed analysis responsibility follows that contract. A business owner changing a confirmed rule creates a change. When both parties lacked evidence, use recorded assumptions and risk allocation rather than an automatic “split the cost” convention. Pause only the disputed work if agreement is impossible.
After approval, update requirements or prototype, interface, tests, budget, milestone, and release notes together. If the old rule has produced data, define migration, historical reporting, and rollback as well as the current screen. Review ordinary changes on a regular cadence while routing production and security incidents through the emergency process.
Track change count, added effort, causes, rework, critical-path delay, and aging approvals to improve discovery and decisions. Sustained volatility is a signal to shorten commitment cycles, validate prototypes again, or adopt time-based pricing. Wavesteam's service process and Transparent Delivery Standard provide a baseline; the contract must name the free scope, rates, allowance, approver, and responsibility.