Minimizing Waste With RAD

8/4/2019 Minimizing Waste With RAD

1/5

Technology

MINIMIZING WASTE WITHB Y T E D R . C O M I ^ I ' O N , C M A

RAP ID APPLICATION DEVELOPMENT (RAD) is a systemsdevelopment philosophy that can be effective in control-ling waste and inefficiencies that are so common withsystems development projects. The sad fact is that, inmany cases, systems design teams spend enormous timeand effort designing information systems that aren't suit-ed to the user's needs. In some cases, they may beaddressing the wrong problemaltogether while spendinglarge sums of money on an ill-conceived project design.

The primary objective of all development effortsshould be delivering a system that meets user expecta-tions, but too often systemdevelopment objectives aredefined in terms of technical considerations with littleconcern for the user. One of the essential ingredients ofRAD is the significant involvement of end-users.

Information Services professionals can lose sight of thefact that the final product delivered is likely to be receivedwithout enthusiasmor even rejected-because it fails tomeet user expectations. In the end, it doesn't matter howwell resources are used if the work is unacceptable.

When RAD is properly implemented, the user becomesan integral part of the system development process,approving decisions throughout the development cycle.

RAD produces systems faster because the systems tend tomeet user expectations, thereby reducing the amount ofrework required prior to implementation.

R A D v s . O L D E R M E T H O D O L O G I E SThe most common pre-RAD methodology is called thewaterfall method. In this model, each step of the applica-tion design and development process is completedsequentially. Information systems designers take the lead,documenting requirements and design after meeting withthe user. When a design phase is final, the user is asked tosign on the dotted line, indicating the design will meethis or her needs, and the process moves on to the nextphase. Usually, system designers write these design docu-ments using technical terms, complete with a multitudeof structure charts that the average user doesn't under-stand. Then the designers disappear to add levels ofdetailed documentation and program code during thecourse of the system development process. When theysurface again with the completed design, ready to be test-ed, it's possible the user will discover it isn't what theywanted.

Investing in tools such as CASE {Computer-Aided


2/5

System Engineering) or prototyping software may bringsome limited benefits, but simply incorporating them intoexisting traditional or waterfall methodologies may onlybring disappointment. A likely outcome could be anunhappy user and a project beset with enormous wasteand inefficiencies because developers didn't fully under-

Figure 1; Im plications of Using Traditiona l Design Tech niques

Dev e l o p men tDirection

stand users' needs (see Figure 1). This wasn't the case withBoral Bricks, a $280 million Atlanta subsidiary of BoralLtd. Steve Konicki reported in Information Week (October23, 2000) that Boral moved its DOS-based financials andorder-manag emen t systems to Oracle applications using aRAD app roach by tying to gether all 20 of its U.S. factories

so that company headquarters couldclosely monitor costs and productionand report more efficiently to theparent company. The deployment toOracle financials took 90 days andcost about $1.2 million for software,consulting, and hardware. DickCrandall, Boral's CIO, explained, "Wedidn't think a 90-day deploymentwas possible, even though that waswhat we were told to expect, so whenwe went live we were very surprised."

The RAD process attempts tojump-start projects by involving theuser in short design sessions aimedat outlining system requirements.The m ain purpose of the RAD phi-


3/5

losophy is getting the user involved as an active partici-pant throughout the development cycle (see Figure 2).With the assistance of the user, documenting require-ments and design are mo re likely to speed up the processof program development. Combined, these processes willshorten the overall development cycle and minimizev^aste by focusing on value-added activities. The toolsmost often associated with RAD are visual an d/or object-orien ted, su ch as Visual Basic, Java, and CASE tools . Withthis software, users can help design outp ut screens andreports that are easily converted to prog ram code. Theprocess involves the users in a cyclic process of reviewand program modification. The tools also allow designprofessionals to c omm it ideas to code and make p rogrammodifications that support user needs. Procedural lan-guages such as COBOL are difficult to modify and areseldom used in iterative prototyping, but some develop-ers have used them anyway. Likewise, it's possible todevelop systems with visual or object-oriented develop-ment tools using traditional waterfall methodologies.

For larger companies with international operations,employing the RAD philosophy may turn three-year proj-ects into one-year projects. In his article, Konickidescribes the experience of Raytheon C orporation 's Air-craft subsidiary, a $2.7 billion operation. Using SAPAccelerated Solutions, an ERP system was fully imple-men ted in just over a year for about $55 million. JohnDerney, Raytheon Aircraft's director of enterpriseresource planning, estimated that if a more conventionalapproach had been used, the project could have takenthree years at a cost of about $300 million.

Figure 2: U si ng t he R A D Met hodo l ogy

Perce iveUser Nee*

Direct ion otUser ' s Needs

R A D D E F I N E DAlthough the term RAD has been co-opted by otherprocesses, it's essentially a four-step, applications-buildingmethodology that scales a prototype or mock-up of anapplication and improves the functionality of that proto-type before placing the product into fioll-scaleproduc-tion. The steps are

Delining user requirements Building a system p rototype

Actual developm ent andtesting

Placing the system intoproduction

It's important to note that these four steps are not dis-crete but should be viewed as a continuous process witheach previous step being revisited as the prototype isrefined. Both developers and end-users are involved ineach step. The user mus t still sign off on the prototyp ebefore the final application can be developed, and end-userfeedback is incorporated into application design throughan iterative process. RAD contrasts with the traditionalwaterfall methodo logy, where each step of design a nddevelopment is completed sequentially. With RAD tech-niques you can expect more effective communicationbetween system designers and users, leading to a shorteneddevelopment cycle and better matching of user needs.

^ First, developers and users definebusiness needs and translate theminto specifications for the systemdesign. For exam ple, if a team isbuilding a point-of-sale system, thebusiness staff describes the sellingprocess in detail. The developmentstaft docu me nts this process and asksthe questions needed to draw out thedetails of an automa ted system.

These joint applications-design ses-sions serve two valuable functions:They ensure that developers and end -users share the same vision for the fin-ished product, and they keep businessneeds as the prim ary drivers of systemdesign.

AdjustingDevelopmentDirection


4/5

After agreeing on requirem ents, the developers build asystem p rototype that creates some of the ftinctionality ofthe finished system but is primarily meant to let the end-users see enough of the application's front end to deter-mine whether it will fit the organization's needs.

Once the end-users have signed off on the prototype, it'stime to get to the heart of the matterthe system-buildingprocess. The developers add the required functionality tothe proto type system, shaping the finished project. Again,this is an iterative processas the developers progress intheir work, they show the application to the end-users a ndget their feedback. End-user feedback is inco rporateddirectly into the system developm ent process. Typically,users and developers will meet a number of times toreview and refine the system during this phase.

Finally, the system is placed into p rodu ction, and usersare trained. At this point, everyone reviews the system toensure that it meets all of the requirements drawn upduring the RAD process. If it fails to m eet them all, theprocess will begin again to develop the needed enhance-ments. When development is completed, testing begins.Only when all testing is completed is the systemreviewed.

The constant interplay between the user group and thedevelopers reduces the chances that a project will stray offcourse . RAD also offers a mo re flexible way to allowchanging business conditions and needs to be incorporat-ed into the development process.S U G G E S T I O N SRAD provides an environment for faster applicationsdevelopment, but it also has its share of risks. Organiza-tions need to make a significant investmen t of time,money, and training when planning to deploy RAD toolsand techniques. It's probably not a good idea to launchyour company's RAD initiative w ith a m ission-critical,time-sensitive project. Start small and use the first fewdevelopmen t efforts to become familiar with your toolsand methodologies and to shake out the bugs you'llinevitably en counter.

Speed isn't always a good thing^^faster developmentcycles can m ean a faster pa th to mistakes. It's im portan tfor all participants in a RAD-based project to understan dthe process and the project goals before jump ing in. Fordevelopers new to the concept, RAD may seem complexand intimidating. Here are additional suggestions:

1 . Know the problem you're trying to solve. RADworks when you understand the business problem thatthe application must solve. Technology professionals tend

to focus on th e technology, but the project team muststay focused on the business problems that need solving.End-users are a vital resource for assisting in determiningthe inputs and outputs of a system, decision-supportneeds, and all of the legacy and new data sources thatfeed the new application.

2. Pursue a sound development process. Don't go toan extreme during the planning phase. But make surethat the project team is focusing on 10-20 tasks thatwould include requirem ents, planning, analysis, design-ing, testing, and implementation.

3 . The prototype should not replace the applicationdesign. Use prototypes as a method for assessing userrequirements and for providing a skeleton for the finaldesign. Prototyping should be viewed as an initiativeprocess, with each version com ing closer to the u ltimatedesign.4. Don't forget training. RAD deployments that aren'taccompanied by adequate staff training are likely to resultin handholding. Make sure that users understand thatnew applications will force change. Without proper ori-entation and involvement, users are likely to get lost in asea of new screens that handle financial transactions anew way or that provide new ways for displaying cus-tomer information. It's not uncommon to overlap thecut-in of the new system with the phasing-out ot the oldsystems 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 technolo-gies. Take some time and select a technology or a com bi-nation of technologies to solve your business problem .Don't attempt to let a particular technology or gimmickdrive the design of your application.

RAD is a systems design philosophy th at can provide ameans for assuring that application design meets userexpectations. When compared with conventional designphilosophies, the payoffs from effective RAD deploymentcan be significant. But RAD doesn't provide a panacea formanagement teams who want to trim costs from theirsystems development budgets. As with any managem entprinciple, you must be aware of the potential pitfallswhen this relatively new design approach isn't properlydeployed.

Ted Compton, CMA , CSP, Ph.D. is the O'Bleness Professorof MIS at Ohio University. His prior business experienceincludes positions w ith Cincinnati Milacron, Sperry RandCorporation, and W.G. Seinshiemer and Associates. You canreach him at Compton@ ohio.edu.


5/5

Documents

Minimizing Waste With RAD