e commerce project development risks

International Journal of Information Management 23 (2003) 25–40

E-commerce project development risks: evidencefrom a Delphi survey1

Tom Addison*

School of Economic and Business Sciences, University of The Witwatersrand, Private Bag 3,

Wits 2050, South Africa

Abstract

This paper reports on a study to determine the opinion of expert practitioners of the most important risksin the development of e-commerce projects. The 32 respondents in the final round of the survey were mainlyproject managers from South African software houses. Various academics and users of e-commerce systemsalso contributed to the survey. The Delphi technique was used to gather the data and to rank the risks.Misunderstanding the users’ requirements emerged as the most significant risk, followed by the absence

of declared business benefits. As with conventional systems, there is a risk of top management not gettingtotally committed to the project, very often giving verbal encouragement to the IT team but overlooking theimpact on the business as a whole.Respondents place a high importance on the security issues surrounding e-commerce projects.

Transactions are subjected to more threats, and developers have to incorporate procedures to ensuretransaction integrity and confidentiality, and then convince potential customers of the system’s security.Other related issues include transaction tracability and database security and integrity.Hype in the market suggested that there was a large risk of delivering systems too slowly as a result of

‘‘cumbersome’’ methodologies. The research did not find this to be the case.Different perspectives emerged from the viewpoints of developers, project managers, clients/users and

academics.r 2003 Elsevier Science Ltd. All rights reserved.

Keywords: E-commerce; Security issues; Risk management; Delphi survey

*Tel.: +27-11-717-8152; fax: +27-11-717-8139.

E-mail address: [email protected] (T. Addison).1An earlier version of this work was presented at the BITWorld conference, Cairo, June 2001, publisher RITI.

0268-4012/03/$ - see front matter r 2003 Elsevier Science Ltd. All rights reserved.

PII: S 0 2 6 8 - 4 0 1 2 ( 0 2 ) 0 0 0 6 6 - X

1. Introduction

Information Systems (IS) and the development and management thereof have been the subjectof many academic research studies since it became apparent that many, possibly even a majorityof IS projects exceeded their allocated budgets and/or their planned timescales.Software has characteristics which differentiate IT projects from other disciplines, such as

construction/building projects. They include invisibility and flexibility (Brooks, 1975). Invisibilityrefers to the inability to visibly see progress, and the potential of software to be flexible results inthe tendency to change scope and thereby threaten deadlines. In addition, all IT projects areunique (if they were not they would presumably be package implementations), and therefore theabsence of usable historical benchmarks renders us somewhat ineffective when attempting toestimate project timescales.One of the cornerstones of project management is risk management, and documented studies at

various intervals from 1981 to 1998 have enabled IS managers to be aware of most of the potentialrisks during the development of IS projects. (See for instance McFarlan, 1981; Boehm, 1991; Barki,Rivard, & Talbot, 1993; Keil, Cule, Lyytinen, & Schmidt, 1998.) These risks vary from inexperiencewith applied technology, through misunderstanding user requirements, to lack of top managementsupport. Some of these risks, such as the three just mentioned, prevail regardless of the computerarchitecture, and are expected to prevail indefinitely. Recent research (Keil et al., 1998) indicatesthat risks in projects can (broadly) be categorised as those over which the project manager hascontrol, and those, which are caused by non-controllable elements. Different managementstrategies are needed to anticipate, avoid, recognise, and counteract these different categories.

2. Defining electronic commerce

Rayport and Jaworski (2001) formally define e-commerce as ‘‘..technology mediated exchangesbetween parties (individuals, organizations or both) as well as the electronically based intra- orinterorganizational activities that facilitate such exchanges.’’ Schneider and Perry (2000) state thata good definition of electronic commerce ‘‘would mention the use of electronic data transmissionto implement or enhance any business process’’. According to Watson, Berthon, Pitt, andZinkhan (2000), electronic commerce involves the use of information technology to enhancecommunications and transactions with a company’s stakeholders, and includes activities such asestablishing a web page to facilitate those communications. Electronic commerce is narrowlydescribed in some instances as a mechanism for internet-enabled electronic data interchange(EDI). Most definitions of ‘‘commerce’’, however, contain the verb ‘‘trade’’ (see for instance the[unabridged] Oxford English Dictionary). The writer’s interpretation is that an e-commerceproject involves the development of an information system to enable trading to take place, andthat as a minimum requirement a web site to facilitate the trading is used.E-commerce projects retain many similarities with conventional systems development projects.

Issues that are (unavoidably) similar include the need for feasibility studies, determination ofrequirements, programming and testing. However, developers are constantly under pressure toabandon sound systems development methodologies as their management regards them as toocumbersome. This has led to various R&D groups searching for methodologies, which may not be

T. Addison / International Journal of Information Management 23 (2003) 25–4026

as thorough. A constant complaint of e-commerce system developers is that projects taking morethan 12 months (some say 3 months) to develop will not be usable, as they will have beensuperseded by better systems offered by the competition.For electronic commerce projects, while the characteristic of uniqueness (described earlier) is

certainly still there, and timescale estimating is (consequently) still difficult if not more difficultthan for traditional systems, the (e-commerce) project under development often leaves itselfexposed for the whole world to see. Misunderstanding the requirements (caused by inadequatesystems analysis) takes on a new perspective. Whereas users can be interviewed to determine theirrequirements, customers often cannot, and future customers may not even be known.Against a background of failures of numerous dot com companies, even older companies

are closing down as a result of inappropriately planned entries into the e-commerce world.Companies are only now beginning to realise that e-commerce projects are not just an issuefor the IT department, but a major decision affecting the company as a whole. In many instancesbusiness processes have to be transformed, new systems have to be interfaced back to, or replace,legacy systems, and international time differences in various instances force a company tooperate extended and more flexible working hours to satisfy new customers and ensure web sitecredibility. In the process they discover a host of new competitors, and have to make strategicdecisions as to whether to operate in the international markets. Almost by definition, web businessimplies minimum legislation and rules, particularly in the global context where countries differ intheir views and laws regarding issues such as privacy and transparency, but also in terms oftaxation, liability and other factors affecting business transactions. Companies electing to operate24 h a day, 7 days a week, could well overlook various things, such as their existing systems areaccustomed to shutting down every evening to produce end of day reports and enable certainfields to be reset. The need to interface the e-commerce system to the existing systems is not simplya matter of file transfer, it is conceivable that the existing systems will have to be severely re-architectured so that they themselves can operate for 24 h a day. Companies need to seriouslyinvestigate whether their business partners in the supply chain will follow suit.

3. Previous studies in IT project risk management

One of the first methods of categorising the magnitude of risk in an IS project was introducedby McFarlan (1981). This method uses as its source a questionnaire that encompassed allhardware, software, users and vendor degrees of experience and other issues surrounding aproposed new system. The issues are categorised according to size, technology and structure.McFarlan (1981) suggested that an organisation should have a portfolio consisting of a balance ofhigh- and low-risk projects.The risk return relationship is fairly well known, organisations being unlikely to enjoy positive

growth unless various risks are taken. The more recent studies in IT project risk management havefocused more on the negative connotations of risk. Boehm (1991) surveyed several experiencedproject managers and published a list of the top 10 software risk items, namely:

* personnel shortfalls,* unrealistic schedules and budgets,* developing the wrong functions and properties,

T. Addison / International Journal of Information Management 23 (2003) 25–40 27

* developing the wrong user interface,* gold-plating,* continuing stream of requirements changes,* shortfalls in externally furnished components,* shortfalls in externally performed tasks,* real-time performance shortfalls,* straining computer-science capabilities.

(Each of these above can be the precipitator of other consequences, e.g. unrealistic budgets cancause a project to overrun its budget.)An intensive study of 120 projects in 75 organisations by Barki et al. (1993) resulted in the

retention of 23 risk factors. Barki et al. call these uncertainty factors with an explanation that riskand uncertainty factors are synonymous.The 23 (retained) items were:Technical newness

* need for new software,* number of software suppliers,* need for new hardware,* number of hardware suppliers,* number of users outside the organisation.

Application size

* team diversity,* number of people on the team,* number of users {of the system} in the organisation {after implementation},* relative project size,* number of hierarchical levels occupied by users.

Expertise

* team’s lack of general expertise* lack of development expertise in team* team’s lack of expertise with task* team’s lack of expertise with application* lack of user experience and support.

Application complexity

* number of links to future systems* number of links to existing systems* technical complexity.

Organisational environment

* extent of changes* intensity of conflicts


* lack of clarity of role definitions* resource insufficiency* task complexity.

Keil et al. (1998) point out that Boehm’s list excludes items over which the project manager haslimited control. The findings of Keil et al. (1998) in a study conducted in three countries (USA,Hong Kong and Finland) were that the top eleven risk factors identified were:

* lack of top management commitment to the project,* failure to gain user commitment,* misunderstanding the requirements,* lack of adequate user involvement,* failure to manage end user expectations,* changing scope/objections,* lack of required knowledge/skills in the project personnel,* lack of frozen requirements,* introduction of new technology,* insufficient/inappropriate staffing,* conflict between user departments.

The ranking of these risks varied slightly from country to country.Keil et al. (1998) point out that the most important risks are frequently not under the control of

the project manager. They mapped the different risks identified by their sample into a 2� 2 grid,the Y-axis showing the perceived relative importance of a risk (moderate or high), and the X-axisshowing the perceived level of control (low or high). Keil et al. (1998) suggest further that risksshould be managed according to which quadrant they fall into as per the grid.

4. Importance of the study

The previous work reported above examined the risks from a generic point of view, i.e. did notcategorise the type of system, for example e-commerce, object oriented, enterprise resourceplanning (ERP) and so on. E-commerce and other web-based systems have certain characteristicswhich differentiate them from more traditional systems. For instance web-based payment systemsdo not yet enjoy the trust and security of well-entrenched traditional payment systems, and thedevelopment of digital certificates and security protocols is relatively young. As the Internetinfluences new directions in business processes, new job titles begin to emerge (for example ‘‘webarchitect’’), and supply chains transform (for example in book publishing, the classical chain ofauthor, publisher, wholesaler, retailer is changing to reduce the number of steps in the chain.Just as the business environment is experiencing new risks (for instance the risk of a wholesaler

being disintermediated), or existing risks experiencing different priorities, similar dynamics arebeing experienced in the development of computer systems to support web-based systems.Against the above background, this research seeks to determine the most important risks in the

development of e-commerce projects. Whereas it is expected that various risks will prevail


regardless of the type of system being developed (for example the lack of top managementcommitment to the project), the changing type of system and the changing business environmentsuggest that we should be aware of new risks and re-examine the importance of the moretraditional risks.

5. The Delphi technique for research in information systems

The Delphi technique was developed by NC Dalkey and his associates at the Rand Corporationin the 1950s. It is used extensively in IS research to identify and rank key issues for managementattention (Delbecq, Van de Ven, & Gustafson, 1975). Various researchers have used the techniqueto conduct research into IS management issues (see for instance Brancheau, Janz, & Wetherbe,1996; Keil et al., 1998).The method consists principally of knowledgeable and expert contributors individually

completing a form and submitting the results to a central coordinator. The coordinator processesthe contributions, looking for central and extreme tendencies, and the rationales therefore. Theresults are then fed back to the respondent group, who are asked to resubmit their views, assistedby the ‘‘new’’ input provided by the coordinator. The most significant difference between theDelphi technique and other methods of joint decision-making is that respondents do notcommunicate directly with one another (Delbecq et al., 1975). There is, therefore, no risk thatparticipants’ opinions will be suppressed by others by virtue of rank/status or personality. There isalso a high degree of anonymity (participants are known only to the coordinator), participants donot have to travel, and within a given time limit, can respond at the most convenient time.Delbecq et al. (1975) point out that whereas practitioners of the Delphi technique are in general

agreement regarding objectives (of Delphi studies), there are variations among practitionersregarding design, for example the number of iterations. Schmidt (1997) argues that there are threedistinct phases in data collection. The first phase is to discover the issues, the second is todetermine the most important, and the third is to rank the issues.In the discovery phase, participants are asked to list and describe their view of the six most

important issues. Descriptions are necessary because different respondents will use differentterminology for the same issue.In the second phase, a consolidated list, in random order, is issued to the participants, who will

be asked to select the top 10% of the issues from a consolidated list. The coordinator eliminatesall issues that were not selected by a simple majority of the respondents. If necessary (i.e. if morethan 20 items have still not been eliminated), a second round of this phase can be conducted, usinga condensed list, but this is unusual.In the third phase, the final list is sent to the respondents, who are asked to rank the items on

the list.Controlled feedback is given to respondents after each round, including the degree of consensus

among respondents.Regarding the issue of determining an optimum number of survey respondents, Delbecq et al.

(1975) suggest that few new ideas are generated within a homogeneous group once the size exceeds30 well-chosen participants, for decision-making purposes. However, if confident researchfindings were sought, a larger group would be more appropriate.


6. Respondent profile

For the first round of the survey, the researchers sought participation of experiencedproject managers and senior developers of e-commerce projects, as well as their clients. Thiswas accomplished by approaching some of the members of the Project Management specialinterest group of the Computer Society of South Africa, a direct marketing association, anelectronic commerce association, three successful e-commerce solution providers, and otherindividuals. Participants were in turn asked to encourage participation from other experts, andthis resulted in contributors from other countries. For the final round of the survey, contributionswere also sought from members of the ISWORLD list server, and this resulted in the inclusionof additional participants, including academics. Half of the 32 participants in the final round ofthe survey were project managers and developers from South African organisations, mainlysoftware houses.

7. Delphi first round procedures and interim results

The processes follow the recommendations of Schmidt (1995). Industry experts received an e-mail message inviting them to list at least six important risks in the development of e-commerceprojects. The researchers considered advising respondents of the outcome of similar surveys, forexample the work of Keil et al. (1998) which identified IS project (development) risks in general,not focussing on any specific type of IS project. This idea would have enabled respondents to havea better understanding of the subtle difference between risks and factors causing risks. The ideawas rejected, however, in line with the view of Schmidt (2000), who advises that ‘‘seeding’’ therespondents with the outcome of similar, previous studies, can result in the respondents notvolunteering any additional items. In addition, the data may be ‘‘tainted’’ by pre-emptivesuggestions.Respondents were given a limited amount of time to respond to the survey. The research-

ers collated the results, and used personal judgement when different respondents appearedto be mentioning the same issue using different vocabulary. This judgemental process wasthen validated by sending the consolidated list back to all of the initial respondents and request-ing them to confirm that their contributions had been correctly mapped. The 27 consolidateditems, prior to verification by the respondents, were grouped into the following 10 categories:

1. Issues related to user/customer requirements, attracting new customers, scope (4 items).2. Business and supply chain issues (2 items.)3. Methodology issues (1 item).4. Strategic planning/management/direction (3 items).5. Management and user support/commitment (2 items).6. Web page design considerations (2 items).7. Security issues (1 item).8. System integrity, testing and conversion issues (4 items).9. Staff issues (4 items).10. Technical environment (4 items).


Various items offered by the respondents were not carried through after the first round of thesurvey. These included items which the researchers perceived would be absent if reasonablemanagement processes were in place.Respondents were contacted to enquire whether the researchers had correctly interpreted the

meaning of their original input. As a result of this process, one additional issue was added to thelist. This appears as item 3.2 in Appendix A.

8. Delphi final round procedures

A computer-assisted method of aggregating the responses (see below) and thereby automatingthe ‘‘ranking’’ process was used. Schmidt (1995, 1997) notes that past researchers have combinedthe second and final (third) rounds of Delphi surveys, but cautions against this when the sheernumber of issues is going to inhibit the ranking process. As participants were not asked to ‘‘rank’’issues, i.e. compare the relative importance of an issue against other issues, and as theconsolidated list now consisted of a manageable 28 issues, the research proceeded directly to thefinal round.Participants were sent an e-mail message asking them to contribute to the final round. The

method used was to allow each participant to state a level of importance in the range 1–10, foreach of the 28 issues. Participants logged onto a web page specifically designed for this purpose,and used a ‘‘submit’’ method to send their input to the researchers. For each issue, a participantselected one of 10 numbered radio buttons, as per a method previously used by Scott and Walter(2001). This enabled the scores for each issue (for all participants) to be aggregated. The rankingprocess was completed by software, the issue with the highest (aggregate) score being ranked first,and so on. (The alternative method of expecting each respondent to rank 28 issues in descendingsequence of importance was felt to be unrealistic.)The issue list as presented to final round Delphi participants, with expanded descriptions of the

risk issues, is shown in Appendix A.

9. Analysis

The captured data was interpreted and the 10 most important risks are shown in Table 1. Fiveof the ‘‘top 10’’ risks reported by Keil et al., who did not specify type of project, also appear in thetop 10 for e-commerce projects established with this study. These are listed in Table 2.A more detailed breakdown of the rankings, including the job categories of academics, clients/

users, developers and project managers, is presented in Table 3.The means for the four job categories for each of the 28 issues were compared. Two tests were

performed—an ANOVA test which assumes the scores are normally distributed and theKruskall—Wallis test for k independent samples which is a non-parametric test. (The non-parametric test is not dependent upon the normality assumption.) The ANOVA and Kruskall–Wallace significance levels were tabulated and showed that none of the groups differ in terms ofmean scores over all the 28 issues.


Two correlations on the ranks in Table 3 were performed—Kendall’s tau and Spearman’s rankcorrelation. The Kendall’s tau results are shown in Table 4. (Spearman’s rank correlation yieldedsimilar results.) With only two exceptions, correlations of the rank scores were significant at the5% level of significance The two exceptions are client/users with academics and client/users withproject managers.The statistical tests comparing the four job categories suggest that most of the results can be

used with confidence, but it is suggested that any ‘‘findings’’ by job category are used with caution.The sample size of any of the job categories is smaller than that advocated by Delbecq et al.(1975).Many of the respondents had submitted comments and rationale with their responses, and some

of these are reported in the commentary below.

10. Interpretation and commentary

The results confirm that some risks prevail whether it is an electronic commerce project or a‘‘conventional’’ systems development project. Misunderstanding the users requirements emerged

Table 1

Top 10 e-commerce project development risks

Overall rank Risk

1 Misunderstanding the user/customer requirements

2 Absence of declared business benefit

3–4 (joint) Too narrow focus on the IT project issues and overlooking the impact on the distribution channels

and the business in general

3–4 Inadequate security features being built into the system

5 Lack of e-commerce project experience

6 Lack of understanding of web page design principles

7 Lack of top management commitment and support

8 Failure to manage end user expectations

9 Insufficient procedures to ensure security, integrity and availability of the database

10 Lack of user commitment and involvement

Table 2

Top 10 risk items appearing in both e-commerce and other projects

Description Generic risks (Keil et al.,

1998) USA rank

E-commerce risks (this

study) overall rank

Misunderstanding the user/customer requirements 2 1

Lack of required skills/e-commerce project experience 7 5

Lack of top management commitment and support 1 7

Failure to manage end user expectations 5 8

Lack of user commitment and involvement 3 10


Table 3

E-commerce risks ranked overall and by category of respondent

Item number and description Overall rank Academics Clients/users Developers Project

managers

1.1. Misunderstanding the user/customer

requirements

1 3 17–20 2 1

4.1. Absence of declared business benefit 2 4 2 8–12 3–4

2.1. Too narrow focus on the IT project

issues and overlooking the impact on the

distribution channels and the business in

general

3-4 (joint) 8 1 7 2

7.1. Inadequate security features being

built into the system

3–4 1 12–13 3–4 8

9.1. Lack of e-commerce project

experience

5 5–6 3–4 8–12 7

6.2. Lack of understanding of web page

design principles

6 2 8–10 6 13–14

5.1. Lack of top management

commitment and support

7 9–11 8–10 1 10–11

1.2. Failure to manage end user

expectations

8 7 22–23 5 6

8.1. Insufficient procedures to ensure

security, integrity and availability of the

database

9 5–6 21 8–12 5

5.2. Lack of user commitment and

involvement

10 9–11 11 3–4 20–21

8.3. Inadequate testing 11 17–18 14–16 13 3–4

8.2. Insufficient procedures to ensure

transaction traceability, confidentiality

and correctness

12–13 13–15 14–16 14–15 9

9.4. Retaining skilled staff 12–13 17–18 6–7 8–12 22–23

2.2. Underestimating the complexity of

building interfaces to legacy systems

14 13–15 6–7 19–21 12

1.4. Scope creep 15–16 16 24 8–12 16

(table continued)


Table 3 (continued)

Item number and description Overall rank Academics Clients/users Developers Project

managers

10.2. Site growth issues overlooked 15–16 9–11 17–20 19–21 17–19

3.2. Scope too ambitious 17 25–26 5 14–15 10–11

4.2. Absence of regular reviews against

goals

18 13–15 3–4 22 26

1.3. High and unplanned support and

maintenance costs

19–20 12 26–27 24–25 15

10.4. Dependence on multiple products

and suppliers

19–20 19 17–20 19–21 22–23

10.3. Applying incorrect technology 21 20 22–23 23 13–14

3.1. Inadequate methodologies resulting

in the system being ‘‘too slow to market’’

22–23 21–22 12–13 26 17–19

6.1. Insufficient approval processes for

web site development

22–23 23–24 14–16 16–18 24

9.2. Insufficient understanding of new

jobs and clarity of each (new) role

definition

24 23–24 8–10 16–18 25

8.4. Loss of data during conversion from

one system to another

25 21–22 25 24–25 20–21

9.3. Lack of creativity of IT people 26 27 17–20 16–18 28

10.1. Insufficient planning for multiple

browsers/software platforms

27 25–26 26–27 28 17–19

4.3. Absence of government guidelines/

legislation and international guidelines

for electronic transactions, including

international transactions

28 28 28 27 27

Table 4

Correlation of ranks overall and by category of respondent

Overall Academics Client/users Developers Project managers

Overall (28) 1.000 0.719 0.365 0.639 0.638

Academics 1.000 0.236 (not sig.) 0.518 0.573

Client/users 1.000 0.308 0.167 (not sig.)

Developers 1.000 0.403

Project manager 1.000


as the most significant risk, followed by the absence of declared business benefits. They werefollowed by four items which can be attributed to electronic commerce, principally the impact onthe distribution channels and web security issues.The contrasting perspectives of each respondent group are evident in the rankings shown in

Table 3. An issue to a project manager, such as a technical issue, may have minimal importance toa user. The user may have the power to demand that the issue gets resolved, and might be moreconcerned with the business issues. This begs the question as to what perspective academicsshould be taking (thereby influencing priorities and viewpoints in teaching), and the resultssuggest that academics may be emphasising the wrong issues.There was one unexpected result; the noise from the market place that existing development

methodologies are inadequate did not convert to a top 10 issue by any of the respondent groups.The (overall) top three risks (and several others), however, implies that rigorous methodologiesmay not always be used.Many of the risks identified can be categorised as issues which require precautionary measures

when developing e-commerce projects. In a sense, many ‘‘risks’’ can be avoided when anexperienced solutions provider has frequently experienced an issue and knows how to anticipateit. In comments accompanying the ranking, one respondent suggested that some of the items arenot issues ‘‘unless you didn’t plan for them during development’’. Companies and individuals areall at different points on their experience curves.At the other end of the ranking list, there was broad consensus that guidelines for international

transactions was not an important risk factor, but this may reflect the responsibility areas of theparticipants, i.e. and those that did not participate. Another item perceived as less important wasthe browser incompatibility issue.

11. Future research

There are many business models of ‘‘electronic commerce’’. For example the B2C (Business toConsumer) and the B2B (Business to Business) situations are different, and there is a need forfurther research to determine the major risks for different trading profiles. Even the term B2B isnot descriptive enough, the one to many profile, for instance, represents the model of a monopoly.The security risk (concatenated to one item in this research) can be exploded into several

different items and a similar ranking study could take place to determine the most significantitems.

12. Conclusion

This paper has confirmed that various risks are still prevalent, and that they occur ine-commerce as well as traditional projects. Misunderstanding the user requirements and theabsence of declared business benefits emerging as the major risks, suggest that many projects arebeing initiated without feasibility studies and rigorous systems analysis. As with traditionalsystems, there is still a risk of top management not getting totally involved and committed tothe project, very often giving verbal encouragement to the IT team but overlooking the fact that


the project is going to have a major impact on the business as a whole, and necessitate thetransformation of various business processes and the timing thereof.Five items which can be attributed to electronic commerce were in the ‘‘top 10’’, principally the

impact on the distribution channels and web security issues. E-commerce systems are unlikely toflourish at the rate predicted by earlier hype, until there is more confidence and trust in theenvironment. This can only be achieved when potential users of e-commerce systems perceive thatthe accuracy and security, in the web environment, of data, systems and equivalents to cash, is noworse than that offered with conventional systems and procedures.

Appendix A.—expanded descriptions of risk issues

The list below replicates the issue list as presented to final round Delphi participants.

A.1. Issues related to user/customer requirements, attracting new customers, scope

1.1. Misunderstanding the user/customer requirements (caused by inadequate systems analysisand insufficient involvement with the end user). Users and customers have an importantdifference—users can be interviewed to determine their requirements. There is the need to identifywho these customers are. There is the need to ensure the project meets customer expectations andnot presumed expectations.1.2. Failure to manage end user expectations. Users have various preconceived ideas and

interpretations of e-commerce systems, capabilities and terminology, and these (misunderstand-ings) have to be discovered and managed.1.3. High and unplanned support and maintenance costs. Provision has to be made for time to

make changes, and there is the possibility of introducing errors with the changes. The businessmay need to take the site down temporarily. This will not only be costly. In some instances there isthe (post project) risk of losing business if the main site is taken down while changes are made.1.4. Scope creep. Striving to be flexible and being willing to incorporate changes invariably

threatens the deadline or budget.

A.2. Business and supply chain issues

2.1. Too narrow focus on the IT project issues and overlooking the impact on the distributionchannels and the business in general. The end-to-end business processes may not have beenconsidered. The project is not seen as a new way of doing business. There may be a tendency tofocus on internal or external processes and not both. There is a possibility that the company maynow be competing globally. Business processes will usually have to change. For example, there isan eventuality that the company and IT may have to transform to 24� 7 including existing ande-commerce systems. This also impacts on the operations department, and therefore service levelagreements, and could also have a ripple effect along the supply chain.2.2. Underestimating the complexity of building interfaces to legacy systems, for the essential

business continuity. For example, backend systems integration can be severely affected if the


front-end is constantly changing. Interfaces to back office systems may not be seamless, causingtransactions to be misrecorded.

A.3. Methodology issues

3.1. Inadequate methodologies resulting in the system being ‘‘too slow to market’’. There isoften a perception that projects taking longer than 3 or 6 or 9 or 12 months are outdated. Good,well-established project methodologies directly conflict with the need for speed. Previous projectmanagement tools and methodologies do not wholly apply. There may also be an illusion thatweb site changes are easy. Newer ‘‘light’’ methodologies that attempt to strike a balance betweenrigor and speed are either not known or have not earned market credibility.3.2. Scope too ambitious. Implementation is not phased. Client wants everything in the first

release, causing overwhelming testing environment and absence of client feedback opportunities.

A.4. Strategic planning/management/direction

4.1. Absence of declared business benefit, or expecting the programme to be a panacea for poorbusiness practice. The project should not be separate from the company’s complete business plan.4.2. Absence of regular reviews against goals, to enable abandon/continue decisions. The high-

pressure competitive environment of these systems can be a major cause of review meetings beingcancelled.4.3. Absence of government guidelines/legislation and international guidelines for electronic

transactions, including international transactions.

A.5. Management and user support/commitment

5.1. Lack of top management commitment and support. The expectations of the entirecompany as well as its customers will have to be managed. Commitment is not only encouragingIT, it includes gaining commitment from other departments too.5.2. Lack of user commitment and involvement. There will be negative consequences unless the

requirements definition includes ALL interested parties/users, including (previously less relevant)parties on the supply chain.

A.6. Web page design considerations

6.1. Insufficient approval processes for web site development. For other forms of advertising,e.g. TV ads, there are usually strict approval processes.6.2. Lack of understanding of web page design principles. The user interface needs to be

excellent in terms of well-documented web page design principles, and totally intuitive forthe targeted customer. Poor designs result in navigation being too difficult for the end user.A common error is too many features (on the web site) too soon. Potential customers and currentcustomers will be reluctant to use the site.


A.7. Security issues

7.1. Inadequate security features being built into the system. It is necessary to create anenvironment which secures the trust of the user and hence the user’s commitment. There is a needto minimise current and future threats to the successful completion (as well as ongoing running) ofthe project. There are concerns about trading online because of the potential interception offinancial information. Unauthorised changes could go undetected.

A.8. System integrity, testing and conversion issues

8.1. Insufficient procedures to ensure security, integrity and availability of the database. Thiscan result in loss of data and/or data accuracy.8.2. Insufficient procedures to ensure transaction tracability, confidentiality and correctness.8.3. Inadequate testing as a result of pressure by sponsor, causing system errors and also

fraudulent activities. It is necessary to identify and neutralise fraudulent activities, so sufficienttime has to be allowed for testing.8.4. Loss of data during conversion from one system to another, as well as compromise of

security. These amount to the risk of getting bad publicity and the loss of customers.

A.9. Staff issues

9.1. Lack of e-commerce project experience. Managers are also inexperienced and cannotcontrol implementers. There is a possibility that not even the consulting companies have therequired skills. Project managers are in a new environment and do not appreciate the importanceof issues such as supply chain integration and marketing strategy.9.2. Insufficient understanding of new jobs and clarity of each (new) role definition. (New

categories can include network architect, security specialist, strategic planner, usability specialist,and artistic person.)9.3. Lack of creativity of IT people. IT people may not have the aptitude or training in the

artistic side of creating interfaces to attract customers/consumers.9.4. Retaining skilled staff. There is a skills shortage and high turnover of staff. There is a need

for long-term commitment from a developer who may be short term.

A.10. Technical environment

10.1. Insufficient planning for multiple browsers/software platforms. Although there are twodominant browsers, developers may be focusing on one only.10.2. Site growth issues overlooked. Architecture may not cope with the transaction volume

(peak periods, and/or growth capability overlooked). Service levels need to sustain trading partnerrelationship.10.3. Applying incorrect technology. The small number of IT people can be inclined to use the

technology they are familiar with, instead of the best or most appropriate technology available.On the other hand, some software products supplied by vendors (suppliers of software to enablee-commerce development) are released with insufficient testing and incorrect documentation,


necessitating additional coding by (implementer) developers, adding additional risk. Some of theimplementation tools may be unfamiliar and incompatible.10.4. Dependence on multiple products and suppliers. The system depends on the successful

functioning of several supplied products (for example, browser, firewall software, developmentsoftware and file server.)

References

Barki, H., Rivard, S., & Talbot, J. (1993). Toward an assessment of software development risk. Journal of Management

Information Systems, 10(2), 203–225.

Boehm, B. W. (1991). Software risk management; principles and practices. IEEE Software, 32–41.

Brancheau, J. C., Janz, B. D., & Wetherbe, J. C. (1996). Key issues in information systems management: 1994–95 SIM

delphi results. MIS Quarterly, 225–242.

Brooks, F. P. (1975). The mythical man-month. Reading, MA: Addison-Wesley.

Delbecq, A. L., Van de Ven, A. H., & Gustafson, D. H. (1975). Group techniques for program planning. Glenview, IL:

Scott, Foresman and Company.

Keil, M., Cule, P. E., Lyytinen, K., & Schmidt, R. C. (1998). A framework for identifying software project risks.

Communications of the ACM, 41(11), 76–83.

McFarlan, F. W. (1981). Portfolio approach to information systems, Harvard Business Review, Sep-Oct, 142–150.

Rayport, J. F., & Jaworski, B. J. (2001). E-commerce. Singapore: McGraw-Hill.

Schmidt R. C. (1995). Managing delphi surveys using nonparametric statistical techniques. Working Paper, The Hong

Kong University of Science and Technology, May.

Schmidt, R. C. (1997). Managing delphi surveys using nonparametric statistical techniques. Decision Sciences, 28(3),

763–774.

Schmidt, R. C. (2000). Personal communication with the author. December.

Schneider, G. P., & Perry, J. T. (2000). Electronic commerce. Course Technology-ITP, Canada.

Scott, G., & Walter, Z. (2001). Management issues in web systems development. Working paper, University of

Connecticut, April.

Watson, R. T., Berthon, P., Pitt, L. F., & Zinkhan, G. M. (2000). Electronic commerce. Florida: Dryden Press.

Tom Addison is Principal Tutor, Information Systems, at the University of the Witwatersrand. He has over 30 years

experience in the field of IS Management, originally in the commercial environment and in the academic environment

for the last 10 years. His major research and consulting interest is in the field of multicultural issues in project

management, and risk management. He holds the qualifications of Bachelor of Science from the University of Cape

Town, a Higher Diploma in Education from the University of the Witwatersrand, and a Masters degree in Business

from the University of South Africa.


e commerce project development risks

Business

van de ven

giving verbal encouragement

nonparametric statistical techniques

declared business benets

managing delphi surveys

insufcient approval processes

inadequate systems analysis

inadequate security features