Design and Adoption of a Web Application Development Methodology for International TradingCharts.com, Inc.

Applied Project for Master of Business Administration

Athabasca University

Centre for Innovative Management

J. Michael (Mike) Ritchie

March 16, 2009

Ritchie 2

Abstract

Many small website development organizations struggle with process related problems. At International TradingCharts.com, Inc. (TradingCharts), those problems result in project failures including cost overruns and customer dissatisfaction. Since development of small Web application projects is at the heart of TradingCharts operations, addressing the weaknesses in methodology is vital to continued company success.

Exploring the question of appropriate development methodology requires answers to four questions:

• What are the strengths and weaknesses of methods employed by TradingCharts?

• What unique challenges face Web application development?

• What methodologies are described in academic literature?

• What methodologies do other Web industry participants employ?

These questions are researched though a thorough literature review of published methodologies and empirical studies of methodologies used in the industry, followed by an study of thirty projects undertaken by TradingCharts in 2008.

Analysis of TradingCharts’ projects revealed patterns of failure that underline need for methodology improvement. Over 40 percent of projects experienced problems. The research found that company methods are emergent and often inappropriate.

Web application development is unique in ways that affect selection of an appropriate development methodology. The most visible distinct characteristic is the emphasis placed on visual design and user interface aspects of Web applications, which results in multidisciplinary development teams and wide scope of development activities. Further, Web project methodologies must address wide diversity in scope of purpose, end users, platform support, and clients. Literature describes many formal development methods.

Software development methodologies can be located on a scale of increasing rigor, ranging from informal, to Agile, to predictive methods. Agile methods shun excessive documentation and embrace flexible processes, quick delivery of client value, and employee empowerment. Predictive methods are linear, stepwise, and fully planned and predictable. Predictive methodologies like the familiar waterfall and Systems Development Life Cycle methods are often heavy weight, and may be more appropriate for larger or critical projects. Agile methodologies like Extreme Programming and Feature Driven Development may be more appropriate for smaller projects and in environments where specifications are unstable, as is common in Web application projects.

Studies of methodologies employed in Web development organizations paint a surprisingly coherent and orderly view of Web development. Most methodologies

Ritchie 3

employed are primarily predictive, but contain infusions of Agile practices. The resulting amalgam of old methods and new practices delivers orderly benefits of predictive methods combined with the speed and flexibility of Agile processes. The apparently unlikely combination may be driven by local factors and industry characteristics.

Local factors affect selection of appropriate methodology, since alignment with characteristics including company culture, HR philosophy, current practices and customer expectations will improve efficacy and aid adoption. TradingCharts' culture, HR philosophy, current practices and work environment create an environment supportive of employee empowerment and teamwork.

Analysis of industry and local factors leads to understanding of the characteristics desirable in a development methodology for TradingCharts. The process must address needs for client interaction, provide an appropriate degree of guidance for an empowered team-driven environment, meet client expectations, suit the nature of TradingCharts' projects and pace, and provide flexibility by allowing for requirement changes.

The need for predictability implied by customer expectations and current practices contrasts with Agile-like need for requirements flexibility and team empowerment. A simplistic view of methodologies suggests that methods will be either predictive or adaptive. However, analysis of published and practical methodologies reveals that some Agile methodologies are comprised of Agile inner iterative cycles embedded within a predictive linear structure. One of those methodologies, Feature Driven Development (FDD) stands out as an ideal base upon which to build an appropriate development methodology for TradingCharts.

FDD processes and practices must be tweaked to address the unique requirements of Web development and align with local factors at TradingCharts. The most substantial change involves development of a Web application modeling practice. Other tweaks are simple modifications that align FDD practices with existing practices, scale it to team and project size, and adapt it to accommodate Web development and aid in implementation at TradingCharts.

A people-centric incremental implementation process is planned to guide TradingCharts in its adaptation and adoption of FDD. Group and individual meetings will address resistance, seek employee input and encourage buy-in, and facilitate the implementation process. FDD is phased in over a period of eight months, in a sequence selected to ease resistance and deliver near-term positive results. The schedule is not prescriptive, but will agilely adapt as dictated by factors such pace of staff acceptance and learning.

Adoption of Feature Driven Development will address many problems in the projects that TradingCharts undertakes, and unleash employee energy and skills to propel the company toward a successful future.

Ritchie 4

Table of Contents

ABSTRACT .............................................................................................................................................................. 2

TABLE OF CONTENTS .............................................................................................................................................. 4

1.0 INTRODUCTION ................................................................................................................................................ 5

2.0 RESEARCH PURPOSE AND QUESTIONS ............................................................................................................. 5

3.0 RESEARCH DESIGN ........................................................................................................................................... 6

3.1 Methodology .................................................................................................................................................. 6

3.2 Scope and Boundaries .................................................................................................................................... 6

3.3 Ethical Review ................................................................................................................................................ 7

4.0 LITERATURE REVIEW ........................................................................................................................................ 7

4.1 Methodology Defined ..................................................................................................................................... 7

4.2 The Need for Formal Development Methodology .......................................................................................... 7

4.3 Unique Characteristics of Web Development Projects ................................................................................... 8

4.4 The Range of Existing Methodologies .......................................................................................................... 12

4.5 Methodologies Described in Literature ........................................................................................................ 13

4.6 Web Development Methodologies used by Industry Participants ............................................................... 26

5.0 RESEARCH RESULTS ........................................................................................................................................ 30

5.1 Development Processes Employed by TradingCharts ................................................................................... 30

5.2 Unique Process Requirements of Web Development ................................................................................... 38

5.3 Summary of Development Methodologies Described in Literature .............................................................. 39

5.4 Methodologies Observed in the Industry ..................................................................................................... 42

6.0 ANALYSIS ....................................................................................................................................................... 43

6.1 Local Factors that Affect Selection of Methodology .................................................................................... 43

6.2 Desirable Development Methodology Characteristics ................................................................................. 45

6.3 Narrowing the Range of Options .................................................................................................................. 47

6.4 Selection of Best-fit Development Methodology .......................................................................................... 49

6.5 Adaptation of FDD Methodology Practices to TradingCharts ...................................................................... 49

7.0 RECOMMENDATIONS ..................................................................................................................................... 51

7.1 Proposed Development Methodology Design .............................................................................................. 51

7.2 Implementation Plan .................................................................................................................................... 54

7.3 Key Factors of Sustainable Success .............................................................................................................. 58

8.0 CONCLUSION.................................................................................................................................................. 60

9.0 REFERENCES ................................................................................................................................................... 61

10.0 APPENDICES ................................................................................................................................................. 67

10.1 Principles behind the Agile Manifesto ........................................................................................................ 67

10.2 Survey of TradingCharts Methods: data .................................................................................................... 68

10.3 Scoring of Practices and Process for Implementation Prioritization .......................................................... 69

Ritchie 5

1.0 Introduction

Many small Web development organizations struggle with process related problems. At International TradingCharts.com, Inc. (TradingCharts), those problems result in failures including cost overruns and customer dissatisfaction.

TradingCharts is a new media publisher that disseminates stock and commodity market information to a wide audience through its publicly-accessible Web sites. In addition to providing that service, the company also develops Web sites for local and provincial organizations1. Development of small Web application projects is at the heart of both operations.

Small Web application development projects share common challenges and concerns with other software development projects. Those challenges include perceived need for concise specification, concerns surrounding communication and coordination between development team members, and diverse threats such as inefficiency and specification creep. Existing literature describes development methodologies that attempt to address those challenges. Those methodologies express a range of development approaches and philosophies that fit a wide range of environments. Unfortunately, those methodologies are not as easily adapted within the unique development environment of small Web development projects, which differ from other software projects in aspects including diversity of developer skill set and team backgrounds, criticality of end user satisfaction, project scope, and development pace.

This paper addresses the question of formal Web project development methods. It explores the unique requirements of small Web development projects, evaluates TradingCharts’ processes and experiences, examines the formal development methods described in literature, and analyzes published empirical studies of methods employed by similar organizations. It then selects and adapts a formal development methodology appropriate for implementation at TradingCharts, in light of the cultural and business environment of the company and the unique characteristics of Web development projects. Finally, an incremental adoption plan prescribes a change management process that recognizes and addresses that importance of people in incorporating the new development methodology at TradingCharts.

2.0 Research Purpose and Questions

The purpose of this paper is to answer the question, “What formal development methodology will work best for TradingCharts?” That outcome will be derived through research and subsequent analysis of the following research questions:

RQ 1: What is the nature and what are the strengths and shortcomings of the development methodology employed at TradingCharts?

1 See http://www.mrwebsites.ca/our_clients.html for examples of third-party projects.

Ritchie 6

RQ 2: What are the unique characteristics of Web application development, and how might those factors affect the selection or design of an appropriate development methodology?

RQ 3: What development methodologies are described in literature, and which of those methodologies are suited or adaptable to Web design companies?

RQ 4: What development methodologies do other Web development organizations use?

Fulfilment of the purpose of this research—the selection of a development methodology for TradingCharts—will result from analysis of the four research questions in light of local aspects of TradingCharts operations, including company culture, development team size and environment, nature and diversity of company projects, and existing or accessible support technologies.

3.0 Research Design

3.1 Methodology

Research will be primarily a conceptual exploration of literature, with an additional reflective aspect.

Research initially focuses on a review of literature, which broadly explores formal development methodologies, and then focuses on methodologies developed specifically for use in Web application development. In addition, the review expands to include empirical studies of methodologies in use by small Web development organizations. The scope of papers and books reviewed leans toward those that describe Agile methodologies, and methodologies specifically designed for Web development.

Reflective aspects of the research include exploration and evaluation of development methods at TradingCharts. This research includes elucidation of current development processes and quantitative evaluation of project success as it relates to project methodologies.

3.2 Scope and Boundaries

After initial exploration of traditional and Agile development methods, the literary review is limited to articles that relate directly to formal development methods intended for, or particularly well suited for use in Web technology projects. Literature reviewed includes articles published by practitioners to supplement academic literature when necessary2. Research does not consider methodologies based on specific technologies or tools, except to the extent that aspects of those methods might be employed without the use of those technologies or tools. The quantitative primary research is limited to correlation

2 Literature published by practitioners supplements academic literature when academic literature is insufficient in certain areas of exploration.

Ritchie 7

of project parameters, methods and outcomes in thirty randomly selected projects completed by TradingCharts in 2008.

3.3 Ethical Review

Research involved in this project is exempt from ethics review. Primary research is limited to that portion of this study that evaluates development methods employed by TradingCharts. That research is “related directly to assessing the performance of an organization or its employees or students, within the mandate of the organization or according to the terms and conditions of employment or training” (Jugdev, 2008) and is therefore considered exempt from ethical review.

4.0 Literature Review

4.1 Methodology Defined

The term methodology conveys varied meanings depending on context and audience. The Canadian Oxford Dictionary defines methodology as "a body of methods used in a particular branch of activity". In A Dictionary of Computing, Daintish and Wright (2009) describe the term as "a coherent set of methods used in carrying out some complex activity... most frequently used in terms such as programming methodology". TechEncyclopedia (2009) suggests that the term implies specific outcomes, in its definition of methodology as "a specific way of performing an operation that implies precise deliverables at the end of each stage". Cockburn (2002) expands those definitions by discussing the concept of methodology depth, describing "little-m methodologies" as methods that define a few techniques and roles, and "big-m methodologies as those that prescribe every aspect of development processes, practices and standards (p 65).

This paper considers methodology in the broadest context, as a collection of cohesive methods, processes, practices, activities and outcomes that together define and prescribe a coordinated and effective approach to software development.

4.2 The Need for Formal Development Methodology

According to Boehm (1988), software development process models are important because they lay out the order of phases and tasks that a project should follow; without an appropriate process, projects might "come to grief" (p 61). This contrasts with Nandhadumar and Avison (1999) who contend that traditional development models are "a necessary fiction to present an image of control" (p 7).

In 2006, Boehm again underlines the need for appropriate methodology, warning that most software projects failures result from factors that application of appropriate methodology would mitigate. Such problems include “lack of user input, incomplete and changing requirements, unrealistic expectations and schedules, [and] unclear objectives” (p 22). Palmer and Felsing (2002) support that perspective, stating that

Ritchie 8

some developers list requirements, then go straight to writing code—a practice they suggest might suffice for simple jobs, but not for more complex projects.

Such problems are not limited to general software projects. Epner (2000) found widespread failure in Web projects, with 84% of projects failing to meet business needs, 53% lacking in functionality, 69% of projects suffering from delays, and 63% running over budget. Whitson (2006) agrees, and explains that Web developers often underestimate project complexity and do not perceive need to apply formal development methodology to Web projects.

In numerous attempts to address these issues, literature is rife with descriptions of formal methods that range widely in philosophy and degree of rigor. This variety reflects different values, and contrasting opinions of the roles that formal processes should play in guiding software development. In addition to the variety in approach, methodologies differ in scope and detail.

The question germane to this research is therefore the selection of synthesis, development and application of a formal development methodology appropriate in values and approach, breadth and depth, for use at TradingCharts. Exploration of that question requires discussion of a number of published development methods, grounded by consideration of methods in use by Web development practitioners, and cognizant of factors unique to Web development projects.

4.3 Unique Characteristics of Web Development Projects

While all software projects share a common need for formal development methodologies, Web projects have unique characteristics that might affect the composition and characteristics of an appropriate Web development methodology. According to Deshpande and Hansen (2001), traditional software engineering processes are too narrow, and a different approach is required for Web applications. Web development projects differ from the development of other software in four main aspects: false perceptions of simplicity, unique product attributes, diversity of users and platforms, and the wide skill set needed to develop successful Web applications.

4.3.1 History and Misperceptions

The history of the Web development industry produced a legacy of damaging false perceptions regarding the complexity of Web projects. Those perceptions link to a naivety regarding the need for formalized methodology. According to Murugesan and Ginige (2005), many developers continue to approach Web development as an "authoring work", instead of the application development process that it is (p 6).

In its early history, Web applications quickly evolved from static collections of pages and graphics into integrated systems that liberally mixed presentation, static and dynamic content, and processing instructions into an unstructured conglomerate. However, practitioners discovered that Web applications built on this architecture were brittle and difficult to manage and update, since it was challenging to make changes to code spread throughout many pages of the site (Jazayeri, 2007). This realization spurred

Ritchie 9

adoption of a more structured architectural paradigm, in which most programming code is centralized in a few code files, while the extent of programming code in the actual display pages is limited to what is displayed to the user (Jazayeri, 2007). This level of structure is necessary to allow Web development to grow in complexity into successful, complex applications. However, Web development organizations like TradingCharts have been slow to recognize that this new complexity and scale of development demands more robust development methodology.

4.3.2 Product Attributes and Client Expectations

Web applications possess unique product attributes and client expectations that are not as dominant in other software projects. For example, Web projects differ from other software projects in product scope. Both McDonald and Welland (2001), and Murugesan and Ginige (2005) contend that web application deliverables often consist of code and design which are developed in parallel with the data upon which those components act. Murugesan and Ginige also recognize that Web applications must include consideration of ongoing content creation and management. At least for large Web applications, Turban, McLean and Wetherbe (2004) disagree, stating that large applications require integration with existing systems and data. There is likely truth in both perspectives in different contexts, and both perspectives are relatively unique to Web application development.

McDonald and Welland (2005) also perceive a difference in that other types of applications generally coordinate between the business model, domain model, and software model, while Web applications must also incorporate an artistic model (p 7) which adds complexity to the development process. Lang and Fitzgerald (2007) expand upon that concept, stating that Web development is the "fusion of heretofore disparate fields...very different from what has gone before" (p 217).

The diversity and breadth of Web application scope may in part be driven by diversity of purpose. Wallace, Raggett, and Aufgang (2003) state that Web projects are often new marketing tools (p 9). Powel agrees, and further describes Web development to be a blend of "print publishing and software development... marketing and computing...internal communications and external relations, and...art and technology (2000). In a different perspective on the diversity of purpose, McDonald and Welland suggest that Web projects more often participate in business process redesign (pp 9-10) and often have a more direct impact on business processes than other types of software applications, which they claim are "largely implementations of existing business practice" (p 8). In addition to scope, Web development projects differ in other attributes such as development pace.

Compared with development of other applications, Web development operates at a higher velocity, and with greater flexibility. Wallace et al. (2003) suggest that Web methodologies must deliver frequent iterations in "weeks rather than months" (p 4). Sheikh and Tarawnet concur, stating that Web projects have "tighter time frames", and require "fine-grained ongoing evolutionary maintenance" (p 481). In part, time-to-market demands drive the rapid development and release pace, but the pace is also encouraged by the ease with which changes to a Web application are made and

Ritchie 10

distributed. Jazayeri (2007) attributes some of the popularity of the World Wide Web with this very ability to release new versions, and the ease of adding functionality to Web applications without the need to package, distribute and install new releases. Lang and Fitzgerald (2007) suggest that the rapid pace of website development demands that Web development methods focus on "agility, speed, efficiency and productivity" (p 217). Difficulty in defining requirements confounds the rapid pace. Murugesan and Ginige (2005) state that it is "not fully possible" to completely define Web requirements at project initiation, because the Web application will evolve as the project progresses. These concerns suggest that an appropriate methodology must enable quick or continuous releases, and allow for considerable flexibility in requirements.

Murugesan and Ginige (2005) note other significant differences in Web projects. They observe that Web-based software must employ creative graphics and incorporate multimedia in the user interface, and warn that displeased users might more easily switch to a competitive product. The merging of graphics and functionality, also dictates different practices, since testers must perform some tests “by eye "(Wallace, D., et al., 2003, p 9). Kushwaba et al. (2006) concur, offering as a solution that Web development methodologies incorporate "engineering, management, and cognitive principles involving a high user-centric basis" (p 1). Secondly Murugesan and Ginige observe that Web development uses "cutting-edge, diverse technologies" (p 8), and go on to warn that those technologies are quickly evolving with constant advances and new standards. Finally, they note that Web projects demand greater consideration of security and privacy issues than traditional software. These issues must be addressed through a robust, user-centric, yet flexible methodology that is not strongly tied to specific technologies.

4.3.3 The Human Dimension

The people dimension of Web application development demands fresh consideration of approaches to clients and end users. Literature observes distinctions between the development of Web and other software applications, in terms of the inaccessibility and diversity of end users, the range of Web browser applications and platforms, and unique characteristics of Web application sponsors.

Kushwaha et al. (2006) suggest that one reason for the complexity of Web development is in the lack of knowledge about end users. This issue arises from the potentially immense reach enjoyed by the medium. Web projects deployed publicly on the World Wide Web are often targeted to a "vast, variable user community...with varying requirements, expectations, and skill sets"(Murugesan and Ginige, 2005, p 7)3. Deshpande and Hansen (2001) agree that developing for unknown users presents a unique challenge to Web development methodologies.

3 TradingCharts’ financial websites reach over 350,000 unique users each month, scattered across many countries. For projects related to the financial Web sites, end-user diversity is a critical concern. However, the company has also developed workflow systems targeted for use by a very small number of well-known users. Such projects enjoy much greater ease in development, since concerns about diversity of end user culture, their cognizant abilities, or technical capabilities are greatly reduced.

Ritchie 11

The range of software and hardware platforms employed by users of World Wide Web is also unique. Wallace et al. (2003) agrees with Murugesan and Ginige (2005) in voicing concern for this diversity, noting that a wide range of devices and formats must be considered for Web applications to work appropriately. An ideal methodology will address that challenge, perhaps through innovative testing practices.

Another unique human aspect of Web development relates to project sponsors and clients. Grossman et al. (2004) note that Web developers are often isolated from the client, resulting in poor communication that results in inefficiency, and motivates developers to make assumptions about client needs4. This is a specific concern identified by Beck and Andres (2005), although their solution in the XP methodology—having a full-time client on site—is impractical for use by distant customers and in small project sizes. A related concern described by Bauer (2005) is that Web clients do not know what is possible; this issue is echoed by Wallace et al. (2003) who note that Web project customers are not as experienced as clients of other software projects; Web clients often ask Web developers provide guidance on project opportunities and threats.

Another people-related challenge and distinction of Web projects results from the wide range of skills required, and the resulting multidisciplinary nature of Web development teams. Wallace et al. (2003) suggest that this diversity has affected the evolution of Web methodologies. At first, a single multitalented webmaster performed all Web development activities. In contrast, Web development now incorporates many disciplines and skills; each brings a legacy of processes, practices and approaches to incorporate into the development methodology. Murugesan and Ginige (2005) note that Web development is a greater melding of visual design and coding than is found in other software development, and as a result, development teams are "multidisciplinary, like a film production team" (p 21). Wallace (2003) notes the impact this factor has on development models, stating that Web project management must not be modeled after software or marketing practices, but "as a new entity consisting of multidisciplined teams with close coupling to customer stakeholders" (p7).

The small size of Web development organizations5 directly affects selection of development methodology. Richardson et al. (2007) note that there is a perception in small organizations that formal methodologies and practices are “time-consuming and targeted to large organizations” (p 18). They go on to describe small organizations as “extremely responsive and flexible” with a management style which encourages entrepreneurialism (p 19). The challenge is to find balance by building upon the strengths of small organizations, while addressing shortcomings that result from weak or inconsistent methodologies.6

4 TradingCharts works with many distant clients, often by email or telephone. Company experience suggests that such communication can be adequate, although it suffers from problems of slowness, potential for miscommunication, and lack of richness which can hinder activities such as creative brainstorming.

5 TradingCharts has a development staff of five.

6 Please see section 4.1 for details of those weaknesses.

Ritchie 12

The many ways in which Web development differs from traditional software development suggest that merely adopting a traditional methodology for Web projects might not suffice. A non-traditional methodology or adaptation might be required.

4.4 The Range of Existing Methodologies

Boehm (2002) visualizes that development approaches are located on a continuum of formality and rigor, from adaptive approaches on one side of the scale, to predictive methods toward the opposite end.

Figure 1: Boehm’s Continuum of Development Methodology (Boehm, 2002)

On the adaptive side of Boehm's scale are newer Agile processes that "welcome changing requirements, even late in development" (Beck et al. 2001). Such processes accommodate, if not embrace change, and assume that agility in process and flexibility in design will deliver best value to the client. According to Fowler and Highsmith (2001), "facilitating change is more effective than attempting to prevent it” (p3). This philosophy contrasts sharply with predictive or "monolithic" methodologies (McDonald and Welland, 2001) which are predicated on the assumption that project requirements can be "completely locked in and frozen" (Abrahamsson et al., 2002, p 10). The predictive approach allows for delineation of project scope, enumeration of deliverables for contracts, scheduling and resource allocation for project control, and avoidance of cost overrun and specification creep by restricting change, although those benefits might accrue at substantial cost in overhead, flexibility and delivered value.

Other dimensions of difference in development methodologies are apparent in degree and target of focus, and in process formality. A comparison of the Agile methodologies Extreme Programming (XP), and Feature Driven Development (FDD) provides powerful examples of those differences. According to Khramtchenko (2004) XP focuses mainly on the activity of code generation, with code writing performed “on the fly” (p 12) whereas FDD has formal design and review processes. Similarly, XP espouses minimal documentation whereas FDD encourages a modest level of documentation (Palmer and Felsing, 2002). Similar differences in focus and formality exist in other established methodologies.

Considering the range of development philosophies and motivations, it is perhaps unsurprising that Abrahamsson et al. (2002) contend that a single one-size-fits-all software development process is not available for all imaginable processes.

Ritchie 13

4.5 Methodologies Described in Literature

4.5.1 Informal Methods

When software development was in infancy, programmers did not understand need for formalized process. They would simply "ask a few questions, then go about writing code" (Turban et al., 2004, p 634). Boehm (1998) describes the process as the "code and fix" method, which consisted of two steps:

1) “Write some code”

2) “Fix problems in the code” (p 62).

Projects following this process often failed (Boehm 1998) which led developers to realization that discipline and order were required, and thus to the development of predictive methods such as Systems Development Life Cycle (SDLC) (Turban, 2004, p 635).

4.5.2 Predictive Methods

Although there is no standard SDLC, a representative configuration can be visualized as an eight-stage method consisting of:

1) Feasibility/initiation

2) Plans and analysis

3) Product design

4) Code or acquisition

5) Integration

6) Implementation

7) Evaluation

8) Operations and maintenance7 (Boehm 1998, Turban 2004)

Early stage wise SDLC methods gave way to the enduring waterfall method, which allows for feedback and limited iteration between consecutive development stages (Boehm 1988). Despite the allowed iteration, the model was usually implemented as a purely sequential process (Boehme, 2006). As such, the waterfall method remained encumbered by reliance on rigid documentation and specifications frozen in the early requirements phase, followed by complete design and design reviews, finally followed by code and testing only when the design was finalized. That encumbrance aligns poorly with many projects, such as end user applications (Boehm, 2002), and it adds onerous system overhead in the production of non-deliverable artifacts. Many process models followed the SDLC, which continues to influence many modern methodologies. Turban (2004) contends that all eight steps remain important for larger projects today, while supporters of some contemporary methodologies remain highly critical of the method. According to Palmer and Felsing (2002), predictive methodologies are “heavy

7 The eight steps listed are an amalgam of the waterfall methods described by Boehm (1988) and Turban (2004).

Ritchie 14

on ceremony and administrative activity”, and good at keeping people busy with paperwork, meetings and reports (p 4).

Many of the development models to follow waterfall methods attempt to address these weaknesses, through process design alone or through a combination of process and tools. The waterfall gave way to the evolutionary model, which engaged end users in an iterative design process intended to elicit better understanding of end user needs (Boehm, 1998). However, the evolutionary model suffered from problems analogous to those of the code-and-fix method, with similarly poor results. More methodologies were to follow in attempts to address these issues.

Boehm's Spiral Model (1988) attempts to address the weaknesses of waterfall, and to support concurrent development processes. This risk-driven methodology is visualized through ever-expanding spirals of increasing investment, commitment and progress. Each spiral passes through common phases including identification of objectives, evaluation of risk and alternatives, prototyping, design, validation/verification, and planning. Repeated identification and analysis of project risks is a primary driver of the system, used to determine appropriate levels of maturity in each design and development activity (Boehm, 2006). Unfortunately, the Spiral Method exhibits weaknesses when applied in smaller or flexible projects. For example, premature freezing of scope can encourage stakeholders to request excess functionality up front with insufficient consideration of business value (Mugridge, 2008). Boehm (1988) admits that use of the Spiral Method might be limited to "large, complex, ambitious software systems"(p 71). Unfortunately, those terms seldom describe Web development projects.

While concepts and adaptations of newer waterfall-like methodologies might be of interest in Web application development, they do not substantially alter the basic philosophy of SDLC/waterfall-based development methods, which are predicated on requirement predictability, attendant early requirement freeze, scope limitation, and process/resource control.

Beck and Andres (2005) draw a convincing and discouraging connection between Taylorism and traditional SDLC/waterfall-based methodologies. According to Pruijt (2000), Taylorism separates “conception from execution”, implies low trust in the workplace, and requires control to impose strict work guidelines for production staff. According to Beck and Andres (2005), Taylorism treats workers as mostly-interchangeable cogs in a machine, while engineers decide how work should be done and how long it should take, and quality control is separated from production to the point that it assumes a punitive role. They go on to state that our development methodologies have adopted that structure, which is “bizarrely unsuited to software development” (p. 132).

The philosophies embedded within predictive methodologies contrast sharply with the values embraced by agile development methods.

Ritchie 15

Table 1: Summary of Major Differences between Agile and Plan-driven Methods (Boehm, 2002)

Ritchie 16

4.5.3 Agile Methods

Agile development methods differ in philosophy and practice with plan-driven predictive methods8. Agile methodologies are based on the Agile Manifesto (Kent et al., 2001) which endorses the following values:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Those values are expressed through twelve principles.9 According to Abrahamson et al. (2002), Agile methodologies embrace agile values and enact the agile principles by:

• delivering useful artifacts

• confidence and reliance in people

• collaboration

• quality and excellence

• simplicity

• continuous adaptation

Central to each of the Agile methodologies are characteristics such as rapid, incremental development cycles, people-centricity with close communication between stakeholders, easily understood and employed processes, and specification flexibility (Abrahamsson et al., 2002). The values and principles of Agile methodologies seem intuitively aligned with the needs of Web application development: “agility, speed, efficiency and productivity” (Abrahamson et al., p. 98).

Two of the best-known agile methodologies are Extreme Programming and Feature Driven Development. While many other agile methodologies exist, these methods deserve specific study because they:

• Have been deployed in real development environments

• Do not rely upon specific technologies

• Are accessible and documented

• Provide an illustrative view into the range of agile practices10

• Are the basis of several Web development specific processes

An exploration of the two methods is therefore of value in research intended to identify an appropriate development methodology for TradingCharts.

8 Table 1 summarizes some of the major differences between plan-driven and agile methods.

9 Please see Appendix 10.1 for the full text of the twelve agile principles.

10 Please See section 4.4.4 for agile methodologies (and adaptations) for specific use in Web projects.

Ritchie 17

Extreme Programming

Extreme Programming (XP) might be considered one of the most agile development methods. XP is mentioned frequently in the literature (Turban et al. 2004; Cao 2008; Abrahamsson et al., 2002; McDonald and Welland, 2001; etc.), and may therefore be the most widely known Agile methodology. Whitson (2006) describes Extreme Programming (XP) as a “natural fit” for Web development due to its quick, iterative cycles, minimal design, and acceptance testing (p. 23). Beck11 and Andres (2005) describe XP as a lightweight methodology that can be deployed for teams of all sizes, is based on addressing constraints, and is agile enough to adapt to "vague or changing requirements" (p. 3). According to Beck and Andres (2005), software development can be compared with driving a car; you need to "stay aware...adapt...change" (p. 11). Beck’s design of XP reflects that philosophy.

XP employs practices such as small/frequent releases, minimalistic design, test-driven development, frequent refactoring, code authors working in pairs, team code ownership, continuous code integration, sustainable work hours, on-site customer presence, and open work area design. XP works best in team sizes of three to ten members, who should be physically located in the same workspace (Abrahamson et al. 2002).

A good methodology must be built upon values, principles and practices (Beck and Andres, 2005), and XP is designed in that manner. XP embraces five values:

• Communications

• Simplicity

• Feedback

• Courage

• Respect

Those values are realized through a set of primary and corollary practices. The practices are situation-dependent, and chosen according to circumstances (Beck and Andres, 2005). Each of the primary practices can be implemented independently of other to delivery immediate benefit. The primary practices include (Beck and Andres, 2005):

• Sit Together: the entire development team shares a single space.

• Whole Team: include all required skills and people on the team.

• Informative Workspace: use wall space to post “story cards”12.

• Energized work: do not overwork staff; use forty-hour workweek.

• Pair programming: developers work in pairs, with one writing code, and the other planning and continuously reviewing.

11 Extreme Programming was developed by Kent Beck while working on the C3 payroll system for Chrysler.

12 See practice 6.

Ritchie 18

• Stories: plan projects in small units of client-valued functionality; write up on small index cards.

• Weekly cycle: full team meeting each week to review progress, have customers select next stories to implement, break stories into tasks and have members sign up for tasks.

• Quarterly cycle: plan project one quarter at a time

• Slack: In all planning periods, include optional tasks that can be dropped if project falls behind schedule

• Ten-Minute Build: Use automatic build-and-unit-test system that runs in ten minutes

• Continuous Integration: integrate and test ever few hours

• Test-first programming: design unit tests before writing code

• Incremental Design: use minimal design up front; improve and expand design every day

Figure 2: Extreme Programming Methodology (Wells, D., 2000)

Is XP appropriate for Web design? Despite the Whitson’s (2006) view that XP is a good fit, some concerns arise. For example, the XP practices of incremental design and continuously negotiated scope do not mesh well with customer expectations for budgeting and predictability. While Beck and Andres (2001) claim that XP practices can be applied individually, they also state that the greatest benefit of XP will compound when “interactions between the processes amplify their effect. Fortunately, there are other Agile methodologies to explore, some specific adaptations for Web development, and at least one—Feature Driven Development—that is located in a middle ground between the predictive methods like SDLC, and the free-wheeling design-while-developing method of XP.

Feature Driven Development

The Feature Driven Development (FDD) methodology is based more in traditional approaches than the XP method is, and its application of the four values of the Agile Manifesto are more moderate. For example, FDD invests in an initial design process

Ritchie 19

that is missing from XP. According to Palmer and Felsing (2002), a reasonable amount of work is done up front in an FDD methodology which ensures that “the output converges on the desired result” (p 58).

FDD is model-driven, employing a user-centric domain modeling process at the start of each project, to enable requirements analysis and facilitate knowledge transfer, common vision and a shared understanding upon which FDD successes rely (De Luca, 1). The importance of domain modeling is echoed by Palmer and Felsing (2002), who explain that the domain model is vital; “without it, you can very quickly end up; lost or driving in circles, continually reworking and refactoring the same pieces of code” (p 37). Deconstruction of the domain model gives birth to the core concept of FDD: features. Features are defined as atomic “client-valued piece[s] of functionality”; FDD processes are thus structured around defining the features, then “designing and building each feature in an iterative manner” (Bauer, 2005). In addition to providing structure and flexibility, the feature-based approach aids in tracking progress.

Although more traditional than XP, the FDD methodology is not as thoroughly documented or academically explored. The primary author and proponent of FDD, Jeff De Luca, has not published academic papers about the method. However, the method is formally described by Palmer and Felsing (2002), less-formally documented on De Luca’s website (http://www.nebulon.com/ ), and discussed in depth by practitioners through an active online user community (http://www.featuredrivendevelopment.com/ ) . With modest adaptation, practitioners and authors Bauer (2003, 2005) and Xiaocheng, Paige, Polack, Chivers, and Brooke (2006) recommend the use of FDD in Web development.

FDD is built upon a core of best practices. The practices are not new, but the combination is. According to Palmer and Felsing (2002), the practices could be implemented a few at a time, but the full benefit of FDD arises only when the entire method is implemented. They also state that "FDD is flexible and adaptable, but there are some best practices that need to be included in order for it to be an FDD process” (p 36):

• Domain object modeling

• Developing by Feature

• Individual code ownership

• Feature teams

• Inspections

• Regular builds

• Configuration management

• Reporting/Visibility of results

FDD prescribes five specific processes which together fully encompass the methodology. Each of the processes is easily understood, and each can be documented in less than two printed pages (Bauer, 2005). The first three processes

Ritchie 20

encompass the entire scope of the project, while the last two processes iterate for each feature. The five processes described by De Luca (2) are:

1) Develop an Overall Model: Model the domain using UML diagrams.

2) Build a Features List: Decompose model of entire project by enumerating and describing features in terms of the business domain language.

3) Plan By Feature: Determine the development sequence of all features in the project, based on dependencies, staff resources, and business priorities.

Repeat processes 4 and 5 for each feature:

4) Design By Feature: Select feature development team, explore and expand feature specification, and then validate feature design.

5) Build by Feature: Write code that implements feature, perform unit tests, and then integrate with project.

Figure 3: Five Phases of the FDD Methodology (Palmer & Felsing, 2002)

According to Palmer and Felsing (2002), the FDD approach balances management need for analysis and design with customer need for business-valued progress. In so doing, FDD avoids “analysis paralysis often found in...traditional processe[s] while avoiding the refactoring that results when coding begins before a shared understanding of the project exists” (p 73). This balance might help address some concerns that arise from implementing a more Agile methodology such as XP.

`4.5.4 Methods Specific to Website Development or Small Projects

A number of methodologies have been proposed, that are specifically developed for Web development. Unfortunately, many of the methodologies are light in detail, numbers of practitioners are few, and no Web specific methodology is supported by empirical research of their efficacy or practicality. Nevertheless, these methods provide valued opportunities for exploration into candidate methods and practices appropriate for Web development.

Web Engineering

Web Engineering brings a traditional engineering aspect to Web development. The predictive method attempts to balance programming, publishing and business aspects of Web development (Whitson, 2006). The process applies “scientific, engineering and

Ritchie 21

systematic approaches”, to bring control to Web projects (Murugesan and Ginige, 2005, p 3). However, according to Whitson (2006) no process or set of practices has emerged as the single accepted Web Engineering methodology.

Murugesan and Ginige (2005) have designed a Web Engineering process that appears firmly based in traditional, predictive software development methodologies. They identify four waterfall-like stages in the Web development process:

1) Context analysis

2) Architectural design

3) Web page design

4) Web maintenance

Software Engineering for Web

Closely related to the Web Engineering process described by Murugesan and Ginige (2005), is the Software Engineering for Web (SEW) method developed by Hseih (2003). Like Web Engineering, SEW is a predictive process that employs a substantial up-front design process, with implementation proceeding once the design phases are complete. However, SEW differs from Web Engineering in two material aspects: SEW uses modeling in the design process, and it better recognizes the unique needs of Web development. Hsieh prescribes three phases in the Software Engineering for Web method.

1) The Structural Design phase identifies Web pages, functionality of each page, server-side and client-side processing, and page relationships. The outcome of this phase is a modelling diagram that Hseih (2003) calls a page flow diagram. Hseih’s diagram models visible Web pages, and hidden functionality, which Hseih labels invisible Web pages. Arrows illustrate potential paths between the pages, labelled by the events causing the execution and the data involved.

2) The Detailed Design phase addresses the traditional technical design aspects of software development, and design aspects specific to Web design including visual and user interface design decisions.

3) The Implementation phase is when the client-valued work occurs, including client-side and server-side code.

Of particular interest might be Hseih’s modeling method, since it demonstrates that non-traditional modeling methods may be useful in Web application development.

Software Development Process for Small Projects (SDPSP)

According to Russ, Melissa and McGregor (2000), small software projects are unique in that:

• The customer is a specific and active stakeholder.

• The team size is small, but quality demands are high.

• The team might include members with part-time participation.

Ritchie 22

• Interactions are usually informal and efficient.

• Small teams usually enjoy shallow management structure.

• Small projects can be more easily adaptive than larger ones

In light of these factors, Russ et al. propose a software methodology that they name Software Development Process for Small Projects. This predictive method delineates between artifacts as being actuals (products central to development), and by-products (side effects of attempts to create actuals).

Specific roles are identified in the methodology, which itself is comprised of eight phases reminiscent of waterfall methods.

1) Requirements/scoping

2) Domain analysis

3) Application analysis

4) Architectural design

5) Application design

6) Program Implementation

7) Integration

8) System test

Inspection is employed at each phase, to evaluate success of each phase and if necessary, work iterates back to previous phases.

While the process described by Russ et al. is not unique, it is interesting in its elucidation of phases that are similar to those taken in TradingCharts’ existing methods.

WebHelix

WebHelix is a unique methodology developed by Whitson (2006), and based loosely upon Boehm’s ( 2006) Spiral Model.

Figure 4: The WebHelix Process (Whitson, 2006, p 25)

Ritchie 23

The core of the method is an iterative spiral that includes five steps: analysis, design, code, test, evaluation; each step creates a working prototype, and each iteration of the spiral and each step implements a working set of features. The spirals are nested between start up processes of business evaluation and project planning, and ending processes of deployment and maintenance.

The process is attractive in its simplicity, agility and in its seeming fit with naturally agile methods. Developed primarily for use in an academic setting, Whitson (2006) claims success in using the methodology in commercial Web development

Cognitive Web Engineering

Kushwaha,Singh and Misra (2006) propose a methodology that is driven by a need they perceive: to recognize and address user-based cognitive factors in Web development. According to Kushwaha et al. (2006), the lack of user-centric approach in the requirements, analysis and design of Web applications contributes to high failure rates. They contend that such failure might be mitigated by use of a a cognitive process of Web development. This contention meshes with the opinions of Olsen (2005) who states that user-centric processes such as prototyping will reduce overall development costs” (p 5), and Boehm (2006), who relates that software project failures can result from lack of user input. Kushwaha et al. (2006) suggest that the need for cognitive approach is particularly acute for Web applications, which reach a varied and inclusive user group. The authors also recognize that consideration in Web development processes should recognize cognitive differences within members of the Web development team.

Kushwaha et al (2006) do not describe the Cognitive Web Engineering in terms of a defined series of phases, but they do prescribe major activities of the method, all of which are user-centric.

The authors have researched this process from the cultural perspective of the subcontinent of India, in which Kushwaha et al. (2006) relate that a “fair amount of the business community is uneducated or fairly literate just enough to carry out their business” (p 3). It is possible that the need for cognitive design is more acute when the Web application targets a different cultural environment. Despite that concern, Kushwaha et al. (2006) demonstrate the need for human-centric activities in Web development methodologies.

Agile Approach for Web Systems Engineering

Souza and Falbo (2004) suggest a development framework named Agile Approach for Web Systems Engineering (AAWSE). Although based on traditional predictive approaches, the method includes practices that embrace agile values, placing emphasis on delivering client value, and on lightweight modeling activities. However, those practices do not embody Agile values as fully as methods like XP.

Ritchie 24

WebXP

Martel and Martel (2002) claim that XP is a “good fit for many Web-based projects” (p 68). Wallace, Raggett and Aufgang (2003) concur. Working to reconcile the unique characteristics of Web development with the Agile nature and challenging practices of XP, Wallace et al. (2003) developed WebXP, an adaption of XP intended for deployment in Web projects.

Like XP, WebXP is an iterative process driven by fulfillment of small portions of client-valued functionality expressed in XP stories. Unlike XP, WebXP places additional emphasis on initial planning, and Wallace et al (2003) suggest that the iterative process starts with a few standard iterations/stories that address infrastructure design and technology risks.

WebXP diverges from Beck’s and Andres’ (2005) description of XP in additional practices. Wallace et al. (2003) recommend that estimation of effort be based on carefully maintained records of past work, to help fulfill client expectations of fixed-cost estimates13. Wallace et al. (2003) also recognize that Web project clients might have difficulty trusting the developing organization. To build trust, Wallace et al. (2003) propose that developers offer the client a “Customer Bill of Rights” (p 24), which includes promises to provide a full plan and rights to change direction, receive value, and see progress and remain informed.

WebXP appears to be a practical adaptation of XP to Web application development.

FDD for Web

Some practitioners enthusiastically endorse FDD as a methodology for Web development, and aspects of FDD are recognized in other published Web project methodologies14. This might be because FDD is a more “straightforward process” as compared with other agile processes (Xiaocheng et al., 2006, p 306), and one that seems to be a closer fit with the familiar SDLC paradigm, due to the significance FDD places on initial modeling and planning (Khramtchenko, 2004). Web development practitioner Bauer (2005) contends that FDD is simple to understand and easy to implement in a Web development context.

Xiaocheng (2006) suggests an adaptation of FDD to Web projects, which addresses security concerns. Xiacheng’s adaptation reduces the FDD process to four steps by merging the Build Features List and Plan by Feature processes of De Luca’s original FDD methodology15. Further, Xiochange (2006) extends De Luca’s processes to include specific security-related activities in every phase.

13 Fixed rate estimates are commonly expected by TradingCharts’ customers.

14 WebHelix in particular is similar in its nesting of Agile iteration of feature implementation within an overall predictive framework.

15 Please see the previous section entitled “Feature Driven Development” for details of De Luca’s FDD method.

Ritchie 25

Bauer (2003) voices unequivocal support to the use of FDD in Web development from the perspective of practitioner. In an exploration of available methodologies, Bauer (2005) compares methodologies based on simplicity, size of method documentation, implementation cost, risk of failure, and the existence of “real-world examples”. Bauer concludes that FDD is “far better suited to Web development”. Bauer’s (2005) implementation of FDD for Web projects makes few excursions from De Luca’s process; Bauer claims that the unadulterated FDD methodology works well in Web development projects.

LIPE

Zettell, Maurer and Wong (2001) propose an XP-based development methodology named Lightweight Process for E-Business. Although designed for a small venture-capital funded e-company, the method might provide some guidance in the design of an appropriate development methodology for TradingCharts, due to similarities such as small team size, the desire for minimal process overhead, and focus on results.

LIPE employs all XP practices except for Pair Programming, which is replaced with code inspection. Zettell et al. detail LIPE in terms of “activities, artifacts, roles and tools” (p. 5) through elaborate diagrams. LIPE defines roles in terms of activities, not individuals. By defining roles and separating quality responsibility into a distinct role, Zettell et al (2001) introduce an element of Taylorism that seems incompatible with Agile processes.

Zettell et al. (2002) admit that LIPE has not been implemented in the industry, and no empirical data is therefore available

Agile Web Engineering

McDonald and Welland (2002) propose a formal methodology named Agile Web Engineering (AWE). The authors suggest that the system style is based on the Boehm's Spiral Model, and yet endorses Agile principles. A closer look at the model suggests that the similarity to Boehm’s spiral is superficial.

AWE recognizes the diverse nature of members of Web development teams, and emphasizes collaboration between various disciplines. MacDonald and Welland (2002) embrace Agile appreciation of team members as critical to success, and contrast the AWE method focus on delivering working systems with the emphasis predictive methods place on documentation. The authors claim that AWE embraces all principles of Agile development. Unfortunately, MacDonald and Welland’s description of AWE is light on specific practices and implementation details, although it offers promise in its recognition of the unique requirements of Web development, and in embracing Agile methods.

According to Lang and Fitzgerald (2007), “there is a vast and ever-growing 'jungle' of academically-produced web/hypermedia system design methods in the literature, none of which are being used to any significant extent in practice"(p 217). It is the intent of this paper to draw pragmatic connections between academia and practice.

Ritchie 26

4.6 Web Development Methodologies used by Industry Participants

Whitson (2006) contends that Web project development proceeds with "little or no design methodology" (p. 21). Other academics warn of crisis in Web development due to the industry’s chaotic development methodologies. While empirical data of development processes employed in Web projects is limited, available data suggests that the perception of Web development as chaotic or troubled is flawed.

Despite the lack of comprehensive empirical data, a number of surveys provide guidance, if not a definitive description of methods presently employed in Web development projects. Those surveys include:

• Lang and Fitzgerald (2005) explore formal methodologies in hypermedia applications, which they define to be all hyperlinked applications, including Web sites and help systems. The survey identifies a number of formal methods employed within the industry. Lang and Fitzgerald find that Web-specific formal methods are seldom used; most methods employed are adaptations of general software development methods.

• In 2007, Lang and Fitzgerald perform a more probing exploration of Web methodologies in Ireland. They aggregate and analyze 165 survey responses, to reveal a surprisingly coherent image of Web development processes as organized and mature methodologies.

• Sheikh and Tarawneh (2007) explore the practice of Web Engineering in Jordan. They find that Web Engineering practices are deployed to some degree in most Jordanian Web development projects, suggesting a degree of maturity in industry methods.

• Kahn (2007) surveys 15 practitioners in the Australian Web development industry to identify the extent that Agile methods are employed. Kahn finds that Agile processes are almost universally perceived to provide value.

• Newman and Landay (2000) visit five commercial Web development organizations, to survey eleven developers. All organizations surveyed practiced a surprisingly similar methodology. Unfortunately, Newman’s and Landay’s survey is dated—possible cause for doubt as to relevance in a rapidly maturing industry.

• Garzotto and Perrone (2006) survey one hundred potential users of Web development methodologies to identify why academically proposed Web-specific methods are seldom used in industry. In the process, they explore methods presently employed and identify desirable qualities of development methodologies.

The international aspect of the empirical data raises some concern. Most studies occurred on continents other than North America. As such, survey results might not be representative of the Web development industry in this continent. However, increasing globalization of the industry and implicit similarities—particularly between countries like Ireland, Australia and Canada—suggest that the results should be relevant for North

Ritchie 27

America. Despite geographical differences that span four continents, patterns emerge from the studies:

• First, most Web development organizations use a defined and disciplined development process (Lang and Fitzgerald, 2007; Newman and Landay, 2000, Sheikh and Tarawneh, 2007, Lang and Fitzgerald, 2005).

• Most processes are in-house amalgams that combine aspects of common methods, including fragments of “apparently incompatible paradigms” by joining old and new methods like SDLC and Agile practices, (Lang and Fitzgerald, 2007, p 212), sometimes assembling an appropriate approach for the circumstances from a toolkit of practices.

• Most processes are very similar, based primarily upon SDLC/Waterfall (Lang and Fitzgerald, 2007; Garzotto and Perrone, 2006; Newman and Landay, 2007, p 264), with the addition of Agile practices like collective code ownership, regular team meetings and emphasis on the people aspects of development. (Lang and Fitzgerald, 2007).

• Methodologies specifically designed for use in Web projects were seldom used outside of academia (Garzotto and Perrone, 2006; Lang and Fitzgerald, 2007; Lang and Fitzgerald, 2005).

Both Newman and Landay (2000) and Lang and Fitzgerald (2007) found that methods used in most Web projects are primarily linear and predictive in nature. Lang and Fitzgerald (2007) outline the general methodology most clearly (p. 212-213):

1) Project initialization: identify objectives, timeline and budget

2) Planning/requirements definition

3) User Interface design, information architecture

4) Technical design and implementation

5) Release

6) Maintenance

Newman and Landay (2000) perceive a similar process—perhaps viewed from a graphic design orientation:

1) Information design

2) Navigation design

3) Graphic design

4) Information architecture

5) User interface design

6) (presumably) ongoing maintenance

According to Newman and Landay (2000), this process is one of “iterative refinement” (p 267) that employs intermediate artifacts such as site maps, story boards, schematics, prototypes and specifications to explore, convey and refine design.

Ritchie 28

Evidence of disciplined processes is apparent in both approach and practice. Lang and Fitzgerald (2005) find that 94 percent of survey respondents contend that project planning is essential, while 80 percent of respondents believe that plans should be clearly documented. Action supports those opinions. The researchers found that 87 percent of respondents reported that their organization prepared written specifications for their most recent project, although the documentation was less detailed than most software specifications. Further, 68% of respondents reported that their organization had written procedures for aspects of Web development such as technical design, requirements, UI design, testing, coding, and project management. Lang and Fitzgerald (2007) also found that 63% of respondents used documented procedures in project planning. However, they note that such documents “serve as flexible templates to guide and assist rather than to constrain and direct”; they suggest that the methods provide a high-level process while a “pick-and-mix selection of low-level techniques” supports the development activities (p 217). Sheikh and Tarawneh (2007) also found that formalized Web development processes are common.

According to Sheikh and Tarawneh (2007), Web developers in Jordan employ practices that suggest a degree of maturity in process and the use of formal, predictive methods:

• 67% perform cost/benefit and risk analysis prior to project initiation

• 53% employ change management procedures

• 76% employ tools to manage requirements tracking

• 74% use tools to track and report project status

While the work of Newman and Landay (2000), Sheikh and Tarawneh (2007), and Lang and Fitzgerald (2007, 2005), all paint a picture of Web development as formal and predictive, some Agile practices and methods are evident. Newman and Landay hint at aspects of agility in their study (2000), in which they describe the common Web development method as a user-centric process of iterative refinement. Lang and Fitzgerald (2007) found that formal Agile methodologies were used in 15% of Web development organizations, and note that

“many of the participants in [their] study have independently evolved practices that are remarkably similar to those of Agile methods family, such as collective code ownership; and emphasis on simplicity; the use of regular informational team briefings; insistence on a close working relationship with the client; the pursuit of continuous process, involvement through reflective evaluation; and a general emphasis on people, communication and working software over processes, document, and adherence to plan. ... Emphasis of design guidance is very much on agility, speed, efficiency and productivity” p 217).

Lang and Fitzgerald (2007) conclude that the combination of old predictive methods with new agile practices provides advantages of both: the orderly benefits of predictive methods combined with the “advantages of speed and flexibility” of Agile practices (p 217). Kahn (2007) finds that practitioners believe Agile processes are far more beneficial than might be suggested by the extent of formal adoption.

Ritchie 29

Although Khan (2007) does not explore the extent of adoption of Agile methodologies, survey respondents perceived value in the methods. For simple projects, 67% of respondents believed that Agile methods decrease costs, with the ratio increasing to 87% for medium- or high-complexity projects. In addition, most respondents believed that Agile methods increase quality and reduce project time. Interestingly, Khan found that even when Agile methods were formally adopted, practices are not applied consistently. For example, XP methodology practitioners usually only followed seven of the twelve XP practices. When viewed in light of the findings of other empirical data, these results give rise to the question of why Agile methods are not more frequently and thoroughly adopted.

Results of Khan’s survey (2007) reveal that lack of customer collaboration and the difficulty of applying Agile methods to complex projects are barriers to the adoption of Agile methodology. In exploring why Web-specific academically developed methods are seldom adopted, Garzotto and Perrone (2006) might illuminate reasons why Agile methods are not as common as suggested by wide support. They suggest that methods must be easy to use, easy to learn, provide project management support, appropriately compromise between “richness and simplicity” (p 91), and provide support of good documentation. The best-known Agile methodology might deliver short on those commodities.

.4.7 Conclusions

Academic literature establishes the need for formal development methodology in general software development and for Web application development in particular. Without an appropriate method, Web projects might fail in numerous modes, such as failing to fulfill business needs, being over budget or behind schedule. Modern Web applications are far more complex than early attempts. Unique characteristics of Web projects compound this complexity, such as the melding of operational functionality with graphic design, the wide scope of target audience and technical platforms, the unfamiliarity of Web project customers, and the wide scope of purposes that Web applications must fulfill. These factors add to the challenge of selecting an appropriate development methodology.

In its short history, many development methods have been employed to impose order in the otherwise chaotic development process. Boehm (2002) locates methodologies on a continuum of order and rigor from adaptive to predictive; agile to stepwise.

All methodologies might possess qualities that have value for Web development. Development methods known as Web Engineering are the most traditional and predictive of Web-specific methodologies; Web Engineering best suits customer needs for fixed-price-projects and management need for predictability. Other methods address needs for modeling, while the range of Agile Web development methods strive to strike appropriate balance between needs for predictability and needs for responsiveness, and an associated balance between “planning effort (including architectural aspects) and decisions left to developers” described by Hochmüller and Mittermeir (2008, p 8).

Ritchie 30

Empirical research supports the suspicion that published methods may not be ideally suited to Web projects. Use of academically produced Web-specific methods is nearly non-existent in practice. In its place, practitioners employ a surprisingly similar and largely predictive process based on traditional SDLC/waterfall, with the paradoxical addition of select Agile practices which deliver benefits of responsiveness and flexibility, quick iterations, and focus on people. In light of the unique requirements of Web development and the associated need to reconcile and balance demands for both planning and flexibility, this finding should not be surprising.

5.0 Research Results

5.1 Development Processes Employed by TradingCharts

“Making processes explicit--good or bad-- is the first step to understanding what is going on, seeing what works and what doesn't” (Palmer and Felsing, 2002, p. xvii). Exploring the strengths and shortcomings of development processes employed by TradingCharts today will aid in discovery of an appropriate methodology for the future.

5.1.1 Process Details

Development approaches at TradingCharts vary in approach and rigor. Selection of method usually depends on perceived project complexity, but sometimes the choice is made with little forethought. A single developer informally manages and completes very small maintenance jobs and site updates. Small and mid-sized projects—ones that require less than 80 hours of effort—are managed more formally, using a flattened team approach. Larger projects employ a waterfall-like method, with linear and documented design, analysis, implementation and deployment phases.

Figure 5 illustrates the three development method paths employed by TradingCharts; sadly, the implied orderliness of the illustration misleads. In practice, details of the three process paths are often emergent: observed more than prescribed, and inconsistent in discipline and rigor16. In addition, some projects suffer from complete lack of orderly process; at times, an individual developer will assume a small project, and proceed independently in an unstructured, “cowboy” fashion. Fortunately, that occurrence is becoming infrequent; projects usually proceed in an orderly and reasoned processes.

Proposals / Client Negotiation

Every TradingCharts project begins with an inquiry by the client17 that is addressed by the Customer Service Representative (CSR). Through client consultation, the CSR

16 Although processes for small to mid-sized projects has largely been emergent, several attempts to design, document and apply a waterfall-like process have been applied to larger projects at TradingCharts, with some success.

17 In the case of an internal project for the TradingCharts website, the client is often TradingCharts’ Managing Director.

Ritchie 31

generates a very high-level set of requirements. If the project is tiny, the CSR will generate a “ticket” and send work instructions to an appropriate developer. For all other projects, the CSR generates an estimate and proposal. With developer assistance, the CSR uses a component-based estimating system to estimate project effort and price. In addition to providing a client price estimate, this process generates a job worksheet that enumerates project features and expected effort. The resulting client proposal and worksheet become important operational artifacts, guiding work and providing developers with a document in which to record time and note specification changes.

Figure 5: Present Processes Employed at TradingCharts

Ritchie 32

Tickets

The CSR enters details of small jobs into the TradingCharts job tracking system. Developers volunteer to perform ticket jobs based on their workload, skills and project familiarity. Ticket work is usually competed within one business day of receipt. This casual and expedited ticket process is responsive to customer demands for quick site updates, but it can result in low quality and outdated documentation, and ticket work can interrupt large projects.

Small Projects

A small Web project is considered as one that requires less than twenty-five hours of effort. Such projects usually entail very little code, and therefore remain primarily in the domain of graphic design. Small projects begin with the creation of an estimate/job worksheet; once the customer has approved the cost estimate, the project is entered into the job tracking system, and is then discussed with the development team. Team members volunteer for tasks (based on their regular roles). Project work then usually follows the semi-formal path illustrated in Figure 5.

Mid-sized Projects

A mid-sized project is one that requires between twenty-six and eighty hours of development effort. Such projects generally require a balanced mix of graphic design and code development. This type of project usually follows the general process illustrated in the left-most path of Figure 5, although the process remains informal. In contrast with the method used for small projects, code developers are involved in the process earlier and preliminary analysis and infrastructure consideration occurs concurrently with the artistic design process.

Larger Projects

The process followed for larger projects is similar to that of mid-sized projects, although it involves much more planning and formality. Substantial initial specification and design is invested before implementation activities, and responsibility for project management, progress and process is assigned to an individual. That individual is also responsible for technical design aspects, assigning tasks, and resolving issues.

5.1.2 Tool and Environmental Support

TradingCharts management endorses a Theory Y 18 human resource philosophy, and a team approach to project development. Team empowerment, interaction and communication is supported and encouraged throughout the development process.

18 In his 1960 book, The Human Side of Enterprise, Douglas McGregor describes a (now) well-known management theory that distinguishes between two philosophies of human resource management. McGregor’s Theory X managers assume that employees dislike work, lack ambition and require extrinsic motivation. Theory Y managers believe that employees seek responsibility and are intrinsically motivated (Carson, M., 2005)

Ritchie 33

Staff meet for a daily 15 minute stand-up meeting, to discuss progress and status of all ongoing projects, and opportunities for improvement. The development environment encourages communication and teamwork; layout of the design/coding area is open, with individual areas separated by half walls in an arrangement that facilitates communications but delineates personal space. Product specifications are stored in a team Wiki, which doubles as a knowledge repository. A set of semi-automated spreadsheets tracks project progress. Functional artifacts are developed and stored in shared file space. Design tool support is strong, with focus on a few robust applications. However, process support tools like automated testing and versioning are absent.

5.1.3 Efficacy of TradingCharts’ Methods

A subjective assessment of the methods employed by TradingCharts suggests that the processes are somewhat effective, but suffer from weaknesses and inconsistencies. To explore those concerns empirically, thirty recent projects at TradingCharts are studied. Results are perhaps unsurprising, underscoring the need for greater formality and consistency of methodology.

Research Method

The thirty projects were selected randomly from projects completed for third-party clients in 2008. Internal projects were not considered for study, because effort and results are recorded more consistently, and customer approval is more objectively visible for third party projects. It is believed that third-party projects are representative of all projects undertaken by TradingCharts, and that the results of this study are equally valid for internal projects as well as those produced for third parties.

Data regarding the projects studied was gathered from company records and post-project appraisals. Project parameters considered were:

• Project effort in hours

• Project complexity using the scale devised by Murugesan and Ginige (2005) of “informational”, “Interactive”, “workflow oriented”, “collaborative work environment”, “online community/marketplace” (p 5)

• Methodology employed, selected from: ad hoc/cowboy coding, single developer, development team, development team with leader, or structured/planned SDLC19

Results recorded for each project include:

• Time or budget overruns

• Other types of problems encountered

• Customer satisfaction

19 One project process did not fit neatly into one of the classes of methods selected, due to the nature of the work. That project entailed installation of pre-developed functionality into a customer Web site. Although the project effort was twenty-one hours, due to the simple nature of the work, the project was managed like a ticket.

Ritchie 34

Project Characteristics

Characteristics of the projects studied reveal a bias toward smaller, less complex projects, but with a sizeable portion of total hours invested in a few larger projects.

Ritchie 35

Thirteen of the subject projects experienced one or more problems. Objectively, eight projects were over budget and/or over time and three resulted in customer dissatisfaction. Thirteen projects experienced subjective problems due to five modes of failure.

Correlation of Project Characteristics and Problems / Failure Modes

Analysis of problems experienced in the troubled projects reveals striking correlations. Unsurprising is the finding that ad hoc methods resulted in problems in over half of projects. Surprisingly, most projects using the leader/team structure resulted in problems. This finding contrasts sharply with the complete absence of problems experienced when using the structured/SDLC method, and with the lower incidence rate in the leaderless developer team (23 percent).

Ritchie 36

Exploration of failure modes exhibited by projects developed using the leader/team method and structure indicates that failure modes in this troubled method exhibit no consistent pattern of cause20.

Examination of problem frequency by project complexity reveals another striking correlation—the frequency of problems in transactional projects is higher than that of all other complexity levels.

20 Note that while the findings might be considered indicative, the small sample size limits confidence in these findings.

Ritchie 37

However, closer examination of the failure modes exhibited in troubled transactional projects does not reveal a meaningful pattern.

The data suggests that the quantity of problems in transactional projects correlates with the development method employed. Eighty percent of transactional projects used the ad hoc/cowboy method. This inappropriate choice of process is likely the root cause of many problems in transactional projects.

Analysis

The empirical exploration of TradingCharts projects reveals some troubles. First, projects suffer from a high overall rate of problems (over 40 percent). Although that rate aligns with reported industry rates (Epner, 2000), the need for dramatic improvement is indicated. Secondly, failures in projects using the leader/team structure exceed those of the leaderless team structure. pointing to addressable issues. Possible reasons include leadership failure, confusion in roles, unsatisfied expectations for greater direction, or—conversely—unaccustomed lack of employee empowerment. Finally, the use of the ad hoc process for projects of transactional complexity is a poor choice; such projects unquestionably demand an orderly methodology. These three issues can be addressed through deployment of an appropriate development methodology at TradingCharts.

5.1.4 Conclusion

While TradingCharts’ environment provides strong support for teamwork and knowledge sharing, development methods are informal, emergent and sometimes inappropriate. Although the processes are functional, lack of formality and consistency contribute to project failure. In addition, the processes provide nominal support for iteration, and are inflexible, predicated on assumptions of stable requirements and specifications. Comparison with industry participants suggests that TradingCharts might suffer from

Ritchie 38

competitive disadvantage due to its processes. Analysis of 30 projects undertaken by TradingCharts supports that contention, with over forty percent of projects suffering problems attributed to weakness in methodology.

5.2 Unique Process Requirements of Web Development

Web application development is distinct and unique as compared with traditional software development. Many of those characteristics suggest need for unique practices and approaches in Web application development methodologies.

The most visible difference between Web projects and general software projects is the emphasis placed on visual design and user interface aspects. The importance of creative graphics and ease of use ties with the low cost of switching--often a Web user can switch to competitive products with little effort and no cost. This characteristic influences development methods in multiple ways. An obvious effect is that Web applications must be tested ‘by eye’; automated testing is unlikely to detect failure in visual design and user interface. Visual emphasis also dictates that effective Web development teams must include representation from the graphic and UI design disciplines. The multidisciplinary nature of the team brings varying perspectives of value and preconceptions about process that a development methodology must consider.

Web applications exhibit increased diversity in practical dimensions. One such dimension is in scope of purpose; Web applications serve diverse purposes including e-commerce, advertising, workflow facilitation, and collaborative virtual workspaces. Another dimension of diversity is the range of end users. A Web application might attract hundreds of thousands of users from different cultural backgrounds, and with varying levels of computer skills. Confounding this issue is the distance and inaccessibility to many of the users, who might be located in remote locations. Creative application of user-centric design would therefore be a valued ingredient in Web development methods. Finally, Web applications must operate on a wide range of software and hardware platforms, dictating integration of testing using multiple platforms into the development processes.

Web clients differ from sponsors of other software projects. Often unaware of pitfalls and opportunities afforded by the technology, clients seek greater guidance from Web developers. When this guidance is insufficient, requirements become difficult to identify at project initiation and requirements tend to evolve dramatically during implementation. Compounding these concerns is the pace with which Web projects proceed. Together, these factors point to a shift away from the traditional software development paradigm of monumental release cycles, to methodologies that allow for change, are flexible, quick and efficient, and responsive to client needs. Fortunately, the small size of most Web development teams and projects might more easily permit those characteristics.

Small development teams also allow ease of communication and knowledge sharing: benefits that should be levered in Web development methodology, as a means to accommodate the rapid pace of technology advance and to facilitate a light and agile method not overly burdened by ineffective and expensive documentation. Small team

Ritchie 39

sizes also allows for a flattened team structure, even better equipped to share diverse knowledge.

It is clear that the choice or design of an appropriate development methodology for TradingCharts should reflect the unique character of Web development.

5.3 Summary of Development Methodologies Described in Literature

To organize discussion, development methods relevant to Web application projects might be categorized in four different classifications delineated along two dimensions.

Figure 6: Convenient Classification of Development Methodologies

Predictive methods are those predicated on assumptions that system requirements can—and should be—decided before development begins, and that design work should be complete before implementation begins. Such methods promise predictability, effort estimation, and planning; however, they are burdened by process overhead such as substantial documentation and rigid formality. They do not allow emergent requirement discovery and generally employ a change-management system intended to discourage change. Predictive methods embody a degree of Tayloristic21 philosophical belief in control, combined with a touch of Theory X human resource philosophy.

Instead of controlling change, Agile processes accept or encourage changes. Similar to just-in-time manufacturing, an Agile process defers work until the product of such work is required, and it shuns artifacts not valued by clients. Agile methods recognize the value of humans in more of a Theory Y philosophical perspective, and strive to empower employees to make appropriate design and implementation decisions as

21 Taylorism describes an overall production philosophy that prescribes the separation of planning from execution, wherein educated managers and engineers decide how work will be performed and at what pace, by a workforce of replaceable workers who are expected to work like cogs in a machine (Beck and Andres (2005)..

Ritchie 40

projects proceed. However, Agile methods arguably lack structure, order and discipline, and they may encounter attendant difficulties in effort estimation, scope creep and planning.

Both predictive and Agile development approaches are found in general-purpose and Web-specific methodologies.

5.3.1 Predictive, General-Use Methodologies

These predictive methods include enduring methodologies such as the widely recognized waterfall and systems development lifecycle (SDLC). The methods are widely understood, clearly defined, and stepwise, with modest and seldom-practiced accommodation of iteration. The typical SDLC consists of eight phases: project initiation and feasibility study, analysis and planning, product design, implementation or acquisition, integration, implementation, evaluation, and maintenance.

Other types of general-purpose predictive development methods include Boehm's Spiral Model. The risk-driven Spiral Model is visualized through ever-expanding spirals of development cycles. Each cycle includes orderly phases including objective identification, evaluation of risk and alternatives, prototyping, design, validation/verification, and planning.

The Spiral Method and other predictive methodologies seem most appropriate for large and/or critical projects, since such projects might benefit from a greater degree of control and formal coordination. Process overhead related to predictive methods—such as extensive documentation—might constitute an onerous burden for projects of more modest scale.

5.3.2 Agile, General-Use Methodologies

A number of Agile methodologies are described in literature and found in practice. Two of the most significant Agile methods are Extreme Programming (XP) and Feature-Driven Development (FDD).

Extreme Programming is the most widely known Agile methodology, and it might be considered one of the most adaptive. In the view of Whitson (2006), the quick, iterative cycles, minimal up-front design and focus on testing renders XP appropriate for Web development. In its original form, XP addresses many aspects of the development process, and is extensive in detail related to human interaction and iterative development cycles. The methodology defers most design effort until the iterative implementation cycle. Close client involvement is demanded in all phases, to the extent that XP requires that a customer actually collocate with the development team.

XP is clearly agile in its response to emergent and changing customer needs. However, some method practices do not mesh well with client expectations in Web development projects. In the experience of the author, most Web project clients will find XP practices of on-site customer, negotiated scope, and deferral of requirements, to be onerous or risky. While it is claimed that the XP yields greatest benefits when all practices are employed, deployment of individual XP practices might be both practical and beneficial.

Ritchie 41

Feature Driven Development

Feature Driven Development (FDD) is marginally more traditional than XP. The methodology embeds iterative Agile design and build cycles within a larger framework reminiscent of predictive methods.

FDD development begins with three well-defined sequential activities: modeling, identification of features, and planning. Following the three initial project-wide activities come two activities that iterate for each feature identified. For each feature, a design is created, and then the feature is implemented.

FDD replies upon a few specific practices and general technologies. The basic FDD methodology is designed for use in object oriented programming projects. Use of other implementation technologies does not preclude use of FDD methodologies, but some adjustment to the modeling practice will be required. FDD also prescribes practices of test-first design and code review to assure quality; implementation of those practices might complicate FDD deployment in some environments22.

Agile methodologies of XP and FDD are attractive in their responsiveness to changing and evolving requirements. However, both methods present implementation challenges, particularly in light of the unique challenges of Web development.

5.3.3 Predictive Web Specific Methodologies

Many predictive Web specific development methods centre around processes and practices generally labelled Web Engineering. Although there is no single widely recognized Web Engineering methodology, methods of this family share similar values and practices. Web Engineering strives to bring order and discipline while balancing the technical, visual and publishing aspects of Web development through application of traditional engineering practices. Web Engineering methodologies are strongly predictive, stepwise and explicit. Client valued work tends to be performed near the end in such methods, following formal requirements specification, and technical, navigational and information design.

An interesting variation of predictive Web development methodology is Software Engineering for Web (SEW) (Hseih, 2003). The process proposes a lightweight and original modeling activity as a primary specification and documentation artifact. The activity results in a visual model of Web pages, code, and their relationships that seems intuitively valuable as an exploration, communication and documentation tool.

Some published Web development methodologies embed Agile values and principles within a predictive framework. For example, WebHelix builds upon the visualization of Boehm’s Spiral Model. Implementation occurs in iterative spiral cycles, each of which includes sequential activities of analysis, design, code, test and evaluate. Each cycle produces a working set of features, and the development spiral continues until the

22 Test-first design and code review are not practiced at TradingCharts. Implementation of those practices might require special change management considerations.

Ritchie 42

project is completed. The Agile Approach for Web Systems Engineering similarly prescribes activities based on Web Engineering practices, to which the designers append practices of modeling and modest documentation.

Direct adaptations of Agile methods to Web development abound.

5.3.4 Agile Web Specific Methodologies

Agile methods for Web projects abound in both literature and practice. Both XP and FDD have been adapted and implemented for Web development.

Modeled after XP, iterative cycles of design and implementation drive WebXP to produce client-valued functionality called stories in each iteration. WebXP begins with a short planning session that identifies and defines stories, assigns stories to developers, estimates effort, determines content from clients, and manages risk. Implementation follows, in the form of iterative cycles which each result in fulfillment of an XP story. The first stories are standard, predefined activities required of Web projects, including preparation of infrastructure and graphic design, followed by identification and resolution of technically high-risk factors of the project.

FDD for Web is an adaptation of FDD to Web projects, which some practitioners enthusiastically endorsed. Few adaptations are required of FDD to allow its use in Web development, although at one formal adaptation23 suggests merging the second and third initial activities of Building Features List, and Plan by Feature. Bauer (2005) emphatically endorses FDD in Web development projects, and suggests that it might easily be adapted to procedural code environments by employing a different modeling process.

Adaptations of Agile methodologies seem implicitly well suited for Web application development, while predictive methods provide features that align well with customer expectations.

5.4 Methodologies Observed in the Industry

Few studies of development methods applied in actual Web development organizations are available. Accessible studies paint a surprisingly coherent and orderly view of Web development processes.

The studies find that methodologies employed for Web development are largely predictive, with up-front planning and waterfall-like linearity. Most methods employed are documented, formal, mature and thorough, employing specific practices borrowed from both traditional project management and published general software development methods. Surprisingly, academically published methodologies designed specifically for Web development are seldom used.

23 Please see FDD for Web in section 4.5.4 for details of Xiaocheng’s (2006) adaption of FDD methodology to Web application development.

Ritchie 43

While the methods employed are generally predictive, Agile-like values of people-centricity, simplicity and communication are infused into the methods through Agile practices such as common code ownership, user-centric design, quick iteration, and team meetings. The resulting amalgam of old methods and new practices delivers orderly benefits of predictive methodologies, combined with the speed and flexibility of Agile processes.

The stepwise method commonly found in Web development practice might be summarized as follows:

1) Identify business goals, timeline and budget

2) User interface, navigational, information, and graphical design

3) Technical design and implementation

Possible iteration from steps 3-4

4) Acceptance testing

5) Release

6) Maintenance

Few practitioners have adopted formal Agile methods, although industry participants widely acknowledge that Agile methodologies deliver benefits in quality and efficiency. Challenges in acquiring the extent of customer involvement required by Agile methodologies is found to be one reason for low levels of adoption; other concerns include difficulty applying Agile methods to larger projects, lack of method documentation, and limited project management support. Despite those concerns, Agile methods do align well with the unique characteristics of Web project development.

6.0 Analysis

6.1 Local Factors that Affect Selection of Methodology

Selection of a development methodology for TradingCharts must consider alignment with local factors such as corporate culture, norms and values, human resource philosophy, present practices, development team size, nature and diversity of projects, customer expectations, and existing tools and technologies. Alignment with these factors will aid adoption and acceptance by limiting disruption and reducing resistance.

TradingCharts culture is informal, and encourages teamwork, knowledge sharing, flattened management, and entrepreneurial spirit. Projects are often team-based, and staff members liberally share problems and solutions. Problem sharing and team approaches are supported in many ways. For example, every workday begins with a brief stand-up meeting to discuss progress and issues and share suggestions for project and process improvement. The human resource (HR) philosophy, rewards system and development environment support the culture. TradingCharts’ HR philosophy aligns with McGregor’s Theory Y, which holds that given the right conditions, workers are intrinsically motivated to work intelligently and purposefully, and find fulfillment in

Ritchie 44

performing work well. Those conditions are provided in part by adequate fulfillment of staff physiological and security levels of Maslow’s hierarchy of needs24. TradingCharts achieves this by providing good rates of pay, benefits including health and life insurance, and confidence in job security. Further, the TradingCharts’ reward system encourages team identification and motivation through performance-related remuneration and bonuses. Finally, the work environment supports teamwork, sharing, and communication through physical design of the workspaces. Staff share a common workspace that is bright and spacious with near wall-to-ceiling windows and a countryside view; the common workspace has personal work areas delineated by half walls that facilitate communication and team atmosphere while providing a sense of personal space. A comfortable common meeting room with wall-mounted monitor provides a comfortable and practical venue for staff and client meetings.

Although TradingCharts has not written a formal values statement, a guided implicit consensus on company values has emerged. TradingCharts recognizes the value of people and appreciates the unique contributions of each. In response, management and staff agree to treat all people with respect and dignity, and to be fair and honest in all activities. In the case of irreconcilable conflict between business objectives and these values, these values prevail. These values will be reflected in the design of a appropriate development methodology.

Present tools support team communication and sharing as well. Staff use the company’s private encrypted messaging system extensively. Persistent communication, knowledge capture and document sharing is enabled by the company Wiki. In addition, the company has recently started to adopt groupware application, although use of the system is presently nascent. A shared development fileserver and workgroup write access to production servers support shared ownership of code and design artifacts. However, the company does not use a revision control system, and use of its development server is inconsistent.

As revealed in by the empirical study of TradingCharts’ projects25, most work performed by TradingCharts is in the form of very small projects of less than 40 hours. Total development staff size is six, and project teams usually consist of three to six members, depending on project size, required skills and staff workload.

Customer expectations also affect selection of development methods and practices. Many of TradingCharts’ customers are small business managers, who naturally tend to perceive Web development from a paradigm based on familiarity with advertising and print procurement. That paradigm results in expectations that Web development should be predictable in result, timelines and cost.

24 In 1970 Maslow published his popular theory of motivation which states that people are motivated by a hierarchy of needs: physiological, security and safety, belonging, esteem, cognitive, aesthetic, self-actualization. When needs lower in the hierarchy are fulfilled, higher levels of needs become primary motivators (Flannes and Levin, 2005).

25 Please see section 5.3.1 for analysis of TradingCharts projects and methods.

Ritchie 45

Consideration of these aspects of local environment will be important in selection of methodology and practices for TradingCharts. Culture and environment will also affect the design and implementation of the change management plan that will guide TradingCharts forward in adopting and institutionalizing the processes prescribed by the selected methodology.

6.2 Desirable Development Methodology Characteristics

Desirable characteristics of development methodologies will be considered on three tiers of increasing specificity:

1) General characteristics that should be considered in all types of projects and environment

2) Characteristics of particular interest or concern for Web development in light of the factors specific to Web application projects

3) Those characteristics that are especially desirable for TradingCharts, due to its particular mix of projects, culture, existing processes and values.

6.2.1 General Requirements of Development Methodologies

For all types of development, a methodology should provide guidance and order, laying out phases and activities, and answering the questions of what to do next and when is work finished. A method should also prescribe activities related to process control and testing. The level of guidance and detail provided by the methodology should be appropriate for the project nature and environment, depending on factors including criticality, team size, and priorities (Cockburn, 2000), and it should express an appropriate balance between control/rigor, and empowerment/flexibility. Finally, the methodology should have been tested in the field, in circumstances similar to those of the intended deployment. These characteristics should all align with project and industry characteristics, within the specific context of the organization and its culture, values and philosophy.

6.2.2 Methodology Characteristics Desirable for Web Development

Web development projects present unique challenges that suggest specialized characteristics for appropriate methodologies. Formal methods for Web development should:

• Encourage interaction with clients and provide flexibility in requirements and refinement of specification, since customers might not fully grasp the potential project scope or implications, and might not recognize opportunities and pitfalls provided by the medium and technologies until the project progresses

• Provide minimal formal team structure to evenly balance the roles of various members and encourage equal participation in light of the diversity of required skill sets and disciplines

• Recognize the importance of graphic and user interface design, and appropriately weight related activities in methodology priorities

Ritchie 46

• Prescribe quality-related activities that consider the end-user experiences that elude automated testing due to the diversity of supported end-users and platforms

• Be light enough to operate at a fast development pace with minimal effort invested in non-functional artifacts such as excess documentation

• Lever advantages of small project and team size and low effort of releases

Method characteristics must also be considered in the context of TradingCharts’ environment.

6.2.3 Specific Methodology Requirements Desirable for TradingCharts

In addition to factors of Web development in general, consideration of specific characteristics of TradingCharts’ environment and project mix indicate that an ideal methodology must fulfill specific needs. A methodology appropriate for TradingCharts should address:

• Client expectations for minimal involvement in project 26, predictive estimates of cost and timelines, and understanding of the process and costs—perhaps through the use of metaphoric connection to familiar activities such a print or advertising procurement

• Alignment with present practices such as shared ownership of artifacts, interactive prototyping and refinement of design candidates, and estimation of effort/tracking of progress through decomposition of projects into client-valued components

• Implementation of the new methodology by allowing a gradual implementation path that addresses resistance to change and the need to demonstrate value of new methods

• The generally-small size of TradingCharts projects while accommodating projects of larger scale, by limiting required method overhead while providing for method expansion when required

• Ease of understanding and application with attendant minimal process documentation

• Need for concurrent work on multiple projects in a phased approach, to accommodate overlapping project schedules and difficulties that result from customer-related delays

• Alignment of HR philosophy and culture by empowering staff and trusting them to make thoughtful and appropriate decisions regarding process and design, and by providing appropriate levels of process guidance and control

Finding a development methodology that embodies all general, industry-specific and company requirements might be challenging, despite the quantity of candidates.

26 For example, experience at TradingCharts indicates that few customers would accept the XP practice of the “on-site client”.

Ritchie 47

6.3 Narrowing the Range of Options

Considering the plethora of development methodology options, practical selection of a method demands an initial narrowing of candidates. A view of methodologies and requirements from an academic perspective is helpful in identifying practical candidates.

Boehm’s 2002) visualization of the range of development methodologies27 as a continuum from adaptive to predictive, describes one dimension relevant to methodology selection. Cockburn (2000) perceives that methodologies also vary in depth: some describe only guidelines, whereas others detail each activity at length. Cockburn suggests that the depth of a methodology should relate to team size, project criticality, and project priorities like productivity or defect intolerance. In addition, Cockburn notes a “positive feedback loop” between team size and methodology depth: a smaller team requires less depth of methodology, and with less process overhead the team works more efficiently (p 67).

At TradingCharts, the team size is small, criticality is usually low, and project priorities are usually a fixed mix that leans toward productivity. In these circumstances, Cockburn’s (2000) framework points toward a methodology of light depth. This aligns well with other company- and industry-specific methodology requirements28, which suggest that an appropriate methodology will be light in process depth, quick to learn and easy to implement.

Cockburn’s (2000) framework of method depth readily combines with Boehm’s (2002) continuum of the adaptive/predictive dimension of methodologies to create a two-dimensional framework of methodologies upon which candidate methodologies can be located.

Locating TradingCharts’ requirements of methodology on the framework should allow selection of the most appropriate candidates found in literature. As discussed earlier, an ideal method would be located in the lower half of the framework, with low method depth resulting in an easy to understand and implement methodology that empowers and guides development teams instead of constricting their activities and burdening them with process requirements. Locating TradingCharts on the horizontal adaptive-predictive axis is more perplexing.

27 Please see section 4.4 for an illustration of Boehm’s continuum of software development methodologies.

28 For example, the industry requires low process overhead and while TradingCharts’ existing practices and HR philosophy require a process that embodies team empowerment.

Ritchie 48

Figure 7: Two-dimensional Development Methodology Selection Matrix29

TradingCharts seems confronted with conflicting process requirements. Customer expectation of predictive pricing and timelines agrees with management need for planning and avoidance of requirements-related risk, indicating that an appropriate methodology must be predictive in character (and therefore located on the right-hand side of the framework). However, the inevitability of emergent and evolving

29 The two-dimensional matrix is synthesized from the Boehm’s (2002) continuum of software adaptiveness and predictiveness, and Cockburn’s (2002) frameworks of method depth. Methodologies reviewed in previous sections have been located on the framework through review and subjective analysis.

Ritchie 49

specifications aligns with the customer need for guidance and cultural desire for empowerment and teamwork, to indicate that the appropriate methodology will be adaptive and agile (and therefore located on the left-hand side of the framework). Those concerns are borne out by the apparent confusion in the industry, wherein practitioners have adopted methods that are largely predictive, but embed seemingly incongruent agile practices30. This apparent contradiction seems to frustrate common sense, and use of the framework for method selection.

6.4 Selection of Best-fit Development Methodology

Contemplation of the apparently incongruous methodology requirements to be both predictive and adaptive reveals that the seeming paradox can be resolved. Predictive needs are greatest at the uppermost levels of development activities such as high-level specification, planning and estimation. Needs for adaptive practices are greatest in inner project activities—focussed in the design and implementation activities. Therefore, certain project level activities—business needs identification, initial requirements discovery, effort estimation, project planning, project-level design activities--can be performed from a predictive perspective, while design and implementation activities associated with granular and atomic functionality can be performed in iterative cycles in an Agile process embedded within the overall predictive framework. In the light of that epiphany, methods employed by Web development practitioners begin to make sense.

Returning to the two-dimensional Boehm-Cockburn framework might now yield useful guidance. Methodologies matching TradingCharts’ needs to be lightweight and primarily Agile but embedded in an overarching predictive methodology will be located in the lower half and just left of centre on the horizontal axis of the framework. Four methodologies are found in that area: FDD, FDD for Web, WebHelix and AAWSE. Revisiting previous analysis of those methodologies reveals that FDD, FDD for Web, and WebHelix fit the desired pattern: iterative, Agile cycles embedded within an overall predictive project framework. Of the three, only FDD has seen practical use in the industry. For these reasons, Feature Driven Development is the selected to form a solid and proven foundation upon which to build an appropriate development methodology for TradingCharts.

6.5 Adaptation of FDD Methodology Practices to TradingCharts

The selected methodology, Feature Driven Development meets many of TradingCharts’ requirements. FDD provides an appropriate level of guidance to empower staff to use their skills in design and implementation, while guiding them through an orderly process without unnecessary activities or production of low value artifacts. The team-oriented methodology aligns well with TradingCharts’ culture, practices and philosophy, and is easy to learn. Further, FDD will be easy for customers to understand, and fits well with TradingCharts’ existing estimation and project management systems. FDD is agile, with

30 Please see section 4.6 for discussion of methods employed by industry participants.

Ritchie 50

two levels of iteration in which requirements might change and design can evolve31. Unsurprisingly, FDD is not a perfect fit; some tweaks are required for implementation at TradingCharts.

Mismatches between FDD and TradingCharts are few, but resolution of those differences will be vital for successful adoption. Two modifications entail modest changes to methodology phases. Other tweaks affect specific FDD practices.

• Proposal and initial requirements identification: TradingCharts generates project proposals or explores project feasibility before project initiation; these activities will become a new process zero, added before the five standard FDD processes.

• Graphic design: TradingCharts begins each project with iterative development of an artistic concept design; that activity is added to FDD process 1, as an activity performed concurrent with modeling.

• Infrastructure and information design: A standard first feature addressing information and infrastructure will launch the iterative implementation phase for most projects; although this activity does not deliver client-valued functionality, it is a prerequisite for many other features.

• Code ownership: FDD insists that specific developers own code classes. However, individual code ownership counters team philosophy, and presents challenges in the absence of the code owner. TradingCharts will therefore continue its practice of shared ownership of all artifacts.

• FDD employs UML modeling to provide business domain and object models. UML models may have less utility in procedural development environments such as is used by TradingCharts and such modeling might be excessive in defining relationships and processes that might be expressed in a simpler manner. For that reason, a new, simple modeling method will be employed to explore and communicate the design of Web applications as a number of systems composed of FDD features.

• Customer interaction: FDD does not provide for substantial interaction with clients. TradingCharts will involve clients extensively in the new process zero, and frequently within the inner FDD design and build cycles, particularly in design activities, and through use of prototypes in every Design By Feature iteration.

• Estimation of effort: FDD allows for progress tracking through a simple count of remaining activities for all features; TradingCharts will improve on that practice by recording effort expended on completed features, and by creating a repository of features as simplified patterns, initially stored in the existing company Wiki32. This

31 Cyclic iteration occurs in the fourth and fifth phases: feature design and feature implementation, and it can also occur through incremental model refinement (and even addition of features) at every pass through the design-and-build cycle by iteration back to through the first three phases of the FDD methodology.

32 Once the time recording, project tracking and pattern activities become institutionalize, a custom application will be developed to support the processes.

Ritchie 51

repository will also aid in providing patterns for re-use in the modeling process introduced above.

• Some of the FDD processes require minor adaptation for application within the small staff size at TradingCharts. For example, FDD recommends formation of multiple small groups to present competing models in Process 1. In reality, there is likely to be just a single group of perhaps two members who develop the model.

Adaptation of FDD by implementing these tweaks should result in a development methodology well suited to TradingCharts’ industry and specific environment.

7.0 Recommendations

7.1 Proposed Development Methodology Design

7.1.1 The FDD Development Framework

The development methodology adopted by TradingCharts will be based on the Feature Driven Development method devised by De Luca, and described in detail by Palmer and Felsing (2002). The previous section of this paper describes the required adaptations to FDD practices, while the following section addresses implementation concerns. The method will consist of the five steps described by De Luca, and Palmer and Felsing, with the addition of an initial step for high-level requirements discovery and proposal writing, and addition of graphic design activities to the first step. Figure 8 illustrates the process framework.

Figure 8: Modified FDD Process33

33 The FDD methodology framework adapted from Palmer and Felsing (2002, p 58).

Ritchie 52

Aside from the changes illustrated above, and noted in the previous section, the methodology will follow that detailed by De Lucas in his specification document entitled FDD Processes34. All practices of FDD will be adopted over time. The most substantial variation on the FDD process is the introduction of a new modeling process.

7.1.2 Modeling Method

The new modeling process incorporated into FDD Process 1 will visually diagram Web applications as a series of coordinated pieces of functionality or visual design. Those items will be grouped together into a system. The system and pieces of functionality (widgets and actions as described below) will each become FDD features. The modeling method is intended to strike a pragmatic balance between abstraction and implementation.

Figure 9: The TradingCharts Modeling Method: System Example

Figure 10: TradingCharts Modeling Method: Collection Example

34 De Lucas latest specification of the FDD processes is available online at http://www.nebulon.com/articles/fdd/download/fddprocessesUSLetter.pdf

Ritchie 53

The following vernacular will be used in the modeling method:

"Widgets" are simple and encapsulated visible pieces of functionality, like "standard header", "product list", "main navigation", "bread crumb" or "search form". Widgets always have a visual design aspect, but might also have a coded behaviour. For example, a widget might need to fetch data from a database table for display. Widgets generally should not have any side effects beyond visual effect. Square-cornered rectangles will represent Widgets in the model. Widgets will be implemented as re-usable (within a project) drop-in components used in systems.

"Actions" are simple and encapsulated pieces of functionality, like "add user" or "check login". A function will often have side effects (such as altering data in a database), but will not normally have a visible aspect. Visual/interaction will be the responsibility of the enclosing system, which might call upon different widgets to display the results of an action. Actions will be represented in the visual model with round-cornered rectangles. Actions will be implemented as versatile re-usable drop-in components of systems.

“Collections” will be employed as a model construct intended to reduce model clutter. A collection refers to set of standard widgets and actions. For example, a Web application might include the standard navigational widgets of “breadcrumb”, “top nav”, and “bottom nav”. Those widgets might be contained in a single collection and modeled separately to reduce visual complexity of the systems model. A collection will be diagrammed in the system model as a square-cornered rectangle with multiple layers. The collection itself will be modeled in a separate document.

"Systems" are often simple web pages (most will be) that will usually contain widgets. However, a system might also be a more complex mini-application with multiple views and behaviours. For example, a system might allow the user to browse through an online product catalogue. A system will generally be implemented in a single "system" code file, with most or all of its functionality provided by actions and widgets as drop-in components. A system will be modeled on a single Wiki page35. When a system has multiple, complex views, each view can be modeled separately if required. A system will be modeled visually as a square-cornered rectangle surrounded by an appropriate constellation of widget and action objects. Note that widgets might also contain nested widgets or actions; in that case, the widget will have its own constellation of objects.

Infrastructure and data models will be modeled as systems, with associated abstract access methods modeled as actions.

Although not a modeled feature, the concept of suite will be closely associated with models. A suite will be a collection of closely related actions and widgets. For example, a suite named “user accounts” might contain all artifacts associated with user account

35 The use of Wiki’s for project documentation is common in Agile methods, according to Capiluppi, A., Fernandez-Ramil, J., Higman, J., Sharp, H. & Smith, N. (2007).

Ritchie 54

creation, logging in and logging out. All artifacts associated with suite members will be located in a single development and implementation server directory. The suite concept will help organize development artifacts, and will aid in quick location of code and artifacts in a self-documenting manner.

Each system, widget or action diagrammed will be assigned a short identifier and a mnemonic title. The identifier will contain a two-letter initial of the client name followed by three serial numbers. The next letter of the identifier will be ‘W’, ‘A’ ‘C’ or ‘S’ to indicate that the object is a widget, action, collection or system; finally, if the object is intended to be re-usable in multiple contexts within the project, the identifier will be suffixed with the letter R. An overview of each such object will be recorded in the project Wiki pages, for easy access by team members. Information initially recorded for each object will include:

• Identifier and title

• Suite

• Required by (systems/widgets/actions)

• Dependencies

• Description

• Code declaration (if appropriate)

The modeling system as described should provide effective communication of requirements to the design and implementation team.

7.2 Implementation Plan

7.2.1 Strategy

According to Hochmüller and Mittermeir (2008), Agile methodologies cannot be adopted quickly. They warn that the “people process” is the most critical factor in a successful transition (p. 6). Implementation of the FDD methodology at TradingCharts will be staged to minimize disruption, encourage staff buy-in, and foster a gradual, evolutionary move to FDD methodology. Similarity with existing company processes will ease the evolutionary adoption, since employee should not perceive FDD as disruptive. Despite the anticipated ease of acceptance, management must not presume such support. People tend to resist change for a variety of reasons. Therefore, the FDD implementation approach must specifically address the people aspect of the people-technology-process triangle of IT systems (Palmer and Felsing, 2002), as it applies to development methodology.

According to Gotsill, and Natchez (2007), people resist change for three main reasons:

• Lack of understanding of objectives

• Disagreement with new direction

• Anxiety about how the change will affect them

Ritchie 55

To address those reasons, FDD implementation and design of process details will invite and encourage the full participation (and even leadership) of staff members. Group discussion and individual meetings will serve to communicate and inform staff members, identify specific concerns, respond to employee questions, and seek employee advice and input –both into the change process and regarding specifics of the methodology itself. The change management approach employed will be integrative, addressing both logical and psychological dimensions of change as recommended by Zink, Ulrich and Schroder (2008), and flexible, as suggested by Minza (2009).

Palmer and Felsing (2002) note that introducing small changes is easier than imposing major changes. Beck and Andres (2005), and Bauer (2003) agree, suggesting that both XP and FDD adoption should start by first adopting select individual practices, and then building upon those practices by gradually introducing the full set of processes and practices.

7.2.2 Order of Adoption

Prioritization of the order of implementation of specific practices should consider characteristics such as practice benefits, difficulty of implementation, alignment with culture and existing practices, who will be responsible, and who will benefit most by adoption of the practice. A simple scoring exercise based on those criteria36 suggests the following order implementation should be:

1) Build features list (16) Modeling (13)

2) Modeling (13) Build Features List (16)

3) Plan by Feature (12)

4) Design by Feature and Build by Feature (11)

5) Results Visibility (8)

6) Inspections of Design

7) Inspections of Model

8) Code Inspection

9) Configuration Management

The scoring methodology does not consider natural prerequisites of any practice or phase. When prerequisites are considered, one inconsistency emerges from the list as scored – that Modeling is a prerequisite of the Build Features List activity. Fortunately, the modeling process has value even when not embedded in a complete methodology. Therefore, the proposed order of implementation exchanges the first two items (as illustrated with the strike-through text above), such that implementation starts with Modeling, followed by Build Features List. The close relationship and value of those processes suggests their implementation in the same implementation iteration. The proposed order of adoption is subject to change following input from involved staff

36 Please see Appendix 10.3 for details of the prioritization exercise.

Ritchie 56

members. Based on the process prioritization, and with due consideration of the importance of the people-related aspects of change, a tentative timeline is proposed.

7.2.3 Timeline

Quick action is desired. The current process-related problems must be addressed soon; in addition, a leading developer will be absent on a one-year leave beginning April 1, 2009. Their input and involvement into the adoption plan and methodology design is preferred. Therefore, adoption of the FDD process should begin immediately, following the proposed schedule:

Table 2: Tentative Implementation Schedule

Goals and objectives Activities Target Date

Goals: Staff support of new methods Methodology refinement

Objectives: Staff learns about new methodology. Staff concerns identified. Staff objections resolved by alteration of methods, explanation, or negotiation.

Staff roundtables, and individual meeting meetings, informal discussions

Mar. 31, 2009

Goal: Grow staff recognition of methodology value.

Objectives: Demonstrate success of the Modeling and Build Features List processes in one project. Refine Modeling process. Refine Build Features List process.

Use Modeling and Build Features List processes for one small project

Staff roundtables, individual meetings, and informal discussions

April 30, 2009

Goal: Grow staff acceptance and familiarity with methodology value, prepare for adoption of additional processes and practices.

Objectives: Demonstrate refined Modeling and Build Features List processes in second project. Refine modeling process. Refine Build Features List process.

Use modeling and Build Features List processes for one mid-sized project

Staff roundtables, and individual meeting meetings, informal discussions

May 31,2009

Ritchie 57

Goal: Formally adopt Modeling process.

Objective: Achieve staff agreement through consensus, on consistent use of Modeling and Build by Features processes

Staff roundtables, and individual meeting meetings, informal discussions

June 15, 2009

Goals: Further progress toward full methodology adoption.

Objectives: Test suitability of Plan by Feature, Design by Feature, and Build by Feature processes. Refine processes

Use all five FDD processes in a single small high-success probability project

Introspective staff meetings to discuss processes.

July 31, 2009

Goals: Refine all FDD processes employed to date. Grow staff support.

Objectives: Demonstrate successful use of all five FDD processes. Write formal definition of FDD methodology, as deployed at TradingCharts.

Use all five FDD processes in a single mid-sized, high-success probability project

Introspective staff meetings to discuss processes, and reach consensus on methodology design.

Sept. 15, 2009

Goals: Adopt inspection practices Formally adopt full FDD methodology

Objectives: Demonstrate inspection practices in a single project Reach agreement on full implementation of FDD methodology by consensus Assign one staff member to become guardian and coach for the methodology.

Use inspection practices in a single simple project.

Introspective staff meetings to identify and mitigate or negotiate concerns, and to choose method coach.

Oct. 15, 2009

Goal: Introduce configuration management

Objectives: Identify and deploy appropriate versioning system

Review available versioning systems, with consideration given to integration with existing tools, and acceptability within company culture

Date dependent of identification of suitable tools.

Ritchie 58

Incremental and evolutionary improvement of the methodology and practices will be ongoing, driven through monthly process meetings that involve the entire staff. Beck and Andres (2005) warn of the danger and ease that behaviours might revert to old practices. To mitigate that risk, a volunteer method coach will watch and provide guidance to ensure that FDD methods and practices are sustained; HR practices will support continued FDD application by rewarding staff for consistent methods application.

Every aspect of methodology and practice design and application—in initial implementation and into the future—will centre on employee issues. Although formalized through minimal documentation, the FDD methodology and practices deployed by TradingCharts will be a living method that gradually evolves with process maturity, and in response to changing cultural, technological, and environmental conditions. It is through this adaptive and people-centric approach to both methodology and implementation that TradingCharts will achieve a successful transition to an improved development process that will serve company needs well into the future.

7.3 Key Factors of Sustainable Success

The scope of this research and resulting recommendations is limited to selection and implementation of a development methodology for TradingCharts. However, successful and sustained adoption of the methodology will require consideration of key success factors that fall beyond this scope. Those success factors relate to the governance and management of projects, process, and people.

7.3.1 Project Assessment

Post-execution evaluation of projects will provide operational accountability to both management and clients while identifying opportunities for improvement of practices and processes. A simplistic project assessment method might contemplate simple success metrics such as developer efficiency, customer satisfaction, and defect rate. While such measures are useful, they fail to accommodate the unique characteristics of Web application development, such as the multidisciplinary nature of the work and development team, and the range of business goals fulfilled by Web applications. A more appropriate assessment methodology will consider factors including marketing, business, people and technology as recommended in the evaluation methodology prescribed by St-Pierre (2001)37. Effective project assessment will provide accountability and reveal staff-related issues, while fostering team empowerment and growth by facilitating feedback of successes and failures. These effects will encourage and support incremental improvements in practices, and identification of methodology-related shortcomings, which will feed into process evaluation.

37 St-Pierre (2001) develops a method for objective assessment of electronic commerce projects which considers metrics including management factors, technology criteria, and human interface assessment, combining all in a weighted formula that results in a single score named the Evaluation Quality Composite Index.

Ritchie 59

7.3.2 Critical Methodology Evaluation

Continuous methodology evaluation and improvement compliments and mirrors project assessment. While feedback from project assessment will provide some guidance as to efficacy of the development methodology, according to Woo, Mikusauskas, Bartlett and Law (2006), effective methodology assessment must also consider factors including "ease of use, repeatability, adaptability, integration with other tools, amount of uncertainties, responsiveness to changes, accountability, traceability and manageability" (p 199). Mirroring concerns regarding project assessment, a simplistic methodology evaluation might only consider metrics directly related to organizational success and efficiency. According to Woo et al., a more appropriate evaluation method must exhaustively consider additional perspectives including those related to industry (evolving tools and techniques), project, product and staff. Outcomes of methodology evaluation will include continuous process improvement and assurance that the methodology remains aligned with the organization’s strategic goals and priorities.

7.3.3 Planning

Process efficiency depends, in part, on planning that maximizes use of developer time, ideally by scheduling a uniform level of work for a fixed-size team. Traditional scheduling practices include network project management frameworks such as Critical Path Analysis (CPM) and Project Evaluation and Review Technique (PERT), supported by tools such as Gantt charts. Unfortunately, these methods are of limited use at TradingCharts, where numerous concurrent projects share the limited resources of the single development team, and project progress often blocks waiting on customer interaction. The problem of scheduling limited shared resources can be addressed by the concurrent planning of multiple projects in a way that considers individual project priorities and the criticality of the shared resources in each project (Nicholas, 2002). Unfortunately, at TradingCharts the unpredictable timing of customer interaction results in sporadic project “workability” that exasperates the problem. TradingCharts must address this issue, perhaps by addressing the fitful flow of work by ensuring timeliness of customer interaction, by ensuring that valued standing projects are always available for work, and/or by using downtime to perform process overhead tasks such as project and process evaluations.

7.3.4 Technical Skills Excellence

Technical competency of development team members is vital to success of the prescribed methodology. Staff skills are rendered critical by the reliance and implicit trust vested in developers in organizations that employ Agile methodologies. In these organizations, teams are required to make appropriate design decisions with minimal extrinsic guidance, relying largely upon team knowledge and skills to identify superior options. Further, the small team and organizational size requires special care to ensure that there are no gaps in required skills inventory. In Web application development, the pace of evolving Web technologies heightens difficulty in attaining and maintaining relevant staff skills.

Ritchie 60

These factors demand a concerted effort to ensure team technical excellence, through alignment of organizational policy and practices that should include:

• hiring skilled staff

• providing opportunities for continuous learning

• offering education incentives

• paying rates of remuneration that encourage staff retention

Attention to these four key success factors is requisite to sustained success in applying Feature Driven Development methodology at TradingCharts.

8.0 Conclusion

Through study of software development methodologies, viewed through a lens of analysis of company needs, cultural factors and environmental characteristics, this paper prescribes an effective and appropriate development methodology for International TradingCharts.com, Inc.

TradingCharts' Web development projects suffer substantial rates of failure. The exploration of company development processes reveals troubling correlations that suggest weakness in development methodologies. Those weaknesses result in problems for over forty percent of TradingCharts projects. Research and analysis of needs and alternatives suggests that an appropriate candidate is found in an established general-purpose Agile methodology.

A survey of methods found in academic literature reveals a variety of methodologies, from adaptive to predictive, lightweight to detailed, and intended for general software development or designed specifically for Web development projects. Exploration of methodology requirements that address the unique characteristics of Web development projects, viewed in light of the cultural, workspace and business environment of TradingCharts indicate that the company will benefit by adopting an Agile development methodology that is embedded within a predictive overall framework. Of the three methods that appear to suit those criteria, Feature Driven Development is selected as the base for TradingCharts' methodology. FDD aligns well with present company processes and customer expectations, and the methodology has been proven effective through its use in the Web development industry.

FDD is not a perfect fit for TradingCharts. However, after modest tweaks and the creation of a modeling process, the FDD should provide a base from which to build an effective adapted methodology. Consideration of HR aspects of change management suggests that a gradual, employee-centric adoption process is required. An eight-month adoption process is suggested, although the timeline and phases are likely to change as employee input is accommodated.

Adoption of Feature Driven Development will address many problems in the projects that TradingCharts undertakes, and unleash employee energy and skills that will propel the company toward a successful future.

Ritchie 61

9.0 References

Abrahamsson, P, Outi, S. & Ronkain, J. (2002) Agile Software Development Methods: Review and Analysis. V.T.T. Technical Research Centre of Finland. Retrieved Oct 29, 2008 from http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf

Barber, K. (2004). Definition of Methodology. The Canadian Oxford Dictionary. Oxford University Press. Oxford Reference Online. Retrieved January 18, 2009 from http://0-www.oxfordreference.com.aupac.lib.athabascau.ca/views/SEARCH_RESULTS.html?searchnumber=1&q=methodology&timelines=0&category=s7&scope=subject&ssid=449024706&filter_out=long

Bauer, M. (2003). FDD & Web Development. Non-academic web page. Retrieved January 13, 2009 from http://www.designit.com.au/articles/fdd_web_development

Bauer, M. (2003). FDD Process One, The Human Factor. Non-academic web page. Retrieved January 13, 2009 from http://www.designit.com.au/articles/fdd_process_one_the_human_factor

Bauer, M. (2005). Successful Web Methodologies. Non-academic web article. Retrieved January 13, 2009 from http://www.designit.com.au/articles/successful_web_methodologies

Beck, K., & Andres, C. (2005). Extreme Programming Explained: Embrace Change. 2nd ed. Pearson Education, Inc. Upper Saddle River, NJ

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A, Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Principles behind the Agile Manifesto. Retrieved November 1, 2008 from http://agilemanifesto.org/principles.html

Boehm, B. (1988). A Spiral Model of Software Development and Enhancement IEEE May 1988 (pp 61-72). Retrieved October 29, 2008 from http://www.cs.usu.edu/~supratik/CS%205370/r5061.pdf

Boehm, B. (2002) Get Ready for the Agile Methods, With Care. Computer 35(1): 64-69. As referenced by Abrahamsson et al (2002)

Boehm, B., 2006. A view of 20th and 21st century software engineering. ICSE '06: Proceedings of the 28th international conference on Software engineering. ACM. Retrieved January 10, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1134288&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Capiluppi, A., Fernandez-Ramil, J., Higman, J., Sharp, H. & Smith, N. (2007). An Empirical Study of the Evolution of an Agile-Developed Software System . ICSE '07: Proceedings of the 29th international conference on Software Engineering. IEEE Computer Society. Retreived January 7, 2009 from http://0-

Ritchie 62

portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1248883&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Carson, C. (2005). A Historical View of Douglas McGregor's Theory Y. Management Decision. Vol. 43, Iss 3, pp 450-460. Emerald Group Publishing Limited. Retrieved February 5, 2009 from http://0-www.emeraldinsight.com.aupac.lib.athabascau.ca/Insight/viewContentItem.do;jsessionid=A61181D5352C022BC6EA33E4D4D1811D?contentType=Article&hdAction=lnkpdf&contentId=1463109&history=false

Cockburn, A. (2000). Selecting a project's methodology. IEEE Volume 17, Issue 4, July-Aug. 2000 Page(s):64 - 71. Retrieved February 22, 2009 from http://0-ieeexplore.ieee.org.aupac.lib.athabascau.ca/stamp/stamp.jsp?arnumber=854070&isnumber=18557

De Luca, J. (undated). The Latest FDD Proceses. Retrieved January 13, 2009 from http://www.nebulon.com/articles/fdd/download/fddprocessesUSLetter.pdf

De Luca, J. (undated, 1). Agile Software Development using Feature Driven Development (FDD). Retrieved January 12, 2009 from http://www.nebulon.com/fdd/index.html

De Luca, J. (undated, 2). FDD Processes. Retrieved January 12, 2009 from http://www.nebulon.com/articles/fdd/download/fddprocessesUSLetter.pdf

De Luca, J. (undated, 3). FDD Implementations. Retrieved Jan 12, 2009 from http://www.nebulon.com/articles/fdd/fddimplementations.html

Deshpande, Y. & Hansen, S. (2001). Web Engineering: Creating a Discipline among Disciplines. Retrieved Jan 19, 2009 from http://0-ieeexplore.ieee.org.aupac.lib.athabascau.ca/stamp/stamp.jsp?arnumber=917974&isnumber=19845. Multimedia, IEEE. Volume 8, Issue 2, April-June 2001 (pp 82-87)

El Sheikh, A. & Tarawneh, H. (2007). A survey of web engineering practice in small Jordanian web development firms. ESEC-FSE '07: Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering. ACM. Retrieved January 10, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1287692&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Epner, M.(2000). "Poor Project Management Number-One Problem of Outsourced E-Projects", Research Briefs, Cutter Consortium. (as referenced by Kushwaha, D, Signh, R., and Misra, A. (2006)

Flannes, S. & Levin, G. (2005). Essential People Skills for Project Managers. Management Concepts. Retrieved February 5, 2009 from http://ezproxy.athabascau.ca:2066/book/id_14168/book.asp

Ritchie 63

Fowler, M. & Highsmith, J. (2001). The Agile Manifesto (pdf). Retrieved November 1, 2008 from http://www.hristov.com/andrey/fht-stuttgart/The_Agile_Manifesto_SDMagazine.pdf

Garzotto, F. & Perrone, V. (2006). Industrial Acceptability of Web Design Methods: An Empirical Study. Journal of Web Engineering, Vol. 6, No.1 (2007) 073-096. Retrieved January 8, 2009 from http://www.cs.ucl.ac.uk/staff/v.perrone/publications/Industrial_acceptability_of_Web_Design_Methods_An%20empirical%20study_(JWE).pdf

Gotsill, G., & Natchez, M. (2007). From Resistance to Acceptance: How to Implement Change Management. T + D. American Society for Training and Development. Retrieved from http://0-search.ebscohost.com.aupac.lib.athabascau.ca/login.aspx?direct=true&AuthType=url,ip,uid&db=a9h&AN=27448963&site=ehost-live

Grossman, F., Bergin, J., Leip, D., Merritt, S., & Gotel, O.(2004) IBM Corp. retrieved January 8, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1034933&type=pdf&coll=ACM&dl=ACM&CFID=17598605&CFTOKEN=52436509

Hochmüller, E. & Mittermeir, R. (2008). Agile Process Myths. APOS '08: Proceedings of the 2008 international workshop on Scrutinizing agile practices or shoot-out at the agile corral. Retrieved January 10, 2008 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1370145&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Hseih, S. (2003). Software engineering for Web application development. Journal of Computing Sciences in Colleges. Volume 19 Issue 1. Consortium for Computing Sciences in Colleges. Retrieved January 8, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=948740&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Jazayeri, M. (2007). Some Trends in Web Application Development. FOSE '07: 2007 Future of Software Engineering. IEEE Computer Society. Retreived January 9, 2008 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1254719&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Jugdev, K. (2008). Excerpt draft notes of new Applied Project Study Guide. Athabasca University. Received by personal email October 12, 2008.

Kaplan, R., & Norton, P. (1996). The Balanced Scorecard. Harvard Business School Press. Boston, Ma.

Kent, B., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, M., Schwaber, K., Sutherland, J. & Thomas, D., (2001). Manifesto for Agile

Ritchie 64

software development. Websites. Retrieved October 24, 2008 from http://www.agilemanifesto.org/

Khan, A. (2004). A Tale of Two Methodoloties for Web Development: Heavyweight vs Agile. Retrieved January 16, 2009 from https://www.dis.unimelb.edu.au/staff/sandrine/supervision/PDF/AliKhan_615690FinalReport_2004.pdf

Khramtchenko, S. (2004). Unpublished academic paper written for Software Architecture and Engineering class at Harvard. Retrieved January 13, 2009 from http://www.featuredrivendevelopment.com/files/FDD_vs_XP.pdf

Lang, M. & Fitzgerald, B. (2005). Hypermedia Systems Development Practices: A Survey. Software, IEEE Volume 22, Issue 2, Mar-Apr 2005 Page(s):68 - 75. Retrieved February 22, 2009 from http://0-ieeexplore.ieee.org.aupac.lib.athabascau.ca/stamp/stamp.jsp?arnumber=1407831&isnumber=30525

Lang, M., & Fitzgerald, B. (2007). Web-based systems design: a study of contemporary practices and an explanatory framework based on "method-in-action". Requirements Engineering, 12(4), 203-220. Retrieved November 4, 2008, from http://0-search.ebscohost.com.aupac.lib.athabascau.ca/login.aspx?direct=true&AuthType=url,ip,uid&db=a9h&AN=26961184&site=ehost-live

Maurer, F. & Martel, S., (2002). Extreme Programming: Rapid Development for Web-Based Applications. IEEE Internet Computer. Jan-Feb 2002 (pp 86-90). Retrieved December 20, 2008 from http://www.agilealliance.org/system/article/file/1026/file.pdf

McDonald, A. & Welland, R. (2001) "Web Engineering in Practice". Proceedings of the 4th WWW10 Workshop on Web Engineering”, pp. 21 – 30, May 2001.(as referenced by Kushwaha, D, Signh, R., and Misra, A. (2006)

McDonald, A. & Welland, R. (2001). Agile Web Engineering (AWE) Process. Department of Computing Science, University of Glasgow, Glasgow, Scotland. Retrieved October 28, 2008 from http://www.dcs.gla.ac.uk/publications/PAPERS/7087/TR-2001-98%5B1%5D.pdf

Mirza, B. (2009). Organizational Change Starts With Individual Employees. HRMagazine: SHRM's 2009 HR TREND BOOK,31-32,34. Retrieved February 10, 2009 from http://0-proquest.umi.com.aupac.lib.athabascau.ca/pqdweb?did=1607406611&sid=2&Fmt=3&clientId=12302&RQT=309&VName=PQD

Mišic, V. (2006). Perceptions of Extreme Programming: an Exploratory Study. SIGSOFT Software Engineering Notes , Volume 31 Issue 2. ACM. Retrieved January 9, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1118542&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Ritchie 65

Mugridge, R. (2008). Managing Agile Project Requirements with Storytest-Driven Development. IEEE Software, 25(1), 68. Retrieved October 25, 2008, from http://0-proquest.umi.com.aupac.lib.athabascau.ca:80/pqdweb?did=1410645121&sid=1&Fmt=6&clientId=12302&RQT=309&VName=PQD

Murugesan, S. & Ginige, A. (2005). Web Engineering: Introduction and Perspectives. Idea Gropu Inc. Retrieved January 12, 2009 from http://www.idea-group.com/downloads/excerpts/01%20Suh.pdf

Newman, M., & Landay, J. (2000). Sitemaps, storyboards, and specifications: a sketch of Web site design practice. DIS '00: Proceedings of the 3rd conference on Designing interactive systems: processes, practices, methods, and techniques. ACM. Retrieved January 6, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=347758&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Nicholas, J. (2004). Project Management for Business and Engineering. 2nd Ed. Butterworth-Heinemann, 2004

Olsen, H. (2002). The Bottom-line of Prototyping and Usability Testing. The Interactive Designer's Coffee Break. Iss 02-Q2-2002. Retrieved January 11, 2009 from http://guuui.com/issues/02_02.php

Palmer, S., & Felsing, J. (2002). A Practical Guide to Feature Driven Development. Prentice Hall PTR. Upper Saddle River, NJ

Pruijt, Hans (2000). Repainting, modifying, smashing Taylorism. Journal of Organizational Change Management, 13(5), 439-451. Retrieved February 11, 2009, from http://0-proquest.umi.com.aupac.lib.athabascau.ca/pqdweb?did=115926921&sid=2&Fmt=3&clientId=12302&RQT=309&VName=PQD

Richardson, I. & von Wangenheim, C. (2007). Guest Editors' Introduction: Why are Small Software Organizations Different? IEEE Software, 24(1), 18-22. Retrieved October 25, 2008, from ProQuest Computing database. (Document ID: 1326207391).

Russ, M. & McGregor, J. (2000). "A Software Development Process for Small Projects". IEEE software (0740-7459), 17 (5), p. 96. Retrieved Jan 12, 2009 from http://0-ieeexplore.ieee.org.aupac.lib.athabascau.ca/stamp/stamp.jsp?arnumber=877874&isnumber=19003

Ste-Pierre, A. (2001). The Evaluation of E-Commerce Applications – A Conceptual Framework. Received March 14, 2009 by personal e-mail from Ste-Pierre.

Souza, V., & Flabo, R. (2005) An Agile Approach for Web Systems Engineering. Dec 2005 WebMedia '05' Proceedings of the 11th Brazilian Symposium on Multimedia and the Web. Publisher: ACM. Retrieved November 5, 2008 from http://0-portal.acm.org.aupac.lib.athabascau.ca/citation.cfm?id=1114223.1114237&coll=ACM&dl=ACM&CFID=11161642&CFTOKEN=80727344

Ritchie 66

TechEncyclopedia (2009). Definition of Methodology. Retrieved Jan 18, 2009 from http://www.techweb.com/encyclopedia?term=methodology

Turban, E., McLean, E. & Wetherbe, J. (2004), Information Technology for Management: Transforming Organizations in the Digital Economy (4th ed.) Hoboken, New Jersey: John Wiley and Sons, Inc.

Wallace, D., Raggett, I. & Aufgang, J. (2003). Extreme Programming for Web Projects. Pearson Education, Inc. Upper Saddle River, NJ

Wells, D. (2000). Extreme Programming Process Diagram. Retrieved January 20, 2009 from http://www.extremeprogramming.org/map/project.html

Whitson, G. (2006). WebHelix: Another Web Engineering Process. Journal of Computing Sciences in Colleges , Volume 21 Issue 5. Consortium for Computing Sciences in Colleges. Retrieved January 11, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1127358&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Woo, F., Mikusauskas, R., Bartlett, D., and Law, R. (2006). A framework for the effective adoption of software development methodologies. In Proceedings of the 44th Annual Southeast Regional Conference (Melbourne, Florida, March 10 - 12, 2006). ACM-SE 44. ACM, New York, NY, 198-203. Retrieved March 14, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1185493&type=pdf&coll=ACM&dl=ACM&CFID=26038009&CFTOKEN=14460408

Zettell, J., Maurer, F., Münch, J., & Wong, L. (2001). LIPE: A Lightweight Process for E-Business Start-up Companies based on Extreme Programming. Kaiserslautern, 2001, VII, 19 pp.. Ill., Lit. IESE-Report, 042.01/E Reportnr.: 042.01/E. Retrieved December 20, 2008 from http://vg00.met.vgwort.de/na/38a0f2cb63fc3f3b2fdb?l=http://publica.fraunhofer.de/eprints/urn:nbn:de:0011-n-64950.pdf

Xiaocheng, G., Paige, R., Polack, F., Chivers, H. & Brooke, P. (2006). Agile development of secure web applications. ICWE '06: Proceedings of the 6th international conference on Web engineering. ACM. Retrieved January 9, 2009 from http://0-portal.acm.org.aupac.lib.athabascau.ca/ft_gateway.cfm?id=1145641&type=pdf&coll=ACM&dl=ACM&CFID=17948185&CFTOKEN=85773179

Zink, K., Ulrich, S. & Schroder, D. (2008). Comprehensive Change Management Concepts: Development of a Participatory Approach. Applied Ergonomics (39). Research Institute for Technology and Work. Kaiserslautern. Retrieved from http://0-www.sciencedirect.com.aupac.lib.athabascau.ca/science?_ob=ArticleURL&_udi=B6V1W-4S9R894-2&_user=1067473&_coverDate=07%2F31%2F2008&_rdoc=1&_fmt=&_orig=search&_sort=d&view=c&_acct=C000051252&_version=1&_urlVersion=0&_userid=1067473&md5=89efd7f5a43aa50453ab0e2d3aa25a6c#cor1

Ritchie 67

10.0 Appendices

10.1 Principles behind the Agile Manifesto

We follow these principles: Beck et al., (2001)

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Ritchie 68

10.2 Survey of TradingCharts Methods: data

Project complexity

Number

of

Projects

Project Effort in Hours

Number

of

Projects

Informational 18 0-40 20

Interactive 6 41-80 6

Transactional 5 81-120 1

Workflow 1 121-160 1

161-200 1

Project size

201+ 1

Small 6

Medium 16 Problems Objectively Observed

Large 8 Over Budget 8

Customer dissatisfaction 3

Coding Complexity

No coding 1 Project Failure Modes / Causes

Minimal 10 Business value unrealized 2

Modest 13 Developer inexperience 4

Substantial 5 Delay wait on customer input 3

Complex 1 Difficulty identifying requirements 4

Code defects 2

Methodology Employed

Ad-hoc, cowboy development 7 Number of challenged projects 13

Single-developer, out of box 1

Multiple developer team 13

Leader + Development team 7

Formal SDLC 2

Ritchie 69

10.3 Scoring of Practices and Process for Implementation Prioritization