I have been asked to take a look at the benefits and risks of implementing the RAD approach in my organisation. The benefits of RAD are fairly well documented. However, I am struggling to identify a comprehensive list of risks associated with using the method. I would be extremely grateful for any advice that you may be able to offer. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
With the advent of tools that substantially reduce the time it takes to build prototypes and applications, RAD has come to make a great deal of sense.
However there are some risks associated with RAD.
1. Since people tend to improve thier knowledge with each interation of exprerience, in this case, each iteration of a prototype, it is possible to have a run-a-way scope. This means what was suppose to be RAPID becomes elongated and endless.
2. Many RAD efforts focus on rapid programming and short cut the need to clearly define measurable outcomes of the project, the operational and organizational metrics that will be monitored post implementation, the workflows that are impacted, etc. When this happens the project becomes IT focused and not Organizational / Productivity / Value leveraging focused.
3. With RAD comes a bit of Chaos and Fluidity. Requirements are constantly changing. People can get lost and the project can get unweildy.
My suggestion is that RAD efforts begin after a functional set of requirements has been established. This gives you a baseline to control scope creep and clearly creates a context for understanding the Value the effort is suppose to create.
