WWW.DISSERTATION.XLIBX.INFO
FREE ELECTRONIC LIBRARY - Dissertations, online materials
 
<< HOME
CONTACTS



Pages:   || 2 | 3 | 4 |

«Abstract Large IT projects may not deliver what they promise. Often they are late. Often they are over budget. Often what is eventually delivered is ...»

-- [ Page 1 ] --

Why Large IT Projects Fail

Peter Henderson

p.henderson@ecs.soton.ac.uk

School of Electronics and Computer Science

University of Southampton, SO17 1BJ, UK

May 2006

Abstract

Large IT projects may not deliver what they promise. Often they are late. Often they are

over budget. Often what is eventually delivered is not either what was originally specified nor

what is actually needed. There are many reasons why this happens. We discuss some of those

reasons here and argue that many of them are a consequence of failure to specify requirements anything like adequately. We introduce the notion of requirements drift as a root cause of failure and show, by the use of models, that the often quite large discrepancies between expectations and reality can be the consequence of quite modest amounts of requirements drift.

This preprint is available at http://www.ecs.soton.ac.uk/˜ph/LargeIT.pdf Keywords: Large IT Projects, Requirements, Failure, Open Systems, Complexity, Models 1 Introduction Large IT projects are those that involve hundreds of software engineers and require many years to complete. Such projects often fail. Failure can be in various forms. Sometimes the delivered system fails to provide significant requirements to the standard of quality which makes it possible to actually deploy the system. Sometimes the anticipated cost for the project is exceeded by a large factor. Sometimes the anticipated delivery date is exceeded by a large factor. Often, failure involves a combination of all three of these effects.

The main problem is to determine the causes of such failures, since this must precede the recom- mendations for mitigating their consequences. We will enumerate the accepted reasons for large project failure and show that an underlying cause of all of them is what we shall call requirements drift.

The accepted reasons why large IT projects fail are many and various, but include all the following 1 2 Why Large IT Projects Fail - http://www.ecs.soton.ac.uk/˜ph/LargeIT.pdf

1. There is too much optimism as to the potential benefits of IT and as to the cost of delivering those benefits

2. There is too little investment at the beginning.

3. Sufficient investment is made eventually, but is too late.

4. There is not enough technical know-how in the project team.

5. There are opposing Human Factors aspects - including insufficient consideration of teams, project management and risks.

6. The project does not plan incremental roll-out and fails to anticipate the effect of big-bang on the organisation.

7. The project tries to match IT to the existing Business Processes of the organisation, rather than mandating that the Business Processes change to match those implicit in the IT.

8. Initial underinvestment leads to an investment legacy, where the project has invested in bad decisions and doesn’t have the courage to retreat.

9. There are many management disaster scenarios such as (a) parent/child governance scenario - where authority within the project remains with senior management in the customer.

(b) the enthusiastic builder scenario - where the supplier has a vested interest in prolonging the project since payment is related to time-on-the-job rather than delivery of results.

10. And of course, because of insufficient planning and simply because projects take a long time from inception to completion, there is a requirements explosion during the lifetime of the project which means that what is eventually required is significantly different from what was originally anticipated In fact, because of the impossibility of accurately capturing requirements (where supplier and customer absolutely have the same understanding) before a project begins, and because an organisation learns over time, requirements are subject to constant change, a phenomenon we call requirements drift. Each of the reasons listed above can be shown to have an underlying cause which is explained by requirements drift.

We have built a series of models of large projects, based on our understanding of how real projects perform [Chatters 1998], and used these models to explain how failure could be anticipated if requirements drift were considered from the outset and throughout. Our results demonstrate the quite remarkable butterfly effect of modest changes in the rate of drift. Small changes in that can lead to significant changes in time, cost and quality, the principal measures of success.

–  –  –

1.1 Outline of Paper First we characterise what we mean by large IT projects and what it means for them to fail. Then we put some flesh on the bones of the ten reasons listed above for project failure. These reasons are, of course, interrelated, so there is no best order in which to present them, since whatever we do we have to make forward reference to reasons that we have not yet elaborated. It is a conjecture of this paper that everything is related to the (in)ability to keep control of requirements, so every reason will make forward reference to that.

Next we introduce the notion of requirements drift which captures the observation that as a project proceeds, the requirements change. Many of these changes are actual, but many are simply a consequence of the organisation learning more about what the original requirements actually involved.





In this section we argue that the ten reasons previously discussed can all be seen as an aspect of requirements drift, or can be shown to be exacerbated by requirements drift.

Then we introduce a model that we can use to explain the relationship between requirements drift and project metrics. We show, by the use of this model, the effect of modest requirements drift on project cost and schedule and on the quality of the delivered product.

Finally we discuss how this insight can be used to better control projects and to mitigate the consequences of project failure.

2 The Characteristics of Large IT Projects and their Failures

2.1 The Characteristics of Large IT Projects There are a number of ways in which a large project is measured. Perhaps the most obvious is the cost. However, this measure cannot be considered in isolation. For example, one way to lower the cost of a product, is simply to deliver something of lower quality. Or, what amounts to the same thing, to deliver it too early. Consequently, when discussing large projects we need to consider a number of dimensions. Here, we distinguish Size, Quality, Cost, Schedule and Complexity. Before we discuss their relationship, let us first define them.

2.1.1 Size

Large IT projects are dominated by the need to deliver software, in all its many diverse forms.

Normally, contemporary projects involve a much greater proportion of existing code, that simply needs to be configured, than they do original code. The software engineers spent their time modifying some of this code, in particular setting parameters and writing scripts that will specialise the existing code to the specific requirements of this project. Thus, the quantity of delivered software may be measured in millions of lines of code, but only a few thousand of those lines will be new.

Nevertheless, the larger figure is an essential measure of size, since in many repects it quantifies the amount of work that the engineers need to do in order to understand the functionality delivered by a given component before they can accurately specialise it. There are established means of calculating how much work will be involved in producing code [Boehm 1981] which have been refined in recent 4 Why Large IT Projects Fail - http://www.ecs.soton.ac.uk/˜ph/LargeIT.pdf years to handle this contemporary case of building largely from existing components [Boehm 2000].

These methods require good historical data from similar projects, ideally those delivered by the same supplier. This data is seldom available. Other measures of size are necessary.

Once a project is complete, a reasonable measure would be the number of (hundreds of) engineeryears required to complete it. Clearly, projects continually try to estimate this figure from their inception, since it is a major component of the delivery cost. Where software is concerned, such measures are often wildly inaccurate. The Mythical Man-Month [Brookes 1979] tells us that, for many reasons, the delivery of a software product can require up to ten times the effort of producing a proof-of-concept prototype. This figure is seldom believed by managers and is frequently the reason that initial estimates of cost are substantially too low. This can be thought of as an inability to estimate the size of the product accurately.

One conjecture is that the best measure of size for a project is to count the number of requirements.

Clearly the more requirements there are, the more work there will be to do, even if it is only to confirm that an existing component does indeed deliver a given requirement. Of course, this begs the question of how big is a single requirement, and even whether that question is well-formed. But, assuming we can enumerate all requirements, collect them in a document and break them down into unit requirements (say, for example, something anticipated to require one engineer-month), then we would have a reasonable prediction of the size of a project. After all, this is exactly what we do in project management when we construct a Gantt chart and agree a delivery schedule.

2.1.2 Quality

Now we come to the measure of what it means for a delivered IT project to be of acceptable quality. When project progress is reported informally (in the press, for instance) it is often the case that the perceived end-user quality is unacceptable. The system may not deliver the anticipated functionality, it may be very slow or it may be very difficult to use. It may even still break in the users’ hands, where residual bugs expose themselves too readily.

Considering only this extrinsic quality, we can imagine the end-user sitting down with a list of requirements, and analysing the system to see which of those requirements are delivered to their satisfaction. If we imagine them ticking those requirements that they find acceptable, then we would eventually have a crude measure of (their perception) of the delivered quality. Optimistically we might hope that they had ticked 90%, 99% or even 99.9% of those requirements. These would be significantly different measures of quality, perhaps only the last of those actually being acceptable in a realistic application and often higher levels of quality are expected, especially in a safety-critical context. Moreover the cost of going from 90% to 99% can exceed the cost of getting to 90% in the first place, and then getting to 99.9% can, in turn, exceed that. These diminishing returns are issues that we will return to later.

–  –  –

2.1.3 Cost Large projects cost large amounts of money. The recent project “National Programme for IT” in the UK NHS [NHS 2005] was originally costed at around £6,000m, whereas a recent official report estimates that the eventual cost may be double that and some reporters have even predicted £20,000m before delivery is as originally planned [NAO 2006]. These are very large numbers, but the effect is not uncommon, an initial estimate that doubles, then trebles and worse. Many large public works go over budget by similar factors, For example, in his report on the inquiry into the cost of the Scottish Parliament building, Lord Fraser states the inquiry was set up to evaluate a project “which is now two and a half years behind schedule with costs running approximately ten times more than the original estimate of 40m.” [Holyrood 2004]. While going over budget is not unique to the IT industry, it is increasingly familiar in respect of the size of the discrepancy between initial estimate and ultimate cost [Humphrey 2004].

In the case of large IT projects, the cost is largely for staff. The procurement aspect of large projects is usually dominated by the cost of employing sufficient staff. This in turn is estimated on the basis of perceived size and complexity of the building task.

Large projects are however normally the subject of competitive tendering and the initial cost proposals are clearly dominated by the need to win the bid. Purchasers of large IT will try to mitigate their risk by tying the supplier in to some punitive form of damages but often this just causes one or more of the consortium to collapse. The customer is left with a legacy investment and a partially completed project. The money has gone. The choices are stark. Invest more to continue (with new suppliers) or go without the solution. Effectively the project starts over. A cynic might say that large projects require two or three such restarts until the organisation learns sufficiently about the problem in hand, until more realistic objectives are established [Cambridge 2001].

2.1.4 Schedule

Delivery on time is also unusual for large IT projects. Many of the steps in a development process are necessarily sequential. Software can’t be tested until it is built. Integrated systems can’t be built and tested until their components are available. Non-functional requirements (performance, human factors etc) can’t be tested until a realistic subset of the functionality is available and a large scale evaluation can be established.

The project will anticipate that many of these things can be overlapped. In theory, that will be true. In practice, it will be difficult to achieve. Often we have a project that has been planned with dependencies on a number of key components (e.g. promised functionality in a new version of an operating system). Late arrival of the key components result in delays and reworking, adding to schedule slippage and overall cost.

Again, the Mythical Man-Month [Brookes 1979] tells us that person-months are not subject to arithmetic laws. A task may well require 12 person-months, but it may (for example) be that this necessarily is in the form of 2 persons for 6 months. Adding a third person will not reduce the schedule. Three people still require 6 months. Indeed, they may require longer, if the added person needs to be trained, since this calls time away from the initial two. This is sometimes quoted as “adding more people to a late project makes it later”.



Pages:   || 2 | 3 | 4 |


Similar works:

«ABC Amber Text Converter Trial version, http://www.processtext.com/abctxt.html Something Wonderful Judith McNaught Now then, Jordan explained, smiling reassuringly into Alexandra's enormous blue-green eyes as he matched his actions to his words, a kiss is a thing to be shared. I'll put my hands on your arms, thus, and draw you close. Alexandra looked at his strong fingers gently imprisoning her upper arms, then finally dragged her embarrassed gaze to his. Where do my hands go? Jordan squelched...»

«CHAPTER ONE INTRODUCTION 1.0 Reasons for the audit The Public Servants Housing Loan Scheme (PSHLS) was set up by the government in 1975 to provide financial assistance to public servants to enable them put up residential accommodation of their own. Twenty years (by December 2005) since its inception, the Scheme has been able to assist 3,939 public servants out of 350,000 (figure given by Controller and Accountant General). Many retired public servants refuse to quit government bungalows...»

«FOR PUBLICATION UNITED STATES COURT OF APPEALS FOR THE NINTH CIRCUIT UNITED STATES OF AMERICA, No. 11-10036 Plaintiff-Appellee, D.C. No. v. 2:09-cr-01040MHM-4 CORDAE L. BLACK, Defendant-Appellant. UNITED STATES OF AMERICA, No. 11-10037 Plaintiff-Appellee, D.C. No. v. 2:09-cr-01040MHM-6 ANGEL MAHON, Defendant-Appellant. UNITED STATES OF AMERICA, No. 11-10039 Plaintiff-Appellee, D.C. No. v. 2:09-cr-01040MHM-2 KEMFORD J. ALEXANDER, Defendant-Appellant. 2 UNITED STATES V. BLACK UNITED STATES OF...»

«    INTERIOR LAYERED DEPOSITS IN CHAOTIC TERRAINS ON MARS Mariam Sowe Dissertation zur Erlangung des Doktorgrades im Fachbereich Geowissenschaften an der Freien Universität Berlin Berlin, Januar 2009   Erstgutachter: Prof. Dr. Ralf Jaumann Freie Universität Berlin Institut für Geologische Wissenschaften Fachrichtung Planetologie und Fernerkundung sowie Deutsches Zentrum für Luftund Raumfahrt Institut für Planetenforschung, Abt. Planetengeologie Zweitgutachter: Prof. Dr. Gerhard Neukum...»

«Glossary of Mining Terminology After Damp Gasses resulting from underground combustion, normally carbon monoxide. This is a loose term implying any fatal gas in a mine after an explosion or fire. Air Shaft A vertical opening into a mine for the passage of air. Airway Any passage in a mine along which an air current moves. Some passages are driven solely for air. Other passages, such as a main level, are all purpose, to move air, men, coal, and materials. Anthracite Coal of the highest...»

«Subject to approval by the Guardianship/Conservatorship Interim Committee GUARDIANSHIP AND CONSERVATORSHIP INTERIM COMMITTEE MINUTES Friday, November 19, 2004 9:30 a.m. Gold Room State Capitol, Boise, Idaho The meeting was called to order at 9:35 a.m. by Cochair Senator Bart Davis. Other committee members present were Cochair Representative Debbie Field, Senators Patti Ann Lodge, Dick Compton and Bert Marley and Representatives Leon Smith and Allen Andersen. Representative Sharon Block was...»

«MailEnable Quick Start Guide MailEnable Quick Start Guide Messaging Services For Microsoft Windows 2003/2008/2012 MailEnable Pty. Ltd. 59 Murrumbeena Road Murrumbeena VIC 3163 Australia t: +61 3 9569 0772 f: +61 3 9568 4270 www.mailenable.com Page 1 of 7 MailEnable Quick Start Guide Getting Started This document shows you how to get MailEnable up and working in a short period of time. It is assumed that MailEnable has already been installed on your Microsoft Windows server. Please refer to the...»

«GODSPEEDHOSTEL /GODSPEEDHOSTEL GODSPEEDHOSTEL.COM Welcome We are so excited that you are interested in Panhellenic Recruitment! On behalf of our Panhellenic Association Executive Board and our Panhellenic chapters here at Penn State, I am thrilled to welcome you to one of the largest and strongest fraternity and sorority communities in the country! We are so proud to serve as the home for 19 Panhellenic sororities and 3 Associate Panhellenic Chapters all of which have played a crucial role in...»

«GALA AUCTION ITEMS as of 12.9.2013 LIVE AUCTION 1-Insider Experience with the 2013 Stanley Cup Champs This is a once in a lifetime opportunity to feel like an insider with 2013 Stanley Cup Champions! Grab three friends and watch the Blackhawks take to the ice during a regular season home game from four amazing seats and VIP parking. Before the game, you will enjoy dinner with John McDonough, President of the Blackhawks. One lucky person from your group will ride the Zamboni during intermission!...»

«On Soloing by Randell Young, D.Mus. I once had the opportunity to do a few gigs in a quartet featuring the great keyboardist/composer Rob Mullins. Nate Phillips, who had worked with Rob in the Jazz Crusaders, and Jeff Suttles, who had just come off tour with Janet Jackson held down the bass and drums, respectively. The basic concept was to play instrumental arrangements of funky R&B tunes, sort of like a funk version of Paul Shaffers' Worlds Most Dangerous Band (the David Letterman Show band)....»

«University of Illinois Library Africana Collections and Services, Room 325 International and Area Studies Library African Studies Acquisitions List November 2010 – December 2011 004.67096 D492 Development of Local Internet Traffic in West and Central Africa and Beyond: Synthesis of an E-Discussion. Dakar: Panos Institute West Africa, 2005.070.4 Sa575h Sane, Ibrahima, and Johan Deflander. Heeding the Voiceless: a Guide to Use Oral Testimonies for Radio Documentaries. Dakar, Senegal: Panos...»

«1 MULBARTON PARISH COUNCIL Minutes of the Parish Council Meeting held at 7.30pm on Monday 1st August 2016.Councillors present:Bev Leek Richard Tucker Steve Sewell Derek Aldous First Public Session.1.1 Police Report. PCSO Sore was unable to attend the meeting but had emailed the office with the crime statistics for the past month. In the time period between the last meeting and midnight 31 July there were five reported crimes: assault x 2 plus criminal damage to a motor vehicle whereby two...»





 
<<  HOME   |    CONTACTS
2016 www.dissertation.xlibx.info - Dissertations, online materials

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.