Technology

MINIMIZING WASTE WITH

BY T E D R. COMI^I'ON, CMA

RAPID APPLICATION DEVELOPMENT (RAD)

is a systems

development philosophy that can be effective in controlling waste and inefficiencies that are so common with systems development projects. The sad fact is that, in many cases, systems design teams spend enormous time and effort designing information systems that aren't suited to the user's needs. In some cases, they may be addressing the wrong problem altogether while spending large sums of money on an ill-conceived project design. The primary objective of all development efforts should be delivering a system that meets user expectations, but too often system development objectives are defined in terms of technical considerations with little concern for the user. One of the essential ingredients of RAD is the significant involvement of end-users. Information Services professionals can lose sight of the fact that the final product delivered is likely to be received without enthusiasmor even rejected-because it fails to meet user expectations. In the end, it doesn't matter how well resources are used if the work is unacceptable. When RAD is properly implemented, the user becomes an integral part of the system development process, approving decisions throughout the development cycle.
50

RAD produces systems faster because the systems tend to meet user expectations, thereby reducing the amount of rework required prior to implementation.

RAD vs. OLDER METHODOLOGIES

The most common pre-RAD methodology is called the waterfall method. In this model, each step of the application design and development process is completed sequentially. Information systems designers take the lead, documenting requirements and design after meeting with the user. When a design phase is final, the user is asked to sign on the dotted line, indicating the design will meet his or her needs, and the process moves on to the next phase. Usually, system designers write these design documents using technical terms, complete with a multitude of structure charts that the average user doesn't understand. Then the designers disappear to add levels of detailed documentation and program code during the course of the system development process. When they surface again with the completed design, ready to be tested, it's possible the user will discover it isn't what they wanted. Investing in tools such as CASE {Computer-Aided

STRATEGIC FINANCE I June 2002

System Engineering) or prototyping software may bring some limited benefits, but simply incorporating them into existing traditional or waterfall methodologies may only bring disappointment. A likely outcome could be an unhappy user and a project beset with enormous waste and inefficiencies because developers didn't fully under-

Figure 1; Implications of Using Traditional

Development Direction

stand users' needs (see Figure 1). This wasn't the case with Boral Bricks, a $280 million Atlanta subsidiary of Boral Ltd. Steve Konicki reported in Information Week (October 23, 2000) that Boral moved its DOS-based financials and order-management systems to Oracle applications using a RAD approach by tying together all 20 of its U.S. factories so that company headquarters could closely monitor costs and production Design Techniques and report more efficiently to the parent company. The deployment to Oracle financials took 90 days and cost about $1.2 million for software, consulting, and hardware. Dick Crandall, Boral's CIO, explained, "We didn't think a 90-day deployment was possible, even though that was what we were told to expect, so when we went live we were very surprised." The RAD process attempts to jump-start projects by involving the user in short design sessions aimed at outlining system requirements. The main purpose of the RAD phiJune 2002 I STRATEGIC FINANCE 51

losophy is getting the user involved as an active participant throughout the development cycle (see Figure 2). With the assistance of the user, documenting requirements and design are more likely to speed up the process of program development. Combined, these processes will shorten the overall development cycle and minimize v^aste by focusing on value-added activities. The tools most often associated with RAD are visual and/or objectoriented, such as Visual Basic, Java, and CASE tools. With this software, users can help design output screens and reports that are easily converted to program code. The process involves the users in a cyclic process of review and program modification. The tools also allow design professionals to commit ideas to code and make program modifications that support user needs. Procedural languages such as COBOL are difficult to modify and are seldom used in iterative prototyping, but some developers have used them anyway. Likewise, it's possible to develop systems with visual or object-oriented development tools using traditional waterfall methodologies. For larger companies with international operations, employing the RAD philosophy may turn three-year projects into one-year projects. In his article, Konicki describes the experience of Raytheon Corporation's Aircraft subsidiary, a $2.7 billion operation. Using SAP Accelerated Solutions, an ERP system was fully implemented in just over a year for about $55 million. John Derney, Raytheon Aircraft's director of enterprise resource planning, estimated that if a more conventional approach had been used, the project could have taken three years at a cost of about $300 million.

RAD DEFINED
Although the term RAD has been co-opted by other processes, it's essentially a four-step, applications-building methodology that scales a prototype or mock-up of an application and improves the functionality of that prototype before placing the product intofioll-scaleproduction. The steps are

Delining user requirements Building a system prototype Actual development and testing Placing the system into production

It's important to note that these four steps are not discrete but should be viewed as a continuous process with each previous step being revisited as the prototype is refined. Both developers and end-users are involved in each step. The user must still sign off on the prototype before the final application can be developed, and end-user feedback is incorporated into application design through an iterative process. RAD contrasts with the traditional waterfall methodology, where each step of design and development is completed sequentially. With RAD techniques you can expect more effective communication between system designers and users, leading to a shortened development cycle and better matching of user needs. ^ First, developers and users define business needs and translate them into specifications for the system design. For example, if a team is building a point-of-sale system, the business staff describes the selling process in detail. The development staft^ documents this process and asks the questions needed to draw out the details of an automated system. These joint applications-design sessions serve two valuable functions: They ensure that developers and endusers share the same vision for the finished product, and they keep business needs as the primary drivers of system design.

Figure 2: Using the RAD Methodology

Perceive User Nee* Adjusting Development Direction

Direction ot User's Needs

52

STRATEGIC FINANCE I June 2002

After agreeing on requirements, the developers build a system prototype that creates some of the ftinctionality of the finished system but is primarily meant to let the endusers see enough of the application's front end to determine whether it will fit the organization's needs. Once the end-users have signed off on the prototype, it's time to get to the heart of the matterthe system-building process. The developers add the required functionality to the prototype system, shaping the finished project. Again, this is an iterative processas the developers progress in their work, they show the application to the end-users and get their feedback. End-user feedback is incorporated directly into the system development process. Typically, users and developers will meet a number of times to review and refine the system during this phase. Finally, the system is placed into production, and users are trained. At this point, everyone reviews the system to ensure that it meets all of the requirements drawn up during the RAD process. If it fails to meet them all, the process will begin again to develop the needed enhancements. When development is completed, testing begins. Only when all testing is completed is the system reviewed. The constant interplay between the user group and the developers reduces the chances that a project will stray off course. RAD also offers a more flexible way to allow changing business conditions and needs to be incorporated into the development process.

to focus on the technology, but the project team must stay focused on the business problems that need solving. End-users are a vital resource for assisting in determining the inputs and outputs of a system, decision-support needs, and all of the legacy and new data sources that feed the new application. 2. Pursue a sound development process. Don't go to an extreme during the planning phase. But make sure that the project team is focusing on 10-20 tasks that would include requirements, planning, analysis, designing, testing, and implementation. 3. The prototype should not replace the application design. Use prototypes as a method for assessing user requirements and for providing a skeleton for the final design. Prototyping should be viewed as an initiative process, with each version coming closer to the ultimate design. 4. Don't forget training. RAD deployments that aren't accompanied by adequate staff training are likely to result in handholding. Make sure that users understand that new applications will force change. Without proper orientation and involvement, users are likely to get lost in a sea of new screens that handle financial transactions a new way or that provide new ways for displaying customer information. It's not uncommon to overlap the cut-in of the new system with the phasing-out ot the old systems by three or four weeks to assure proper training. 5. Don't let the project be driven by glitzy technology. Make sure project teams review all the available technologies. Take some time and select a technology or a combination of technologies to solve your business problem. Don't attempt to let a particular technology or gimmick drive the design of your application. RAD is a systems design philosophy that can provide a means for assuring that application design meets user expectations. When compared with conventional design philosophies, the payoffs from effective RAD deployment can be significant. But RAD doesn't provide a panacea for management teams who want to trim costs from their systems development budgets. As with any management principle, you must be aware of the potential pitfalls when this relatively new design approach isn't properly deployed.
Ted Compton, CMA, CSP, Ph.D. is the O'Bleness Professor of MIS at Ohio University. His prior business experience includes positions with Cincinnati Milacron, Sperry Rand Corporation, and W.G. Seinshiemer and Associates. You can reach him at [email protected].
June 2 0 0 2 I STRATEGIC FINANCE

SUGGESTIONS
RAD provides an environment for faster applications development, but it also has its share of risks. Organizations need to make a significant investment of time, money, and training when planning to deploy RAD tools and techniques. It's probably not a good idea to launch your company's RAD initiative with a mission-critical, time-sensitive project. Start small and use the first few development efforts to become familiar with your tools and methodologies and to shake out the bugs you'll inevitably encounter. Speed isn't always a good thing^^faster development cycles can mean a faster path to mistakes. It's important for all participants in a RAD-based project to understand the process and the project goals before jumping in. For developers new to the concept, RAD may seem complex and intimidating. Here are additional suggestions:
1. Know the problem you're trying to solve. RAD

works when you understand the business problem that the application must solve. Technology professionals tend

53