Enterprise Risk Factors

8/8/2019 Enterprise Risk Factors

1/8

Risk Factors in Enterprise Wide Inform ation Mana gem entSystems Projects

Email:

Mary SumnerS o u t h e r n I l l i n o i s U n i v e r s i t y E d w a r d s v i l l e

C a m p u s B o x 1 1 0 6E d w a r d s v i l l e , I L 6 2 0 2 6P h o n e : 6 1 8 -6 5 0 -2 0 9 3

F a x : 6 1 8 -6 5 0 -3 9 7 [email protected] or [email protected] B S T R A C TIn the past several years many organizations have initiatedenterprise-wide information managem ent systems projects , usingsuch packages as SAP, Peoplesoft, and Oracle. These projectsoften represent the s ingle largest investment in an informationsystems project in the his tory of these companies , and in manycases the largest s ingle investment in any corporate-w ide project.These enterprise-wide information management systems projectsbring about a host of new questions, because they represent a newtype of management challenge. Some of these questions andissues are: What are the major risk factors associated with implementingtraditional MIS projects? What are the major risk factors associated with enterprise-wide information management projects? wh at new risk factors need to be addressed in ERP projects?What are some of the risks in MIS projects that are notfactors in ERP projects?Based upon the findings, enterprise-wide informationmanagement systems projects pose new opportunities andsignificant challenges. Some of the "summary" ideas which arere-iterated throughout the case s tudies are: Justify the enterprise-wide projects based upon cost-justification and economies o f scale. Re-engineer business processes to "fit" the package, ratherthan trying to modi fy the software to "fit" the organizat ion'scurrent business processes. Identify and implement s trategies to re-skill the exis ting ITworkforce and acquire external expertise through vendorsand consultants when needed.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed tbr profit or com mercial advantage and thatcopies bear this notice and the full citation on the first page. To copyotherwise, to republish, to post on servers or to redistribute to lists.requires prior specific permission and/or a fee.SIGCPR 2000 Evanston Illinois USACopyright ACM 2000 ! -58113-212-x/00/04...$5.00

Utilize "business analysts ," with both business knowledgeand technology knowledge. Obtain top managem ent support for the project and establishstrong project leadership. Make a commitm ent to training end-users in custom reportdevelopment. Manage change thr ough leadership, effectivecommunications, and the role o f a champion.1 . I N T R O D U C T I O NIn the past several years many organizations have initiatedenterprise-wide information management systems projects , usingsuch packages as SAP, Peoplesoft, and Oracle. These projectsoften represent the s ingle largest investment in an informationsystems project in the his tory of these companies , and in manycases the largest s ingle investment in an y corporate-w ide project.These enterprise-wide information management systems projectsbring about a host of new questions, because they represent a newtype of managemen t challenge. The managem ent approaches forthese projects may be altogether different from the managerialapproaches for traditional MIS projects . Some of these questionsand issues are: What are the major risk factors associated with implementingtraditional MIS projects? What are the major risk factors associated with enterprise-wide information management projects? What are the differences? wh at new risk factors need to beaddressed in ERP projects? Wha t are some of the risks inMIS projects that are not factors in ERP projects?Most organizations have extensive experience managingtraditional MIS projects , but these new ERP projects mayrepresent new challenges and present new risk factors that mustbe handled differently. This paper will provide case s tudies ofseven organizations implementing enterprise-wide informationmanagement systems projects and will provide insight into eachof these questions based upon their experiences.2 . R I S K S I N I M P L E M E N T I N GI N F O R M A T I O N S Y S T E M S P R O J E C T SA simple definition of "risk" is a problem that hasn' t happenedyet but could cause some loss or threaten the success of yourproject if it did (Wiegers , 1998). A number of research s tudieshave investigated the issue of the relative importance of variousrisks in software development projects and have attempted toclassify them in various ways. Much has been written about the

180


2/8

causes of informa tion system s projec t failures. Poo r technicalmethods is only one of the causes, and this cause is relativelyminor in comparison to larger issues, such as failures incommunications and ineffective leadership.In their study of the factors that software project managersperceive as risks, Keil, Cule, Lyytinen and Schmidt organizedrisks into four quadrants, includin g risks associated with custom ermandate, sc ope and requirements, execution, and environment.They also posed strategies to minimize risks in each of thesecategories. Customer mandate deals with the risks of lack ofsenior management commitment and lack of user commitment.Risks associated w ith scope and requirements includemisunderstanding requirements and failing to manage cha ngeproperly. Risk factors in the execution quadrant include issues ofinappropriate staffing, la ck of an effective method ology , and poorestimation. In the enviro nmen t quadrant, th e risks deal withissues over which the project manager ma y have no control, suchas changing scope/objectives and conflicts between userdepartments (Keil, Cule, Lyyt inen, Schmidt, 1998).In a study of issues that contribute to the cancellation ofinformation systems development projects, Ewusi-Mensah pointsto lack of agreement on a set o f project goals/objectives, lack of ameasurement system for assessing and controlling project risk,lack of adequate technic al expertise and application know ledge ,lack of an adequate technolog y infrastnacture to support projectrequirements, lack of senior management involvement, andescalating time and cost overruns are all associated with projectabandonment (Ewusi-Mensah, 1997).In their paper, Barki, Rivard and Talbot propose a variety of riskfactors associated with softwar e deve lopm ent projects. Som e ofthese risk factors include technological newness (need for newhardware, software), application size (project scope, number ofusers, team diversity), expertise (lack of devel opme nt expertise,task of application-specific expertise, lack of user experience),application c omp lexity (technical com plexity , links to existinglegacy systems), organizational environment (task complexity,extent of changes, resource insufficiency, and magnitude ofpotential loss). While this research constructs and attempts tovalidate ris k measures, it doe s not address the issue o f wha t riskcontrol strategies are most directly associated with managingproject risk and in assuring project success (Barki, Rivard, andTalbot, 1993).In his paper, "Software Risk Man agem ent: Principles andPractices," Barry B oehm identifies ten software risk factors,including personne l shortfalls, unrealistic schedules an d budgets,developing the wrong functions, developing the wrong userinterface, "gold-plating," a continuing stream o f changes inrequirements, shortfalls in externa lly furnished com ponent s,shortfalls in externally performed tasks, performance shortfalls,and strained technical capabilities (Boe hm, 1991). In addition,McFarlan developed dimensions of project risk based uponproject size, experience with the technology, and project structure(McFarlan, 1981).

Robert Block, in his text on factors contributing to project failure,notes numerous causes of project failure, including resourcefailures (conflicts of people, time, and project scope), requirementfailures (p oor specifica tion of requirements), goal failures(inadequate statement o f syste m goals), technique failures (failureto use efffective softw are develo pme nt approaches), user contactfailures (ineffective communications with users), organizationalfailures (la ck of leadership), tec hnol ogy failures (ven dor failure,failure of hardware/so ftware t o meet specifications), size failures(excessive size), and people management failures (conflict,antagonism). In addition, proje ct mana geme nt and controlfailures, caused by inadequate planning and tracking, cancontribute to project failure (Block, 1983).3 . RISKS IN CLIENT-SERVER SYSTEMSWith systems that involve the use of new client-servertechnology, it is often critical to acquire external expertise,including vendor support, to facilitate successful implementation.Also, the costs of training and support are often under-estimated,and these costs may be many times greater than originallyanticipated. Client-se rver implementations often bring"surprises" with respect to cost, because of the costs ofdecentralized servers, systems integration software, technicalsupport, a nd software updates and version control. In actuality,the total cost of a client server implementation can be three to sixtimes greater than for a com parab le mainframe-based system.Even though there are great cost reductions possible throughmoving off the mainframe, the costs of learning the newtechnology and of acquiring technical support are substantial.(Caldwell, 1996).4 . W H A T A R E T H E M A J O R R I SKF A C T O R S A S S O C IA T E D WIT HE N T E R P R IS E -WID E IN F O R M A T IO NM A N A G E M E N T P R O J E C T S?The purpose o f this study is to dev elop a better understanding ofthe major risk factors associate d with enterprise-wide informationman agem ent projects. Thes e case studies will examine these riskfactors. The case studies describe the experiences o f sevencomp anies implemen ting enterprise-wide informationmanageme nt systems using SAP, Peoplesoft, and Oracle. Thecase studies were developed using in-depth interviews with thesenior managers responsible for planning and implementingenterprise-wide s ystem s within the respec tive organizations. Inaddition to assessing the risks associated with technology,organizational fit, people factors, and size, the case studiesprovided insight into the critical success factors associated withsuccessful proje ct implementation and control,The findings describe seven case studies which have beenaccomplished as a "pilot" study for this research. These casestudies will hig hlight the issues o f project justification,organizational fit, technology fit, people and skill mix, criticalsuccess factors, and factors associated with project "failure."They deal with three SAP Projects, two Peoplesoft Projects, andtwo Oracle Projects.

Lack of adequ ate technolo gy infrastructureTech nological new ness, strained technical

Ewusi-Mensah, 1997.Barki, Rivard, Talbot, 1993, Boehm, 1991, Block,

181


3/8

capabilities, failure o f technology to meet 1983, Cash, McFarlan, 1992.specifications. Ewusi-Mensah, 1997, Block, 1983.ack of agreement on project goalsLack o f technical expertiseLack o f application knowledgeLack o f user commitment, ineffectivecommunications with users

Ewusi-Mensah, 1997.Ewusi-Mensah, 1997, Barki, Rivard, Talbot, 1993.K eil, Cule, Lyy tinen , and Schmidt, 1998 . Block,1983.Lack of senior management involvement Ewusi-Mensah, 1997, K eil, Cule, Lyytinen, andSchmidt, 1998.Barki, Rivard, Talbot, 1993.pplication c om plexity (technical complexity)Misunderstanding requirements, changes inrequirementsOrganizational environment (resourceinsufficiency, extent o f changes)Unrealistic schedules and budgetsLack o f an effective methodology, poo r estimation,failure to perform the activities needed

Changing scope and objectivesConflicts between user departmentsInappropriate staffing, personnel shortfalls

Lack o f measurement system for controlling risk,inadequate project management and tracking.

Keil, Cule, Lyytinen, and Schmidt, 1998, Boehm,1991. Block, 198 3, Cash, McFarlan, 1992.Barki, Rivard, Talbot, 1 993 , Block, 1983.Boehm, 1991.K eil, Cule, Lyy tinen , and Schmidt, 1998 , Block,1983.Keil, Cule, Lyytinen, and Schmidt, 1998.Keil, Cule, Lyytinen, and Schmidt, 1998.Keil, Cule, Lyytinen , and Sehmidt, 1998, Boehm,1991, Block, 1983.People and personality failures Lack o f effort, antagonistic attitudes, peopleclashes, Block, 1983.Ewusi-Mensah, 1997, Block, 1983.

Table 1: Sum mar y of Risk Factors in Information S ystems Projects5 . F I N D I N G SThe case studies are based upon the experiences of sevencomp anies implem enting enterprise-wide in forma tionmanageme nt systems using SAP, Peoplesoft, and Oracle. Theseare all Fortune 500 companies representing a va riety o f industries,as you can see from Table 2:6. PROJEC T JUSTIFICATIONBeginning in 1996, the pharmaceutical manufacturer started acorporate-wide SAP project. The business justification for theproje ct was operational excellence, e.g. cutting the costs of coretransactions-processing systems, such as order processing andinventory management. In addition, an integrated package couldsupport worldwide business operations and replace division-levelsystems. Before SAP, the pharmaceutical firm had four

purchasing packa ges --on e for each business unit. SAP providedeconomies of scale in development, maintenance and operations.Its overall costs were divided by a much larger number of users.For example, buying a $100,000 package to support 5000 users isless expensive than buying a $25,000 package to support 100users. In addition, the SA P proje ct enabled the pharmaceuticalcompany to reduce its information systems development stafffrom 500 to 50 people.Some of the "business drivers" for the SAP implementation at thepharmaceutical manufacture r included: data integration,standardization, acces s to time ly and comp lete informa tion,leverage gained in purchasing, and globalization. SAP cut thecosts of operational systems, imp roved the reliability of customerservice, and a ssured timely delivery and follow-up.

182


4/8

BeveragemanufacturerMilitary aircraftmanufacturerElectricalmanufacturer

Investmentbrokerage firmPharmaceuticalmanufacturer

Consumer productmanufacturer

Chemicalmanufacturer

*external consultants

Nature o f business

Manufactures foodand beverageproductsManufacturesmilitary aircraftManufacturer ofelectrical andelectronic productsand systemsNational investmentbrokerage firmManufactures andmarkets high-valueagriculturalproducts,pharmaceuticals, andfood ingredientsManufacturesdog/cat foods anddry cell batteryproductsManufactures anddistributesbiochemicals,organicchromatographyproducts, anddiagnostic reagents

1998 sales

$12,832,000,000

No. of employeesworldwide25,123

6 0 , 6 0 0

No. IT(technology)employees1,100

(info No. of projectemployees50 internal, 25external*

$15,000,000,000 850 80-100 internal, 20extemal*$12,29 8,600 ,000 100,700 90 25 internal, 50-60(one division) extemal*(one division)I$1,135,000,000 13,690 725 25 internal$7,514,000,000 24,700 600 25 internal, l 0I external*

$4,653,000,000 750

2001,127,000,000

23,000

6,000

100 internal, 20external*

20 internal, 10external*

Table 2: Com pany ProfilesThe original project justification for the SAP project at thebeverage manufacturer was similar. There were extensiveeconomies of scale associated with consolidating four MISprojects into one, and SAP offered an integrated, corporate-widesolution. The business justification entailed major cost savingsfrom reducing the costs of operational level information systems.SAP provided hard-dollar savings, based upon integration of dataand processes, a common database, and increased leverage inpurchasing and buying.The major sources of justification for the SAP project at thechemical manufacturer were the need to integrate a number ofdifferent order processing systems, the need to improve andintegrate financial systems, and the ability to reduce theworkforce through systems integration. The major motivationbehind the project was to gain a "competitive advantage" byproviding "seamless" order processing to customers in a globalmarketplace. This meant that any customer in the world couldplace orders using one integrated order processing system, asopposed to using many different systems for different productlines.

The Peoplesoft Project at the military aircraft manufacturer wasjustified in terms of better information, cost-reduction, and dataintegration. Between 70 and 80 systems were replaced by asingle, integrated system. While the original intent was toimplement an integrated human resources/payroll system usingPeoplesoft, the first phase o f the project involved completing thehuman resources (H R) com ponent and creating an interface to theexisting payroll system. After the completion of the firm'smerger with a commercial aircraft manufacturer, the plan was tointegrate both HR and payroll, using the Peoplesoft software. Asyou will learn later, this "phased-in" approach created significantproblems in system implementation.The major justification for the Peoplesoft Project at theinvestment brokerage firm was data integration, a commonsystems approach, and hard dollar savings through integration.The Oracle project at the consumer products manufacturer wasalso justified in terms of data integration and cost-reductionthrough the re-engineering o f business processes.

183


5/8

Bev erag e m an u fac tu re rMil i tary ai rcraf t manufacturerE lec t ri ca l p ro d u c t s m a n u fac tu re rIn v es tm en t b ro k erag e f i rmPh arm aceu t i ca l m an u fac tu re rCo n su m er p ro d u c t sm an u fac tu re rCh em ica l m an u fac tu re r

Sy s t emS A PPeo p leso f tOracle ( fmancials , inventory , et .al )Peo p leso f tSA POracle ( f inancials , inventory)S A P

Just i f icat ionCo s t - r ed u c t io n o f o p era t i o na lsy s t em sCost - reduct ion ; data in tegrat ionCo s t - r ed u c t io n ; i n v en to ryred u c t io n ; h ead c o u n t sav in g sD ata i n t eg ra t i o n ; co m m o nsy s t em sCo s t - r ed u c t io n o f co reo p era t i on a l sy s t em sCost - reduct ion ; data in tegrat ionCo s t - r ed u c t io n ; sy s t em sin tegrat ion

Project In i t iat ion1996199419961996199619961996

Tab le 3: Project Typ e and JustificationThe major purpose o f the Oracle project at the electrical produc tsmanu facture r was to implemen t Oracle financial, distribution, andmanu factur ing systems. The busines s justific ation included:inventory reduction, headcount savings, and reduced lead timesthrough on-time delivery.Table 3 summarizes the basis for project justification for thevarious SAP, Peoplesoft, and Oracle projects. Since all of theprojects are still in the process of implementation, theimplementation dates are not noted here.7 . RISK FAC TORS7.1 La ck Of A Proper Ma nagement Structure.With out central projec t leadership, there is excessive duplicationof effort. Monsanto put some one "in charge" and centralized themanageme nt structure of the project in order to avoid duplicationof effort. Another, more complex issue is related to the problemof having too many "chief 's." At Boeing, three different vice-presidents (including the H R head, the IT head, and the FinanceVP) all had the same authority and conflicts arose in establishingcomm on requirements. In implementing a "centralized" system,centralized authority must "call the shots." (Monsanto, Boeing)7.2 Failure To Re-Design B usiness ProcessesTo Fit The Software.Avoid customization. Ma ny companies "go to war" with thepackage and try to make it meet their business processrequirements, only to lead the way to huge c ost overruns andproject failure in some cases. Rather than attempting to modifythe software, Monsanto re-engineered their business processes tobe consistent with the software, and this has proved to be criticalto the project's success. It is important to re-design businessprocesses to be consistent with system specifications (Monsanto,Anheuser Busch, Sigma, Boeing, Edward Jones, Ralston,Emerson Electric). First and foremost is the importance of usinga "vanilla " implementation, e.g. "no t chan ging the originalsoftware." In the Boeing case, a number of pieces of thePeoplesoft software were customized. In its implementation, forexample, the H R piece was 70% vanilla, 30% custom. Thepayroll piece was 60% vanilla, and 40% custom; and the benefits

piece was 50% vanilla, 50% custom. One of the most difficultand time-consuming aspects of the project was the creation of a"bridge" between the H R and legacy payroll application, and thisresulted in extensive time and cost delays. If modifications arenecessary, establish an up-front agreement between IT and usermanagers with respect to w hat is to be modified.7.3 Insufficient Training and Re-Skill ingMo nsan to invested heavi ly in training and re-skilling theirdevelopers in SAP software design and methodology . Mostfirms emphas ized the investme nt in the training, re-skilling, andprofessional development of the IT workforce. In the experienceof four companies, training costs were higher than expected(Monsanto, A/B, Sigma, Boeing).7.4 Insufficient Internal ExpertiseWhen they did n't have needed expertise internally, Monsantobrought in the consultants they needed. Most firms madeinvestments in training and support required to overcometechnical and procedural challenges in design andimplementation. It was important to maximize the use ofconsultants (Monsanto, Emerson).7 .5 Lack Of Senior Managem ent SupportWithout question, top management support is critical to thesuccess of a project. It is important to achieve the support ofsenior management for accomplishing project goals andobjectives and aligning these with strategic business goals.(Monsanto, Anheuser Busch, Sigma, Boeing, Edward Jones,Emerson Electric).7 .6 Lack O f A Ch ampionThe project leader for the SAP project was clearly a "champion"for the project, and that role wa s critical to marketing the projectthroughout the organization. (Monsanto, A/B).7.7 Insufficient Discipline and StandardizationAnother "risk factor" whic h is closely associated with thesoftware itself is insufficient adherence with the standardizedspecifica tions that the software supports. It is importa nt to avoidcomprom ising the system and its specifications. In terms of

184


6/8

"lessons learned," Monsanto 's experience demonstrated theimportance of using SAP's built-in "best practices ," its systemsdevelopment methodology. Standardization is key to success , andcan create greater flexibility and chan geability down the line.(Monsanto).7.8 Ineffective Co mmu nicationsIt is critical to communicate what is happening, including thescope, objectives, and activities of the project. (Monsanto)7.9 Lack Of "Business" AnalystsOne of the critical workforce requirements for the project was theability to obtain analysts with both "business" and tech nologyknowledge. Instead of 200 "program mers" with average skills ,the SAP project demanded and could be accomp lished with 20 o fthe "best and brightest" analysts. H owever, retaining theseprofessionals was a s ignificant problem because of their marketvalue. (Monsanto, A/B).7.10 Lack of IntegrationIn terms of factors conducive to project failure, one of the mainfactors associated with failure is lack of integration. The projectneeds to be based on an enterprise-wide design. You can' t s tartwith "pieces," and then try to integrate the software compon ent'slater on. It is important to use a "federal" approach; define whatis needed at the enterprise-level, and then apply it to the businessunit level. A phased-in approach is superior to the "big-bang,"all-at-once approach. (Monsanto, Boeing, Em erson).7.11 Failure to Mix Internal and ExternalPersonnelUse a mix o f consultants and internal s taff to work on the projectteam, so that internal s taff members can "grow" the necessarytechnical skills for SAP design and implementation. Maintainexcellent s taffing, both by deve loping internal personnel and byusing external consultants . (A/B, Sigma)

7.12 Failure To Place a "Business" Leader InCharge, So That Project Leadership ComesFrom The Business Perspective. (A/B)7.13 Failure to Empower the "Team"Manage team expectations effectively. (A/B, Boeing)7.14 Lack o f Ability to Recruiting and RetainQ ualif ied ERP Systems DevelopersIt is difficult to recruit and retain goo d technical people becausemarket rates for these people are much higher. Management m ustunderstand and appreciate the criticality of high-tech workerturnover, recruitment, and retention issues (Ralston, Boeing, A /B,Edward Jones).7.14 Insufficient Training of End-UsersMost firms emphasized making a major commitment to trainingend-users in system uses. This meant re-skilling the end-users innew technologies and applications and supplementing"generalized" user training with training in the use of specificapplication modules (Sigma, Boeing, Ralston. Emerson).

7.15 Lack O f Data Integration and DataStandardizationUse a common data model and common data definitions to drivecommon business processes (Monsanto, Boeing).7.16 Inabil ity to Obtain A Fu ll-TimeCommitment of "Customers" To ProjectManag ement and Project Activit iesIt may be difficult to get managers to commit to projectmanagement roles , because they may be uncertain about whatresponsibilities will s till be open to them once they are transferredback to their functional areas. Getting the "business" areas todedicate people to the management o f the project is a key priority.(Boeing, Edward Jones).7.17 Avoid Technological BottlenecksIt is important to prepare for client-server implementation well inadvance. (Boeing).7.18 Lack of Disciplined, Flexible ProgramManagementOnce data input was decentralized to the shop floor at McDonnellDouglas/Boeing as part of the Peoplesofi HR systemimplementation, there was major resis tance by end-users . Thisreinforces the critical importance of training. (Boeing).7.19 Lack Of An Integrated TechnologyStrategy To Su pport Client-ServerImplementationThe different " technology" environments at Boeing and MDCcreated delays in establishing consis tency and coordination inplatforms, database management systems, and operating systemenvironments for the Peoplesoft application. For example, thechoice of whether to implement Peoplesofft using Unix/Oracle asan operating system/database environment or MVS/DB2 becamean issue. Whi le Unix/Oracle is the "standard" environment atMD C, MV S/DB 2 is the system standard at Boeing (Boeing).7.20 Avoid Bu ilding Bridges to LegacyApplicationsThe Boeing/McDonnell Douglas merger complicated the projectand necessitated the creation of a "bridge" between the PeoplesoftHR software and the MDC legacy system, resulting in extensivetime and cost delays. It is important to implement a totalintegrated package at one time, rather than in pieces. Thebuilding of a bridge between a Peoplesoft module and a legacyapplication was problematic and illustrated the complexity ofbuilding a bridge to a legacy system (Boeing).7.21 Failure to Recognize the Risk of " ScopeExpansion"It is important to address "scope expansion" requests withinformation on the time, cost, and business impacts of thesechanges (Ralston).

185


7/8

7.22 Failure To Recognize The Im portance OfApplication-Specific K nowledgeIt is important to obtain consultants who are specialis ts in specificapplication modules (Ralston).

7.23 Failure to Emph asize Reporting,Including Cu stom Report DevelopmentThe use of report generators , and user training in reportingapplications is critical to project implem entation success (Boeing,Ralston).

7.24 Failure to Integrate Add-On Moduleswith the ERP SystemWhen software does not meet requirements , most firms used bolt-on's , o r add-on packages which are offered by third- party vendors(Emerson). Several project managers emphasized the need tol imit the number o f "bo l t -on ' s , " o r "add-on ' s , " to those which a reabsolutely critical to accom plishing project activities (Emerson).A summary of the risk factors affecting enterprise-wideinformation management systems projects is shown in Table 4.

Organizational fit

Skill mix

Manage ment structure and strategy

Software systems design

User involvem ent and training

Technology planning

Project m anagement

Failure to re-design business processesFailure to follow an enterprise-wide design which supports dataintegrationLack o f data integration and lack o f data standardizationInsufficient training and re-skillingInsufficie nt internal expertiseLack of business analysts with business and tec hnology knowledg eFailure to effectively mix internal and external expertiseLack o f ability to recruit and retain qualified ERP systems developersLack of senior managem ent supportLack o f proper manage ment control structureLack of a championIneffective comm unicationsLack of a change manag eme nt strategyFailure to adhere to standardized specifications which the softwaresupportsFailure to effectively integrate "add-on" modul esFailure to rec ognize the importance o f application-specific knowle dgeInsufficient training of end-usersIneffective communicationsLack o f fu l l -t ime commitment of customers to project management andproject activitiesLack of sensitivity to user resistanceFailure to em phasize reportingInability to avoid technological bottlenecksLack of an integrated technology strategy to support client-serverimplementat ionAttempting to build bridges to legacy applicationsLack o f disciplined, flexible project mana gem entFailure to recognize the risk o f scope expansion (time, cost)

Tab le4 : Sum mary of Risk Factors in Enterprise-Wide Projects8. W H A T A R E S O M E O F T H E R I S K S INE R P PR O J E C T S T H A T A R E N O TF A C T O R S I N M I S P R O J E C T S ?When the risk factors affecting MIS projects are compared withthe risk factors affecting ERP systems projects , some of theuniquely important factors affecting the ERP projects include: The danger of customization.

The new investment in recruiting, re-skilling, training instate-of-the-art technology. The new challenge of using external consultants andintegrating their application-specific knowled ge andtechnical expertise with exis ting teams. The new project managem ent risk, resulting from extensivesize/scope and data integration. The risk of technological newness and technologicalbottlenecks in a client-serv er environment.

186


8/8

The managem ent of change, including organizational changebecause o f systems integration. The emerging role of the business analyst, combiningtechnology and business skills.9 . S U M M A R YEnterprise-wide information management systems projects posenew opportunities and significant challenges. Some of the"summ ary" ideas which are re-iterated throughout the case studiesare: Justify the enterprise-wide projects based upon cost-justification and economies o f scale. Re-engineer business processes to "fit" the package, ratherthan trying to modify the software to "fit" the organization'scurrent business processes. Identify and implem ent strategies to re-skill the existing ITworkforce and acquire external expertise through vendorsand consultants when needed. Utilize "business analysts," with both business know ledgeand technology knowledge. Obtain top managem ent support for the project and establishstrong project leadership. Make a commitme nt to training end-users in custom report

development. Manage change through leadership, effectivecommunications, and the role o f a champion.Without question, the effective management of these hugeprojects is a new and unique challenge which requires the use ofproject management and control methods that have not been usedextensively in the past. The sheer size of these projects requirescentralized control, strict discipline, and extensive monitoring ofproject outcomes. Compare d with traditional MIS projects, lessemphasis is placed upon customizing the system to supportunique business process requirements. Using a large-scalepackage such as SAP to support the business creates a morecentrally controlled, consistent organizational structure and andextensive data integration.

1 0 . R E F E R E N C E S[ 1 ] Barki, H., Rivard, S., and Talbot, J., "Toward an assessmentof software developme nt risk," Journal of ManagementInformation Systems, V. 10, No. 2, 1993, pp. 203-225.[2] Beath, C. "Supporting the information technologychampion," MIS OuarterlT, V. 15, No. 3, 1991, pp. 355-373.[3] Block, Robert. The Politics of Projects, Yourdon Press,Prentice-Hall, 1983.[4] Boehm, B.W., "Software risk management: Principles andpractices," IEEE Software, V. 8, No. 1, 1991, p. 3241.[5] Caldwell, B. "Client-Server: can it be saved?" InformationWeek, V. 584, 1996, pp. 36-44.[ 6 3 Cash, J, McFarlan, F.W., McKenney, J, and Applegate, L,"A Portfolio Approach to IT Develop ment," CorporateInformation Systems Management, Irwin Publishing, ThirdEdition, 1992.[7] Charette, R.N. Software Engineering Risk Analysis andManagement. New York: Intertext, 1989.[8 ] Davenport, Thomas H., "Putting the Enterprise into theEnterprise System," Harvard Business Review, July-August,1998, pp. 121-131.[9] Ewusi-Mensah, Kweku, "Critical Issues in abandonedinformation systems development projects,"Comm unicat ions of the ACM , V. 40, No. 9, Sept. 1997, pp.74-80.[10] H ammer, M. and Champy, J., Re-engineerin~ theCorporation: A Manife sto for Business Revolution,Nicholas Brearley Publishing, London, 1993.I l l ] Keil, Mark; Cule, Paul E.; Lyytinen, Kalle; and Schmidt,Roy C., "A Framework for identifying software projectrisks," Communications of the ACM, V . 41, No. l l, Nov.1998, pp. 76-83.[12] Lacity, Mary and Subramanian, "Managing Client-ServerImplementation," Journal of Information Technology, V. 12,1997.[ 1 3 ] McFarlan, F.W., "Portfolio approach to informationsystems," H arvard Business Review, V. 59, No. 5, Sept-Oct.1981, pp. 142-150.[14] Mumford, E., "Participative systems design: structure andmethod. System s, Objectives, Solutions, V. 1, No. 1, 1981,pp. 5-19.[15]Wiegers, Karl , "Know your enemy: software riskmanageme nt," Software Development, Oct. 1998.

187

Enterprise Risk Factors

Documents

Transcript of Enterprise Risk Factors