RAD appeared when companies were building very large systems on large computer mainframes. These programs had thousands of lines of code. Using Waterfall worked very poorly - too many moving pieces, lots of destructive going back, large numbers of Subject Matter Experts (SMEs) and unclear requirements for systems that had never been built before. These projects would drag on and on. Where I worked, the name of the project would change to avoid the embarrassing lack of completion. It made sense to try to get everyone on the same page rather than fight the churn, so customer / product owners were invited to meetings to prototype the functionality using RAD.
RAD still had a Project Manager and Sponsor who controlled the project. The customer / product owner was still somewhat a necessary inconvenience to most developers. The cultural change was hard. It was difficult for the Project Manager to collaborate with and not control the customer / product owner, and disagreements arose. Prototyping went on and on with no clear idea how to end it and move on. This was called “Death by Prototyping” in IT. Again, the customer / product owners got frustrated, stopped showing up until the system was built, then demanded many changes.
The current SAM (see the book Leaving ADDIE for SAM) approach from Allen Interaction takes RAD one step closer. The stakeholders have a giant meeting (SAVVY start) to kick-off the project, defining high level requirements and deliverables together. A Project Manager / Facilitator runs this meeting and tracks the progress of the pieces of the project. This person plays the role of the leader. Teams divide up to build the pieces, made up of both developers and customer / product owners collaborating. In the Design Iteration, the teams are instructed that they will have three (no more) prototypes. before moving on to the Development Iteration which implements three more iterations to finish the build – Alpha, Beta, Gold. This is based on research from The Mythical Man Month by Frederik Brooks. His research showed that after three iterations there is not enough value added to justify the cost of the additional prototype.
This approach has been used successfully to develop e-Learning, but it still faces challenges. Customer / product owners may not be available, or may have the political clout to prototype forever. The Project Manager may not have the support from the Sponsor or customer / product owners to force attendance or adherence.