TK Strategies  

Project Management HOME LINKS RESUME ABOUT  
 

Commentary

Project Management

PMBOK®
Knowledge Areas

Leadership

Expertise in
Application Area

Effective Communication
with Stakeholders

Managing
Organizational Change

Organizational Behavior
in Reorganizations

HR Considerations

Subcontracting
Team Roles

Schedule and
Cost Control

Project Schedule
Inflation using PERT

Bypassing
Procurement Personnel

Procurement / Contractual
Management Considerations

Importance of
What-If Scenarios

RAD vs. General
Project Management

Risk Analysis:
Qualitative vs. Quantitative

Thought-provoking
Quotes

Disclaimer:
The information and
opinions expressed are
offered for educational
purposes.  No responsibility
 is accepted for the outcome
of their application.

 

 TK Strategies

RAD vs. General Project Management

Rapid Application Development vs. General Project Management

A General Project Management model, according to the PMBOK® Guide, is the “application and integration of the project management processes of initiating, planning, executing, monitoring and controlling, and closing” (Project Management Institute, 2004), encompassing a general, yet disciplined, approach to managing projects.  Inherently, these processes require that project managers pay close attention to detail; anticipating, monitoring, and controlling – to the greatest extent possible – all aspects of the project throughout its lifecycle.  Nevertheless, project management methodologies “… must have enough flexibility that they can be adapted easily to each and every project” (Kerzner, 2003), prompting a consideration of the rapid application development (RAD) approach.

A RAD model of project management is based on the concept that, In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution” (Maner, 1997).  This means the amount of time allocated to complete a project – or a segment of a project – under certain circumstances can be significantly reduced when using this model.  Unfortunately, when RAD was first introduced, it sometimes was used it as an excuse to abandon all discipline (Yourdon, 2000).  Realistically, this reduction in time is proportional to the reduction of project activities executed.  In other words, some project activities must be sacrificed to reach the objective sooner; therefore, the question we must ask:  to what extent will the quality of the deliverable be affected?

As we consider if these differing models should be used simultaneously, or if it is better to use them independently, we must remind ourselves that project management “methodologies should be designed to support the corporate culture, not vice versa” (Kerzner, 2003).  This implies, in certain cases, a mix of these models could evolve into a custom model tailored to reduce a project’s timeline.  However, an optimum mix of these models must be based on a clear understanding of when a RAD approach is appropriate.  A RAD approach is suitable under conditions such as the following  (Gantthead.com, n.d.):

  • When project objectives are well defined

  • When decisions can be made by a small number of project members

  • When technical architecture is clearly defined, and key technology components are already installed and tested

  • When technical requirements are well within the capabilities of the technology in use

Although a RAD approach does not seem appropriate for all projects, it could enhance a general project management approach, but not without first excluding the activities that could become compromised.  For instance, a project's standards and protocols could be negatively affected by a RAD approach because, by cutting corners in these areas, subsequent uniformity of operations could become less efficient – the opposite of the project’s objective.  Alternately, an intended level of support could be reduced by a margin greater than the estimated impact of its reduction on its support function.

RAD does provide significant time and cost savings over general project management approaches when applied to “non-mission-critical project initiatives” (Shaw, 2005).  Ultimately, the challenge in every project is to determine how great a deficiency and increased possibility of risk can be tolerated by incorporating a RAD approach, in exchange for a reduction of the general project management timeline.

References

Gantthead.com. (n.d.). Process/Project RAD – RAD – Rapid application development processes. Retrieved February 18, 2006, from http://www.gantthead.com/process/processMain.cfm?ID=2-19516-2.

Kerzner, H. (2003). Project management a systems approach to planning, scheduling, and controlling (8th ed.). Hoboken, NJ: John Wiley & Sons, Inc.

Maner, W. (1997). Rapid application development. Retrieved February 18, 2006, from http://csweb.cs.bgsu.edu/maner/domains/RAD.htm#2.

Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK guide) (3rd ed.). Newton Square, PA: Author.

Shaw, B. (2005). Totally RAD, Dude – Managing rapid application development expectations. Retrieved February 19, 2006, from Project Perfect Web site: http://www.projectperfect.com.au/info_rad.php.

Yourdon, E. (2000). Success in E-projects. Computerworld, 34, 36. Retrieved February 18, 2006, from Business Source Elite database.

 

Web design: TK Strategies

Copyright (c) 2007-2014 TK Strategies.  All rights reserved.