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

E-commerce project development risks: evidence

from 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 risks
in the development of e-commerce projects. The 32 respondents in the final round of the survey were mainly
project managers from South African software houses. Various academics and users of e-commerce systems
also 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 getting
totally committed to the project, very often giving verbal encouragement to the IT team but overlooking the
impact 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 ensure
transaction 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: tom@isys.wits.ac.za (T. Addison).
1
An 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
26 T. Addison / International Journal of Information Management 23 (2003) 25–40

1. Introduction

Information Systems (IS) and the development and management thereof have been the subject
of many academic research studies since it became apparent that many, possibly even a majority
of 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). Invisibility
refers to the inability to visibly see progress, and the potential of software to be flexible results in
the tendency to change scope and thereby threaten deadlines. In addition, all IT projects are
unique (if they were not they would presumably be package implementations), and therefore the
absence of usable historical benchmarks renders us somewhat ineffective when attempting to
estimate 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 potential
risks 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 inexperience
with applied technology, through misunderstanding user requirements, to lack of top management
support. Some of these risks, such as the three just mentioned, prevail regardless of the computer
architecture, and are expected to prevail indefinitely. Recent research (Keil et al., 1998) indicates
that risks in projects can (broadly) be categorised as those over which the project manager has
control, and those, which are caused by non-controllable elements. Different management
strategies 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 exchanges
between parties (individuals, organizations or both) as well as the electronically based intra- or
interorganizational activities that facilitate such exchanges.’’ Schneider and Perry (2000) state that
a good definition of electronic commerce ‘‘would mention the use of electronic data transmission
to implement or enhance any business process’’. According to Watson, Berthon, Pitt, and
Zinkhan (2000), electronic commerce involves the use of information technology to enhance
communications and transactions with a company’s stakeholders, and includes activities such as
establishing a web page to facilitate those communications. Electronic commerce is narrowly
described 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-commerce
project involves the development of an information system to enable trading to take place, and
that 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 of
requirements, programming and testing. However, developers are constantly under pressure to
abandon sound systems development methodologies as their management regards them as too
cumbersome. 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–40 27

as thorough. A constant complaint of e-commerce system developers is that projects taking more
than 12 months (some say 3 months) to develop will not be usable, as they will have been
superseded 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 difficult
than for traditional systems, the (e-commerce) project under development often leaves itself
exposed for the whole world to see. Misunderstanding the requirements (caused by inadequate
systems analysis) takes on a new perspective. Whereas users can be interviewed to determine their
requirements, 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 issue
for the IT department, but a major decision affecting the company as a whole. In many instances
business 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 to
operate extended and more flexible working hours to satisfy new customers and ensure web site
credibility. In the process they discover a host of new competitors, and have to make strategic
decisions as to whether to operate in the international markets. Almost by definition, web business
implies minimum legislation and rules, particularly in the global context where countries differ in
their views and laws regarding issues such as privacy and transparency, but also in terms of
taxation, liability and other factors affecting business transactions. Companies electing to operate
24 h a day, 7 days a week, could well overlook various things, such as their existing systems are
accustomed to shutting down every evening to produce end of day reports and enable certain
fields to be reset. The need to interface the e-commerce system to the existing systems is not simply
a 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 seriously
investigate 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 introduced
by McFarlan (1981). This method uses as its source a questionnaire that encompassed all
hardware, software, users and vendor degrees of experience and other issues surrounding a
proposed 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 of
high- 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 have
focused more on the negative connotations of risk. Boehm (1991) surveyed several experienced
project 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,
28 T. Addison / International Journal of Information Management 23 (2003) 25–40

* 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 can
cause 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 risk
and 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
 T. Addison / International Journal of Information Management 23 (2003) 25–40 29

* 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 has
limited 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-axis
showing the perceived level of control (low or high). Keil et al. (1998) suggest further that risks
should 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 not
categorise the type of system, for example e-commerce, object oriented, enterprise resource
planning (ERP) and so on. E-commerce and other web-based systems have certain characteristics
which differentiate them from more traditional systems. For instance web-based payment systems
do not yet enjoy the trust and security of well-entrenched traditional payment systems, and the
development of digital certificates and security protocols is relatively young. As the Internet
influences new directions in business processes, new job titles begin to emerge (for example ‘‘web
architect’’), and supply chains transform (for example in book publishing, the classical chain of
author, 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 are
being 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
30 T. Addison / International Journal of Information Management 23 (2003) 25–40

regardless of the type of system being developed (for example the lack of top management
commitment to the project), the changing type of system and the changing business environment
suggest that we should be aware of new risks and re-examine the importance of the more
traditional risks.

5. The Delphi technique for research in information systems

The Delphi technique was developed by NC Dalkey and his associates at the Rand Corporation
in the 1950s. It is used extensively in IS research to identify and rank key issues for management
attention (Delbecq, Van de Ven, & Gustafson, 1975). Various researchers have used the technique
to 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 processes
the contributions, looking for central and extreme tendencies, and the rationales therefore. The
results are then fed back to the respondent group, who are asked to resubmit their views, assisted
by the ‘‘new’’ input provided by the coordinator. The most significant difference between the
Delphi technique and other methods of joint decision-making is that respondents do not
communicate directly with one another (Delbecq et al., 1975). There is, therefore, no risk that
participants’ opinions will be suppressed by others by virtue of rank/status or personality. There is
also a high degree of anonymity (participants are known only to the coordinator), participants do
not 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 practitioners
regarding design, for example the number of iterations. Schmidt (1997) argues that there are three
distinct phases in data collection. The first phase is to discover the issues, the second is to
determine 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 different
terminology 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 eliminates
all issues that were not selected by a simple majority of the respondents. If necessary (i.e. if more
than 20 items have still not been eliminated), a second round of this phase can be conducted, using
a 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 exceeds
30 well-chosen participants, for decision-making purposes. However, if confident research
findings were sought, a larger group would be more appropriate.
 T. Addison / International Journal of Information Management 23 (2003) 25–40 31

6. Respondent profile

For the first round of the survey, the researchers sought participation of experienced
project managers and senior developers of e-commerce projects, as well as their clients. This
was accomplished by approaching some of the members of the Project Management special
interest group of the Computer Society of South Africa, a direct marketing association, an
electronic commerce association, three successful e-commerce solution providers, and other
individuals. Participants were in turn asked to encourage participation from other experts, and
this resulted in contributors from other countries. For the final round of the survey, contributions
were also sought from members of the ISWORLD list server, and this resulted in the inclusion
of additional participants, including academics. Half of the 32 participants in the final round of
the survey were project managers and developers from South African organisations, mainly
software 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-commerce
projects. The researchers considered advising respondents of the outcome of similar surveys, for
example 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 have
a better understanding of the subtle difference between risks and factors causing risks. The idea
was rejected, however, in line with the view of Schmidt (2000), who advises that ‘‘seeding’’ the
respondents with the outcome of similar, previous studies, can result in the respondents not
volunteering any additional items. In addition, the data may be ‘‘tainted’’ by pre-emptive
suggestions.
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 appeared
to be mentioning the same issue using different vocabulary. This judgemental process was
then 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 consolidated
items, 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).
32 T. Addison / International Journal of Information Management 23 (2003) 25–40

Various items offered by the respondents were not carried through after the first round of the
survey. These included items which the researchers perceived would be absent if reasonable
management 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 the
list. 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 automating
the ‘‘ranking’’ process was used. Schmidt (1995, 1997) notes that past researchers have combined
the second and final (third) rounds of Delphi surveys, but cautions against this when the sheer
number 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 the
consolidated list now consisted of a manageable 28 issues, the research proceeded directly to the
final 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, for
each 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 participant
selected 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 ranking
process 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 descending
sequence 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. Five
of the ‘‘top 10’’ risks reported by Keil et al., who did not specify type of project, also appear in the
top 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 the
Kruskall—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 of
mean scores over all the 28 issues.
 T. Addison / International Journal of Information Management 23 (2003) 25–40 33

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., E-commerce risks (this
1998) USA rank 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

Two correlations on the ranks in Table 3 were performed—Kendall’s tau and Spearman’s rank
correlation. The Kendall’s tau results are shown in Table 4. (Spearman’s rank correlation yielded
similar results.) With only two exceptions, correlations of the rank scores were significant at the
5% level of significance The two exceptions are client/users with academics and client/users with
project 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
34 T. Addison / International Journal of Information Management 23 (2003) 25–40

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 1 3 17–20 2 1
requirements

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

2.1. Too narrow focus on the IT project 3-4 (joint) 8 1 7 2

issues and overlooking the impact on the
distribution channels and the business in
general

7.1. Inadequate security features being 3–4 1 12–13 3–4 8

built into the system

9.1. Lack of e-commerce project 5 5–6 3–4 8–12 7

experience

6.2. Lack of understanding of web page 6 2 8–10 6 13–14

design principles

5.1. Lack of top management 7 9–11 8–10 1 10–11

commitment and support

1.2. Failure to manage end user 8 7 22–23 5 6

expectations

8.1. Insufficient procedures to ensure 9 5–6 21 8–12 5

security, integrity and availability of the
database

5.2. Lack of user commitment and 10 9–11 11 3–4 20–21

involvement

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

8.2. Insufficient procedures to ensure 12–13 13–15 14–16 14–15 9

transaction traceability, confidentiality
and correctness

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

2.2. Underestimating the complexity of 14 13–15 6–7 19–21 12

building interfaces to legacy systems

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

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

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 18 13–15 3–4 22 26

goals

1.3. High and unplanned support and 19–20 12 26–27 24–25 15

maintenance costs

10.4. Dependence on multiple products 19–20 19 17–20 19–21 22–23

and suppliers

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

3.1. Inadequate methodologies resulting 22–23 21–22 12–13 26 17–19

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

6.1. Insufficient approval processes for 22–23 23–24 14–16 16–18 24

web site development

9.2. Insufficient understanding of new 24 23–24 8–10 16–18 25

jobs and clarity of each (new) role
definition

8.4. Loss of data during conversion from 25 21–22 25 24–25 20–21

one system to another

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

10.1. Insufficient planning for multiple 27 25–26 26–27 28 17–19

browsers/software platforms

4.3. Absence of government guidelines/ 28 28 28 27 27

legislation and international guidelines
for electronic transactions, including
international transactions

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
36 T. Addison / International Journal of Information Management 23 (2003) 25–40

as the most significant risk, followed by the absence of declared business benefits. They were
followed by four items which can be attributed to electronic commerce, principally the impact on
the 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 to
a user. The user may have the power to demand that the issue gets resolved, and might be more
concerned with the business issues. This begs the question as to what perspective academics
should be taking (thereby influencing priorities and viewpoints in teaching), and the results
suggest 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 methodologies
may 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 an
experienced solutions provider has frequently experienced an issue and knows how to anticipate
it. In comments accompanying the ranking, one respondent suggested that some of the items are
not issues ‘‘unless you didn’t plan for them during development’’. Companies and individuals are
all 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 the
participants, i.e. and those that did not participate. Another item perceived as less important was
the browser incompatibility issue.

11. Future research

There are many business models of ‘‘electronic commerce’’. For example the B2C (Business to
Consumer) and the B2B (Business to Business) situations are different, and there is a need for
further research to determine the major risks for different trading profiles. Even the term B2B is
not 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 significant
items.

12. Conclusion

This paper has confirmed that various risks are still prevalent, and that they occur in
e-commerce as well as traditional projects. Misunderstanding the user requirements and the
absence of declared business benefits emerging as the major risks, suggest that many projects are
being initiated without feasibility studies and rigorous systems analysis. As with traditional
systems, there is still a risk of top management not getting totally involved and committed to
the project, very often giving verbal encouragement to the IT team but overlooking the fact that
 T. Addison / International Journal of Information Management 23 (2003) 25–40 37

the project is going to have a major impact on the business as a whole, and necessitate the
transformation 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 to
flourish at the rate predicted by earlier hype, until there is more confidence and trust in the
environment. This can only be achieved when potential users of e-commerce systems perceive that
the accuracy and security, in the web environment, of data, systems and equivalents to cash, is no
worse 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 analysis

and insufficient involvement with the end user). Users and customers have an important
difference—users can be interviewed to determine their requirements. There is the need to identify
who these customers are. There is the need to ensure the project meets customer expectations and
not 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 business
may need to take the site down temporarily. This will not only be costly. In some instances there is
the (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 distribution
channels and the business in general. The end-to-end business processes may not have been
considered. The project is not seen as a new way of doing business. There may be a tendency to
focus on internal or external processes and not both. There is a possibility that the company may
now be competing globally. Business processes will usually have to change. For example, there is
an eventuality that the company and IT may have to transform to 24  7 including existing and
e-commerce systems. This also impacts on the operations department, and therefore service level
agreements, 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
38 T. Addison / International Journal of Information Management 23 (2003) 25–40

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

A.3. Methodology issues

3.1. Inadequate methodologies resulting in the system being ‘‘too slow to market’’. There is
often 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 project
management tools and methodologies do not wholly apply. There may also be an illusion that
web site changes are easy. Newer ‘‘light’’ methodologies that attempt to strike a balance between
rigor 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 poor
business 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 being
cancelled.
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 entire
company as well as its customers will have to be managed. Commitment is not only encouraging
IT, 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 for
the 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 current
customers will be reluctant to use the site.
 T. Addison / International Journal of Information Management 23 (2003) 25–40 39

A.7. Security issues

7.1. Inadequate security features being built into the system. It is necessary to create an
environment which secures the trust of the user and hence the user’s commitment. There is a need
to minimise current and future threats to the successful completion (as well as ongoing running) of
the project. There are concerns about trading online because of the potential interception of
financial 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. This
can 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 sufficient
time 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 cannot
control implementers. There is a possibility that not even the consulting companies have the
required skills. Project managers are in a new environment and do not appreciate the importance
of 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 two
dominant 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 partner
relationship.
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 enable
e-commerce development) are released with insufficient testing and incorrect documentation,
40 T. Addison / International Journal of Information Management 23 (2003) 25–40

necessitating additional coding by (implementer) developers, adding additional risk. Some of the
implementation 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, development
software 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.