ADDIS ABABA UNIVERSITY

COLLEGE OF NATURAL SCIENCE

SCHOOL OF INFORMATION SCIENCE

Assessment of why software projects fail in government organization

in Ethiopia

Advisor: - Ato Getachew Jemaneh

By

Samuel Asrat

February, 2017

ADDIS ABABA

i
 ADDIS ABABA UNIVERSITY

COLLEGE OF NATURAL SCIENCE

SCHOOL OF INFORMATION SCIENCE

Assessment of why software projects fail in government organization

in Ethiopia

By

Samuel Asrat

February, 2017

ii
 ADDIS ABABA UNIVERSITY
COLLEGE OF NATURAL SCIENCE
SCHOOL OF INFORMATION SCIENCE

Assessment of why software projects fail in government organization

in Ethiopia

A THESIS SUBMITTED TO ADDIS ABABA UNIVERSITY COLLEGE

OF NATURAL SCIENCE SCHOOL OF INFORMATION SCIENCE FOR
PARTIAL FULFILLMENT OF THE REQUIREMENT FOR THE
DEGREE OF MASTER OF SCIENCE IN INFORMATION SCIENCE

By:
Samuel Asrat

iii
 ADDIS ABABA UNIVERSITY

COLLEGE OF NATURAL SCIENCE

SCHOOL OF INFORMATION SCIENCE

Assessment of why software projects fail in government organization

in Ethiopia

By
Samuel Asrat

Approved by Board of Examiners

_______________________ ________________ ________________

Advisor Signature Date

______________________ _________________ ________________

Examiner Signature Date

______________________ _________________ ________________

Examiner Signature Date

iv
 CERTIFICATE

This is to certify that Samuel Asrat has worked on ―An Assessment of why software
projects fail in government organization in Ethiopia” under my supervision. This
work is original in nature and it is suitable for submission in the partial fulfillment of the
requirement for the Degree of Master in Information Science.

____________________
Ato Getachew Jemaneh

v
 DECLARATION

I, the undersigned, declare that this thesis is my original work under the guidance of
Ato Getachew Jemaneh. All sources of materials used for the thesis have been duly
acknowledged.

Name : Samuel Asrat

Signature: _____________

Place: Addis Ababa University

Date of submission: February, 2017

This thesis has been submitted for examination with my approval as a university
research advisor.

Name: Getachew Jemaneh

Signature: ______________

Date of Approval: _________________

vi
 Acknowledgements

I am very much indebted to express my heartfelt gratitude to my advisor, Ato Getachew

Jemaneh, for his enlightened, genuine and constructive comments and suggestions
throughout this work.

I would also like to extend thanks to respondents of both the government and private
companies working on software projects as well as end users for their participation and
support in data collection.

My deepest gratitude goes to my family and friends especially, to Mulalem Yakob,

Birhanu Nebiyu, Yared Bekele, Keno Lemessa, Haimanot Adane, Tagel Mekonenn and
for my beloved wife Fiker. Finally, my sincere thanks go to all relatives who, in one way
or another, contributed to the completion of this study.

vii
 Table of contents
Page no
Acknowledgement ......................................................................................................................Vii
Table of contents ..........................................................................................................................Viii
List of tables’ .................................................................................................................................Xi
List of figures .................................................................................................................................Xii
List of acronyms ............................................................................................................................Xiii
Abstract .........................................................................................................................................Xiv
Chapter one .................................................................................................................................................. 1
1. Introduction .......................................................................................................................................... 1
1.1 Background of the study ............................................................................................................... 1
1.2 Statement of the problem ............................................................................................................ 2
1.3 Objectives of the study ................................................................................................................. 4
1.3.1 General objectives of the study ................................................................................................... 4
1.3.2 Specific objectives of the study.................................................................................................... 4
1.4 Significance of the study ............................................................................................................... 5
1.5 Scope of the study ........................................................................................................................ 5
1.6 Limitation of the study .................................................................................................................. 5
1.7 Operational definitions ................................................................................................................. 6
1.8 Organization of the study ............................................................................................................. 6
Chapter two .................................................................................................................................................. 7
2. REVIEW OF RELATED LITERATURE ........................................................................................................ 7
2.1 Software projects success / failure ..................................................................................................... 7
2.2 Software projects success / failure rate.............................................................................................. 8
2.3 Major factor for software projects failure ........................................................................................ 11
2.4 Major factors for software projects success ..................................................................................... 18
2.5 The effect of software projects failure ............................................................................................. 21
2.6 Software project success / failure from software companies’, practitioner s and end users
perspectives ............................................................................................................................................ 24
2.7 Government and software projects failure/success ......................................................................... 26
2.8 Summary of related works ................................................................................................................ 28

viii
Chapter three .............................................................................................................................................. 29
3. RESEARCH DESIGN AND METHODOLOGY ........................................................................................... 29
3.1 Introduction .................................................................................................................................... 29
3.2 Research methodology ............................................................................................................... 29
3.2.1 Research design ......................................................................................................................... 29
3.2.2 Research methodology/approach ............................................................................................. 29
3.2.3 Source of data ............................................................................................................................ 30
3.2.4 Study population ........................................................................................................................ 30
3.2.5 Sampling method and techniques ............................................................................................. 30
3.2.6 Sample size................................................................................................................................. 31
3.2.7 Instrument for data collection ................................................................................................... 32
3.2.8 Procedures of data collection .................................................................................................... 33
3.2.9 Methods of data analysis ........................................................................................................... 33
3.2.10 Summary of the methodology ................................................................................................. 34
Chapter four ................................................................................................................................................ 35
4. DATA PRESENTATIONS, ANALYSIS AND DISCUSSIONS........................................................................ 35
4.1 Quantitative data presentation and analysis .................................................................................... 35
4.1.1. Respondents profile ............................................................................................................ 35
4.1.2. Position of respondents ...................................................................................................... 36
4.1.3. Different perspective of software projects ......................................................................... 37
4.1.3.1 Experience in software projects (in terms of number of projects) ..................................... 37
4.1.3.2 Ratio of successful/challenged /failed software projects ................................................... 38
4.1.3.3 Overall ratio of successful/failed software projects ........................................................... 39
4.1.3.4 Ratio of software Projects success /failure in terms of project type .................................. 40
4.1.3.4.1 Successful software projects by type ........................................................................... 40
4.1.3.4.2 Cancelled software projects by type............................................................................ 41
4.1.3.4.3 Challenged software projects by type ......................................................................... 42
4.1.4. Effects of software projects failure ..................................................................................... 43
4.1.5. Major factors for software project cancellation/challenge/success from practitioners
perspective.......................................................................................................................................... 44
4.1.5.1 Major factors for software projects cancellation ............................................................... 44
4.1.5.2 Major factors for software projects challenge ................................................................... 45

ix
 4.1.5.3 Major factors for software projects success ....................................................................... 46
4.1.6. Major factors for software projects cancellation /challenge/success from software
company perspective .......................................................................................................................... 47
4.1.6.1 Major factors for software projects cancellation ............................................................... 47
4.1.6.2 Major factors for software projects challenge ................................................................... 48
4.1.6.3 Major factors for software projects success ....................................................................... 49
4.1.7. Major factors for software projects cancellation /challenge/success from end user’s
perspective.......................................................................................................................................... 50
4.1.7.1 Major factors for software projects cancellation ............................................................... 50
4.1.7.2 Major factors for software projects challenge ................................................................... 51
4.1.7.3 Major factors for software projects success ....................................................................... 52
4.2 Qualitative data analysis ................................................................................................................... 53
4.3 Discussions ........................................................................................................................................ 56
Chapter five ................................................................................................................................................. 59
5. CONCLUSION AND RECOMMENDATIONS........................................................................................... 59
5.1 Conclusion ......................................................................................................................................... 59
5.2 Recommendations ............................................................................................................................ 60
References .................................................................................................................................................. 62
Appendix 1 .................................................................................................................................................. 67
Appendix 2 .................................................................................................................................................. 74

x
 List of tables
Page no
Table 2.1 Software projects failure statistics ...........................................................9
Table 2.2 Software projects failure in years ............................................................10
Table 2.3 Summary of software projects cancellation .............................................11
Table 2.4 Explicit success factors ...........................................................................19
Table 2.5 Implicit success factors ...........................................................................20
Table 2.6 Failed software projects failure and their cost from
1992-2005 .................................................................................................22
Table 2.7 Summary of related works .......................................................................28
Table 4.1 Respondents profile ................................................................................35
Table 4.2 Position of respondents ...........................................................................36
Table 4.3 Major factors for software projects cancellation.......................................44
Table 4.4 Major factors for software projects challenge ..........................................45
Table 4.5 Major factors for software projects success.............................................46
Table 4.6 Major factors for software projects cancellation.......................................47
Table 4.7 Major factors for software projects challenge ..........................................48
Table 4.8 Major factors for software projects success.............................................49
Table 4.9 Major factors for software projects cancellation.......................................50
Table 4.10 Major factors for software projects challenge ........................................51
Table 4.11 Major factors for software projects success...........................................52

xi
 List of figures
Page no
Figure 2.1 Ratio of successful to failed projects ......................................................9
Figure 2.2 Major causes of software project failure .................................................18
Figure 2.3 Effects of software project failure for organization..................................21
Figure 4.1 Number of projects respondents participated .........................................37
Figure 4.2 Ratio of successful/challenged/cancelled software projects ...................38
Figure 4.3 Ratio of successful to failed software project ........................................39
Figure 4.4 Successful software projects by type .....................................................40
Figure 4.5 Cancelled software Projects by type .....................................................41
Figure 4.6 Challenged software Projects by type ...................................................42
Figure 4.7 Effects of software Projects failure .........................................................43

xii
 ACRONYMS

ICT Information Communication Technology

IT Information Technology

ERP Enterprise Resources Planning

HRM Human Resource Department

ICMIS Integrated Civil services Management Information System

BSC Balanced Score Card

E-Services Electronic Services

PASC Public Accounts Spending Committee

ROI Return on Investment

SPSS Statistical Packages for Social Science

US United States of America

xiii
 ABSTRACT

In a country like Ethiopia, where information and communication systems are in the
early stage of development, software projects may face several challenges. Software
projects may suffer from schedule or budget overrun or unmet specifications, leading to
failure. This paper aims at assessing the major factors that can lead to software project
failure in government organizations in Ethiopia. This research used quantitative and
qualitative methods. Factors affecting software projects failure are identified based on
extensive literature review. The quantitative aspect of the study involved 48 practitioners
and end users from government organizations and 24 from software companies. In the
qualitative study, direct interviews were used to collect data from 4 senior IT managers
in the government organizations. The quantitative data were analyzed by employing
appropriate techniques of descriptive statistics using SPSS and MS-Excel software tool.
The qualitative data were analyzed using the techniques of open codding. The result of
the study indicated that the major factors for the failure of software project in
government organization are lack of ICT department as well as user involvement in
software projects and lack of knowledge management. Lack of top management
support and Lack of skilled ICT professionals and end users are also the major reason
for the failure of software projects. In addition, the result revealed loss of confidence by
stakeholders was major effects of software project failure. It is recommended that
engaging ICT professionals as well as users in the whole course of the project and
capacity building for end users and ICT professionals is important to minimize failure of
software projects in government organizations and there is also need to gain confidence
of stakeholders by increasing the success rate of software projects. Furthermore, long
term strategy for knowledge management in the area of software project management
is also important.

Keywords: Software projects, Practitioners, Software projects failure

xiv
 Chapter one

1. Introduction

1.1 Background of the study

Software development has its roots in the 1960s and since then software has become
an essential part of modern society. With the help of software it is possible to write a
report, build a bridge, control the space shuttle, build social networks in the Internet, and
it may play a crucial role in overall economy. However, despite the successful
application of software to almost all possible areas, software development projects have
a reputation that they often fail; they are e.g. late, over-budget, or not able to satisfy
customers‘ needs (Cerpa & Verner, 2009; Glass, 2006).

Software applications are the driving force of modern business operations; recent
decades bear testimony to how we have gone from merely using software, to relying on
it, and ultimately becoming dependent on it, for our day to day lives. Software is also
extensively used in areas such as health, transportation, nuclear power generation,
education, and national defense, only to name a few. The smallest flaw could have
devastating consequences that can lead to significant damage.

Project is successful if it delivers the desired performance improvement, or better, at a

time and a cost that provides value for the organization (Glass, 2001). IT projects have
been considered a tough undertaking and have certain characteristics that make them
different from other engineering projects and increase the chances of their failure. There
is still major concern over the implementation of IT projects and difficulties are
continually being experienced despite the more prevalent use of structured
analysis and design methodologies (Wateridge ,1995). Software development is a
highly complex and unpredictable activity. A report indicate that 53% of software
projects were unable to deliver on schedule, within budget, and with the required
functions, while 18% of the software projects were cancelled (Standish, 2004).

1
This stresses the fact that software projects pose various risks and daunting tasks form
any organizations. Now, as organizations invest substantial resources and effort on
software development, identifying the reasons associated with software projects
becomes crucial (Kumar, 2002). As organizations spent huge amount of money for
software projects development, there is a need to work aggressively to protect from
failure. Software projects failure jeopardizes an organization's prospects. If the failure is
large enough, it can steal the company's entire future.

1.2 Statement of the problem

According to The Federal Democratic Republic of Ethiopia Ministry of Communication

and Information Technology, ICT is one of the strategic priorities in the country. In lieu
of the country‘s stride for substantial growth, the government of Ethiopia highly
encourages and promotes the use of information and communication technology in all
development sectors (Ethiopia, Ministry of Communication and Information Technology,
2012). The expected growth and transformation of Ethiopia cannot easily be realized
without software usage. Some of the undergoing software projects in Ethiopia are very
big and complex that they cannot be managed by the old ways and means to reach the
pinnacle of success according to plan and budget (Mignote, 2013).

Software projects failure in government can endanger national security; IT failures can
also stunt economic growth and quality of life. Worldwide, it is hard to say how many
software projects fail or how much money is wasted as a result. If we define failure as
the total abandonment of a software projects before or shortly after it is delivered, then
billions of dollars are wasted each year on bad software. According to charette (2005)
―Governments, too, are big consumers of software.‖ Failure of any of the software
projects can cost large amount of money and other important resources.

There is overwhelming evidence that large IT projects indeed tend to fail. However, the
extent of failure is debated among academics and practitioners. IT projects seem to fail
in both private and public sectors, however failure in public IT projects appear to be
more spectacular due to size, visibility in media and political consequences (Holgeid &
Thompson, 2013). Failure rate of software projects is between 50% and 80%

2
(Alagarsamy & Rajkumar, 2013). The Standish Group report indicates that the success
rate of American software projects amounts to only 16.2% (Standish, 2014). Although in
US software development projects have been carried out for over 50 years, it seems
that we have not yet learned enough to ensure that our software development projects
are successful (Cerpa & Verner, 2009), and there is still a need for research on software
project failure.

According to Mignote (2013), software projects situation is worse in Ethiopia particularly

in government organizations. The works to be done in software projects are mostly
obscure to the user and are not rigorously tested and transferred to the owner. The
major prospects being government organizations, the bureaucracy either lacks
understanding about the products or is susceptible for corruption. Even when
implemented, the technology requires dedication of the customer to transfer it to its
business processes where the work force is stagnant. Besides, the support following the
handover of software is not considered as essential and simply left out for lack of
budget. Despite the fact that it was not possible to obtain publications on the
government organizations with regard to Ethiopian software project success rates, the
investigator had unfortunate chances of witnessing software projects failing either
before completion and delivery or after implementation. This has raised the question,
―Why software projects are failing in government organization?‖

A failed software projects means despair and embarrassment for the project team, and
may ruin careers. Moreover, software project is difficult and expensive, and therefore
software projects failure means loss of economic resources. One study conducted
locally which addressed some aspects of this study, Mullualem (2014) investigate the
factors that lead to software projects failure in case of Addis Ababa. Some of the
limitations of his work are: He did not look the factors that lead software projects being
challenged and cancelled explicitly rather tend to generalize them as failure which
makes his findings difficult to emphasize as well as prioritize on serious problem.
Mullualem (2014), also did not look factor, from software companies, end users and
practitioner‘s perspectives explicitly. In addition, his study also didn‘t address which type
of software projects are cancelled, challenged and successful, which is important to

3
focus on specific project and where improvement can be made and lesson can be
learned. Moreover Standish (2004), investigated software project success/failure factor
and used only IT executive managers as respondents. Mahmood (2014), on his study
entitled reasons of software & IT project failures in Pakistan‘s Government sector, didn‘t
assess from end user, practitioners and software company perspectives and also
investigated cancelled and challenged software projects in general as failed. This
research has filled the gaps by assessing software projects failure in government
organizations from the perspective of software companies, practitioners and end users.
This study also contributed to the literature by assessing failed software projects by
categorizing as cancelled and challenged. Furthermore, the research also examined
which software projects in government organization are challenged, cancelled and
successful based on their project type.

Therefore, the study will address stated research questions.

 What are the reasons for software projects failure/success from software
companies, practitioners, and end users perspective in government organization
in Ethiopia?
 Which type of software projects are cancelled, challenged and successful in
government organization in Ethiopia?

1.3 Objectives of the study

1.3.1 General objectives of the study

The main objective of the study is to assess major factors for failure/success of software
projects in government organizations in Ethiopia.

1.3.2 Specific objectives of the study

The specific objectives of the study are:-

 To identify the major cancellation, challenge and success factors of software
projects from software companies, practitioners and end users perspectives in
government organization.

4
  To identify which type of software projects are cancelled, challenged and
successful in government organization.

1.4 Significance of the study

In today‘s dynamic and competitive environment, serving the public through software‘s
practices are a must for government organization to sustain and as well as to implement
government policies and strategies efficiently and effectively. The study is basically
designed to assess the major factors for failure of software projects. Hence, it is hoped
that the study will help project managers and higher authorities in Ethiopian government
sector to reduce the chances of software project failures by focusing on the major
reasons for the failure of software projects and identify precisely where improvements
can be made to enhance success rate of software projects. The finding also can serve
as a benchmark to assess software project failure in other sectors of the country.
Government organizations can also use the findings as an input to introduce software
projects directives in to the ICT sectors of Ethiopia. Moreover the finding will add value
to the existing body of knowledge on software projects failure i.e. it can be used as an
input for further research on software projects failure.

1.5 Scope of the study

The scope of this study was to identifying major success/failure factor for the software
project in government organization in Ethiopia particularly to ministerial office. Hence,
the study is limited to government organization and may not be generalized to private
sector.

1.6 Limitation of the study

One of the limitations of the study was only practitioners and end users in government
organization are included in the study, besides it would be more interesting if the
perspective of top level managers in the government organization was incorporated.

5
1.7 Operational definitions

 Practitioners: - are programmers, database developers, system analysts,

project managers, team leaders, etc. working in government organization under
department of ICT that support or maintain the software.
 End users: - are employees in government organizations who ultimately use or
are intended to ultimately use the software.
 Software companies: - also known as suppliers, are individual or companies
that sell or develop software to government organizations.

1.8 Organization of the study

The paper is organized under five chapters. The first chapter presented background of
the study, statement of the problem, objectives of the study, significance of the study,
delimitation of the study, limitation of the study, operational definition and organization
of the study. The second chapter deals with review of related literature. Chapter three
deals with nature of the study, source of data, study population, sampling techniques,
methods of data collection and data analysis. Chapter four deal with data analysis and
presentation of the findings of the study.

Finally, chapter five presents the conclusions drawn from the findings and the
recommendations made to address the problems.

6
 Chapter two

2. REVIEW OF RELATED LITERATURE

The purpose of this chapter is to present, discuss and consider the major reasons for
software projects failure/success. Topics to be considered include the relevant history of
software projects failure, effects of software projects failure and finally government
organizations and software projects failure. The base of success and failure reasons is
expanded with the traditional research materials available.

2.1 Software projects success / failure

Despite extensive research into successful software development many software

development projects are still failing. In 1994, 31% of all corporate software
development projects result in cancellation. Amore recent study found that 20% of
software projects failed, and that 46% experienced cost and schedule overruns or
significantly reduced functionality (Procaccino, 2001). Looking at what is meant by
project failure and abandonment, (May,1998), views it from practitioners‘ perspective
as any software project with severe cost or schedule overruns, quality problems, or
suffers outright cancellation. But Ewusi-Mensah & Przasynski (1991) see failure as the
consequence of dwindling expectations of the implemented system and abandonment
as temporary or permanent discontinuation of a project under development.

Rothman (2008) argues that the project has been stopped permanently meaning that it
is killed for life and will not be revisited or restarted again. Whether it is killed permanent
or put on the parking lot, what we mean by abandoning the project is that the
development of that project has been stopped and no budget or resources is assigned
to it as of now. Major modes of software projects failure are late delivery or never
completed poor reliability, cost overrun and user dissatisfaction for exhibiting poor
performance characteristics i.e. failing to meet the requirements (Brooks, 1975). The
actual costs of software projects often greatly exceed the estimated cost. Other projects
are completed within time and cost but do not provide full user satisfaction. The skillful

7
integration of software technology, economics and human relations in the specific
context of a software projects is not easy. For purposes of the study, projects were
classified into three types (Standish, 1995):
Successful software projects: the projects are completed on time, on budget, with all
features and functionality as initially specified.
Challenged Software projects: the projects are completed and operational but over
budget, over the time estimate, and offer fewer features and functions than originally
specified.
Impaired software projects: projects are cancelled at some point during the
development cycle.

The combination of challenged and impaired projects will be considered to constitute as

failure, by the Standish Group.

2.2 Software projects success / failure rate

During the literature survey on projects failure statistics it became evident that various
information technology software projects studies have been conducted, and that the
result varied significantly. This significant is supported by Doresy (2001), who claims
that information system projects are a catastrophe and frequently fail. Depending upon
which academic study is referenced, the failure rate of large projects is reported as
being between 50% and 80%. This occurs because of the natural human tendency to
hide bad news, and consequently the real statistic may be even higher. This is
supported by Glass(2001), in a summary on his book "computing calamities: lessons
learned from products, projects, and companies that found that found that several
computing surveys are detailed in literature stating that 57%,or 68%,or 95% of
computing projects fail.

According to Mullualem (2014), the ratio of successful versus failed software is 57% and
43% respectively but they consider challenged projects as successful and also most
respondents are not able to differentiate challenged with failed projects.

8
 Figure 2.1 Ratio of successful to failed projects

Ratio of succesful to failed projects

43%

Successful
57%
Failed

Source: Mullualem (2014)

The Standish Group also made intensive research by category to identify, successful
software projects, challenged Software projects, failed software projects as shown
below,

Table 2.1 Software projects failure statistics

Source: Standish chaos report-2009

Failure of software and services projects is so widespread and so commonplace that 43

percent of IT managers say their business managers and Boards of Directors tend to
accept faulty IT projects as a normal, necessary evil, according to the Dynamic Markets
Limited study. For a number of reasons, business-critical software and services projects
whether done in-house or outsourced fail far too often. They take too long. They cost
too much. They are riddled with defects and don‘t accomplish the business goals for

9
which they were designed: An August 2007 study by Dynamic Markets Limited of 800 IT
managers across eight countries found:

• 62 percent of organizations experienced IT projects that failed to meet their schedules

• 49 percent suffered budget overruns
• 47 percent had higher-than-expected maintenance costs, and
• 41 percent failed to deliver the expected business value and ROI

Projects failures are associated with the risks embedded in software projects
environment (Kwak & Stoddard, 2004). Previous researches have investigated the
relationship between risk and projects failures. For instance, McFarlan (1981) has
concluded that failure to assess individual projects risk and adapt management
methods accordingly is a critical source of software projects failure. Different types of
risks will affect budget, user satisfactions and system performance (Jiang & Klein,
1999).

Another key finding of the survey is that a high percentage of executive managers
believe that there are more projects failures now than five years ago and ten years ago.
Despite this the fact that technology has had time to mature

Table 2.2 Software projects failure in years

Than 5 Years Ago Than 10 Years Ago

Significantly More Failures 27% 17%

Somewhat More Failures 21% 29%

No Change 11% 23%

Somewhat Fewer Failures 19% 23%

Significantly Fewer Failures 22% 8%

Source: Standish Group 1995

10
As study shows even there are different regarding figures on percentage of Software
Projects failure but we can see that the failure percentage is very high.

Table 2.3 Summary of software projects cancellation rates

Study, year, and location Cancellation/abandonment rate (%)

Standish Group, 1994,US 31
Standish Group, 1996,US 40
Standish Group, 1998,US 28
Jones, 1998, US(Systems projects) 14
Jones,1998,US(Military projects ) 19
Jones,1998,US(other projects) >24
Standish Group, 2000,US 23
Standish Group, 2002,US 15
Computer Weekly, 2003,UK 9
UJ,2003, South Africa 22
Standish Group, 2004,US 18
Standish Group, 2006,US 19
Source: (Adapted from Emam and Koru 2008, P85)

2.3 Major factor for software projects failure

The reasons for challenged, cancelled and success factors, from the Standish Group
will be used supplemented by additional reasons for failure found in the available
research. The Standish Group was formed in 1985 with a vision of innovating group
refection using case-based reasoning techniques. For over 30 years The Standish
Group has been researching and providing advice on how to increase the value of
software investments with research database of 50,000 projects has been done. Major
factors for the failure of software projects are discussed below:-

11
1. User involvement

Standish Group (1995), survey concluded that lack of user input was rated by 12% of
respondent as the number 1 reasons for project being cancelled. Without user
involvement you cannot feel committed to the product, to avoid the reason of project
failure, Even if the projects meets specifications and delivered on time and within
budget, if end user are not willing to use it, the project will fail (Earnshaw, 2001).
Senior management needs to establish a working environment in which the end users
can actively participate in the project and communicate with the team. Then, project
expectations will be clear and right priorities will be set up. Therefore senior
management need to continuously support the project to make it clear to staff it is a
priority.

2. Unclear goals and objectives

Should the project objective not be defined in clear terms, the project team has no
direction and guidance as to what to deliver at the end of the project, resulting in the
project being termed a failure. Many projects are elaborated progressively and in these
scenarios project managers rely on rolling wave planning. As a result, the goal of a
project may be only partially clear due to a poor requirement gathering in the definition
stage of the project. In such case, the scope and schedule developed by Project
managers cannot possibly be accurate because their objectives are unclear. Defining
clear requirements for a project can take time and lots of communication (Alagarsamy &
Rajkumar, 2013). The study by Standish Group (1995), unclear objectives was rated by
5.3% of respondents as the number 8 reasons for projects being challenged.

3. Incomplete requirement and specification

In survey conducted by the Standish Group (1995), incomplete requirement was rated
as the number one reasons for projects being impaired. One of the root causes of IT
project failure is not properly defining the project at the very beginning (Rodgers, 2001).
Project failure due to poor requirements management takes place when the project
team delivers the product without having a clear understanding of what the customer

12
wants and without having any real knowledge of the requirements. When the product is
produced, the customer does not like it because the requirements have not been met,
and this becomes one of the reasons for project failure. Poorly set requirements and
lack of requirements understanding are closely linked to lack of customer involvement
(Alagarsamy & Rajkumar, 2013).

4. Lack of resources

Projects may also fail due to a lack of resources. Every project needs resources. How
much and how many depends on the size and scope of the project. Like most project
managers can attest, working on projects with scarce resources is not all that unusual.
Management will always invariably try to minimize costs while working with maximum
productivity. Projects running somewhat ‗lean‘ are not an unknown in project
management circles. However, there are situations where the project is simply
unattainable because the allocated resources are insufficient. In those types of
situations, it may be a case whereby key personal required for project success are just
made not available (Alagarsamy & Rajkumar, 2013). The study by Standish Group
(1995), concluded that lack of resources was rated by 6.4% of respondents are the
number 6 reason for projects being cancelled.

5. Poor communication

Goldstein (2001), survey found that poor communications was one of the causes of
project failure. Projects sometimes fail due to improper communication. The projects
usually impact a large amount of people. This requires constant communications to all
levels of people throughout the organization. A strong communication strategy can help
with this. Alagarsamy & Rajkumar (2013), many large projects are so complex that
these projects always require large amount of analysis and work. The project teams are
busy doing the analysis, creating WBS, time estimation etc. and project managers do
not communicate progress regularly because they believe that progress will not be seen
by the executive management or they fear of improper reporting.

13
6. Lack of planning

A plan is roadmap that steers the project team to final project compilation. The study by
Standish Group (1995) concluded that lack of planning was rated by 8.7% of
respondents as the number 7 reasons for project being impaired.

7. Didn't need it any longer

This relates to projects being cancelled at any point of the project life cycle because the
company executives decide that the project is not needed anymore. According to the
Standish Group (1995), concluded that the users did not need the solution were rated
by 7.5% of respondents as the number 8 reasons for projects being impaired.

8. Lack of executive support

When executives are not seen or are not actively supporting a project, a subsequent
lack of executive support occurs. Scotts (2000), all too often IT objectives are missed
through lack of senior management support and a failure to create the right environment
to maximize the impact of IT. The study by Standish Group (1995) concluded that 7.5%
of respondents indicated lack of executive support as the number 4 reasons for projects
being impaired.

9. Changing requirement and specification

Changing requirement and specifications occur when the users depart from the
requirement and specifications originally specified at the stat of the project. Taylor
(2001), in his research on IT project failure found that unclear objectives and
requirements were the number one reasons why projects fail. The finding by Standish
Group (1995) concluded that changing requirement was rated as the number 3 reasons
for projects being challenged.

10. Lack of IT management

Without the presence and support of IT management, projects are destined to failure.
The study by Standish Group (1995), concluded that lack of information technology

14
management was rated by 6.2% of respondents are the number 9 reasons for projects
being impaired.

11. Poor risk management

Risk management is an important factor towards software project failure if it‘s not
managed timely and effectively. As nothing can be predicted that what will happen in
future so we have to take the necessary steps in the present to take any uncertain
situation in the future. Risk management means dealing with a concern before it
becomes a crisis (Alagarsamy & Rajkumar, 2013).

12. Unrealistic expectations

Expectations that are set too high result in the client not to receive the expected
product, resulting in the project being classified a failure. Projects with unrealistic
expectations are also about equally likely to be poorly managed projects that fail to
validate the feasibility of satisfying user expectations, or well-managed projects that try
to validate feasibility and find unavoidable factors such as immature technology, a
saturated market that justify a project‘s prompt termination(Alagarsamy & Rajkumar ,
2013). The Standish Group (1995), survey concluded that unrealistic expectations were
rated by 5.9% of respondents as the number 7 reasons for projects being challenged.

13. New technology

New Technology, occur when the organization does not have the necessary skills to
deal with technology. Rodgers (2001), time to time again companies are implementing
project that involve new technologies. Often these projects are created just so the
company can stay up to date with the latest technologies, but fail to recognize that the
newest technologies are also the immature technologies. According to Standish Group
(1995), that technology incompetence was rate by 7% of respondents as the number 5
reasons for projects being challenged.

15
14. Unrealistic timeframes

The timeframes for project implementation should be agreed at the start of a project and
most critically, the timeframe should be realistic. An unrealistic timeframe will most
certainly result in a failed project. The survey by Standish Group (1995), unrealistic time
frames was rated by 4.3% of respondents as the number 8 reasons for project being
challenged.

According to, Ibrahim et al. (2013), major factors for software project is described as
follows:-

1. Poor top management support

Top management is expected to provide support in the areas of committing to any IT

project, sufficient financial and human resource, and the resolution of political problems
if necessary. As an Example: limited financial support contributed to a rushed ERP
implementation process project team members were overloaded and thus high staff
turnover rate, ineffective knowledge transfer, and political problems occurred.
Insufficient commitment could lead to political problems which hindered the
implementation process.

2. Poor consultant effectiveness

Consultants were considered by successful project team members to be inexperienced

and unable to provide a professional level of advice IT project planning. Consultants
may communicated ineffectively during the project phase due to language barriers, and
only suggested workarounds without applying professional skills to conduct IT projects.

3. Poor project management effectiveness

Failure to plan, lead, manage and monitor the project was a core factor that resulted in
software project implementation failure, because the IT project was complex, and this
factor explain project manager‘s competence as key to success of the project. A
competent manager has the technical capability and monitoring capabilities. He makes

16
his people committed for the project through effective leadership and by acting in
nonpartisan ways. He shows his trust in his project team by way of delegating the
authority to his team. He organizes resources through constant persuasion with his
higher ups, he takes active part in construction control meetings held at site level, and
he acts as a catalyst in training his human resources in the skill demanded by the
project. All these attributes can be thought of originating from project managers‘
competence, hence the name. Project teams were required to collaborate with top
management, different departments, users and consultants during implementation
process. The ERP project was considered by the project managers to be challenging
and demanding, as it involved managing systems, people (project team, users and
external consultant) as well as re-designing business processes.

4. Lack of user involvement

Lack of user involvement has proved fatal for many projects. Without user involvement
nobody in the business feels committed to a system, and can even be hostile to it. If a
project is going to be a success, senior management and users need to be involved
from the start, and continuously throughout the development. This requires time and
effort, and when the people in a business are already stretched, finding time for a new
project is not high on their priorities. Therefore senior management need to continuously
support the project to make it clear to staff it is a priority.

According to Mullualem (2014), the major causes of software projects failure in ranking
order are lack of projects management, lack of stakeholder involvement, lack of top
management involvement and support, lack of resources/budget, communication failure
lack of project planning, technology illiteracy, lack of quality management, and lack of
proper organizational structure.

17
Figure 2.2 Major causes of software projects failure

Major causes of software project failure

90% 80%
80% 70%
70% 60% 60% 60%
60% 50% 50%
50%
40% 30% 30%
30%
20% 10%
10%
0%
management…

organizational…
Job loss

Lack of quality
Bad press/media

Lack of stakeholder
Communication

Lack of proper
Lack of project

Lack of project

Technology illiteracy

Management

other
management

Lack of top
planning

involvement
publicity
failure

Source: Mullualem (2014)

2.4 Major factors for software projects success

According to Dorsey (2001), there do seem to be three factors that all successful
projects have in common. Each of these factors is a key to any project‘s success. Each
project can be viewed as a tripod. All three legs must be in place for the tripod to stand
sturdily. In a systems project, these ―legs‖ or critical success factors consist of the
following:

1. Top management support

2. A sound methodology
3. Solid technical leadership by someone who has successfully completed a similar
project. Without each of these solidly in place, the tripod will topple and the project
will fail.

18
According to Jones (1995), the following are major factors associated with success of
project. The factors that have observed as the most significant include:

 Effective projects planning

 Effective projects cost estimating
 Effective projects measurements
 Effective projects milestone tracking
 Effective projects quality control
 Effective projects change management
 Effective development processes
 Effective communications
 Capable projects managers
 Capable technical personnel
 Significant use of specialists
 Substantial volume of reusable materials
Success factors also summarized by different authors' as explicit and implicit factor as
follows;

Table 2.4 Explicit success factor

Explicit success factor

 Well defined projects objective (Purba et al, 1995)
 Find a projects sponsor /champion (Johnson, 2001; The Standish Group, in
Procaccino et al, 2002; Field, 1997, in Reel, 1999)
 Implement a post-mortem analysis (Reel, 1999)
 Ensure effective communication between all parties (Matheson and Tarjan ,1998;
Purba et al, 1995)
 Build the right team (Reel, 1999)
 Experienced projects manager (Johnson, 2001; Purba et al, 1995)
 User involvement is necessary in the development process (Amoako- Gyampah &
white, 1997, in Procaccino et al, 2002; Giglio, 1999;Paulk, Curtis, Chrissis and
Webster,1993,
 The user is knowledgeable and is authorized to make decisions (Rakos, 1990).
 Involve the user in the RE process (Rakos, 1990)
Source: Little, (2003)

19
Table 2.5 Implicit success factor

Implicit success factor

• The ability to make good decisions (Reel, 1999, Purba et al, 1995)
• Give the development team ownership(Giglio, 1999; Rettig, 1990)
• User resistance and communication (Saiedian and Dale, 2000; Reel, 1999)
• The use of a formal methodology (Johnson, 2001)
• Realistic estimations (Johnson, 2001)
• Set up realistic deadlines (Field, 1997, in Reel, 1999; Glass, 1998)
• Allocation of roles to team members (Rakos, 1990; Constantine, in Rettig, 1990)
• Establish basic requirements (Johnson, 2001)
• Complete and accurate requirements from the start (Procaccino et al, 2002)
• Changes in requirements (Duvall, 1995)
• Incorporate effective software measurement into the process (Paulish and Carleton,
1994; Capers Jones, 1995)
• Routines for effective quality control –design reviews, code inspections-(Capers
Jones, 1995)
• Use software tools (Rakos, 1990; Capers Jones, 1995)
• monitor progress( Capers Jones, 1995; Reel, 1999)
• Minimize the scope of the projects (Johnson, 2001)
Source: Little, (2003)

20
2.5 The effect of software projects failure

Software projects end up a failure, it can have numerous impacts on an organizations.

But most organization gives more attention for financial losses even if failing to look
other effects may harm the existence of the organization (Mullualem, 2014).

Figure 2.3 Effects of software project failure for organization

Effect of software project failure

100% 90%
90% 80% 80%
80% 70%
70% 60% 60%
60%
50% 40%
40%
30%
20% 10%
10%
0%
Financial Loss

Job loss
Time Loss

Other
perfromance/moral

Depletion of Asset

Loss of shareholder

Bad press/media publicity

Lowering of

confidence

Source: Mullualem(2014)

A cancelled software project is usually an unwanted situation which means loss of

economic resources, despair, and embarrassment. A large cancelled software project
may ruin careers and even exterminate companies (Ahonen & Savolainen, 2010). The
possibility of software projects failing can be attributed to various reasons - costs,
scheduling and quality issues, and/ or achievement of objectives. The costs of software
projects failure are various. Economically, there is the cost of wasted investment in

21
equipment and labor. There is also the cost of missed opportunities when system
promises benefits or fails to provide them. The fact of failure has also caused damage
to the image of the information system community. For all these reasons, then, failure is
worth investigating, understating, and where possible, avoiding (Sauer, 1993).

The Standish Group estimates that in 1995 American companies and government
agencies will spend $81 billion for cancelled software projects. These same
organizations will pay an additional $59 billion for software projects that will be
completed, but will exceed their original time estimates. Risk is always a factor when
pushing the technology envelope, but many of these projects were as mundane as a
driver‘s license database, a new accounting package, or an order entry system.

Table 2.6 Failed software projects failure and their cost from 1992-2005

Year Company Outcome(costs in US $)

2005 Hudson Bay Problems with inventory system contributes to$33.3
Co.[Canada] million *loss.
2004- UK Inland Revenue Software errors contribute to $3.45 billion*tax-credit
05 over payment
2004 Avis Europe Plc[UK] Enterprise resource planning (ERP) system cancelled
after 54.5 million is spent
2004 Ford Motor Co. Purchasing system abandoned after deployment
costing approximately $ 400 million
2004 J Sainsbury PlC[UK] Supply-chain management system abandoned after
deployment costing $527 million
2004 Hewlet-Packard Co. Problems with ERP system contribute to $160 million
loss
2003-04 AT & Wireless Customer relations management(CRM) upgrade
problems lead to revenue loss of $100 million
2002 McDonald's Corp. The innovation information-purchasing system
canceled after $170 million is spent

22
2002 Sydney Water Billing system canceled after $33.2 million is spent
Corp.[Austrila]
2002 CIGNA Corp. Problems with CRM system contribute to $445 million
2001 Nike Inc. Problems with supply-chain management system
contribute to $100 million loss.
2001 Kmart Corp. Supply-chain management system canceled after $130
million is spent
2000 Washington, D.C City payroll system abandoned after deployment
costing $25 million
1999 United way Administrative processing system canceled after $12
million is spent
1999 State of Mississippi Tax system canceled after $11.2 million is spent; state
receives $185 million damages.
1999 Hershey Foods Corp. Problems with ERP system contribute to $151 million
loss
1998 Snap-on Inc. Problems with order-entry system contribute to revenue
loss of $50 million.
1997 U.S Internal Tax modernization effort canceled after $4 billion is
Revenue Service spent.
1997 State of Washington Department of motor vehicle (DMV) system canceled
after $40 million spent.
1997 Oxford Health plans Billing and claims system problems contribute to
Inc. quarterly loss; stock plummets, leading to$3.4 billion
loss in corporate value.
1996 Arianespace[France] Software specification and design errors cause $350
million Ariane 5 rocket to explode.
1996 FoxMeyer Drug Co. $40 million ERP system abandoned after deployment,
forcing company into bankruptcy
1995 Toronto Stock Electronic trading system canceled after $25.5 million is
Exchange spent

23
1994 U.S federal aviation Advanced automation system canceled after $2.6
administration billion is spent
1994 Chemical California DMV system canceled after $44 million is spent
1993 Chemical Bank Software error cause a total $15 million to be deducted
from 100,000 customer accounts
1993 London stock Taurus stock settlement canceled after $600 million is
exchange[uk] spent
1993 Allstate Insurance Office automation system abandoned after deployment,
Co. costing $130 million.
1993 London Ambulance Dispatch system canceled in 1990 at $11.25 million;
service[uk] second attempt abandoned after deployment,
costing$15 million
1993 Greyhound Lines Bus reservation system crashes repeatedly upon
Inc. introduction, contributing to revenue loss of $ 61 million
1992 Budget rent-a-car, Travel reservation system canceled after$165 is spent
Hilton hotels Marriott
international, and
AMR[American
Airlines]
Sources: Charette, (2005)

2.6 Software project success / failure from software companies’, practitioner s and
end users perspectives

When software is developed through a contractual project there are parties which have
different perspectives and different goals (Collins & Baccarini, 2004; de Wit, 1988;
Sadeh, Dvir, & Shenhar, 2000; Taylor, 2007). Furthermore, the supplier has the
responsibility to develop software for the customer, and at the same time the project is a
way of making business for the supplier. Therefore, it is not straightforward to convey
how a supplier perceives the software development project failure.

We also recognize that all stakeholders of a development projects have important

perspectives on success and what they would like to achieve through the completion of
24
a particular projects, including the development team, senior management, customers
and end-users. It has been suggested that most projects managers do not understand
how to define a successful projects or how to characterize projects success (Bennatan,
2000; Kanter, 1988; Linberg, 1999). A common perception is that a successful project
satisfies business goals and meets its schedule (Baccarini, 1999; Linberg, 1999; Pinto &
Slevin, 1988; Wohlin et al., 2000; Wohlin & von Mayrhauser, 2000). However, research
has shown that whether a project is viewed as a success or failure depends on the
perception of the person viewing the projects (Pinto and Mantel, 1990; Wateridge,
1995). Consequently, a single projects may be considered successful by one
stakeholder and a failure by another (Naquin,Tynan, Charles, & Renee, 2003; Walsh &
Schneider, 2002).Studies such as (Glass, 1999; Procaccino & Verner, 2002) highlight
stakeholder deference's when they are asked about their perceptions of the successor
otherwise of a projects.

According to Linberg (1999), investigation software development projects are composite

case. Further investigation shows differences in management and developer
perceptions of the success/failure or otherwise of projects and the prediction of projects
success/failure from the viewpoint of both groups. We find that both managers and
developers consider the level of customer and user involvement contributes most to
projects success.

The software development projects involve several classes of participants (customer,

developer, user and maintainer). Each of them has specific satisfaction criteria. Thus,
the definition of "unsatisfactory outcome" is multidimensional (Boehm, 1991).

Developers perceive the next most important factors to be: (i) that customers and users
have realistic expectations and (ii) the scope of the projects is well defined. On the other
hand, to predict success from management‘s viewpoint, participation of customers and
users in estimating projects schedules is significant. Management, who is paying for the
projects, has its own view of what constitutes successful projects. In some cases this
view is different from that of the developers, while users may take another view
(Linberg, 1999).

25
Even though there is a tendency among projects managers to focus on the technical
issues involved in software development, including those related to hardware and
software (such as programming language and compilers) (DeMarco & Lister, 1999), the
cause of most projects failures has little to do with technological issues (DeMarco 1991;
McConnell 1996; Warne & Hart 1996; Linberg 1999; Sumner 1999; DeMarco & Lister,
1999]. Although research suggests that failed projects suffer from the poor management
of people-related problems rather than technical problems (DeMarco 1991; McConnell
1996; Linberg 1999; Sumner 1999; DeMarco & Lister, 1999), it is important to analyze
projects failures from all perspectives. Poor software development practices places
organizational resources, such as time, money and the pool of software practitioners
(programmers, database developers, system analysts, etc.) at risk. Practitioners
become burned out, de-motivated and are likely to have decreased personal
productivity (Procaccino, 2002).

2.7 Government and software projects failure/success

Today IT has a key role in all fields of life and the concept of E-Government has evolved
in the last 10 years. In today‘s modern world, a successful Government cannot be run
without the support of Information Technology; Software and Database systems
(Mahmood, 2014). According to, Charette (2005), software failure in government can
endanger national security, and also failures can also stunt economic growth and quality
of life.

Government software projects seems to have an endless capacity to go wrong and it

seems that we never learn. The same mistakes are repeated over and over again and
most of the time they lack close follow-up of their operationally.

The UK government spent some billion on IT in 2009, and the public sector seems to
make less effective use of IT compared to the private sector, according to (PASC,
2011). PASC points out that continuing IT mismanagement in public sector is leading to
severe project failures and waste of taxpayers‘ money.

26
All branches of the government and public sector rely on software to manage and
analyze the massive amounts of data they collect on a daily basis. With each
department managing thousands to millions of people‘s data and individual needs, it is
no surprise that a public sector institution requires a robust software system. Whether
the task is allocating welfare and medical assistance checks on a monthly basis,
collating and processing travel visa applications, or properly tallying votes to determine
the outcome of an election, software lies at the heart of every organization‘s ability to
fulfill their duties to their public. Unfortunately however, all of this means that a
breakdown in the software can bring crucial public services grinding to a halt (Chelsea,
2014). Government software projects will never succeed as long as they are treated like
construction projects, run by multiple competing departments, tied to political timelines.
Many projects management tools and techniques have been developed to reduce the
risk of an IT projects failure but some serious policy making at government level is
required to reduce the software & IT projects failures. Government offices should not be
influenced by the elected politicians (Mahmood, 2014).

According to Mahmood (2014), there are 8 factors for the failure of software projects in
government sector particularly in Pakistan. These are lack of skilled professionals, low
pay, job security, experiences has no worth, over workload on skilled persons, over
workload skilled persons, organizational politics, lack of leadership, are the major
factors for software projects failure.

27
2.8 Summary of related works

Table 2.7 Summary of related works

Author Objective Method Finding Remark

Mullualem Assessment Quantitative -Lack of project -Doesn’t show which type of software
(2014) of major research management, lack of projects are cancelled, challenged &
factors that project planning, successful in terms of project type.
leads to communication failures
-The study does not show objectively
software as top reason for failure
the reasons for software projects being
projects of software project.
challenged, cancelled & successful
failure:
explicitly.
A case Study
of Addis -The perspective of software
Ababa company, end users & practitioners
were not addressed independently.
-Small sample size.

Standish The Mixed -The three major -The study only presented the factors
(2004) Standish Approach reasons for software that lead software project
Group project to be challenged success/failure only from IT
Report are lack of user input, executive manager’s perspective.
CHAOS incomplete
requirements & -The study didn’t also look which
specifications, & type of software projects are
change requirements & successful, challenged and cancelled.
specifications.

-The three major

reasons that lead
software projects
cancellation are
incomplete
requirements, lack of
user involvement and
lack of resources.
Mahmood Reasons of Qualitative -Lack of skilled -The study does not show objectively
(2014) software & professionals, low pay, the reasons for software projects
IT project job security, being challenged, cancelled &
failures in experiences has no successful explicitly.
Pakistan’s worth, over workload
government on skilled persons, over -Doesn’t show which type of
sector workload skilled software projects are cancelled,
persons, organizational challenged and successful in terms of
politics, lack of project type.
leadership, are the
major factors for -The perspective of software
software projects failure companies, end users &
practitioners were not addressed.

28
 Chapter three

3. RESEARCH DESIGN AND METHODOLOGY

3.1 Introduction

This chapter covered the nature of the study, research design, sources of data, study
population, samples size, sampling techniques, instrument for data collection, and
methods and tools of data analysis.

3.2 Research methodology

3.2.1 Research design

Research design is a blue print to conduct a research study, which describes what
research approach (methodology) to follow, the target population, sample size and
method, and tools of data collection and analysis used to answer the research question.
In general the function of a research design is to ensure that the evidence obtained
enables the researcher to answer the research questions as unambiguously as possible
(Kotari, 2004). In this research descriptive research specifically survey research was
used, because it enables the researcher to describe the current state of software
projects failure at sample government organization. Moreover Zegeye et.al. (2009)
stated that ―Surveys gather data at a particular point in time with the intention of
describing the nature of existing conditions, or identifying standards against which
existing conditions can be compared.

3.2.2 Research methodology/approach

The selection of research approach is depends on the research problem, research

questions and the objectives of the research. According to Kotari (2004) there are three
approaches to conduct a research: qualitative, quantitative and mixed approaches.
Quantitative approach involves the generation of data in quantitative form which can be

29
subjected to rigorous quantitative analysis in a formal and rigid fashion. Qualitative
approach to research is concerned with subjective assessment of attitudes, opinions
and behavior. Research in such a situation is a function of researcher‘s insights and
impressions. Mixed approach utilizes the strengths of both qualitative and quantitative
research. In this research, a combination of quantitative and qualitative methods were
used.

3.2.3 Source of data

The study used both primary data and secondary sources of data. The primary data
were collected from practitioners and end users working in government organization,
and software companies through questionnaire and interview. For background
discussion and literature review, secondary sources of data also utilized from various
publications, different journals, books, and articles related to the subject under study
and other online materials.

3.2.4 Study population

The total populations in the study are 22 government organization established under
ministerial level and 79 software companies who have experience in working for
government organization.

3.2.5 Sampling method and techniques

For quantitative study, probability sampling method, incorporating simple random

sampling was used to identify the 12 government organizations and 12 software
companies. The reason for using probability sampling particularly simple random
sampling approach is:
 The governments organizations are formed through law, therefore, the name and
contact information of the populations sample were readily available.
 Since the software companies are registered organizations in Ethiopia, the
participating companies were also available.

30
Regarding respondents, from each governmental organization two practitioners and two
end users were selected. From practitioners and end users side the study involved
respondents with at least one software project development experience to respond on
success and failure factors using purposive sampling specifically expert sampling.

For the qualitative study, senior ICT staff are selected and interviewed to gather their
experiences and insights. Purposive sampling technique is used to select senior
members of ICT staffs. The researcher selected the interviewees purposefully who are
believed to be appropriate key informants for the study.

3.2.6 Sample size

For quantitative study, from total of 22 governmental organization established under

ministry level 12 were taken as sample which means 54% from total population.
According to Creswell (2013), in the survey research, it is logical to take 10% of the
population as a sample. In addition, the data from ministry of trade shows that, there are
about 280 registered software companies but out of which only 79 have experience
working for the government organization, therefore from the available lists 12 which
means 28% from the total population were randomly selected. Thus, from each
governmental organization two practitioners and two end users was selected. From
practitioners and end users side the study involved respondents with at least one
software project development experience to respond on success and failure factors
using purposive sampling specifically expert sampling. And, in preliminary survey most
software companies total population is not more than 10, therefore, two respondents
were selected randomly from each software companies. Therefore, from both
government organizations and software companies‘ total samples of 72 respondents
were taken to represent total population for quantitative data gathering.

31
For the qualitative study, based on the researcher‘s subjective judgment, the sample
size was initially determined to be 5. Later in the process, the data was saturated after
four selected key informants are interviewed. According to Creswell (2007), saturation is
the concept of analyzing the collected data and come in to a point at which the
researcher can no longer find new information that adds value with respect to the
intended goal. Hence, the interview is quitted after the four senior members are
interviewed. Accordingly, the selected key informants are: 2 ICT directors, 2 software
development team leaders from government organization.

3.2.7 Instrument for data collection

The instruments used for collecting the required data were questionnaire and interview.
Self-completed questionnaires were administered to software companies, practitioner
and end-users. Questionnaire was preferred because it is an efficient and economical
way of gathering data from a large number of respondents anonymously (encourage
respondents to provide genuine information) as well as relatively easy to analyze the
data (Kotari, 2004; Zohrabi 2013). The data collection instrument was mainly developed
from a synthesis of literatures that are relevant to meet objective of this study. Ranking
questionnaire was used to obtain data from practitioners, end users and software
companies. Content validity of questionnaire has been conducted. According to
Kerlinger & Lee (2000), validity can be measured in the form of content and construct.
Content validity assesses how well the survey instrument items address the problem
being investigated. The instrument was revised based on the subject matter experts‘
feedback. Content validity of the questionnaire was conducted by 2 University lecturer,
2 practitioners, 2 end users and 2 software companies. The objective of the content
validity was to test whether the survey instrument provided consistent and accurate
information. Accordingly, modifications were made on the questionnaire items based on
the feedbacks; in order to reduce bias and maximize response rate. Most of the
feedbacks were related to the layout of the questionnaire and the language used such
as simplifying specific jargons and phrasing of various items. As a result, a total of 72
questionnaires were distributed to the respondents.

32
Another instrument for data collection used in this study was Interviews. The interview
outline was prepared with a list of subjects and questions drawn from the questionnaire
Interviews are well suited when looking for opinions, experiences and privileged
information from respondents in key positions (Creswell, 2007). In addition semi-
structured interview questions were also used. Semi-structured interview was preferred
because it enables the researcher to elicit a great amount of firsthand data from
knowledgeable key informants like ICT directors or parallel position (Zohrabi, 2013).

3.2.8 Procedures of data collection

The survey was implemented using a paper-based questionnaire to obtain a better

response rate. This kind of data collection approach was preferred in order to provide
briefing about the objective of the survey. Moreover, it helped to conduct appropriate
follow-up reminders and support the respondents in any queries they had regarding
the questionnaire items. Accordingly, the questionnaire was hand delivered to 72
selected respondents physically by the researcher. Subsequently, continuous follow-ups
conducted through phone and also visit to encourage the respondents to finalize the
questionnaires timely with their genuine feedbacks. Because of a close follow-up all
questionnaires has been returned.

The interviews were conducted in the interviewees‘ preferred places in order to keep the
comfort of interviewees. The interview was started by a brief introduction regarding the
objective, scope and expected benefits of the study. Next to this, interview has been
conducted based on the prepared outline.

3.2.9 Methods of data analysis

After data were gathered and coded, Statistical Package for Social Sciences 20 (SPSS)
and excel computational techniques were used for the analysis. The data collected
through questionnaires were analyzed quantitatively. Findings were tabulated and
represented in descriptive figures and tables. The findings are presented inside the
body with reference. Position of respondents and major factors for success/failure of

33
software projects are analyzed through SPSS. Effects of software projects,
respondents experience in software projects, ratio of successful to failed software
project, ratio of software projects success /failure in terms of project type has been
analyzed through MS-Excel.

The qualitative data which were collected through interview was coded and analyzed
using open coding method. Then the result was verified by the respondent and
presented. To sum the survey result, analysis of the quantitative and qualitative data
was triangulated and complemented each other to answer the research questions.

3.2.10 Summary of the methodology

The purpose of the study was to assess the major factors for the failure of software
projects in government organization in Ethiopia. Combination of quantitative and
qualitative methods is used to collect and analyze data. Primary data was collected
using self-administered questionnaire and semi-structured interview. The quantitative
data which was collected using questionnaire was analyzed using SPSS and MS-Excel
software‘s. The quantitative data complemented and triangulated with data from
qualitative data which was collected through interview and analyzed using open coding
to answer the research questions.

34
 Chapter four

4. DATA PRESENTATIONS, ANALYSIS AND DISCUSSIONS

In this part the results of this study was presented and analyzed. The part of the study
began with an analysis of the features of sample population with regard to Educational
background. Next, analysis using descriptive statistics with respect to the different
perspective of software projects and effects of software projects failure were described.
Finally, factors for success and failure of software projects will be presented.

4.1 Quantitative data presentation and analysis

4.1.1. Respondents profile

Educational background will help to assess level of respondents in sample population

who are supposed to be studied. Educational variable of sample respondents are
presented in the following way.

Table 4.1 Respondent‘s profile

Educational level Frequency Percent

Certificate 1 1.4
Diploma - -
BA/BSC/BED 58 80.6
MSC/MA 13 18.1

Source -Survey Data (2016)

As we can see from the table 4.1, the maximum numbers of the selected respondents
were BA/BSC/BED degree holders with 80.6%, 18.1% of them were MSC/MA holder,
1.4 % of the respondents were certificate holder.

35
 4.1.2. Position of respondents

While gathering information the research has looked the appropriateness of expertise‘s
participated in the study, particularly to software project participation.

Table 4.2 Position of respondents

Position Frequency Percent

ICT head/director 4 5.6
Project manager/leader 7 9.7
Database Administrator 5 6.9
System Analyst 4 5.6
Programmer 17 23.6
System Administrator 2 2.8
Team Leader 5 6.9
Network Engineer 3 4.2
End users 24 33.3
Other 1 1.4
Total 72 100
Source -Survey Data (2016)

Table 4.2 shows that, from the respondents 24(33.3%) are end users, 17(23.6%) are
programmers, 7(9.7%) are project manager, equally 5(6.9%) are database administrator
and team leader, and equally 4(5.6%) are ICT head/director and system analyst,
3(4.2%) are network engineer, and 2(2.8%) are system administrator. From this we can
deduce that the majority of the respondents participated are the appropriate to the study
population.

36
 4.1.3. Different perspective of software projects

4.1.3.1 Experience in software projects (in terms of number of projects)

Figure 4.1 Number of projects respondents participated

90%
79%
80%

70%

60%

50%

40%

30%

20%
11%
10% 6%
3% 1%
0%
1-5 6-10 11-15 16-20 >20

Source- Survey Data (2016)

In Figure 4.1, respondents were asked in how many software projects did they
participated. Accordingly, majority respondent 57(79.2%) are participated in 1 to 5
projects. Furthermore 8(11.1%) respondents are participated from 6 to 10 projects, and
2(2.8%) of the respondents are participated from 11 to 15 projects, while from the
respondents only 1(1.4%) are participated from 16 to 20 projects and finally 4(5.6%)
respondents have participated in more than 20 projects. From this data, we can deduce
that majority of the respondents lack enough experience in software projects
development.

37
 4.1.3.2 Ratio of successful/challenged /failed software projects

For purposes of the study, projects were classified into three types successful,
challenged and cancelled software projects (Standish, 1995).
Successful software projects, the projects are completed on time, on budget, with all
features and functionality as initially specified. Challenged Software projects, the
projects are completed and operational but over budget, over the time estimate, and
offer fewer features and functions than originally specified. Impaired/cancelled software
projects, are cancelled at some point during the development cycle. Concerning this,
related questions were forwarded to respondents to get their real experience and to
analyze the issue as presented.

Figure 4.2 Ratio of successful/challenged/cancelled software projects

60%
52%
50%

40%

30%
30%

20% 18%

10%

0%
Successful Challenged Cancelled

Source- Survey Data (2016)

As we can see from the above figure, majority of respondents 52% experienced
challenged software projects, 30% of respondents experienced successful software
projects and 18% of respondents experienced cancelled software projects. From the
result we can deduce that most of the respondents experienced challenged software

38
projects and much emphasis should be given for the factors that lead to software
projects to be challenged.

4.1.3.3 Overall ratio of successful/failed software projects

According, to Standish Group the combination of challenged and cancelled projects will
be considered as failure. There is overwhelming evidence that government software
projects indeed tend to fail. Concerning this, related questions were forwarded to
respondents to get their real experience and to analyze the issue as presented.

Figure 4.3 Ratio of successful to failed software project

80%
70%
70%

60%

50%

40%
30%
30%

20%

10%

0%
Successful Failed

Source- Survey Data (2016)

As we can see from the above figure, majority of respondents 70% experienced failed
software projects, and 30(%) of respondents experienced successful software projects.
From the result we can deduce that most of the respondents experienced failed
software projects.

39
 4.1.3.4 Ratio of software Projects success /failure in terms of project type

With respect to the software projects type that respondents participated, figure 4.4
presents the responses obtained through survey.

4.1.3.4.1 Successful software projects by type

Figure 4.4 Successful software projects by type

20%
18%
18%

16%
14%
14%

12% 11% 11%

10% 9% 9%
8%
8%
6%
6% 5%
4% 3%
2% 2% 2% 2%
2%

0%

Source- Survey Data (2016)

From the survey result, educational software has higher rate of success with 18%,
followed by transportation with 14%, ERP and Human resources equally has rate of
success rate11%, health and property management also equal 9% success rate, e-
services 8%, financial 6%, land and house administration 5%, ICT/telecommunication

40
3%, health, pension administration, agricultural software projects all constitute with 2%
of success rate. This shows that an educational software project has more success rate
than the other software projects, followed by transportation.

4.1.3.4.2 Cancelled software projects by type

Figure 4.5 Cancelled software projects by type

25%
22% 22%

20%

15% 13%

10% 9% 9% 9% 9% 9%

5%

0%

Source- Survey Data (2016)

From the survey result, financial and E-service software projects has higher rate of
cancellation rate with both 22% ,followed by property management with 13%, and
transportation, ERP, Human resources, educational and other with equal rate of 9%
cancellation rate. This shows that financial and an E-service software project has more
cancellation rate than other software projects.

41
 4.1.3.4.3 Challenged software projects by type

Figure 4.6 Challenged software projects by type

25% 23%

20%

16%
15%
15%

10%
10%
8%
7%
6%
5% 5%
5%
3%
2% 2%

0%

Source- Survey Data (2016)

From the survey result, human resources software projects has higher rate of being
challenged with rate of 23% ,followed by ERP 16%, financial 15% ,E-services 10 % ,
property management 8%, transportation 7%,educational 6%, ICT/telecom, other both
constitute equally 5%. Health 3%, pension administration and land and house
administration with 2% of being challenged. From this we can conclude that, human
resources software are high rate of being challenged than other software projects
followed by ERP.

42
 4.1.4. Effects of software projects failure

As stated in the literature, software projects failure will have a lot of effect. Figure 4.7
tells us what really does the effect that a government organization has suffered from
failed software projects.

Figure 4.7 Effects of software project failure

100%
90% 86%
80% 71%
67%
70%
57%
60% 51%
50%
40%
30%
20% 10%
6% 4%
10%
0%

Source- Survey Data (2016)

In figure 4.7, respondents were asked a general question to show the possible effects of
software project failure for an organization. As result shows, the majority of respondents
agreed that loss of confidence by stakeholders is the main effect of software project
failure which constitute 85% for most organization followed by time loss 71%, hinders
company growth 67%, services delay 57%, financial loss 51%, Job loss 6%, security
breach 4%, and other constitute 10%.

43
 4.1.5. Major factors for software project cancellation/challenge/success from
practitioners perspective

4.1.5.1 Major factors for software projects cancellation

Central tendency (mean) measure of descriptive statistics of the respondents has been
taken to find the main factors for software projects success/ failure, with minimum mean
shows the most top ranked factor.

Table 4.3 Major factors for software projects cancellation

Rank Cancellation factors Mean

1 Lack of IT management 3.20
2 Lack of planning 4.60
3 Lack of executive support 4.80
4 Poor communication 5.80
5 Unrealistic expectation 5.80
6 Incomplete requirement 6.00
7 Lack of user involvement 6.20
8 Changing requirement and specification 6.80
9 Inadequate risk management 7.20
10 Lack of resources 8.00
11 New Technology 8.40
12 Didn't need it any longer 10.80
13 If any other, please specify:
Source- Survey Data (2016)

In the above table, the three major software projects cancellation factors are lack of IT
management, lack of planning and lack of executive support. The three least
contributing software projects cancellation factors are didn‘t need it any longer, new
technology and lack of resources.

44
The following additional reasons, categorized as other, were supplied as software
projects cancellation factors:-

1. Users resistance for the new software

2. Change in policy

4.1.5.2 Major factors for software projects challenge

Table 4.4 Major factors for software projects challenge

Rank Challenge factors Mean

1 Lack of executive support 4.44
2 Unrealistic time frames 4.5
3 Incomplete requirements and specification 4.67
4 Unrealistic expectations 5.72
5 Lack of resources 6.22
6 Lack of skill in Technology 6.44
7 New technology 7.06
8 Poor communication 7.33
9 Unclear objectives 7.39
10 Changing requirements and specifications 7.67
11 Inadequate risk Management 8.06
12 Lack of user input 8.22
13 If any other, please specify:
Source- Survey Data (2016)

From the above table, the three major factors that lead to software projects being
challenged are, lack of executive support, unrealistic time frames, incomplete
requirements and specification. The three least contributing software project challenged
factors are lack of user input, inadequate risk management, and change in requirement
and specification.

45
The following additional reasons, categorized as other, were supplied as software
projects challenge factors

1. Users resistance for the new software

2. Lack of skilled manpower from software company side

4.1.5.3 Major factors for software projects success

Table 4.5 Major factors for software projects success

Rank Success factors Mean
1 Executive management support 4.30
2 Proper planning 5.00
3 Clear vision and objectives 5.30
4 Realistic expectation 5.60
5 Competent staff 5.90
6 Feeling of ownership 6.20
7 Clear statement of requirement 6.50
8 Hardworking, focused staff 6.50
9 User involvement 6.80
10 Adequate risk management 8.00
11 When the projects are Small 8.30
12 Effective communication 9.50
13 If any other, please specify:
Source- Survey Data (2016)

From the above table, the three major reasons that lead to software projects to succeed
are executive management support, proper planning, and clear vision and objectives.
The three least contributing factors for success of software projects are effective
communication, when the projects are small and adequate risk management.

46
 4.1.6. Major factors for software projects cancellation /challenge/success from
software company perspective

Central tendency (mean) measure of descriptive statistics of the respondents has been
taken to find the main factors for software projects success/failure, with minimum mean
shows the most top ranked factor.

4.1.6.1 Major factors for software projects cancellation

Table 4.6 Major factors for software projects cancellation

Rank Cancellation factors Mean

1 Changing requirement and specification 3.75
2 Incomplete requirement 4.00
3 Unrealistic expectation 4.50
4 Lack of executive support 4.63
5 Lack of planning 5.63
6 Lack of IT management 6.13
7 Lack of user involvement 6.38
8 Lack of resources 6.88
9 Poor communication 7.00
10 Didn't need it any longer 9.00
11 Inadequate risk management 9.50
12 New technology 10.63
13 If any other, please specify:
Source- Survey Data (2016)

From the above table, the three major reasons that lead to software projects being
cancelled are, changing requirement and specification, incomplete requirement, and
unrealistic expectation. The three least contributing software projects cancellation
factors are new technology, inadequate risk management, and didn‘t need it any longer.

47
The following additional reasons, categorized as other, were supplied as software
projects cancellation factors:-
1. Lack of societal awareness with regard to software projects
2. Resistance from user

4.1.6.2 Major factors for software projects challenge

Table 4.7 Major factors for software project challenge

Rank Challenge factors Mean

1 Unrealistic expectations 4.21
2 Changing requirements and specifications 4.50
3 Incomplete requirements and specification 4.58
4 Unclear objectives 5.50
5 Poor communication 5.56
6 Lack of executive support 6.32
7 Unrealistic time frames 6.47
8 Lack of user input 6.53
9 Lack of skill in technology 7.63
10 Lack of resources 8.11
11 New technology 9.26
12 Inadequate risk management 9.50
13 If any other, please specify:
Source- Survey Data (2016)

From above table, the three major reasons that lead to software projects being
challenged are, unrealistic expectations, changing requirements and specifications, and
incomplete requirements and specification. The three least contributing factors for
software project being challenged are inadequate risk management, new technology
and lack of resources.

48
The following additional reasons, categorized as other, were supplied as software
projects challenge factors:-

1. Lack of skill In project management in all stakeholders

2. Lack of proper change management

4.1.6.3 Major factors for software projects success

Table 4.8 Major factors for software project success

Rank Success factors Mean

1 Clear vision and objectives 2.59
2 Clear statement of requirement 4.71
3 Hardworking, focused staff 4.88
4 Proper planning 5.06
5 Executive management support 5.41
6 User involvement 5.47
7 Competent staff 7.06
8 Effective communication 7.24
9 Feeling of ownership 7.29
10 Realistic expectation 8.18
11 Adequate risk management 9.12
12 When the projects are Small 11
13 If any other, please specify:
Source- Survey Data (2016)

From above table, the three major reasons that lead to software projects to succeed are
clear vision and objectives, clear statement of requirement, and hardworking and
focused staff. The three least contributing factors for success of software projects are
when the projects are small, adequate risk management and realistic expectation.

The following additional reasons, categorized as other, were supplied as software

projects success factors:-
49
 1. Strictly following the software development life cycle
2. Project scope management

4.1.7. Major factors for software projects cancellation /challenge/success from

end user’s perspective

Central tendency (mean) measure of descriptive statistics of the respondents has been
taken to find the main factors for software projects success/ failure, with minimum mean
shows the most top ranked factor.

4.1.7.1 Major factors for software projects cancellation

Table 4.9 Major factors for software projects cancellation

Rank Cancellation factors Mean
1 New technology 2.0
2 Changing requirement and specification 2.5
3 Incomplete requirement 3.25
4 Lack of executive support 4.0
5 Didn't need it any longer 5.0
6 Lack of user involvement 5.25
7 Lack of planning 7.0
8 Unrealistic expectation 8.5
9 Lack of resources 8.75
10 Lack of IT management 9.25
11 Poor communication 11.0
12 Inadequate risk management 11.5
13 If any other, please specify:
Source- Survey Data (2016)

From the above table, the three major reasons that lead to software projects being
cancelled are, new technology, changing requirement and specification, and incomplete

50
requirement. The three least contributing factors for the cancellation software
inadequate risk management, poor communication, and lack of IT management.

4.1.7.2 Major factors for software projects challenge

Table 4.10 Major factor for software project challenge

Rank Challenge factors Mean

1 Lack of skill in Technology 1.59
2 Lack of user input 4.59
3 Unclear objectives 5.59
4 New technology 5.71
5 Lack of resources 6.18
6 Lack of executive support 6.47
7 Changing requirements and specifications 7.24
8 Unrealistic time frames 7.41
9 Incomplete requirements and specification 7.47
10 Unrealistic expectations 7.71
11 Inadequate risk Management 10.29
12 Poor communication 10.35
13 If any other, please specify:
Source- Survey Data (2016)

From the above table, the three major reasons that lead to software projects being
challenged are, lack of skill in technology, lack of user input and unclear objectives.
The three least contributing factors for software project being challenged are poor
communication, inadequate risk management, and unrealistic expectations.
The following additional reasons, categorized as other, were supplied as software
projects challenge factors:-
1. Lack of commitment from IT experts

51
 4.1.7.3 Major factors for software projects success

Table 4.11 Major factors for software project Success

Rank Success factors Mean

1 Feeling of ownership 2.33
2 Proper planning 3.00
3 Clear statement of requirement 3.67
4 Clear vision and objectives 4.00
5 Executive management support 6.00
6 Adequate risk management 6.67
7 Effective communication 7.00
8 User involvement 7.67
9 Hardworking, focused staff 8.00
10 Competent staff 8.67
11 Realistic expectation 9.67
12 When the projects are Small 11.33
13 If any other, please specify:
Source- Survey Data (2016)

From the above table, the three major reasons that lead to software projects to succeed
are, feeling of ownership, proper planning, and clear statement of requirement. The
three least contributing factors for success of software projects are when the projects
are small, realistic expectation, and competent staff.

52
4.2 Qualitative data analysis

In addition to the quantitative study, qualitative data analysis is conducted to

supplement and enrich the findings obtained from the survey. Accordingly, interviews
have been conducted with 4 senior ICT staff of government organization, to gather data
regarding reasons for software project success/failure. Moreover, it also helped to
discuss software projects related issues that government organization encountered.
Accordingly, the interview output has been analyzed by conducting open codding as
presented below.

The interviewees were requested regarding the overall software projects contribution to
their organization and all the respondents has replied that software‘s increases
effectiveness and efficiency in services delivery, cost reduction, productivity
improvement, accessibility, internal work process improvement.

Another question raised was to which situation does their organization experienced in
relation to software projects, cancelled/challenged/successful? Three of the
respondents replied as they have experienced challenged and successful software
projects only, while one respondent experienced cancelled, challenged and successful
software projects.

Interviewees were requested for the major reasons for the cancellation of software
projects in their organization. One respondents replied by citing online registration
software projects as example and the reasons for the cancellations of this particular
software were, firstly the project was initiated without the involvement of information
communication technology department and secondly incomplete requirements and
specifications which later leads to disagreement between the vendor and the
organization. Furthermore, lack of skilled ICT professional and unorganized ICT
department also the reason that leads this software projects for the cancellation.

53
The interviewees were also requested regarding the reasons for software projects being
challenged. All interviewee agreed that majority of the software projects in their
respective organization are categorized as challenged. In most government
organization majority of software projects are over budget, over time estimate and also
offers less functionality than originally specified. One interviewee replied by citing HRM
and E-services software projects as challenged in the organization and the major
reason that leads HRM software project to be challenged was, lack of ICT department
involvement. And E-services project also challenged, because lack of top management
support. In addition, unreliability of the e-services software also reason for this project
being challenged.

Second interviewee also cited examples of software project being challenged like
finance, property management, HRM, and the main reasons were lack of involvement
from ICT department and lack of skilled ICT professionals in the organization. In
addition the misunderstanding between end user‘s and the vendor with regard to
requirement and speciation has also resulted to this problem. Furthermore, end users
also were not cooperative to use the system because they feel that, if the system is
implemented they will be out of the job. The other reason was also that, vendor was
tried to customize the software project, which has been done for other organization. In
addition, lack of top management supports also another reason.

Third, interviewee also replied by citing BSC automation, ICMIS, E-services software
projects as challenged. Turnover of ICT professional, lack of skilled manpower and
unwillingness to use the system from the end user side are the major reason that leads
these software projects being challenged. Lack of top management support, lack of
skilled ICT professional and lack of enough ICT Infrastructure were also the main
reason for the software projects to be challenged. The fourth, Interviewee also replied
by giving example of software projects being challenged like tourism statistics,
handicraft database and the major reason for both software to be challenged were lack
of involvement from ICT department and end user side. Both software projects have

54
been initiated and developed in the organization by donors without complete
involvement of end users as well as ICT department.

Interviewees were also requested regarding the major reasons for success of software
projects in the organization. One of the interviewees replied by citing certificate
replacement and authentication software project as successful and the major reason
were firstly, end users has been under pressure by customers to provide efficient and
effective services and they have been in the system side. Secondly, detail requirement
and specification has been taken by the vendors in conduction with the end user. Top
management also in full support of the software because the service delivery has been
one of major compliant area of customers in the organization, which was also an issue
of good governance. In addition, all the interviewee has cited web portal being
successful software project because top management gave full support for the system.
Hence they assume it remarks the existence of an organization. Another interviewee
also cited HRM as successful and the reason behind was the end users were in the side
of project. Furthermore, one interviewee also cited library information system
management as successful.

Another question raised was how they see the effects of failed software project to their
organization. All the interviewees agreed that the failed software projects has resulted
customers to go long way to get services and be an issue of good governances. If
systems have been successful customers will get the services too fast and also the
work pressure from the end users side has been solved. Failed software also created
dissatisfaction of customers and decrease efficiency and effectiveness in internal work
process of their organization. Furthermore, one interviewee also replied a single
software project cancellation resulted the organization to loss 1.2 million Birr.

Lastly, the interviewees were asked to reflect their thought in relation to software
projects in government organization. Three of the interviewees emphasize the
criticalness of knowledge transfer strategy for software projects as the most of the time
when there is turnover of ICT staffs who participated in the projects and somebody who

55
comes to take over the project faces serious challenge. Skilled, strong, organized and
well equipped ICT department is also important for the success of software projects.
One interviewee also replied that top managements should not rush to solve temporary
problem or just for reporting purpose, rather they should give emphasis for proper
planning of software projects. End users should also consider software projects as they
are facilitating there work. In addition, Software Company should look in to details of
requirements and specifications of the organization need rather customizing project
which has been done for other organization for different purposes. One interviewee also
added lack of project management plan is also another issue in government
organization. Furthermore, serious precaution should be taken on details of contractual
agreements with vendors. Finally, ICT departments, end users, top managers and
vendors should work closely to make projects successful.

4.3 Discussions

In this section, the researcher intends to discuss the findings outlined in the previous
chapter. The aim of the research was to extend the understanding of software project
failure and to answer the research problem: Why do software projects fail in the
government organization. And to find which type of software projects are cancelled,
challenged and successful. The literature review and also the finding of this study
reveals overwhelming evidence that software projects in general, and government
software projects in particular, indeed tend to fail.

Previous studies on software projects failure focused either on software companies,

practitioners or end users perspective. The study by Standish (2004), investigated
software projects failure only from IT executive mangers perspective. Whereas, this
study looked comprehensively from the three key role players of software projects
participants such as software companies, practitioner, and end users perspective to
assess the main reason for success/failure. In addition, unlike previous works this study
also covered large and diversified sample size. The study by Mullualem (2014)
employed only 11 questionnaires to 11 organizations and only quantitative method has
been used to undertake the research. While this study employed 72 questionnaires to

56
24 different government and software organizations and both quantitative and
qualitative methods has been used. In addition, this study assessed software project
failure particularly government organization in Ethiopia. Furthermore, software projects
success/failure in terms of project type in government organization was studied and
presented.

The finding from both the questionnaire and interview found that there are more
challenged software project in government organization than cancelled projects. And
this emphasizes the importance of prioritizes those factors that leads for software
project being challenged, While Mullualem (2014), investigated both cancelled and
challenged software projects as failure.

Questions in section 4 and 5 basically to validate the major reason for software project
failure and majority of respondents agreed that lack of ICT department and end user
involvement, lack of top management support, turnover of staffs, and lack of skill in ICT
department and end user side are the major reason for software project failure. This
result differ from the finding of Mullualem (2014), lack of project management, lack of
project planning , communication failures as top reason for failure of software project.
The difference between finding of Mullualem (2014) and this study might be because he
assessed both private and government sectors, while this study assessed government
sector only. This finding was similar to Mahmood (2014), lack of skilled professionals as
one of the main reasons for software project failure in Pakistan‘s Government Sector.
The similarity between Mahmood (2014) and this study might be because both studies
take government organization as there study area.

In section 3 questions 5 is basically to validate the effect that software projects failure
has resulted to an organization and majority of respondents agreed that loss of
confidence by the stakeholders, is the main effect of software project failure for most
organization followed by time loss, hinders company growth, services delay, financial
loss, Job loss, security breach. This result somehow differs somehow from the findings
of Mullualem (2014), financial loss as the top effect of software project failure. The

57
difference between the two studies might be because, Mullualem (2014), considered
both private and government sector for his study, while this research considered only
government organization.

58
 Chapter five

5. CONCLUSION AND RECOMMENDATIONS

This part deals with the conclusion of the study and forwarded recommendations based
on the findings.

5.1 Conclusion

One of the best ways to prevent software projects failure is by identifying what lead to
the failure in the first place. Even with many factors contributing to the failure of a
software projects, there are still ways to ensure the success of a projects by analyzing
and identifying issues and working towards them. Most businesses fail to analyze and
identify these issues, rather tend to overlook them. Keeping track of those identified
factors and putting plans in place to minimize their occurrence will increase the
probability of successful software project result.

In this study, government organizations established under ministry level were

considered to assess the factors that lead software projects to fail, cancelled and/or
challenged. In order to answer the research questions and achieve the objective of the
study, a combination of quantitative and qualitative methods were used.

In due course, extensive literature review was conducted to identify factors for the
failure of software projects. In summary, by way of answering the research questions,
the study has been able to identify the major factors for software project failure in
government organization in Ethiopia. It specifically identified the major factors for
software projects cancellation and challenged from the end users and practitioners in
government organization as well as from software company perspectives. Moreover,
software projects that are cancelled, challenged and successful in government
organizations in terms of project type have been examined.

59
The major findings of this survey can be summarized as:

Software projects fail in the government organization at tremendous rate with 70%
shows failure. From the project category such as cancelled, challenged and successful
the finding through interview and questionnaire shows that majority of the projects in
government organizations are challenged with rate of 52%.

The major factors for failure of software projects in government organization are lack
ICT professional involvement as well as end users in the projects. Furthermore, lack of
top management support and lack of collaborative, integrated approach to the creation,
capture, organization, and access and use of knowledge management system for
software projects are also major factors for failure of software projects. Incomplete
requirement and specification is also the other major reason for the failure of software
projects. A major effect of software project is loss of confidence by stakeholders. The
stakeholders are those who have the power to impact an organization or project in
some way and power to respond to, negotiate with, and change the strategic future of
the organization, therefore the loss of confidence by them will have devastating result
for further software projects.

Furthermore, based on software project type educational software has higher rate of
success, followed by transport software projects. Financial and E-service software
projects has higher rate of cancellation rate. Human resources software projects has
higher rate of being challenged followed by ERP.

5.2 Recommendations

Recently, services delivery through software‘s has got relatively better attention in
government organization in Ethiopia. To reach desired level of software project success
based on government strategy, policy, culture, and get the best out of software project
investment the following recommendations are forwarded,

60
o Software projects require strong leadership and vision. It also requires a
comprehensive strategy through the understanding of political and economic
conditions/realities. Therefore, top managers at government organization and IT
professionals have to be engaged in software projects by understanding the final
outcome of the projects by helping employees to build their capacity on software
projects as well as in technology usage.
o IT executive (leaders) has to take the driving seat to back the confidence of
stakeholders in collaboration with top managers, end users, as well as software
company‘s by working on those identified as major factors for the failure and
prioritize them to improve success rate of software projects.
o Top management of Government organizations shall encourage and reward ICT
professional and end users through different motivational factors like training, career
development and financial incentives to actively participate in software projects.
o In addition to formal communication and collaboration between top managers and IT
leaders, government institutions have to create a favorable condition and encourage
informal networks between top managers and IT leaders. This will substantially
improve understanding between top managers and IT leaders and enable them to
reach a consensus easily during software projects related decision making.
o ICT professionals have to conduct software projects awareness creation campaign
throughout the organization and also create a platform to share software projects
related information.
o There have to be external IT professional bodies or institution which can oversee the
government software projects on regular basis.

61
 References

1. Ahonen, J.J., & Savolainen, P. (2010). Software engineering projects may fail
before they are started; Post-mortem analysis of five cancelled projects". The
Irish software engineering research center, university of limerick, Ireland
2. Alagarsamy, K., & Rajkumar, G. (2013). The most common factors for the failure
for the failure of software development projects. The international journal of
computer science & applications, 1(11), ISSN – 2278-1080.
3. Baccarini, D. (1999).The logical framework method for defining project success.
Project Management Journal 30, 25–32.
4. Bacon, R., & Hope, C. (2013). Conundrum: Why every government gets things
wrong - And What We Can Do about It., ISBN 1849546169, 9781849546164
Biteback Publishing.
5. Barki, H., Riverd, S., &Talbot, J. (1993). Toward an assessment of software
development risk. Journal of management information systems, 10(2), 203-225.
6. Bennatan, E.M. (2000). On Time, Within Budget: Software Project Management
Practices and Techniques, 3, ISBN: 978-0-471-37644-6368 pages.
7. Boehm, B.W. (1991). Software risk management; principle and practices. IEEE
software, 1:32-41.
8. Brooks, F. (1975). The Mythical Man-Month: Essays on software engineering."
Addison-Wesley, Reading, MA.
9. Cerpa, N., & Verner, J.M. (2009). Why did your project fail? Communications of
the ACM. 52 (12), 130-134.
10. Charette, R.N. (2005). Why software fails (software failure). 42, IEEE press
piscataway, NJ, USA, IEEE spectrum, 42-49.
11. Chelsea, F. (2014). Software failure government edition; Software testing.
Top%2010% 20 Reasons% 20why%%20systems%20projects%20fail.htm.
12. Collins, A., & Baccarini, D. (2004). Project success —a survey. J. Cons. Res. 5
(2), 211–231.
13. DeMarco, T., & Timothy, L. (1999). People ware: Productive projects and teams,
2, Dorset house publishing Co., New York, NY.

62
14. De Wit, A. (1988). Measurement of project success. International Journal of
project management, 6 (3), 164–170.
15. Dornyei, Z. (2001). Teaching and researching motivation, London: Longman
16. Dorsey, P. (2001). Top 10 reasons why systems projects fail.
http://www.dulcian.com/papers/
17. Dynamic Markets Limited (2007). IT Projects: Experience certainty. Independent
market research report.
18. Earnshaw, W.D. (2001). Why do large It project fail. http:// www. informs. com/
wplarge .html
19. Emam, K.E., & Koru, A.G. (2008). A Replicated survey of IT software project
failure. IEEE Software, 84-90.
20. Ewusi-Mensah, K., & Przaanyski, Z. (1991). On information system project
abandonment: An exploratory study of organizational practices. MIS quarterly,
67-86.
21. Fetters, M. D., Curry, L. A., & Creswell, J. W. (2013). Achieving integration in
mixed methods designs - Principles and practices. Health Services Research,
48(6 PART2), 2134-2156. DOI: 10.1111/1475-6773.12117
22. Gartner Group. (1998). How to avoid Information technology project failure.
23. Glass, R.L. (2001). Frequently Forgotten Fundamental Facts about Software
Engineering, IEEE Software Proceedings, pp. 110-112.
24. Glass, R.L. (2006). The Standish report: does it really describe a software crisis?
Communications of the ACM, 49 (8), 15-16.
25. Goldstein, M. (2001). Knowing right from wrong; what research tells us about
ways to increase the chances for project success? Project management national
conference-Nashivile, Tennessee, USA.
26. Holgeid , k., & Thompson, M. (2013). The (Governance of large-scale projects -
linking citizens and the state; the Hertie School of governance and the journal for
political consulting and policy advice.
27. Ibrahim, R., Ayazi, E., Nasrmalek, S., & Nakhat, S. (2013). An Investigation of
critical failure factors in information technology projects. Journal of business and

63
 management, 10(3), e-ISSN: 2278-487X, p-ISSN: 2319-7668. Volume 10, PP
87-92.
28. Jiang, J., & Klein, G. (1999). Supervisor support and career anchor impact on the
career satisfaction of the entry-level information systems professional. Journal of
management information systems, 16(3), 219-240.
29. Jones, C. (1995). Patterns of large software systems; failure and success. IEEE
Computer, 28, 86–87.
30. Kothari, C.R.(2004).Research Methodology: methods and techniques
(2nded).New Delhi: New Age International Publication
31. Kumar, R. l. (2002). Managing risks in IT projects: an options
perspective Information & Management, 40(1), Pages 63-74.
32. Kwak & Stoddard. (2004). Project risk management; lessons learned from
software development environment Tec novation, 24 (11), 915-920.
33. Linberg, K.R. (1999). Software developer perceptions about software project
failure; a case study. Journal of systems and software, 49:177–192.
34. Little, T. (2003). Critical success factors in software projects – a framework
under scrutiny. Dissertation for the degree of B.Sc. in the department of
computer Science. University of Högskolan Skövde, Sweden.
35. Mahmood, H. (2014). Reasons of software & IT project failures in Pakistan‘s
government sector; international journal of scientific & engineering research,
5(4), 43 ISSN 2229-5518.
36. May, L. (1998). Major causes of software project failures. Crosstalk: The journal
of defense software engineering, 9-12.
37. McFarlan, F.W. (1981). Portfolio approach to information systems. Harvard
Business Review: 142-150.
38. Mignote Kassa (2013, September 29). Why Ethiopia‘s Software Industry Falters.
Fourtune Newspaper., [ vol 14 ,no 700]
39. Mullualem, T. (2014). Assessment of Major factors that leads to software project
failure: A case study of Addis Ababa. Thesis submitted for partial fulfillment of
master‘s degree in information science. Addis Ababa University.

64
40. Naquin, Charles, E., Tynan, & Renee, O. (2003).The Team halo effect; why
teams are not blamed for their failures. Journal of applied psychology, 88(2),
332-340.
41. PASC. (2011). Government and IT – a recipe for ripoffs: time for a new
approach‖, Volume I.
42. Pinto, J.K., & Mantel, S.J. (1990). The causes of project failure. IEEE transaction
on engineering management, 34:269-276.
43. Pinto, J.K., & Slevin, D.P. (1988). Project success: definitions and measurement
techniques. Project management journal, 19:67-72.
44. Procaccino, J.D. (2002). Quantitative Models for Early Prediction of Software
Development Success: A Practitioner‘s Perspective, Dissertation Submitted to
the Faculty of Drexel University by in partial fulfillment of the requirements for the
degree of Doctor of Philosophy.
45. Procaccino J.D., Verner J.M., Overmyer S.P., & Darter, M. (2002). Factors for
early predication of software development success." case study: Information and
software technology 44:53-62.
46. Rodgers, J. (2001). Overcoming IT project failure.
Http://www.umsl.edu/s98986/Projfailure.html.
47. Ronald Jay, P. (2005). Essentials of Survey Research and Analysis. A Practical
Guide
48. Rothman, J. (2008). Abandoning vs Killing Project, from www.jrothman.com/blog
49. Sadeh, A., Dvir, D., & Shenhar, A. (2000). The role of contract type in the
success of R&D defense projects under increasing uncertainty. Project
Management journal, 31 (3), 14–22.
50. Sauer, C. (1993). Why information system fail: A case study Approach. Great
Britain: Hollen Street Press Ltd.
51. Scotts, A. (2000). IT Failures-A high
Risk.http://www.allerscotts.com/sheet/it_failure_price.html
52. Smith, J. (2002). Why information technology software projects fail in South
Africa. Submitted in partial fulfillment of master‘s degree in business
administration. The University of Wales.

65
53. Standish Group, (1995). CHAOS ‘98: A summary review. A Standish Group
research note 1998. The Standish Group, USA.
54. Standish Group, CHAOS Report. www.standishgroup.com/visitor/chaos.
55. Taylor, A. (2001). IT projects sink or swim. http:// www. Bcs .org .uk /review /
/htm/p061.htm.
56. Taylor, H. (2007). Outsourced IT projects from the vendor perspective: different
goals, different risks. J. Glob. Inf. Manage,15 (2), 1–27
57. Walsh, K., & Schneider, H. (2002). The role of motivation and risk behavior in
software development success. Information Research, 7(3).
58. Wateridge, J.H. (1995). IT projects; a basis for success. International journal of
project management, 13(3).
59. Wohlin, C., & Von Mayrhauser, A. (2000). Assessing project success using
subjective evaluation factors. Journal of software quality.
60. Wohlin, C., Von Mayrhauser, A., Host M., and Regnell, B. (2000). Subjective
evaluation as a tool for learning from software project success, information and
software Technology, 42: 983-992.
61. Zegeye, A., Worku, A., Tefera, D, Getu, M., & Sileshi, Y. (2009). Introduction to
Research Methods: Preparatory module for Addis Ababa University graduate
programs. Addis Ababa University. Retrieved from AAU database.
62. Zohrabi, M. (2013). Mixed Method Research: Instruments, Validity, Reliability and
Reporting Findings. Theory and Practice in Language Studies, 3,254-262

66
 Appendix 1

ADDIS ABABA UNIVERSITY

COLLEGE OF NATURAL SCIENCE

SCHOOL OF INFORMATION SCIENCE

Questionnaire

Dear Respondent

The purpose of this questionnaire is to gather information related to factors for Software
Projects failure in government organizations. The data to be collected through this
questionnaire will be used only for the purpose of educational research. Your responses
will be kept confidential and you will not be asked to disclose your identity.
The success of this study largely depends on your honest and sincere responses that
you make to each question items. Therefore, we kindly request you to provide the
required information as much as possible.

Thank you in advance for your cooperation!

Questionnaire Layout

This questionnaire consists of 7 pages, including the cover page. Six (6) sections have
been compiled in the questionnaire, which cover the following topics:
Section 1: Software projects information
Section 2: Demographic information
Section 3: Different perspective of software projects
Section 4: Information on cancelled software projects
Section 5: Information on challenged software projects
Section 6: Information on successful software projects

67
 Section 1
Software projects information
Objective:
This section deals with the overall information of software projects. Please study the
following definitions before answering.

Definitions:
Software projects: This includes any type of project initiated to design and implement
software. This includes customized software, package software,
e.g. ERP packages and a mixture of customized and packaged
software.
Software failure: Software failure is divided into two categories: project challenged and
project cancelled.
Challenged software projects: - is completed and operational but over budget or over
the time estimate, or delivered with fewer functions than originally specified or the
general perception is that the project is a failure.
Cancelled software projects: - is considered to be a failure if the project is cancelled
at some point during the project life cycle.
Successful software projects: -the projects are completed on time, on budget, with all
features and functionality as initially specified.

68
 Section 2
Demographic information

Instructions:

You will be asked a few demographic questions. Please respond by putting ‗‘ in boxes
or write the answer in the space provided (if any other).
1. Sex Male Female
2. Age: 20 and below: 21-30 31-40
41-50 51 and above
3. Educational Level:

Certificate/level I-III Diploma (Level IV) BA/BSc/BEd

MA/MSC and Above
If any other, please specify___________________
4. What is your position in the organization?
ICT head/director Project manager/leader
Database administrator System analyst
Business analyst Programmer
System administrator Team leader
Network engineer End user
Other (please specify) ____________________
5. Which one of the following categories best describe the nature of your
organization?
Government
Software developing company/ consulting
If other, please specify______________________

69
 Section 3
Different perspective of software projects

Instructions:

You will be asked a few questions regarding software projects. Please respond by
putting ‗‘ in boxes or write the answer in the space provided (if any other).

1. Have you participated in any software projects?

Yes No
2. If your answer is yes for the question number 1, in how many projects you
have participated?
1-5 projects 6-10 projects 11-15 projects
16-20 Projects More than 20 projects
3. Which situation have you experienced during your software project
participation?(You can select more than one).
Successful Cancelled Challenged
4. In which type of software projects categories have you participated in terms of
their function and results?(You can select more than one).
Software Projects Successful Cancelled Challenged
Educational
Health
Electricity utility
Financial
Human resources
ERP
ICT/telecommunication
Pension administration
Transportation
Agricultural
Hotel And tourism
Property management
E-services
Land & house administration
Other

70
 5. What are the effects of software projects failure? (You can select more than
one)

Security breach Job loss Financial loss Time loss

Services delay Loss of confidence by stakeholders

Hinders company growth Other (please specify)_____________

Section 4
Information on cancelled software projects
Objective:
This section deals with the reasons on why software projects are cancelled. You are not
required to answer questions related to reasons for software projects if there is/are no
project cancelled you have experienced so far.

Instructions:
Listed below are initial lists of reasons why software projects are cancelled. Please
follow the instructions:
1. If there are additional reasons on why software projects are cancelled in your
organization, add the reasons to the table.
2. Rank the reasons on why software projects are cancelled in your organization by
putting numbers starting from 1to12. Starting at 1 (one) for the most influential/leading
reason for projects being cancelled, 2(Two) as the second most influential/leading
reasons for project being cancelled and so on.
Software projects cancelled factors Rank
Incomplete requirement
Lack of user involvement
Lack of resources
Unrealistic expectation
Lack of executive support
Changing requirement and specification
Lack of planning
Didn't need it any longer
Lack of IT management
New technology

71
 Poor communication
Inadequate risk management
If any other, please specify:

Section 5
Information on challenged software projects
Objective:
This section deals with the reasons on why software projects are challenged. You are
not required to answer questions related to reasons for software projects if there is/are
no project challenged you have experienced so far.
Instructions:
Listed below are initial lists of reasons why software projects are challenged. Please
follow the instructions:
1. If there are additional reasons on why software projects are challenged in your
organization, add the reasons to the table.
2. Rank the reasons on why software projects are challenged in your organization by
putting numbers starting from 1to12. Starting at 1 (one) for the most influential/leading
reason for projects being challenged, 2(Two) as the second most influential/leading
reasons for project being challenged and so on.
software projects challenged factors Rank
Unrealistic time frames
Lack of resources
New technology
Lack of executive support
Lack of skill in Technology
Incomplete requirements and specification
Unrealistic expectations
Unclear objectives
Lack of user input
Changing requirements and specifications
Poor communication
Inadequate risk management
If any other, please specify:

72
 Section 6
Information on successful software projects
Objective:
This section deals with the reasons on why software projects are successful. You are
not required to answer questions related to reasons for software projects if there is/are
no project successful you have experienced so far.
Instructions:
Listed below are initial lists of reasons why software projects are successful. Please
follow the instructions:
1. If there are additional reasons on why software projects are successful in your
organization, add the reasons to the table.
2. Rank the reasons on why software projects are successful in your organization by
putting numbers starting from 1to12. Starting at 1 (one) for the most influential/leading
reason for projects being successful, 2(Two) as the second most influential/leading
reasons for project being successful and so on.
Software projects success factors Rank
Executive management support
Competent staff
Proper planning
Clear vision and objectives
Realistic expectation
When the projects are Small
Feeling of ownership
Clear statement of requirement
User involvement
Hardworking, focused staff
Adequate risk management
Effective communication
If any other, please specify:

73
 Appendix 2

Interview outline
1. How do you see the overall software projects contribution to your organization?
2. Which situation does your organization experienced in relation to software projects?
Cancelled/ Challenged/ Successful.
3. What are the major reasons for the cancellation of software projects in your
organization?
4. Why software projects are over budget, over the time estimate, and offer fewer
features and functions than originally specified./Challenged/
5. What are the major reasons for success of software projects in your organization?
6. How do you see the Impacts of failed software project to your organization?
7. Do you have any thought in relation to software projects in government
organization?

74