Process/Project RAD - RAD - Rapid Application Development Process

Description

Method in the Madness

Some consider it noble to have a method; others consider it noble
not to have a method. Not to have a method is bad; to stop entirely
at method is still worse. One should at first observe rules severely,
then change them in an intelligent way. The aim of possessing
method is to seem finally as if one had no method.
The Mustard Seed Garden Manual of Painting


To RAD or not to RAD

The Rapid Application Development methodology was developed to respond to the need to deliver systems very fast. The RAD approach is not appropriate to all projects - an air traffic control system based on RAD would not instill much confidence. Project scope, size and circumstances all determine the success of a RAD approach. The following categorize indicates suitability for a RAD approach:

PROJECT SCOPE
Suitable for RAD - Focused scope where the business objectives are well defined and narrow.
Unsuitable for RAD - Broad scope where the business objectives are obscure or broad.

PROJECT DATA
Suitable for RAD - Data for the project already exists (completely or in part). The project largely comprises analysis or reporting of the data.
Unsuitable for RAD - Complex and voluminous data must be analyzed, designed and created within the scope of the project.

PROJECT DECISIONS
Suitable for RAD - Decisions can be made by a small number of people who are available and preferably co-located.
Unsuitable for RAD - Many people must be involved in the decisions on the project, the decision makers are not available on a timely basis or they are geographically dispersed.

PROJECT TEAM
Suitable for RAD - The project team is small (preferably six people or less).
Unsuitable for RAD - The project team is large or there are multiple teams whose work needs to be coordinated.

PROJECT TECHNICAL ARCHITECTURE
Suitable for RAD - The technical architecture is defined and clear and the key technology components are in place and tested.
Unsuitable for RAD - The technical architecture is unclear and much of the technology will be used for the first time within the project.

PROJECT TECHNICAL REQUIREMENTS
Suitable for RAD - Technical requirements (response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used. In fact targeted performance should be less than 70% of the published limits of the technologies.
Unsuitable for RAD - Technical requirements are tight for the equipment to be used.


Rapid means Fast

The RAD method has a task list and a work breakdown structure that is designed for speed. However the major difference in RAD is a set of management techniques that are optimized for speed. Among the most important are:

- Prototyping - an approach based on creating a demonstrable result as early as possible and refining that result. The refinement is based on feedback from the business, the eventual users of the system. Prototyping requires an open approach to development, it also requires an emphasis on relationship management and change management. There are dangers involved in starting prototype development too early and in starting it too late.

- Iteration - is a commitment to incremental development based on refinement. Prototyping and iteration go hand in hand.

- Timeboxing - is a management technique that focuses attention on delivery above all else. Under a timebox scope can change but delivery cannot.