ArticlePDF Available

Abstract and Figures

Research highlights that only one in eight information technology projects can be considered truly successful (failure being described as those projects that do not meet the original time, cost and (quality) requirements criteria). Despite such failures, huge sums continue to be invested in information systems projects and written off. For example the cost of project failure across the European Union was €142 billion in 2004
Content may be subject to copyright.
Understanding the Sources of Information Systems Project Failure
(A study in IS project failure in Europe)
Dr John McManus12 & Dr Trevor Wood-Harper
Abstract
Previous research undertaken by the authors in 2002 highlights that only one in
eight information technology projects can be considered truly successful (failure
being described as those projects that do not meet the original time, cost and
(quality) requirements criteria). Despite such failures, huge sums continue to be
invested in information systems project and written off, for example the cost of
project failure across the European Union was 142 billion Euros in 2004. 'Whilst our
understanding of the importance of project failure has increased, many of the
underlying reasons for failure still remain an issue and a point of contention for
practitioners and academics alike. This paper examines through case research some
of issues and casual factors of information systems project failure.
Key words: Projects, Failure, Leadership, Stakeholders, Risk
1 Corresponding author jmcmanus@lincoln.ac.uk
2 The authors would like to thank Karl Wiegers of Process Impact for his useful comments.
2
Introduction
A predominant paradigm in information systems project management is to view the
development and delivery process as a three way trade-off between time,
(business urgency), Cost (budget) and quality (product functionality or capability).
This paradigm both influences and promotes trade-offs between product
functionality, cost and schedule. Trade-offs are mitigated or eliminated entirely
through arbitrage or negotiation and despite attempts to make software
development and project delivery more rigorous, a considerable proportion of
delivery effort results in systems that do not meet expectation and fail to meet
user expectations.
Previous research and writings by McManus [4] [5] suggest that project
management in many software engineering firms currently ranges from
undisciplined to chaotic. Few organizations have the infrastructure, education,
training, or management discipline to bring projects to successful completion.
Research [6] [7] [8] [13] indicates that more than half of all information technology
projects become runaways overshooting their budgets and timetables while failing
to deliver on their goals. The seemingly high level of project failures tied to the
time, cost and quality paradigm (frequently reported in the news and professional
press) is the motivation for this research, being informed by previous studies into
project failure for example, the seminal work undertaken by the Standish Group
International, CHAOS report in 1995, [7] and the literature on information systems
and the author’s own published works and experience in information systems
development and project management [1].
Prior Research
Prior research by the authors [3] highlights a number of critical causal factors in
failed projects. Findings from this earlier research were based on 42 information
systems (IS) projects that were completed in the period 1994-2001. These earlier
findings included inadequacies in management and technical practices.
Management issues accounted for 65 percent of causal factors identified with failed
projects [1] [3].
Management causal factors account for 65% of the project failure rate
Poor leadership in project delivery
Poor stakeholder communication
Poor competencies (and skill shortages)
Poor stakeholder management
3
Poor estimation methods
Poor risk management
Insufficient management support
Technical causal factors account for 35% of the project failure rate
Inappropriate and ill defined software requirements
Inappropriate technical designs
Inappropriate development tools
Inappropriate user documentation
Poor test planning
Poor technical support
One of the key findings from this earlier research was the lack of stakeholder
communication and the need to pass on business and technical knowledge within
the project community and wider management hierarchy. The importance of
continuous feedback to each of the participating stakeholders cannot be stressed
enough. In particular, details of any mistakes made should be shared with the
project community. Based on our analysis of the post implementation audits there
appears a broad consensus that mistakes are acceptable but failure is not. Failure
was considered an absolute error that could not be recovered from. It was
therefore concluded that success was in fact largely dependent on creating
contingency plans and alternate approaches for projects that have a high perceived
risk coefficient [1].
This Research Programme
Adopted Methodology
It could be argued that the way research is conducted may be conceived in terms
of: the research philosophy subscribed to, the research method employed and the
research instruments used in pursuit of the research objective. In the authors view
research philosophy may be described as a construct about the way in which data
(or information) should be gathered, analysed and used. Research should exhibit
both rigour and relevance. The issue of what research approach and methodology
might be relevant to information systems project failure has been vastly debated.
Earlier research by the authors was undertaken using a “case based approach
(since much of the material examined came from a single entity systems
integration practice). The main attributes of this case based approach may be
defined as:
4
Researcher as observer
Exploratory, explanatory or descriptive
Focus on “How?” and Why?”
Given the complexity of the subject area and the need to build on earlier
research and to broaden the horizon an approach based on cases and Surveys was
deemed applicable. The Surveys looked at different projects (and their team
structures) at the same time, interviews were conducted with a selective number
of project managers to follow up issues or clarify points of interest. In this study a
larger amount of data was analysed than the earlier cases. More consideration was
given to identifying sample projects (through literature reviews) and identifying
the key attributes for data analysis. The period of analysis covered 1998-2005 the
number of information systems projects examined across the European Community
was 214 comprised of both Public and Private sector firms that included 63 projects
from the Public sector and 151 projects from the Private sector (refer to Tables 1
and 2 for breakdown by sector and project value).
Table 1 Number of IS projects examined within European Community
Rank
Sector
Number of Projects
Examined
1
Manufacturing
43
2
Retail
36
3
Financial Services
33
4
Transport
27
5
Health
18
6
Education
17
7
Defence
13
8
Construction
12
9
Logistics
9
10
Agriculture
6
Total
214
5
Table 2 Project value in millions of Euros
Value range
in millions
Euros
Number of
Projects
Percentage
(%)
Accumulative
(%)
0 1
51
23.831
23.831
1 2
20
9.346
33.177
2 - 3
11
5.140
38.317
3 - 5
33
15.421
53.738
5 - 10
4
1.869
55.607
10 - 20
87
40.654
96.261
20 - 50
6
2.804
99.065
50 - 80
2
0.935
100.000
Totals
214
100.00
100.000
Validity of Research
When assuring the validity of information, it is always advisable to use different
techniques to authenticate the substance and accuracy of the data and information
used. In this respect triangulation was seen as a possible use for this purpose.
Triangulation was used as a secondary source of information (e.g. to support an
interview with data from a project) by undertaking this activity it was possible to
find differences between what people said and what they did (that is what they
undertook).
Practical Outcomes
One practical outcome envisaged from this research activity is a continuing debate
amongst academics and practitioners in essence paving the way for new areas of
study in relation to information systems project failure. The research should also
provide an increased understanding of why information systems projects continue
to fail.
Research Questions and Data Analysis
This research builds on previous research undertaken and although by no means
exhaustive this research aims to find answers to three questions. Namely:
1. At what stage in the project lifecycle are projects cancelled (or abandoned
as failures)?
2. What is the average schedule and budget overrun?
3. What are the major causal factors contributing to project failure?
6
Question 1
At what stage in the project lifecycle are projects cancelled (or abandoned as
failures)?
When undertaking software development a number of different approaches and
methodologies can be used however, the most common method in use is the
waterfall method [3]. It is also acknowledged that other approaches (e.g. DSDM,
RAD, and Agile methods) could also be used in parallel with the waterfall method.
Prior research by the authors [3] identified that 7 out of 10 software projects
undertaken in the UK adopted the waterfall method for software development and
delivery. Although some of the projects analysed did use a mixture of software
development methods through a process of normalisation the authors were able to
overlay all 214 projects onto the lifecycle outlined in table 3 below.
Results from the analysis of cases indicates that almost one in four of the projects
examined were abandoned after the feasibility stage of those projects completed
approximately one in three were schedule and budget overruns.
Table 3 Project completions, cancellations and overruns
Number of projects
cancelled3
Number of projects
completed
Number of projects
overrun
(schedule and/or cost)
None
214
None
3
211
None
28
183
32
15
168
57
4
164
57
1
163
69
None
163
69
23.8%
76.2%
Reasons for Project Cancellations
Of the initial 214 projects studied 51 (23.8% were cancelled) - a summary of the
principal reasons why projects were cancelled is given in Table 4. Earlier research
by the Standish Group found that 31% of projects were deemed failures and were
subsequently cancelled [7]. Although this research is based on a much smaller
sample than the Standish Group work the two samples are nevertheless within
acceptable standard deviations of each other. Results from this analysis indicate
3 Includes partial completions
7
that the cancellation of projects (23.8%) can be attributed to a combination of
factors that included the following (from Table 4):
1. Business process alignment
2. Poor requirements management
3. Business benefits overstated
4. Differences between management and client
5. Lack of management judgement (leadership)
6. Insufficient domain knowledge
7. Loss of key personnel
8. Poor communication with stakeholders
9. Poor systems integration
10. Poor change management procedures
Our earlier research [3] elaborated on the symptoms of information systems
project failure in three specific areas: frequent requests by users to change the
system; insufficient communication between the different members of the team
working on the project and the end users (stakeholders); and no clear requirements
definitions. Whilst communication between team and end users was still perceived
as an issue within some projects; the top three issues from this study are: business
process alignment; requirements management; and overspends. For example, the
compatibility of the systems under development were in 28 instances found to be
so far adrift from the core business processes that the projects were abandoned at
a cost of tens of millions euros.
One notable causal factor in these abandonment’s was the lack of due diligence
at the requirements phase, an important factor here was the level of skill in design
and poor management judgement in selecting software engineers with the right
skill sets. Equally the authors found some evidence in poor tool set selection in
that end users found it difficult to sign-off design work in that they could not
relate process and data model output with their reality and practical knowledge of
the business processes.
Table 4 Key reasons why projects get cancelled (N=51)
Business reasons
(N = 10)
Management reasons
(N = 27)
Technical reasons
(N = 14)
19.6%
53.0%
27.4%
Business strategy superseded
Business processes change (poor
alignment)
Poor requirements management
Business benefits not clearly
communicated or overstated
Failure of parent company to deliver
Governance issues within the contract
Higher cost of capital
Inability to provide investment capital
Inappropriate disaster recovery
Misuse of financial resources
Overspends in excess of agreed budgets
Poor project board composition
Take-over of client firm
Too big a project portfolio
Ability to adapt to new resource combinations
Differences between management and client
Insufficient risk management
Insufficient end-user management
Insufficient domain knowledge
Insufficient software metrics
Insufficient training of users
Inappropriate procedures and routines
Lack of management judgement
Lack of software development metrics
Loss of key personnel
Managing legacy replacement
Poor vendor management
Poor software productivity
Poor communication between stakeholders
Poor contract management
Poor financial management
Project management capability
Poor delegation and decision making
Unfilled promises to users and other stakeholders
Inappropriate architecture
Insufficient reuse of existing technical objects
Inappropriate testing tools
Inappropriate coding language
Inappropriate technical methodologies
Lack of formal technical standards
Lack of technical innovation (obsolescence)
Misstatement of technical risk
Obsolescence of technology
Poor interface specifications
Poor quality code
Poor systems testing
Poor data migration
Poor systems integration
Poor configuration management
Poor change management procedures
Poor technical judgement
Question 2
What is the average schedule and budget overrun?
In examining the cases it was noted that the average duration of a project was just
over 26 months (115 weeks) and the average budget was approximate 6 million
Euros, (Table 5). In many instances information on a project being over schedule
and over budget will force senior management to act, however, the search for the
underlying factors should begin else where in the projects history [9]. The pattern
that emerges from a synthesis of case data is complex and multifaceted. In a few
of the of cases examined the project commentary and history was ambiguous;
however, once a decision had been made to support a project which was over
schedule or over budget the ends usually justified the means irrespective of the
viewpoints of individual project managers or stakeholders. For example, one
project undertaken within the financial services sector involved the design, build,
and implementation of a share dealer system for hundreds of bond brokers and
other support staff which involved a multi-layer stakeholder community.
On completion of the project both the client and project managers regarded the
project as a success. There were, however, a number of design and
implementation problems that, with hindsight, could have been avoided. The client
and senior management felt that the project was a success, although it was 20
weeks late was 56 per cent over budget. This was a good result based on client’s
previous track record in information systems delivery.
Table 5 Cost and schedule overruns (N=69)
Projects
From
Sample
2
(2)
11
(13)
19
(32)
25
(57)
12
(69)
Schedule
Overrun
11
weeks
29
weeks
46
weeks
80
weeks
103
weeks
Range
Average
Budget +
10%
Average
Budget +
25%
Average
Budget +
40%
Average
Budget +
70%
Average
Budget +
90%
Cost
Overrun
600,000
Euros
1,500,000
Euros
2,400,000
Euros
4,200,000
Euros
5,400,000
Euros
10
In projects over 6 million Euros, the understatement of effort, stakeholder and
project management costs appeared to be a common feature and small budget
overruns (less than 10%) did not generally reflect the cost or risk of the project.
The fact that it took an additional 20 weeks and extra support and user personnel
to iron out post-implementation problems “was initially hidden without too many
problems the important thing for the project manager and the senior management
team was that the project could be held up as a success.
Question 3
What are the major causal factors contributing to project failure?
Judgements by project stakeholders about the relative success or failure of
projects tend to be made early in the projects life cycle. On examination of the
project stage reports it became apparent that many project managers plan for
failure rather than success. As one project manager commentated …”it seems to
me one of the enduring problems in the organization on these issues (project
delivery) has been that, although there are a large number of very talented
people in the organization, I do not think it has had a sufficient depth of expertise
on the very complicated range of technical issues, operational issues and market
issues which are required to see the project through to a satisfactory and timely
conclusion [10].
When analysing success and failure it is second nature to ascribe “cause and
effect to events” [1], for example, the system went live more or less on time
because the project was well-managed (with a highly respected project manager)
or was late because system testing was not thorough enough. The idea of causality
or the relationship between “cause and event” is central to many conceptions of
theory [11]. When theory is taken to involve explanation and understanding, it is
intimately linked to ideas of causation. Often, to ask for an explanation of an
“event” is to ask for its cause. Similarly, the ability to make predictions from
theory can depend on knowledge of causal connections. For example, the
knowledge that stakeholders (that is a users) involvement contributes to the
development of “successful” information systems warrants the inference that if
stakeholders are not involved in the development of a particular system then the
system is less likely to be successful. This is emphasised in the following case.
During the implementation phase of one project studied the sponsoring
organization was undergoing a major reorganization and was attempting to down-
size some of its operations. The next 18 months were typified by intense political
11
power struggles as the senior management team attempted to position themselves
within the organization. From the project manager’s perspective it seemed that
the personal ambitions of the managers played a significant part in how the
organization would be structured and this influenced significant strategic decisions.
Outcomes were legitimised in language that drew upon the business urgency,
market pressures and customer service etc. It is, however, difficult to ignore the
personal and organizational politics (risk) that bubble away continuously in the
background, and if the management require a software project to fail, then, by
large, they could bring this outcome about. Similarly, if they wanted it to succeed
then to a large extent they could also bring about this outcome.
If we consider the inherent complexity of “risk” associated with software
project delivery [13] it is not too surprising that only a small number of projects
are delivered to the original time, cost, and quality requirements. Our evidence
suggests that the culture within many organization’s is often such that leadership,
stakeholder and risk management issues are not factored into projects early on and
in many instances cannot formally be written down for political reasons and are
rarely discussed openly at project board or steering group meetings although they
may be discussed at length behind closed doors.
A predominant paradigm in information systems project management is to view
the development process as a three way trade-off between time, (business
urgency), Cost (budget) and quality (product functionality and capability) [3]. This
view sees product functionality, cost and time as issues to be traded-off.
Significant trade-offs are mitigated or eliminated entirely through a process of
arbitrage or negotiation. Despite attempts to make software development and
project delivery more rigorous, a considerable proportion of delivery effort results
in systems that do not meet user expectations and are subsequently cancelled
(Table 3). In our view this is attributed to the fact that very few organization’s
have the infrastructure, education, training, or management discipline to bring
projects to successful completion. One of the major weaknesses uncovered during
the analysis was the total reliance placed on methodologies. It could be argued
that following a project methodology, such as PRINCE2 helps project managers and
those involved in organising and delivering software projects and structured
methodologies such as SSADM4 help developers in design and other technical
activities but methods can become an almost immaterial factor in the face of
stakeholder and personal politics. From experience of case study research into the
4 Structured Systems Analysis and Design Method
12
implementation of SSADM, Wastell comments…”Methodology becomes a fetish, a
procedure used with pathological rigidity for its sake, not as a means to an end.
Used in this way, methodology provides relief against anxiety; it insulates the
practitioner from risks and uncertainties of real engagement with people and
problems[12]. One explanation for the reliance on methodology is the absence of
leadership within the delivery process. Processes alone are far from enough to
cover the complexity and human aspects of many large projects subject to multiple
stakeholders, resource and ethical constraints. The basis for developing and
delivering information systems will require an extension of the discipline that is
project management to provide capabilities and understanding in the
interrelationships between leadership, stakeholder and risk management. The
major challenge is to extend our understanding and capabilities within this domain
so that it is possible to address the issues in information systems project failure.
Conclusions
Although our understanding of the importance of project failure has increased, the
underlying reasons still remain an issue and a point of contention for both
practitioners and academics alike. Without doubt there is still a lot to learn from
studying project failure. As previously specified project management is intrinsically
tied to the time, cost, quality paradigm and projects that are challenged are
typically forced to make trade-offs in budget, time estimates, features and
functions (quality). Such trade-offs lead to escalation in which key personnel are
pitted against each other. Going back to the research undertaken there is little
evidence that the issues of project failure outlined in Table 4 have been fully
addressed within information systems project management. Based on this research
project failure requires recognition of the influence multiple stakeholders have on
projects, and a broad based view of project leadership and stakeholder
management. Developing an alternative methodology for project management
founded on a leadership, stakeholder and risk management should lead to a better
understanding of the management issues that may contribute to the successful
delivery of information systems projects.
13
References
[1] McManus, J., (2004), Risk Management in Software Development Projects,
Elsevier, Butterworth-Heinemann, Oxford, UK
[2] McManus, J., (2004), ‘A Stakeholder Perspective within Software Engineering’,
Innovation and Entrepreneurship for Sustainable Development, Proceedings
of the IEEE Transaction International Engineering Management Conference,
18-21 October, Singapore, Vol 2, pp 880-884
[3] McManus, J. and Wood-Harper, T., (2003), Information Systems Project
Management: Methods, Tools and Techniques, Pearson Education, Prentice
Hall, UK, pages 4, 5, 9-10, 207-10, & 228
[4] McManus, J., (2003) ‘The Application of Risk Planning in Software Development
Projects’, Management, Journal Management Services, pp16-18, June
[5] McManus, J., (2002), ‘The Influence of Stakeholder Values on Project
Management’, Journal Management Services, pp 8-15, June
[6] Gibbs, W. W., (1994), Software’s Chronic Crisis,” Scientific American,
September, pp. 8695
[7] Standish Group International, (January, 1995), ‘CHAOS: application project
failure’, Report, Standish Group International
[8] KPMG Canada, (October, 1997), ‘What Went Wrong? Unsuccessful Information
Technology Projects’, [see: www.kpmg.com]
[9] Ewusi-Mensah, K., (1997), Critical Issues in Abandoned Information Systems
Development Projects, Communications of the ACM, Vol 40, No 9
[10] McManus, J., (2005), Managing Stakeholders in Software Development
Projects, Elsevier, Butterworth-Heinemann, Oxford, UK
[11] Gregor, S., (2002), ‘A theory of theories in information systems’, in S. Gregor,
and D. Hart (Eds.), Information Systems Foundations: Building the
theoretical base, Australian National University, Canberra, p 5
[12] Wastell, D., (1996), ‘The Fetish of Technique: methodology as a social
defence’, Information Systems Journal, 6, p 34
[13]Wiegers, K. E., The Journal of the Quality Assurance Institute, July 1997,
Reprinted with permission from the Quality Assurance Institute. (adapted
from Creating a Software Engineering Culture by Karl E. Wiegers (Dorset
House Publishing, 1996).
... But the project success rate has still not improved, as the high scale of project failures (e.g. 66% failure rate in IT based projects) roughly costs $109 million for every $1 billion of project-based investment (McManus and Wood-Harper, 2008;Joslin and M€ uller, 2016;Zaman et al., 2021a, b). For that reason, researchers have widened their research scope and have started focusing on structural characteristics of the project along with the famous iron triangle factors. ...
Article
Purpose: Project managers are under a never-ending pressure to demonstrate the expected value of projects to the project sponsors; however, in most cases, project managers fail to realize this strategic value due to the loopholes left in project governance throughout various stages of the project life cycle. Furthermore, another root cause of project failure might be linked to an exceedingly self-interested project leader who is exploitative of his/her team. This is a recurring yet still unexplored aspect of destructive leadership that requires attention from the scientific community as well as practitioners. Hence, the present study explored the relationship between project governance and information and communication technology (ICT) project success, as well as the moderating effects of exploitative leadership on this relationship. Design/methodology/approach: With this aim, 357 responses were collected from project professionals in the emerging ICT industry in Pakistan, and the results were analyzed using structural equation modeling (SEM) with partial least squares (PLS). Findings: The findings provide new evidence that project governance significantly improves project success opportunities in the ICT industry; however, this relationship is negatively moderated by exploitative leadership. Originality/value: The study findings extend the project leadership literature by uncovering the influence of the dark side of project leadership (i.e. exploitative leadership), in addition to revalidating the impact of project governance on project success through a multi-dimensional context.
... Governments all over the World are losing huge sums of money through projects as a result of project failure. Recent study into over 200 projects showed that only one out eight information and communications technology projects can be considered truly successful [11,12]. According to Heeks, 2006 [13] almost all World Bank funded Projects in Africa is either total failure or partial failure. ...
Research
Full-text available
In recent years, project financing has become an important part of national development; this result of the changing nature of project financing can be attributed to technological advancement, and a complex competitive global marketplace. Every project requires a substantial amount of capital outlay from individuals, sponsors, organizations and or governments and as such the need for good understanding of the risk of financing business-projects practices so as to deliver value for money. All over the world SMEs are seen as the engine for growth of every economy. Despite the huge contributions of SMEs to economic growth such as jobs and market creation and income generation, there is not universally accepted definition of SMEs. A review of related literature on the above topic was undertaken in order to establish the perspectives of scholars on the risks of financing SMEs business-projects. Also, this study has identified business idea risk, competency risk and return on investment risk as the three key risks of financing SMEs business projects. Further, this study has developed an effective conceptual model that present, help to identify and control the risks of financing SMEs business-projects. Fig. 4, tabl. 1, ref. 83.
... Governments all over the World are losing huge sums of money through projects as a result of project failure. Recent study into over 200 projects showed that only one out eight information and communications technology projects can be considered truly successful [20,21]. According to Heeks, 2006 [22] almost all World Bank funded Projects in Africa is either total failure or partial failure. ...
Research
Full-text available
It is stated that most of projects in developing economies face the challenge of insufficient funding, poor financial management, weak administration processes and procedures, lack of quality materials, lack of skilled personnel needed to run the projects, and legal and political concerns that causes poor project quality and less output or impact but it also impacts negatively on achieving national, economic and global development. It is outlined also, that the greatest problem is the absence of an appropriate governance framework; inadequate financial oversight; poor supervision, etc. and all these are pure administration and finance issues within state programs. Therefore, the actuality of the further study with the proposed question, aim and objectives, proposition, rationalization, scope, object and subject, methodology and limitations is grounded, its essential impact into administration and finance as factors for ensuring the success of projects in developing economies and Ghana in particular is shown. Fig. 5, tabl. 3, ref. 59. Introduction. This study investigates administration and finance as factors for ensuring the success of projects and programs in developing economies; to determine the most influential (most essential) administration and finance factors that developing economies, project developers and managers must know in order to achieve projects success. In recent years, project administration and financing has become an important part of national development; this result of the changing nature of project administration and financing can be attributed to technological advancement, and a complex competitive global marketplace. Every project requires a substantial amount of capital outlay from individuals, sponsors, organizations and or governments and as such the need for good project administration and finance practices to deliver value for money. Developing Economies are facing unprecedented challenges in the current knowledge economy, as they strive to attain sustainable development through the implementation of short and long term economic development projects. These challenges have been caused by the current knowledge economy, currently defined: a knowledge economy is characterized with the generation and adoption of new knowledge created by scientific research, technological development, investments in intangible assets, adoption of best practices, and openness to socioeconomic , and cultural innovations [1]. This characteristic of the Knowledge economy has caused a major challenge to the finance and administration of projects implemented by governments, international organizations, individuals and project managers in developing economies. Most projects in developing economies face the challenge of insufficient funding, poor financial management, weak administration processes and procedures, lack of quality materials, lack of skilled personnel needed to run the projects and legal and political concerns. These challenges not only causes poor project quality and less output or impact but it also impact negatively on achieving national, economic and global development. Developing economies implementing projects need finance to
... Numerous authors said that efforts are regularly monitored and managed to avoid the potential of failure (Davis, 2018). Each year, billions of dollars are lost due to project failures (McManus and Wood-Harper, 2008), and this cannot be true across all industries (Nichols et al., 2011). ...
Article
Full-text available
The identification of success elements and success criteria is critical for the successful completion of construction projects. The major goal of this research is to identify success factors and criteria for higher education development initiatives in the Pakistani province of Khyber Pakhtunkhwa. Projects are not successful owing to variety of causes producing delays in completion with high cost notably in construction business with context of higher education. A total 233 questionnaires were gathered from key stakeholders participating in 26 projects of 19 public sector institutions. A structured questionnaires were utilised to obtain data by employing convenience sample approach. This research indicated that project activities factors, human resource, the environmental variables, the procurement factors all positively and substantially affect the project success. This research with identical characteristics or according to the context may be carried out in other place or nation as well as other industry. The investigation offers appealing outcomes for the project managers operating in the building business of Pakistan. Different responsibilities of stakeholders and their acknowledgment and engagement contribute to a project successful since projects success relies on their roles and opinions about success. This research also contributes to academics to concentrate on project management discipline for suggesting link between success variables and success and these should be recognized and work out at the early phase of project
... 4-5], Inability to transform because of long dependencies in value chains [15, p. 77], Failure to see that human behaviour, systems technology, and assets structure defines a network of value creation [16, p. 7], or Misunderstandings of the political agenda or the changing security environment [17]. Subsequently, reduced requirements management [18] or failure to provide benefits [19], [20], [21] have also affected the outcome when developing digitalised military capabilities. ...
Thesis
Full-text available
Transformations of military enterprises seek to use technology to gain better performance, provide more effective outcomes, and excel in the space and time of confrontation. Enterprise Architecture should provide methods and competencies to gain more understanding of transformations and improve the success of these journeys. However, military transformations have a record of a variety of challenges and often fail to deliver intended outcomes. Possibly, the enterprise architecture practitioners are trying to engage a moving target. The failures do not notably follow any exact pattern or line of correlation. Still, they seem to be distributed through the layers of the military structure. Despite the evident problem and risk to national security, there is a surprising lack of research in this field. The dissertation approaches the challenges in military transformations from an enterprise architecture view in a quest to find models that would better explain the interrelationships between the military environment, affairs, knowledge, information, and technology over time—in other words, trying to engage an evolutionary enterprise and see where it may be going. The dissertation approaches the problem from a pragmatic view using a design science approach to create a better tool in modelling the dynamics and evolution of the military enterprise. Since the components and layers of an enterprise follow a different logic, the design needs to apply transdisciplinary research methods appropriate to each layer of the enterprise system. The proposed EA tool improves the quality of an enterprise architect's analysis of military transformations in recognising the current situation, seeing the paths of evolution leading to the current position, and foreseeing both the challenges and opportunities in journeys towards the strategic end state. Furthermore, the EA tool reveals some of the hidden forces driving or hindering the change of an enterprise, and therefore improving the success of digital transformation in the military context. The military decision making may benefit from the improved architectural insight and foresight when defining national-level strategies, implementing changes, maintaining operational capabilities, and, lately, obtaining the most out of their digital transformations.
Article
Full-text available
This study aims to identify and evaluate the perception of major stakeholders on factors causing International Development Project (IDP) failure in the context of Afghanistan. The study adopts a quantitative cross-sectional survey research design. Thirty significant IDP failure factors included in the questionnaire were identified and shortlisted through literature reviews and validated by experts and IDP management practitioners. The survey was conducted using a structured questionnaire to investigate the most significant IDP failure factors, and various statistical tools were employed to evaluate the perception of the survey respondents. RII was used to examine the relative importance index of each failure factor. The failure factors were then grouped into five categories: Financial constraints, Ineffective recruitment, External forces, Project leadership, and Project management practices using EFA. The findings of the study will help the international development community and their IDP implementing partners, INGs and project management practitioners manage IDPs proactively and mitigate the risks of project failure. It will also contribute to the IDP management body of knowledge. The research is the first of its kind to examine the possible factors causing IDP failure in Afghanistan.
Chapter
The main purpose of this chapter is to emphasize the problem of e-government project risks and to introduce a methodology for risk assessment and calculation of costs associated with risk occurrence in e-government projects based on Bayesian networks. The proposed methodology presents a new approach to the assessment of risks and costs related to e-government project risks. As such, it facilitates the holistic decision making procedure for project managers. The application of Bayesian networks in the context of risks and risk related costs reduces the level of uncertainty in e-government projects and provides a graphical structure of risks and corresponding costs. Finally, the sensitivity analysis has also been integrated into the methodology and its results can have a significant impact on the overall project management quality.
Chapter
In this article we discuss ‘slanty design’, which incorporate three new principles into a conventional user-centered design process. These are designing for non-goals (things you wish the user not to be able to do); creating anti-usability (designing so that it is difficult to achieve the non-goals); and clean design (solutions without unwanted side-effects that then have to have solutions designed for them). Slanty design incorporates many of the concepts of socio-technical approaches, and is explained using a variety of examples, including an airport baggage carousel, and the remaining challenges outstanding are described.
Chapter
The main purpose of this chapter is to emphasize the problem of e-government project risks and to introduce a methodology for risk assessment and calculation of costs associated with risk occurrence in e-government projects based on Bayesian networks. The proposed methodology presents a new approach to the assessment of risks and costs related to e-government project risks. As such, it facilitates the holistic decision making procedure for project managers. The application of Bayesian networks in the context of risks and risk related costs reduces the level of uncertainty in e-government projects and provides a graphical structure of risks and corresponding costs. Finally, the sensitivity analysis has also been integrated into the methodology and its results can have a significant impact on the overall project management quality.
Book
Full-text available
As stakeholder relationships and business in general have become increasingly central to the unfolding of stakeholder thinking, important new topics have begun to take centre stage in both the worlds of practitioners and academics. The role of project management becomes immeasurably more challenging, when stakeholders are no longer seen as simple objects of managerial action but rather as subjects with their own objectives and purposes. This book will aim to explain some of the complexities of project management and managerial relationships with stakeholders by discussing the practice of stakeholder engagement, dialog, measurement and management and the consequences of this practice for reporting and productivity, and performance within project management.
Book
Full-text available
Undergraduate and postgraduate courses in Project Management and Information Systems. Research indicates that over half of all IT projects overshoot their budget and timetables while failing to deliver their goals. As a result IT project management has become a serious area of study and this book has been written to back up these courses. Readers of Information Systems Project Management will develop a firm understanding of the practical nature and problems of projects, the ability to apply effective methods and techniques to facilitate the management task, and good team building skills.
Article
Full-text available
The critical risk in project management involves stakeholders and stakeholder values (that is individuals or groups of people who can effect and influence the outcome of projects) and how management mitigates risk in respect to those individuals or groups. The following paper examines paradigm changes in stakeholder values and reviews some of the influences and challenges faced by practitioners in project management. Specifically, the article seeks to investigate stakeholder influence and looks at the determinants of that influence.
Article
Full-text available
Denver's new international air port was to be the pride of the Rockies, a wonder of modern engineering. Twice the size of Manhattan, 10 times the breadth of Heathrow, the airport is big enough to land three jets simultaneously-in bad weather. Even more impressive than its girth is the airport's subterranean baggage-handling system. Tearing like intelligent coal-mine cars along 21 miles of steel track, 4,000 independent "telecars" route and deliver luggage between the counters, gates and claim areas of 20 different airlines. A central nervous system of some 100 computers networked to one another and to 5,000 electric eyes, 400 radio receivers and 56 bar-code scanners orchestrates the safe and timely arrival of every valise and ski bag. At least that is the plan. For nine months, this Gulliver has been held captive by Lilliputians-errors in the software that controls its automated baggage system. Scheduled for takeoff by last Halloween, the airport's grand opening was postponed until December to allow BAE Automated Systems time to flush the gremlins out of its $193-million system. December yielded to March. March slipped to May. In June the airport's planners, their bond rating demoted to junk and their budget hemorrhaging red ink at the rate of $1.1 million a day in interest and operating costs, conceded that they could not predict when the baggage system would stabilize enough for the airport to open. To veteran software developers, the Denver debacle is notable only for its visibility. Studies have shown that for every six new large-scale software systems that are put into operation, two others are canceled. The average software development project overshoots its schedule by half; larger projects generally do worse. And some three quarters of all large systems are "operating failures" that either do not function as intended or are not used at all. Photo of Dallas International Baggage Handling System: SOFTWARE GLITCHES in an automated baggage-handling system force Denver International Airport to sit empty nine months after airplanes were to fill these gates and runways (top). The system that is supposed to shunt luggage in 4,000 independent "telecars" along 21 miles of track still opened, damaged and misrouted cargo as testing continued in July (bottom). The art of programming has taken 50 years of continual refinement to reach this stage. By the time it reached 25, the difficulties of building big software loomed so large that in the autumn of 1968 the NATO Science Committee convened some 50 top programmers, computer scientists and captains of industry to plot a course out of what had come to be known as the software crisis. Although the experts could not contrive a road map to guide the industry toward firmer ground, they did coin a name for that distant goal: software engineering, now defined formally as "the
Article
Full-text available
Very few software projects are completed on time, on budget, and to their original specification causing the global IT software industry to lose billions each year in project overruns and reworking software. Research supports that projects usually fail because of management mistakes rather than technical mistakes. Risk Management in software projects focuses on what the practitioner needs to know about risk in the pursuit of delivering successful software projects.
Article
The aim of this paper is to explore what is meant by 'theory' in Information Systems. Different conceptions of causality are discussed, as they are seen as key to understanding different types of theory. Five different types of theory are distinguished: (i) theory for analysing and describing, (ii) theory for understanding, (iii) theory for predicting, (iv) theory for explaining and predicting, and (v) theory for design and action. Illustrations of relevant work in Information Systems are provided, as are relevant research methods, and the form of contributions to knowledge in each. The limited discussion of the nature of theory in Information Systems indicates that further work is needed, particularly with respect to theory for design and action.
Article
What is it about IS development projects that make them susceptible to cancellations?
Article
Methodology is a central issue in the theory and practise of information systems development. Structured methods, for instance, have been widely championed as providing a way of improving the quality of software systems. In this paper a case study is presented in which a mail order company made an attempt to implement a well-known methodology, Structured Systems Analysis and Design Methodology (SSADM). Far from facilitating the development process, SSADM encouraged a rigid and mechanical approach in which the methodology was applied in a ritualistic way which inhibited creative thinking. The argument is thus, that methodology, although its influence may be benign, has the potential to operate as a ‘social defence’, i.e. as a set of organizational rituals with the primary function of containing anxiety. The grandiose illusion of an all-powerful method allows practitioners to deny their feelings of impotence in the face of the daunting technical and political challenges of systems development. By withdrawing into this fantasy world the learning processes that are critical to the success of systems development are jeopardized. Methodology, whilst masquerading as the epitome of rationality, may thus operate as an irrational ritual, the enactment of which provides designers with a feeling of security and efficiency at the expense of real engagement with the task at hand.
A Stakeholder Perspective within Software Engineering', Innovation and Entrepreneurship for Sustainable Development
  • J Mcmanus
McManus, J., (2004), 'A Stakeholder Perspective within Software Engineering', Innovation and Entrepreneurship for Sustainable Development, Proceedings of the IEEE Transaction International Engineering Management Conference, 18-21 October, Singapore, Vol 2, pp 880-884