difference is that time and resources are fixed and functionality of the deliverable is variable. In other models, the functionality (or product) is fixed, and resources and time are, to a certain extent, flexible.

Businesses today focus on finding the right solutions quickly. DSDM provides a project framework to make this objective achievable. DSDMs goal is speed but not at the expense of quality. DSDM is independent, ensuring that it is adaptable to meet the needs of any organization. The simplicity, practicality, and flexibility of the approach are suitable for vendors, SMEs, consultants, and so on, making DSDM relevant across a variety of industries.

During the functional model iteration, first-pass descriptions of the new or changed processes are produced for refinement. A pilot project is developed during the design and build iteration. Throughout the development, feedback is used to evaluate and refine the processes so that they can be rolled out to the wider development population with confidence that they will achieve the benefits expected of them.

Implementation of processes involves significant communication and training of the project staff. Because communication is important throughout the development of improved processes and their final delivery, a communication strategy is added to the usual DSDM product set.

The structure of process improvement teams is described based on the DSDM roles and responsibilities. As always, the visionary role is an important one in keeping the focus of the work aligned to the needs of the organization.

Rapid Applications Development (RAD) Methodology

Sometimes users just want to see a product they can understand and not have to wait for the development to get off the build line. Traditional software development methodologies usually follow a sequence of steps with formal sign-offs normally at the end of each project phase. This sequence might be:

User requirements are gathered.

Specifications and the design are formulated.

Development begins and the project is completed.

Testing commences. This process can be time consuming, but RAD shortens the approach.

But what happens if you discover during the development phase that the technology doesnt work? This has immense repercussions for the entire linear approach, and such a methodology could very well cause the project to fail. The

time elapsed between the design and development could run into many months or man-hours. Clients are then often unwilling to take such a loss unless it is part of their key business strategy. Project managers need to employ a far more dynamic approach or project methodology for technologies that are untested or fall into a high-risk category. The RAD methodology may be the most suitable to realize immediate benefits.

Compared with many traditional methodologies, RAD compresses the analysis, design, development, and test phases into a dynamic series of short iterative development cycles. RAD uses shorter project phases, which means that benefits are realized much more quickly. With RAD, each iterative development cycle delivers a functional version of the proposed solution. The approach is almost cyclic in nature. However, many organizations dont have the time to spend lengthy periods on development; they want to see immediate results. By following a RAD methodology, clients are able to use a building block approach to see the results. Using RAD, results are almost immediate and the product starts becoming tangible. The developers have the advantage of building on their solution and gradually improving it until it reflects what the client requires. Some characteristics of the RAD methodology are:

Development teams are much smaller than normal.

The development team is integrated (i.e., analysts, developers, testers) and dedicated to the project.

The development phases are shorter, cyclical, and extremely dynamic.

Each release of a RAD version includes actual functionality the client needs.

Releases do not represent entire prototypes; rather, they are usable working systems.

Tasks and activities are performed concurrently rather than sequentially.

RAD makes use of changing technologies and quick decisions.

The entire approach is based on incremental changes, ultimately ending in a quality product.

The project team understands that frequent changes are part of the job. See Figure 4.4 and Table 4.4 for examples of the RAD methodology.

Table 4.4: RAD methodology

AJbws you Id Develop (1 nf iterations fmotves Client throughout Development Provides Quicker RerUls for ihe Oient

Figure 4.4: RAD methodology.

Throughout a RAD methodology, it is important for the project manager to understand that a process needs to be followed. Key steps that need to be emphasized are:

Analysis. On RAD projects, it is crucial to interview all the various management staff in the clients organization (i.e., sales, marketing, legal, procurement, billing) for their requirements and objectives. These managers may see higher value in certain areas, and this needs to be captured in the user requirements statement (URS). (An electronic copy of the URS template is provided on the accompanying CD.)

Business model. When the analysis is completed, the task of putting together a business model is of the utmost importance. Here the project team relies on the analysts to formulate and create various options based on the clients intended strategy. This may include the types of reports needed, financial data, and even the workflow for the solution. (An electronic copy of this business case template is provided on the CD.)