INTRODUCTION
This article first introduces both the technical and business environments in which Web information systems are developed and the unique project variables of these systems. Characteristics are identified where e-business projects differ from traditional information systems projects. The next section presents various system development methodologies, provides a categorization framework and analyzes these categories for situations where each is best utilized. The synthesis of applying the environmental and project variables to the system development methodology categories provides the main contribution of the article. Conclusions are drawn that a project is unlikely to align perfectly with any one methodology. The project manager should select the methodology that is the “best fit” from the model presented here. Finally, the project manager should customize the process based on the unique characteristics of the organization, project, and team.
BACKGROUND
The speed demanded of e-business developers and the ever-fluctuating nature of the technical and business environments in which they must function combine to demand new approaches to the system development process. Traditional methodologies were designed for vastly different environments and cannot be easily transplanted into this new Web setting. In the practitioner press, Yourdon has called for a new “light” version of traditional methodologies (2000) for use in e-business development. Avison and Fitzgerald (2003) have found many Web-based applications being developed in an ad-hoc, trial-and-error manner.
The E-Business Environment
E-business projects are developed in a unique environment that is characterized by “perpetual ambiguity and rapid change” (Nadherny and Stuart, 2000). A Web Information System (WIS) is usually tightly integrated with other non-WISs, such as databases and transaction processing systems (Isakowitz and Bieber, 1998) to support the work of the organization. “Internet time,” the perception that product development and consumer acceptance now occur in a fraction of the time that they traditionally took (Odlyzko, 2001), has increased time-to-market pressure in WIS projects. These distinctive characteristics set e-business projects apart from other types of information systems (IS) projects.
(1) Web Technical Environment
The technical environment for a Web Information System is vastly expanded compared to traditional IS projects. In most traditional projects, an organization builds their information systems in a closed setting, limiting external organizations’ access based upon the controlling organization’s technology choices. Web Information Systems are different in that both external and internal users often access WISs using a variety of different hardware, software, and networking technologies. To further complicate matters, compatibility issues arise when new WISs must interface with existing legacy systems.
(2) Competitive Marketplace
The competitive marketplace plays a far greater role in Web Information Systems than it does in most traditional projects. WIS marketplace impact can be direct and immediate. This situation offers the promise that an organization could quickly gain competitive advantage through its Web Information Systems. However, according to Porter (2001), the five underlying forces of competition: the intensity of rivalry among existing competitors, the threat of substitute products or services, the barriers to entry for new competitors, the bargaining power of suppliers, and the bargaining power of buyers, have been negatively affected by the shift away from quality, features, and service toward price. This has resulted in a dampening of overall profitability, and has reduced the ability of any company to establish an operational advantage that can be sustained. Thus the e-business competitive environment is characterized by the ability of any competitor to rapidly change marketplace dynamics, coupled with the likelihood that any such change will be quickly be supplanted by another competitor’s actions.
(3) Organization’s Culture
Each organization brings to every project its own culture. An organization’s culture is comprised of values, behaviors, and attitudes (Hatch and Schulz, 2001). It provides continuity, structure, common meaning, and order, giving rise to stable patterns of interaction within the organization. However, that stability can be upset by the creative, more liberal culture characteristics of many Web development efforts. Developers who challenge the advisability of traditional project phases and approvals also challenge the established culture and order.
(4) Organizational Strategy
An organization’s Web strategy should be viewed as a continuous cycle that builds on the current strategy of the organization while creating new business models (Venkatraman, 2000). Yet, for some organizations, e-business brings with it a change in strategic emphasis from internal operations to customers. In the world of Web Information Systems, branding has become increasingly important. A brand is the relationship between a company and its customers that is based on vision, culture, and image (Hatch and Schultz, 2001). Personalization of the Web interface and creation of online communities can extend the traditional brand relationship and increase customer loyalty and profitability. The customer, viewing their experience with the organization, should see only a seamless integration of the organization’s overall strategy and their Web initiatives.
(5) Organization’s Technical Environment
Web Information Systems complicate the organization’s technical environment. In the 1970s mainframe era, most organizations had single-site implementations, where all hardware and software came from one manufacturer, and there were designed to work together. The introduction of client/server technologies in the early 1990s replaced this single source with the challenge of integrating hardware and software from multiple vendors. Web Information Systems operate in a distributed world with a multitude of different manufacturers’ components, many of which were not engineered to work together. Organizations have the option of retaining this technology in-house or outsourcing, or a combination of both.
(6) Project Characteristics
Web Information Systems concentrate more heavily on Information Architecture than the average traditional IS project. In a Web Information System context, Information Architecture refers to the design of organization, labeling, navigation, and searching systems to help people find and manage information more successfully (Rosenfeld, 2000). WIS Information Architecture concentrates heavily on the human-computer interface.
Table 1. E-business development methodology variables
| Organization | ||
| Culture: | Conservative | -► Innovative |
| Strategy: | Committed | -► Evolving |
| Technology: | Stable | -► Experimental |
| Non-integrated | -► Integrated | |
| Project | ||
| Objectives: | Clear | -► Unclear |
| Requirements: | Stable | -► Changing |
| Users: | Known | -► Unknown |
| Implementation: | Long | -► Rapid |
| Team | ||
| Skills: | Technical | -► Creative |
| Composition: | Stable | -► Changing |
| Member Experience: Less Experience | -► Highly Experienced | |
| Leadership: | Less Experience | -► Highly Experienced |
A project budget for traditional information systems is often based upon data gathered through historical experience. Web Information Systems generally do not have this kind of past experience to draw upon for estimating. Further, the question of which department should sustain the cost of a project becomes more complex for many WISs, where project ownership issues are often less clear.
Whereas traditional IS projects are largely limited to the IT department, with some involvement of primary users, the development of Web Information Systems requires teams that include a broad range of technical, user, and creative talent. Many WIS teams include marketing staff, business analysts, graphical artists, human-computer interaction specialists, and branding specialists.
System Development Methodology
System development methodology refers here to the framework that is used to structure, plan, and control the process of developing an information system. Most models can be placed into one of four major categories: linear, iterative, parallel, or agile.
(1) Linear Models
While Boehm (1986) tracks system development methodology to Bennington’s 1956 Stagewise model and Royce’s 1970 Waterfall model, other authors suggest that the System Development Life Cycle (SDLC) evolved primarily during the 1970s (Harrison, 1985), in response to organizations’ needs to better organize, plan, schedule, and
Table 2. Situations where linear development models are most beneficial
Clear project objectives Stable project requirements Knowledgeable user No immediate need to install Inexperienced team members Fluctuating team composition Less experienced project leader Need to conserve resources Strict requirement for approvals control projects (Hall, 1980). The SDLC is based upon two principles: dividing projects into phases, and using written documentation and approvals to maintain control. While the exact phases in the cycle vary from one author or organization to the next, they generally follow along these lines: initial investigation, conception or feasibility study; requirements definition; system design; coding, unit testing, integration and system testing; implementation; and ongoing system maintenance. The Waterfall model, which allows some overlap and splashback between the phases, is a variation of the SDLC that loosens this type of control slightly. Another variation on the SDLC is the V Model (Plogert, 1996), which emphasizes system quality assurance. In this model, the stages are partnered in a sort of V shape, with, for example, system design on the left leg of the V paired with system testing on the right leg, and requirements definition on the left leg paired with acceptance testing on the right leg.
(2) Iterative Models
Prototyping is an iterative process that lets users work with a small-scale mock-up of their system, experience how it might function in production, and request changes until it meets their requirements. As Janson and Smith (1985) noted, “Prototyping addresses the inability of many users to specify their information needs, and the difficulty of systems analysts to understand the user’s environment, by providing the user with a tentative system for experimental purposes at the earliest possible time.” Maturity of the prototype methodology led to a further type of iterative development model, Rapid Application Development (RAD). RAD methodologies aim at producing high quality systems quickly, primarily through the use of iterative prototyping, active user involvement, and computerized development tools.
The Spiral model developed originally by Boehm (1986) is an iterative approach that is focused on minimizing project risk. Each trip around the Spiral traverses four basic quadrants: (1) determine objectives, alternatives, and constraints of this iteration; (2) evaluate alternatives; identify and resolve risks; (3) develop and verify deliverables from this iteration; and (4) plan the next iteration (Boehm, 1986; 1988). Boehm’s more recent work reflects an expanded view of the Spiral, requiring identification of stakeholders and their win conditions at the very start of each cycle, and ending the cycle with review and commitment. This broader view of the Spiral merges elements of Boehm and Ross’s Theory W into the Spiral Model (Boehm, 2000). Under Theory W, the primary job of the software project manager is to insure that all of the project’s stakeholders become winners (Boehm and Ross,1989).
Table 3. Situations where prototyping/RAD is most beneficial
Project objectives are unclear Functional requirements are changing User is not fully knowledgeable Immediate need to install something
Experienced team members (particularly if the prototype is not throw-away) Stable team composition Experienced project leader
No need to absolutely minimize resource consumption No strict policy or cultural bias favoring approvals
Analysts/users appreciate business problems involved, before they begin project Innovative, flexible designs that will accommodate future changes are not critical
(3) Parallel Models
Parallel models resemble those used by some advertising agencies when they are under competitive pressure to produce the best possible presentation for their client in the least possible time. The advertising agency’s “three creative comps” becomes three creative treatments of a Web site. With parallel models, different approaches are tried at the same time by different individuals or teams, and then as the project progresses, less productive paths are pruned. Alternative paths may be followed simultaneously just at the project start, or new alternative paths may be introduced when the project reaches critical points. An alternative path model creates multiple paths and prunes as the project progresses.
(4) Agile Development Models
During the late 1990s and early 2000s, a variety of new methodologies were put forth, most aimed at creating a lighter, faster, more flexible and responsive approach to development. Beck’s Extreme Programming (1999) user requirements are noted on index cards and programmers work in pairs, with two developers sharing one computer workstation. Bad code is weeded out regularly through a process called refractoring. Initial studies have indicated that pair coding results in less initial productivity, but that pairs do write code with fewer defects (Radding, 2001; Williams et al., 2000). Highsmith’s Adaptive Software Development (1999) emphasizes developing a flexible team that can function in a complex, rapidly changing environment. Adaptive development grew out of Highsmith’s attempt to apply Rapid Application Development techniques to larger, more complex projects. His adaptive development cycle consists of three major phases or stages: (1) speculate (project mission statement, initial requirements and cycle plan); (2) collaborate (short cycles where system components are developed concurrently and delivered); and (3) learn (review work and team’s performance.)
APPLYING THE MODEL TO SPECIFIC PROJECTS
Table 7 is an enhancement of Table 1, showing the relationships between various development methodologies and organizational, project, and team variables. These were culled from the background section.
When an organization applies the model in Table 7to a particular project, considering all their organization, project, and team variables, the model is unlikely to align perfectly with any one methodology. At this point, the project leader may select a methodology model that is a close fit, cognizant of that model’s limitations when applied to his or her project. For example, an innovative Web Information System might line up well with a agile method except for the lack of experience of the project team. By using the model, the project leader is able to identify this discrepancy and make plans in advance to compensate. Such plans may include team-building exercises, mentoring, weekly status meetings, and skill-building training, for example. Alternatively, when there is not a single methodology that is clearly the best fit, the project leader may elect to create his or her own “best practice” by combining various aspects of those models that most effectively address the organization, project, and team variables.
Table 4. Situations where the spiral model is most beneficial
Risk avoidance is a high priority
No need to absolutely minimize resource consumption
Project manager is highly skilled and experienced Policies or cultural bias favor approvals
Project might benefit from a mix of other development methodologies
Organization and team culture appreciate precision and controls
Delivery date takes precedence over functionality, which can be added in later versions
Table 5. Situations where parallel models are most beneficial
Rapid installation is a primary goal
Solid, experienced team
Strong project management
Excellent project-related communications
Stable team composition
Experienced project leader
Little pressure to conserve resources
Uniquely flexible development team
FUTURE TRENDS
Various development methodologies have risen to the forefront at different times in history. Royce proposed his linear model in the 1970s. Iterative development was widely discussed in the 1980s. Parallel models were popular in the early 1990s. Agile development emerged in the late 1990s. Currently, various agile methods are in vogue. As each new methodology has emerged, its proponents have espoused its virtues. Over time, each methodolody’s limitations have become known as well. The model presented here recognizes both the advantages and the limitations of each methodology. As new methodologies continue to emerge, the model provides a way for project managers to incorporate these emerging methodologies in a way that is appropriate for their organization, team, and project.
CONCLUSION
The rapidly changing business and technical environment that characterizes Web-enabled e-business, coupled with the unique nature of Web development teams themselves, combine to demand a new approach to system development methodology. No existing methodology is ideally suited for all e-business development endeavors. However, existing methodologies do provide a storehouse of options from which project managers can and should select and customize methodologies best suited to their organizations, their projects, their teams, and the unique nature of Web-enabled e-business. When a project most closely aligns with a single methodology, the project leader can compensate in the management of those few variables for which the chosen methodology is not a good fit. If project variables do not clearly indicate a preferred methodology, the project leader must employ those tools and techniques from each methodology that address the “best practice” of each variable. The model proposed here for Web-based systems could be applied to all types of information systems.
KEY TERMS
E-Business Environment: The business environment that is characterized by rapid time-to-market pressures, heterogeneous technical access, and quick IT strategic response requirements.
Extreme Programming: An agile system development methodology that decomposes very large projects into many small projects with minimal requirements and taking just a few weeks to complete, characterized by pair programming and refractoring.
Internet Time: The perception that product development and consumer acceptance now occur in a fraction of the time that they traditionally took (Odlyzko, 2001).
Prototyping: A tool used in system development methodology that lets users iteratively work with a small-scale mock-up of an information system, experience how it might function in production, and request changes until it meets their requirements.
Rapid Application Development: A system development methodology that aims to produce high quality systems quickly, primarily by using iterative prototyping, active user involvement, and computerized development tools.
Spiral Model: A system development methodology that utilizes an iterative process that is focused on minimizing project risk.
System Development Life Cycle: A system development methodology that divides projects into phases and uses written documentation to maintain control.
System Development Methodology: A model that is used to structure, plan, and control the process of developing an information system.
V Model: A modified system development life cycle which emphasizes quality assurance.
Waterfall Model: A modified system development life cycle which allows some overlap and splash back between phases.
Web Information System: An information system that is accessed through the Internet and usually tightly integrated with databases and transaction-processing systems.
