Testing is essential to project success. Whether it is unit testing (which tests one facet of the system) or integrated testing (which tests all components, including existing interfacing systems), testing should be done by current employees along with a testing script. The testing script should include all inputs, step by step, that testers should make. And you should detail, ahead of time, what all outputs should look like.
Testing data and processes should vet all scenarios, including good and bad data. Sometimes results from known bad data are more interesting than those of a desired outcome. Testing should include load tests to see how the system and network respond under heavy utilization. Testers should understand expected outcomes and be expected to report all deviations.
Despite our best efforts, plans don't always go as expected. Every project leader needs to know what go-live success looks like -- and when it's time to admit failure and begin again another day. Every project should have a go-live backup plan in case failure becomes the only option.
Too many go-live events are driven by the belief that "nothing can go wrong." Leaders of these projects often fail to make sure good backups are taken and verified. They don't develop protocols for defining success, nor outline what a failure looks like ahead of time. They don't prepare the team for what to do in the event of a go-live crash. Many brand-new projects hit a fatal stumbling block only to find out they can't go backward. This is poor planning.
With few exceptions, projects should plan for failure and, when the pain is too much, allow for failure back to the old system. Sure, failure is embarrassing and no one wants to plan for it. But not being able to recover during an extended service outage is usually career-ending.
Letting senior management know that you had a backup plan and followed it to a tee when the turds hit the fan is a way to win accolades. Letting an extended downtime event go on and on as you explain to management that there is no way back and the forward path isn't looking so pretty is a much different conversation. Plan to succeed, but have a plan for failure as well.
There are people who ask for expert advice and listen, then choose a different path -- every time. Then they complain when something doesn't work right.
Don't be that person. Don't let that person make big decisions on your team. It's all right to ask for expert advice, only to do something different. That's human nature, and it's often the sign of a good leader. Just don't do it compulsively. More important, if you go against recommendations and the outcome doesn't work, don't blame the consultant.
Deviating from vendor or consultant recommendations means testing the results of your change before go-live. Even if the vendor or consultant agrees with your deviance from their recommendation, make sure the change is tested. Many projects have failed because project leaders "made a few small changes" that left vendors and consultants shaking their heads in the background. You'd be surprised by how many experts remain silent in the face of a very strong customer that seems to know better than the experienced consultants. Everybody wants to be friends. Everyone hopes it works out.
Don't hope. Test. And listen to your experts most of the time.