A specification is only half the work. Whether a system delivers what the concept promises is decided in testing, before the error reaches production, not after. That is why business analysis and testing are not an appendix to my interim project management, but a work step of their own, with its own place in the schedule.
What this discipline is worth shows in an M&A integration: an international group acquired a consulting firm with 80 employees, and all systems and data had to move into the group landscape. After detailed data mapping and several test runs, with written runbooks and a trained team, the cut-over happened over a single weekend. On Monday, business ran as usual; no rollback was needed. The case study is on the references page.
Test cases and acceptance criteria
I write test cases before the build, not after. Every case has an expected result, every acceptance a measurable criterion: what goes in, what must come out, what counts as passed. “Looks fine” is not an acceptance criterion. And I do not just run integration tests, I enforce them, against the understandable urge to rescue a go-live date by cutting test cycles. A cancelled test does not remove the error; it moves it into production, where it costs more.
Testing against real data
Constructed test data checks whether the system does what the developer expected. Real data checks whether it copes with what actually sits in the legacy systems: duplicates, special characters, edge cases grown over years. That is why I test against real data, especially in migrations under ERP change & migration. Why data quality is so often the real bottleneck is covered in Why Projects Fail in Preparation, Not Execution.