Short answer
Define scope in the contract as deliverables and scenarios, pay against accepted deliverables, and run a change control process where every request has a cost, a schedule impact and an owner. The agencies that win also make decisions fast, because slow decisions are where most budget quietly disappears.
In my experience scope problems start in the contract, where vague language lets most things "magically become out of scope" once the work begins, so the first key is to describe what you are buying as specific deliverables, integrations, reports and scenarios that the system must perform, with acceptance criteria your team signs off on. Tying payments to those accepted deliverables rather than to hours or calendar dates keeps everyone focused on finished work.
Once the project is running, I want a change control process that is boring and consistent, which means every request is written down, priced, assessed for schedule impact and approved by someone with authority, and the log is reviewed in every steering committee meeting. Just as important is a decision log, because a project waiting on the agency to settle a policy question is still spending money, and the implementation partner will rightly bill you for the delay.
Lastly, protect your contingency and resist the urge to reopen settled decisions, since every redesign after configuration is far more expensive than the same conversation during process design. The Start at Zero Navigator has more on setting up governance that keeps a project honest, and it is free.