Let's consider this as the phase where the high-level design is handed off to programmers, who then develop the detail design, code and unit-test the changes, and hand off to QA for testing, followed by final release and installation. The people who actually have to code the changes no doubt will have a few challenges, but if you've executed the first two phases well you won't run into too many unexpected problems. The types of problems encountered in this phase usually have to do with learning and dealing with new technology, and finding that tinkering with an application breaks it in unexpected places.
The XML-specific things you probably most need to be concerned with in this phase are issues that are common to other such projects. Having representative test data, in the form of instance documents and schemas, will go a long way in ferreting out problems in unit and system testing. You'll save your programming team a lot of debugging time if you maintain stable development and test environments. Even though new versions of parsing APIs are being issued faster than new women's fashions, don't succumb to the temptation of upgrading. Things that worked with one version can and sometimes do break with a later version, and you'll waste a lot of time if programmers get sidetracked by dealing with a new API version rather than focusing on the tasks at hand. Develop and QA test under one API version, then as a final step upgrade your API to the latest version and QA test again, dealing with any new problems as they come up.