1. Ensure changes align with business and technical requirements.
The close participation from business stakeholders in RAD can lead to feedback loops where, while prototyping, modeling, and testing, ideas for changes are readily apparent and "thrown into the mix". The PM (and the rest of the development team) should reign in this behavior by ensuring that any changes proposed fit within the scope of the defined business requirements. Re-scoping or changing direction is fine, but not during the middle of revision cycles.
2. Clear communication of impact is critical, as is the need for comprehension and full approval.
Many small changes will be made during the application's development. Some have more impact, and should be treated with more importance. For these changes, highlight the larger impact, and be sure to communicate clearly why the impact is greater to decision makers. Ensure that there is full approval by stakeholders, rather than "rubber stamp" agreement to changes, without their comprehension.
3. Limit changes within each development cycle.
Don't try to make too many changes in a given cycle. Move unplanned changes to the next cycle if they are discovered in mid cycle. Sometimes it may seem easy to add another change while in mid-cycle, but this breaks the process. Each iteration should have its own scope, and since the timeline is so short, even adding a few items because they are "small" or won't take "that much work" can ensure deadlines are missed.
4. Carefully validate and test changes during each cycle.
Acceptance testing is an area that gets less attention than bug checking and functional validation. Don't rush or gloss over acceptance testing from users and stakeholders. If they discover problems later, more time is spent on another change to fix the problem. The change implemented may have no bugs, and work properly, but if it doesn't accomplish what the users and owners expect, it has to be reworked just the same.
5. Don't make change requests the sole or primary purpose of a development cycle.
Sometimes the larger goal of the project becomes bogged down by a myriad of small changes during a series of development cycles. If versions of the application are becoming only bug fixes or change request implementations, new features and functionality are simply delayed. Sometimes a revision will be only a set of bug fixes. But if releases are no more than change request updates, major features, and functionality based on business goals are not being implemented. Stay on track; work toward defined requirements during a cycle if at all possible.