Change Management Tips In Rapid Application Development

Rapid Application Development (RAD) has many strengths, and several flavors are currently popular. All RAD strategies focus on fast development cycles, iterative development, and minimizing feature creep. RAD focuses on involvement of business sponsors, users, and owners. RAD methodologies are collaborative in nature, although the type and style of collaboration varies. Agile and Scrum are types of RAD. Change management always presents challenges. With Rapid Application Development these challenges can be magnified if we are not careful. Since development cycles are tight, significant changes can consume an entire cycle. If business process models and prototypes are flawed or need major revision during the project, it can be difficult to meet goals in a timely fashion. If changes require revisions to large amounts of code, development can flounder. Let's examine some tips for change management in a RAD environment.

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.

RAD methodologies allow owners and stakeholders to participate more closely and effectively with development teams. Change requests and feedback come quickly and often. Following the tips above can help prevent disaster by ensuring changes are in sync with project goals, by improving communication, by limiting changes, and by increasing the importance of validation and acceptance.