Work runs in four stages: discovery, build, testing and training, then go-live and handover. You review and approve at the end of each stage before the next one begins, so nothing is built on an assumption you have not seen in writing. You are involved throughout rather than only at the beginning and the end.
Sessions with the people who run the processes being changed. What comes out is a structured set of requirements describing what the system will do, written in business terms rather than technical ones. You read it, correct it, and approve it. Anything we misunderstood gets caught here, which is far cheaper than catching it later.
Configuration against the approved requirements. Anything carrying risk to live data is built and tested separately before it goes near your working system. You see progress as it happens rather than receiving a finished system at the end.
You test the system against your own real scenarios, not a scripted demonstration. Issues found here are fixed before go-live. Training is delivered by role, so each team learns the part of the system they will actually use, and it runs close to go-live so it is still fresh when people start.
The system becomes live, and administrative ownership passes to your team along with documentation of how the system is built and why. Support continues past this point under whichever arrangement you have chosen.
How long each stage takes depends entirely on scope, which is why we agree that with you rather than publishing a figure.
You should never be surprised at go-live, because you approved what was built at each stage before it was built. If a partner cannot tell you what you sign off and when, that is worth asking about before you commit.
If you want to understand how the scope is agreed in the first place, read how Cirro scopes a project and produces an estimate.