ABSTRACT the end of the the inception causes of IT Table 1: Types Correspondence failure Process failure and

Vol. 4, No. 1 Jan 2013 3 ISSN 20 079-8407 Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights ...
Author: Cameron Morton
2 downloads 0 Views 211KB Size
Vol. 4, No. 1 Jan 2013 3

ISSN 20 079-8407

Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights reserved. htttp://www.cisjournall.org

IT Project P F Failures s in Orgaanization ns in Gh hana  1

Godfrred Yaw Koii-Akrofi, 2 Henry H Osborrn Quarshie, 3 Joyce Koi-Akrofi  1, 2

L Lecturer, Regennt University Co ollege of Sciencce and Technology, Acccra, Ghana G 3 Prrograms Manag ger, Technologyy, Vodafone Gh hana.

A ABSTRAC T The T main objeective of this work w was to fiind the various common cauuses of IT prooject failures inn organizationns in Ghana. At A thhe end of thee day, the maain aim of thiis work was to t present to IT professionnals and projeect managers in general, thhe common c causees of IT project failures, to enable them curb these faiilures by addrressing the cau uses right from m the inceptio on of o the IT projeects. To come out with the findings, f quesstionnaires covvering variouss causes of IT T project failurres were sent to t 95 9 companies//institutions across the natiion with 171 respondents. r T respondennts were top IT The I officials annd managers in i thhe various com mpanies/instittutions. The analysis was based on the prremise that there are a num mber of alreadyy known causees of o IT project failures from literature, annd this work was w to re-empphasize some of these cauuses, as well as a establish thhe causes c that aree common in organizations o in Ghana. Th he findings revvealed that thee tilt was moree to process faailure, and theen too expectation failure. Proceess failure hass to do with annything in the project manaagement proceess that can caause IT projeccts delivery d to faill. Some of theese causes revvealed were; no n quality checcks for IT projjects, IT projeects not complleted accordin ng too schedule, noo specific IT project p managgement methoddology follow wed, revision of o scope very often o for a parrticular projecct, and a wrong esttimates. For expectation e faailure, the cau use of failure revealed r was;; project not meeting m user’’s needs. Thesse causes c can be a source of gu uide to organizzations to helpp them reducee considerably y, incidents off IT project faiilures. Keywords: K projjects, managem ment, Informatioon Technology, Ghana, organiizations, users

1. 1 INTRODUCTION N The main m objectiv ve of this worrk is to find the t various v comm mon causes of IT projeect failures in organizations o in Ghana. At the end of thhe day, the maain aim a of this w work is to preesent to IT prrofessionals and a project p managgers in generaal, the commoon causes of IT project p failurees, to enable them curb thhese failures by addressing a thee causes right from the inception of the IT projects. p

Taable 1: Typess of IS/IT projects failure annd descriptionn Category of failure C f C Corresponden nce f failure P Process failurre I Interaction faiilure E Expectation faailure

T projects are a In ttoday’s orgaanization, IT innevitable. Thhis is so because IT conttrols to a larrge extent, e all functional departmentaal operationns. Organizations O her today do not have an optioon as to wheth too invest in IT or not. The isssue is no longger to determiine whether w IT investments result in prrofitability and a productivity p oor not. It hass almost becoome a must for f managers m of organizations to invest inn IT due to the t competitive c addvantage thatt is derived inn it. IT projects have h a high failure f rate th han other proojects due to o a number n of reaasons that aree discussed beelow. The woord “failure” “ musst be situatedd well in reelation to IT//IS projects. p In geeneric terms, “Failure “ is usuually in terms of projects p that aare late or oveer budget, an inability i to fuully realize r the exppected benefitts or gain the acceptance and a enthusiastic e ssupport of ussers and maanagement” [1]. Similar S to maany authors on n project failuure, Cannon [1] describes d failuure as a number of events thhat occur with hin a project thaat does not enable it to conform to specification s and obtains its mission. A number of authors a definee four major categories c of IS/IT I failure [24]. 4 These categgories are cap ptured in table 1 below:

Deescription of failure f Thhe IS fails to m meet its dessign and objecctives Thhe IS overrunss its budget andd or time consstraints Thhe users maintain low or nonn-interaction w with the IS Thhe IS does not meet staakeholders’ exxpectations

This work w considerrs a successfuul IT project as a onne that the deliverables aree according too specificationns, thhe project is delivered on budget, andd on time, annd m meets the useer requiremen nts; user reqquirements arre neecessary as many m projects are a failed beccause they meet thhe specificatioon i.e., functioonal requiremeents but unable too meet the hidden non-funnctional requiirements whicch arre the primaryy concern off end users. Conversely, C a an unnsuccessful of o failed IT project is one that thhe deeliverables arre not according to speccifications, thhe prroject is not delivered on budget, and on time. Thhis coovers the corrrespondence and process failures in thhe taable above. This work considers Innteraction annd Exxpectation faiilures in the table t above ass consequencees off the corresponndence and prrocess failuress. Naughhton and Petters [7] arguue that system m o human perception p annd faailures largelyy depend on iddentification, thereby t ackno owledging thaat one personn’s faailure might be b another’s success. s Theyy maintain thhat thhe notion that a project failled may meann that it did no ot m certain peeople’s objectiives or that it produced whhat meet were seen by so ome as unwan nted outputs. The T impact an nd o the projectt may not be fully treasureed coonsequences of beefore deploym ment.

100

Vol. 4, No. 1 Jan 2013 3

ISSN 20 079-8407

Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights reserved. htttp://www.cisjournall.org

Robinnson [8] posiits that a projject’s failure or success s is defi fined in relatio on to a particcular group with w itts own roles, goals, intereests, and expeectations, whiich are a evaluated in the contexxt of an orgaanization and its political p and soocial environm ment. Ewussi-Mensah [99] also maintains that IS projects p are unnique in that th hey are abstraact in nature and a require r the intense i partnnership of seeveral differeent groups g of staakeholders, inncluding IS staff, s users, and a managemen m t. Floweers [5] definees an informattion system ass a failure f if any of these folllowing situatiions occurs: (1) ( when w the systeem as a wholee does not opeerate as expectted and a its overalll performancce is sub-optiimal; (2) if, on im mplementatioon, it does not perform m as originaally inntended or iff it is so user-hostile that it i is rejected by users u and underutilized; u (3) if, thee cost of the t development d eexceeds any benefits b the syystem may briing thhroughout its useful life; orr (4) due to prroblems with the t complexity c off the system,, or the mannagement of the t is project, p the informationn system development d abandoned a beffore it is comp pleted. Floweers’s first andd second definnitions of failu ure borders b on the system not meetinng design and a operational o exxpectations rig ght from the implementatiion thhrough to thee life time of o the deployed project. The T problem p couldd be from the initiation and planning stagges where w especiaally, operationnal and technnical feasibilitties are a performedd, as well as requirement discovery. The T thhird definitioons borders on o costing, annd the probleem could c stem froom improper capital budggeting techniqque employed. e Thhe fourth definition d alsso borders on operational o feeasibility, as well as the control of the t project p management processs itself.

               

1.1 Method Questiionnaires covvering variouss causes of IT I prroject failuress were sent to t 95 compannies/institution ns accross the natio on with 171 reespondents. The T respondennts were top IT officials and d managers in i the variou us coompanies/instiitutions. Somee institutions//companies haad thhe opportunityy to answer more m than onee questionnairre, inn which case, the questio onnaires weree answered by b diifferent IT officials in thosse particular coompanies/instiitutions. Desscriptive staatistics (meann, m mode, and stanndard deviatio on), frequencyy tables and baar chharts were ussed to do the analysis. The T descriptivve staatistics were applied to all the questions for thhe annalysis. Thhe focus of the analysis wass on: i.

ons that systeems should be Sauerr [6] mentio deemed d to havve failed onlyy if there is a development or operation o term mination. Baseed on this prem mise, the failu ure model m takes the natural systems appproach, whiich explains e systeems behaviorr in terms of o the goal of survival. s Thiss approach deescribes the achievement of survival s throuugh acting onn the environnment so as to obtain o necessaary resources (funding) thatt in turn support thhe system’s continued op perations. A system is not n deemed d to bee a failure as a long as it i survives and a continues c to atttract support in resources.

ii.

iii.

iv. v.

midt, Lyytinenn, Keil and Cuule [10], a grooup Schm of o researchers,, led one of thhe comprehennsive studies thhat were w deployedd to study th he root causess for IT projeect failure f on eexperienced project p manaagers in thrree different d settinngs: Hong Koong, Finland, and the Unitted States. S The three panels of experts acknowledgged innitially a list of 53 IT projject risk factoors. The list was w condensed c to a set of 17 through rankking and pariing down d processees, as shown below: b  Lackk of top mannagement com mmitment to the t projecct

Misunnderstanding the t user requirrements Not managing m channge properly Failurre to gain userr commitmentt Lack of adequate user u involvemeent Confllict between user departmennts Changging scope and objectives Numb ber of organizational units involved i Failurre to manage end-user e expeectations Uncleear / misunderrstood scope and a objectives Improoper definiitions of nd roles an responnsibilities Lack of frozen requuirements Introdduction of new w technology Lack of effective prroject manageement skills Lack of effectiive project managemen nt methodology Lack of required team knowledgge / skills Insuffficient / inapprropriate staffiing

Findinng the comm mon causes of IT project failurees for these institutions/ccompanies annd rank thhem. Findinng whether these t institutiions/companiees have project m management departmen nts I purpossely designateed to initiate and deliver IT projects or not Findinng whether a project managemen nt methodology is foollowed for delivering IT I projects or not Findinng the for thesse motivation compaanies/institutio ons to embarkk on IT projectts Findinng how IT project teaams of thesse compaanies/institutio ons are constittuted

Namess of com mpanies annd individuual mitted to avooid breach of o reespondents haave been om coonfidentiality. The purposee of this woork was not to t exxpose any coompany/instituution, but jusst to bring ou ut clearly how thee picture look ked like when it comes to IT I prrojects and its associated high failures.

101

Vol. 4, No. 1 Jan 2013 3

ISSN 20 079-8407

Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights reserved. htttp://www.cisjournall.org

mary of the questions annd answers by b shhows a summ reespondents (yees and no typpe of questionns) which brinng ouut the causees of IT prroject failures for the 95 9 coompanies/instiitutions repressenting the 1771 respondentss.

2. 2 RESUL LTS AND DISCUSSIO D ON The aanalysis is bassed on the premise that theere are a a numberr of already known k causees of IT projeect failures f from literature, l and d this work is to re-emphasiize some s of these causes, as weell as establishh the causes thhat are a common iin organizatioons in Ghana.. Table 2 beloow

T Table 2: Sum mmary of the questions q and answers by reespondents (yees and no typee of questions)). D Description of o question No IT depart rtment Head of IT not n part of Topp managemennt

% yes 6.4 28.7

% no 92.4 66.7

% Unanswered 1.2 4.7

IT operationns and projectss are outsourced

43.3

50.9

5.8

IT departm ment is responsible r for the managementt of IT projectts. Company dooes not have programs p mannagement department Lack of adeequate IT staaff to work on o issues promptly Users compplain a lot about a IT channges and developments Company haas specific IT T project mannagement methodologyy it follows Company em mploys strict quality checkks for IT projects IT projects aare completed according to schedule Budget for IT projectss is allocatedd at the beginning off each financiaal year Spending forr IT projects go g beyond thee bugetted amount IT projects are deliveredd to users according to specificationns Unrealistic deadlines d are imposed i on IT T projects Enough resoources are assiigned to IT proojects Instances IT T projects delivered to users do not meet their neeeds

81.3

15.2

3.5

49.7

45.0

5.3

46.2

49.7

4.1

40.9

59.1

0

24.6

70.8

4.7

22.2

74.3

3.5

26.3 75.4

71.3 21.1

2.3 3.5

38.0

50.3

11.7

78.9

16.4

4.7

27.5 57.9 61.4

68.4 38.6 35.1

4.1 3.5 3.5

Instances off wrong estimaates

52.6

36.8

10.5

Viability of IT projects are a a major prroblem in the course off executing prrojects IT project sccope are often revised

34.5

57.9

7.6

66.7

28.1

5.3

From m table 2 abovee, the areas off concern are the t ones o that havee been bolded d and italicedd. Firstly, 81.33% of o all responddents said IT department d iss responsible for f delivering d IT projects, andd again 49.7% % do not haave programs p mannagement depaartments. Thiss developmentt is not n good enouugh because programs p mannagement shou uld be b treated as a functional unit where there t should be project p managgers and proggram managerrs purposely for f delivering d prrojects. Prog grams manaagement is a specialized s area of professsion, and musst be treated as such. s

prroject/program m manager ro ole for IT proofessionals caan reesult in probllems in IT projects delivvery from thhe beeginning to thhe end. For prroper delivery of IT projectts, thhe separation between b the project p managger on one sid de, annd the expert (IT professionnal) on anotheer side must be b clearly made. This T is not to say that the IT I professionnal caannot be a prooject managerr; if he/she haas the requisite prroject manageement skill, hee/she can be signed s on. Th his is even an added a advantage, as hiss/her technical unnderstanding will be brouught to bear to help in thhe prroject deliveryy.

Subjeect matter expperts or IT pprofessionals are a not n necessarilyy project/proggram managerss. Assuming

40.9% % of users com mplained aboout IT changees annd developmeents. This perccentage is quiite large, whicch

102

Vol. 4, No. 1 Jan 2013 3

ISSN 20 079-8407

Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights reserved. htttp://www.cisjournall.org

means m that ussers in the co ompanies undeer consideratiion still s see IT as alien and aree not willing tto change, say ya particular p softw ware or progrram once theyy get stuck to it. The T reason couuld be the inaability of the IT I departmentt to communicate c c changes and developments d to staffs welll in advance a beforre those chan nges and devvelopments. The T project p manaagement proocess includdes a channge management m process wherre the duty of the channge management m specialist is to manage the prospectiive change c beforee it even happpens. Failure to do that will w result r in the staaffs showing resistance r to change. c

Anothher major cauuse for IT prooject failure is when projects delivered d to ussers do not meeet their needss. Frrom table 2 abbove, 61.4% of respondentts said projeccts deelivered to com mpanies invollved do not meet m their needds. Thhis is a cleaar manifestatiion of lack of o requiremen nt diiscovery and analysis. a Wheen users are not n consulted in i thhe early stagess of the IT prooject managem ment process to t iddentify or extract system m problems and solutio on reequirements from f them, the t result wiill be that thhe prrojects deliverred will not meet m their needds.

70.8 % of all the respondents r reevealed that thhey do d not havve any speecific projecct managemeent methodology m they follow for projects delivery. Th his simply s meanss that most of o these comppanies have not n taaken project m management as a a serious buusiness, and thhat most m of them m fall withinn level 1(Iniitial-Inconsisteent methods) m andd level 2(Reepeatable-Connsistent Projeect Management) M of the Capabiility Maturity Model. Leveel 1 means m that S System devellopment projects follow no prescribed p prrocess. Leveel 2 meanss that Projeect management m pprocesses and d practices aree established to trrack project ccosts, schedulees, and functioonality. The fiirst tw wo levels of tthis model aree the lowest levvels that portrray loow quality off project deliveery. This is prroven by the fact fa thhat we have 74.3% 7 of respoondents who said s there are no strict s quality checks for IT projects. p

Estimaates are allow wed in projecct managemennt, buut when projeect managers get them wrrong, they caan also be a cause for project faailure. From thhe table abov ve, reespondents peggged wrong esstimates at 522.6%. Scope revision is also a majorr cause for IT I prroject failure if not done well and at the right tim me. Again respondeents pegged it i at 66.7% which w is on thhe hiigh side. s a sum mmary of thhe Table 3 below shows quuestions and answers a by reespondents (Liikert scale typpe off questions) which w also brin ngs out some of o the causes of o IT T project faillures for thee 95 compannies/institution ns reepresenting thee 171 responddents.

On tim ming for IT projects p complletion, 71.3% of respondents r saaid IT projectss are not comppleted accordiing too schedule. Thhis is a major cause for IT project p failuree. T Table 3: Sum mmary of the questions q and answers by reespondents (L Likert scale typpe of questionns) Failure ccause description Employeee IT competennce level IT stafff IT competennce level Positive response level of users when IT projeccts are to delivered them Employeee involvemeent at the plaanning stages oof IT projects Level of o IT usage inn the company as a whole Involvement level of Top

% excellent e

% very good

% good

% satisfaactory

% poor

% nanswered un

12.3

39.2

38

8.2

1.2

1.2

42.7

42.7

10.5

0.6

0

3.5

18.7

49.7

22.2

7.6

0.6

1.2

5.8

17.0

30.4

22.2 2

2 23.4

1.2

33.9

40.9

14.6

10.5 5

0

0

24

45.6

19.9

8.8

1.8

0

103

Vol. 4, No. 1 Jan 2013 3

ISSN 20 079-8407

Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights reserved. htttp://www.cisjournall.org

and M Middle in managers the deployyment and usagee of IT projects IT pproject success raating

21.6

44.4

From m table 3 abovve, employee involvement at thhe planning stages of IT projects recoorded very pooor results. r 23.4% % of respondeents said it was w poor, 22.22% said s satisfactorry, and 30.4% % good. Only 5.8% 5 and 17.00% said s excellentt and very go ood respectivvely. This agaain goes g to provee the point off 61.4% of reespondents who w said s projects delivered d to users u do not meet m their needs. If users are not involvved in the whole projeect management m p process, the prrojects deliverred at the end of

24

2.3

0.6

7.0

a they will no ot thhe day may beecome “whitee elephants” as meet their (userrs) needs, andd hence will noot even attemp m pt too use them. Table 4 below sho ows a summaary of the fouur im mplementationn or deploymeent methods employed e by IT I prroject manageers. DCO means m Direct Change Oveer, PA AR Parallel Run, PIR Pilot Run, annd PIP Phaseed Im mplementation n.

Tablee 4: Which off the followingg four ways doo you employ most to deplo oy IT projects to the employyees?

Valid V

Frequ uency

Percent

Valid Percent

Cum mulative Percent

NA

6

3.5

3.55

3.5

DCO O

26

15.2

15..2

18.7

PAR R

58

33.9

33..9

52.6

PIR

62 2

36.3

36..3

88.9

PIP

19

11.1

11..1

100.0

Totaal

1771

100.0

1000.0

From m table 4 abov ve, 36.3% of respondents r saaid thhey use Pilott Run, 33.9% % Parallel Runn, 15.2% Direect Change C Over,, and 11.1% Phased Impleementation. For F users u who are not so much into IT, Pilot Run is good, as a small sectionn of the users use it for som me time beforee it iss fully deployyed for all useers in the set up. u This reducces thhe number off complaints from f users rigght from scratcch, and a the possibble rejection of o the project if i indeed it dooes not n meet their needs. With the t small secttion of users, the t concerns c that are a raised cann quickly be fixed fi before thhey are a fully deplooyed to the whole w organizzation, since the t small s section represent the whole organnization. Paralllel run r is also goood for users who w are not so much into IT. It offers o them the opportunnity to appreeciate the neew changes c that thhe new system m offers. The danger d thoughh is thhat when thee new system m does not meet m their needs, thhere is a highh possibility of the users to reject it and a stick s to the olld system. Thhis is even moore so when the t new n system dooes not offer significant s advvantage over the t old o one. Direcct Change- ov ver is good foor users who are a very v much intoo IT, and alw ways want to subscribe s to neew changes c and ddevelopments. With users who w are not in nto IT, Direct changeover cann be very dissastrous, as the t users u may noot use the sysstem at all, rresulting in loow productivity. p With regards to project plaans(Task planns, Resource R plaans, Risk Management M Plans, Quallity Control C plans, Communications plans, Isssues

management plans, m p Changee control plaans, Test plann, Deployment pllan), Change control planns topped witth 7.6%, followed d by Risk Maanagement Pllans 5.8%, annd Issues managem ment plans 5.3% 5 as the oones that mo ost n do at all. This T again goees to prove wh hy coompanies do not we have 40.9 9% of users showing ressistance to IT I M of the coompanies undeer chhanges and deevelopments. Most coonsideration do d not considder change coontrol plans as a crritical. This iss indeed one of the causess for IT project faailures. Risk managementt plans as well w as issuees m management pllans are also not considereed. This mean ns thhat projects arre done with no n plans to manage m risks, as a well as resolve very importan nt issues in thhe course of thhe nagers do theiir own thing in i prroject deliveryy. Project man tryying to resolv ve issues without any docum mented process too follow. The qu uestion was allso asked abouut which of thhe foollowing mem mbers(Project sponsor/ Ownner or Steerinng coommittee, Prooject Manageer, Member representativees froom the depaartments, Prooject secretaryy or assistannt, Puublic Relationns Representaative, Changee Managemen nt Sppecialist) has never existed d in their projject teams, annd Puublic Relations Representtative toppedd with 16.4% %, foollowed by Chhange Manageement Specialist with 15.8% %, annd Project seecretary or assistant a withh 10.5%. Thhis reesults show cllearly that thee organizationns involved do d noot constitute their t project teams well. T They leave thhe m most importantt parts of the team out. Soometimes rolees

104

Vol. 4, No. 1 Jan 2013 3

ISSN 20 079-8407

Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights reserved. htttp://www.cisjournall.org

liike public relations, secretaary, and channge managemeent are a not conssidered as critical, and hence are not n considered. c Thhey put all thheir energies on o the techniccal delivery d of thee project, forg getting that thhe end users are a human h beings who are diffficult to manaage, and that the t very v roles thaat are not con nsidered as im mportant are the t roles r that resollve all the hum man issues. Thhis is a potenttial danger d that points to IT projject failures.

3. 3 CONCL LUSION AND RECOM MMENDAT TION In coonclusion, thiss work revealled about sevven worrying w areaas or reasons that contribuute to IT projeect failures f in orgganizations in n Ghana. These reasons are a arranged a in thee order of how w serious theyy are from topp to down: d i.

ii. iii. iv. v. vi. vii.

No project m management departmennts: Comppanies do noot have projeect managemeent deparrtments/units where projectts are run froom, wheree professionaality is assurred for projeect deliveery, but prrojects beingg run by IT deparrtments themsselves, wheree the focus may m not be b on projecct managemeent, but on IT operaations to the detriment d of IT projects thhat are deelivered No quuality checks for IT projects IT proojects not com mpleted accordding to scheduule No sppecific IT projject managem ment methoodology follow wed Revission of scope very v often forr a particular projecct IT proojects not meeeting users needs Wronng estimates

The above seven reasons are in consonannce with w the findinngs of Lyytinnen and Hirscchheim [2], Yeo Y [3] and Gouliielmos [4], who w posits thaat IS/IT failurres can c be groupeed into four main categorries. Using thheir findings, f and comparing wiith the findinggs of this work, thhe tilt is moree to process faailure, and theen to expectatiion failure f as is deescribed in tabble 1. This meeans that projeect management m m must be seen in organizationns in Ghana as a a complete c process that must be well manaaged from endd to end. e Failure tto do that will result in thhe failure of IT projects. p Agaain, for IT T projects to t meet useers expectations, e users must be involved in the whoole process p from the t scratch.

[22]

K. Lyyytinen, R, Hirschheim.. Informatioon failures— —a survey and Classificcation of thhe empiricaal literaturee. Oxford Surveys in i Informattion Technoloogy, 4:257–3099, 1987.

[33]

K. T. Yeeo. Critical faailure factors in informatio on system projects. p Interrnational Jourrnal for Project Managem ment, Vol. 20, No. 3, pp. 12241-246, 2002 2.

[44]

M. Goulielmos. Outlin ning organizattional failure in i informattion systems developm ment. Disasteer Development and Maanagement Journal, Vol. 12, No. 4, pp p. 319-27, 20003.

[55]

S. Floweers. Software failure: Manaagement failurre. Chichestter, UK: John Wiley, 1996.

[66]

C. Sauerr. Why inform mation system ms fail: a casse study approach, a information syystems seriees. Henley-o on-Thames, UK: U Alfred Waaller, 1993.

[77]

J. Naug ghton, G. Petters. Systemss and failurees. Open Un niversity Presss, Milton Keynnes.1976

[88]

B. Robin nson. Social context c and coonflicting interests. Second BCS S conference on o Informationn System Methodologie M es, Edinburgh, pp. 235-249, 1994.

[99]

K. Ewusi-Mensah. Criitical Issues inn Abandoned m Developm ment Projectts. Informattion System Commun nications of thhe ACM, 40, 9, 9 1997.

[10] R. Schm midt, K. Lyytinnen, M. Keil, aand P. Cule. risks: Identifyiing softwarre project A An internatio onal Delphhi study. Journal o of Managem ment Informaation Systemss, 17(4), 5–36, 2001.

mmendation, this t work can be As a form of recom taackled from thhe angle of coomparing induustry to industtry, say s the servicce industry too the manufaccturing industtry, etc e to know what actuallly pertains in the varioous inndustries withh regards to IT T project failuures. This can be taaken up by annother researchher or the authhor in later daate.

REFEREN R CE [1]

J. A. C Cannon. Why IT Applicatiions Succeed or Fail. Industry and Coommercial Trraining, Vol. 26, 2 No. 1, ppp 10-15, 19944.

105

Vol. 4, No. 1 Jan 2013 3

ISSN 20 079-8407

Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights reserved. htttp://www.cisjournall.org

APPENDIX X QUESTIONN Q NAIRE This T is a questtionnaire aimeed at finding the t most comm mon causes oof IT project failure fa in Ghannaian compannies. IT projeccts unlike u other prrojects have high h rates of failure, f and th his normally affect a the Techhnological addvancement off companies, as a well w as the IT knowhow of employees. Inn the end, it can result in pooor performannce of employyees and the organizations o a as a whole. I wouuld be very grrateful if you can c go throug gh these questiions and answ wer them for me. m Names of companies annd inndividuals will not be publiicized to ensuure privacy andd confidentiallity. Thanks fo or your cooperration. A. PERS SONAL AND D COMPANY Y INFORMA ATION NAME:……… N ……………… ……………………………… ……………… ………………… ……………… …………………………… POSITION:… P ……………… ………………… ……………… ……………………………… ……………… ………………… ……………… … NUMBER N OF F YEARS SP PENT WITH THE COMP PANY:……… ………………… ……………… ……………… ……….. NAME N OF CO OMPANY:………………… ……………… ………………… ……………… ……………… ………………… ………….. CORE C BUSIN NESS OF COM MPANY: …… ……………… ……………………………… ……………… ………………… ………… INDUSTRY/S I SECTOR THE E COMPANY Y IS UNDER:……………… ……………… ……………………………… ……… B. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.

QUE ESTIONS Does your compan ny have IT deppartment? YES or NO Is thee head of the IT department part of Top Management? M YES or NO Are IT T operations and a projects outsourced? o Y or NO YES Is thee IT departmen nt the same deepartment resp ponsible for thhe managemen nt of IT projeccts? YES or NO N Does the company have Program ms Managemeent department? YES or NO O Does IT departmennt have enoughh staff to work k on issues prromptly? YES S or NO Do em mployees(userrs) complain a lot about IT changes and developments d s in the compaany? YES or NO N Rate tthe IT compettence level off the employeees: 0-20% % 21-40 0% 41-660% 61--80% 811-100% Rate tthe IT compettence level off the IT staffs 0-20% % 21-40 0% 41-660% 61--80% 811-100% 21-40% Rate tthe positive reesponse level of employees when IT projjects are deliv vered to them. 0-20% 41-600% 61-880% 81--100% Are employees e inv volved at the planning p stagees of IT projeccts? What is thhe level of inv volvement? 0-20% % 21-40 0% 41-660% 61--80% 811-100% Whatt is the level of IT usage in the t company in relation to all a the departm ments and their operations. 0-20% % 21-40 0% 41-660% 61--80% 811-100% Rate tthe involvemeent of Top andd middle manaagers in the deeployment and usage of IT projects. 0-20% % 21-40 0% 41-660% 61--80% 811-100% Does the company have a speciffic methodologgy it follows ffor IT projectss? YES or NO O Does the company employ strictt quality checkks for IT projeects? YES or NO Are IT T projects com mpleted accorrding to sched dule? YES or N NO Does the company allocate budgget for IT projects at the begginning of eveery financial year? y YES or NO Do sppending for IT T projects norm mally go beyoond what is quuoted in the bu udget? YE ES or NO Are IT T projects dellivered to empployees accordding to specifiications? YES S or NO

20. Whatt has been pusshing managem ment over the years to embaark on IT projjects? From thhe list below, rate r them startinng from 1 beinng the most reeason to 4 bein ng the lowest.. aa. As a way to resolve a problem p b b. To seize an a opportunity cc. As a direcctive from management d d. As a resu ult of planningg 21. Are unrealistic u deaadlines imposeed on IT projeects? YES or N NO 22. Are enough e resourcces assigned to t IT projects?? YES or NO 23. Has thhere been insttances where IT I projects deelivered to the employees doo not meet theeir needs? YE ES or NO If YE ES, rate the nu umber of instannces.: 0-20% % 21-40 0% 41-660% 61--80% 811-100% 24. Has thhere been insttances of wronng estimates? YES or NO If YE ES, rate the nu umber of wronng estimates:

106

Vol. 4, No. 1 Jan 2013 3

ISSN 20 079-8407

Journal of Emerrging Trends s in Computin ng and Inforrmation Sciences ©2009-2013 CIS Journal. All rights reserved. htttp://www.cisjournall.org

25.

26. 27.

28.

0-20% % 21-40 0% 41-660% 61--80% 811-100% Has thhe viability off IT projects been b a major problem p in thee course of exeecuting the prrojects? YES or o NO. If YES, rate the numbber of times: 0-20% % 21-40 0% 41-600% 61--80% 811-100% Do yoou very often revise scope ffor your IT prrojects? YES oor NO. If YES S, rate the num mber of times: 0-20% 21-400% 41-660% 61--80% 81 1-100% Whicch of the follow wing four wayys do you empploy most to deploy d IT projjects to the em mployees? aa. Direct Ch hangeover-Neew IT project comes into opperation direct b b. Parallel Run-Old R and New N systems run side by siide for some tiime cc. Pilot Run n- The New syystem is run foor a section off the users beffore full deplooyment d d. Phased Im mplementatioon- New systeem deployed in i phases Tick from the list below b the ones that your company or insttitution does not n do at all when w it comes to t projects plans: aa. Task plan ns b b. Resourcee plans cc. Risk Man nagement Plaans d d. Quality Control C planss ee. Commun nications plan ns ff. Issues ma anagement pllans gg. Change control c plans h h. Test plan n i. Deploymeent plan

29. Whicch of the follow wing has neveer existed in your y project teams? aa. Project sp ponsor/ Owner or Steering committee b b. Project Manager M cc. Member representativves from the departments d d. Project seecretary or assistant ee. Public Reelations Reprresentative ff. Change Management M Specialist 30. Rate tthe success off IT projects inn your compaany/Institutionn? 0-20% % 21-40 0% 41-660% 61--80% 811-100%

107