Integration. Integration of RAD solutions into existing platforms and legacy systems is challenging; therefore, the RAD project team needs to work closely with the clients technical team to capture any business rules or integration issues that would contribute toward a successful integration of the new solution. The well-known software vendors have, to a great extent, already addressed integration into their software. However, if the required solution cannot integrate with certain systems, some customization and development may be needed. This is where the true nature of RAD reveals itself. It goes through various iterations and is repeated until the solution can integrate into the clients organization.

Documentation update. Because of the iterative nature of RAD, it is wise to maintain and update all project documentation on a regular basis as the versions are changed and new versions are tested. Proper configuration management of not only the project documentation, but also the source code and database instances, will keep the project under control.

RAD prototyping can reduce costs. It allows the project manager and the team to identify risks early during the project life cycle. The approach overlaps project phases. However, one of the biggest concerns found with RAD is with quality assurance during the development of the project. Project managers, therefore, must ensure that quality assurance is built into the project.

Team LiB Щ\< previousЩнехт >

The Unicycle Methodology

The unicycle model is a classic methodology still used successfully today. Before using this model, a feasibility study establishes the justification for the project. Figure 4.5 shows that the project phases are closer than other methods and join in the center, which reflects project communications. The following phases are used:

Project feasibility and justification. After the project manager becomes familiar with the project feasibility report, he or she should ensure that the findings are valid and updated. The project manager determines the feasibility for the project during this phase.

User requirements. As with all projects, client requirements are mandatory. Some level of effort is required to determine all user requirements. The project cannot continue until this phase has been completed.

System design. When the user requirements have been specified and approved by the client and the project team, the project commences establishing a high-level design of the main functions of the proposed solution. The system design will decompose this high-level design into manageable parts.

Detailed design. After the project team has established the high-level design, a detailed design is prepared. The detail is captured in the project work breakdown structure (WBS) and the design documentation.

Buy or build. In many cases, depending on the level of detail, the design, and available resources, it may be necessary to buy the solution instead of developing it. This business-driven decision is made and implemented by the client.

Acceptance. All aspects of the solution need to be proven fully functional, documented, tested, validated, and acceptable to the client. This can be achieved through testing.

Commissioning. The commissioning is the actual commencement or deployment of the tried and tested solution. The client and users are provided with the necessary training. After all aspects are resolved, formal acceptance is agreed on.

Completion and postimplementation audit. Closing the project involves ensuring that project resources are dissolved and released to their organizations. The postimplementation audit consists of performing a thorough project audit after a period of three to six months into its operational steady state. The audit

provides many lessons and can be shared with other projects.

Figure 4.5: Unicycle methodology. I Ell