Your SlideShare is downloading. ×
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
E Commerce Project Development Risks
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

E Commerce Project Development Risks

3,676

Published on

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,676
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
103
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 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
  • 2. T. Addison / International Journal of Information Management 23 (2003) 25–40 26 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
  • 3. 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, *
  • 4. T. Addison / International Journal of Information Management 23 (2003) 25–40 28 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 *
  • 5. 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
  • 6. T. Addison / International Journal of Information Management 23 (2003) 25–40 30 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.
  • 7. 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).
  • 8. T. Addison / International Journal of Information Management 23 (2003) 25–40 32 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.
  • 9. 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
  • 10. T. Addison / International Journal of Information Management 23 (2003) 25–40 34 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)
  • 11. 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
  • 12. T. Addison / International Journal of Information Management 23 (2003) 25–40 36 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
  • 13. 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
  • 14. T. Addison / International Journal of Information Management 23 (2003) 25–40 38 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.
  • 15. 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,
  • 16. T. Addison / International Journal of Information Management 23 (2003) 25–40 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.

×