FREE ELECTRONIC LIBRARY - Dissertations, online materials

Pages:     | 1 || 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 2 ] --

6 Why Large IT Projects Fail - http://www.ecs.soton.ac.uk/˜ph/LargeIT.pdf These phenomena are well known in the industry. They are consistently overlooked. Because they are not Laws in the sense of Laws of Physics [Henderson 1998], manager after manager will convince themselves that they do not apply in their particular circumstances.

2.1.5 Complexity Last, we must consider the inherent complexity of large IT projects. Clearly, this varies from project to project, but there is no doubt that software in general can be very complex (in both the formal and informal senses) [Axelrod 99, Kauffman 2000, Chapman 2002, BCS 2004, Xia 2004].

Complexity usually means that the separability of the components of a product are severely constrained. Changes to one component induce changes in many others. This is referred to as being tightly-coupled. A good design will seek loose-coupling or near-independence between components.

However, good design isn’t often achievable in large projects - because of their inherent complexity;

a cyclic problem if ever there was a one. Few project managers have the courage to invest more in design in order to save later on building.

There is some threshold of connectedness above which the complexity of a large IT system becomes intractable, not unlike the thresholds discovered in combinatorial problems [Hayes 2003]. Below this threshold, the work required to solve a problem is effectively linear in some aspect of the size of the problem. But above the threshold, work increases exponentially (or worse) and soon problems just a little above the threshold are, for all practical purposes, unsolvable.

Complexity is often exaccerbated within the project, where building loosely-coupled solutions takes longer than building tightly-coupled ones. The project looks only at the short-term costs and not at the total-cost-of-ownership. A too-quickly developed solution will usually be more tightly-coupled than it could be, and that will lead to problems with internal complexity much later.

2.1.6 On the relationship between Size, Quality, Cost, Schedule and Complexity

Clearly these five aspects of largeness in a large project are themselves related. We have referred already to some of these relationships, for example larger projects will cost more. In fact we even suggested that cost was a reasonable measure of (post facto) size. We will not try to formalise the relationship, but an informal discussion is warranted.

Figure 1 is a diagrammatic representation of the relationship between these five values and is based on a model that we have used in earlier experiments [Chatters 1998]. The box in the centre of the diagram is intended to denote the development process (think of it as a factory) which takes in components of a certain Quality and builds and outputs a product of a certain Quality. The dominant measures of the size of the task at hand are the perceived Size and Complexity of the product. By doing Work on the product (i.e. designing, building and testing it) we can affect the Quality of the output. We can also affect the delivery Schedule.

–  –  –

Similarly, if the input Quality of basic components from suppliers is high, we would expect to achieve a target output Quality for less Work. Here, we align Work with Cost, on the basis that person-years is the dominant cost in large projects.

In [Chatters 1998] we showed that output Quality is related to Work by a law of diminishing returns; that as the project gets bigger the amount of delivered Quality per unit of Work reduces.

This rather obvious property was supported in that paper by some rudimentary data, but data of that sort is very difficult to acquire because it can be very sensitive. We found that the data we did collect was rather unreliable and so it was not possible, at that time, to establish the relationship precisely.

2.2 What Failure Means

Given these five Measures we can state what it means for a large IT project to be perceived as failing, or to have failed if it has been abandoned. Since it is often the case that large IT projects are perceived as failing long before they are finished, we address the symptoms in the order in which they are usually reported. First we discover that the project is going Over Budget, then we discover that it is Over Time and finally we discover that the customer sees it has having Low Quality.

2.2.1 Over Budget Many IT projects cost a little more than originally budgeted. The characteristic of large IT projects seems to be that they go over budget by a very large factor. Then, the fact that their budget is already very high, means that the additional cost will be newsworthy.

Since this cost over-run will normally happen before the original schedule has run its course, it will normally be the need for the suppliers to renegotiate their contract that is the first indication that a project is failing. As we shall see, it is the realisation that the requirements apparently agreed in the initial contract cannot be delivered for the initially quoted price that kicks off this renegotiation.

2.2.2 Over Time

–  –  –

than anticipated, so more Work is required (i.e. more Cost) and it will take longer, because we cannot trade person years (except within fairly tight limits).

2.2.3 Low Quality Finally, when a first product release is eventually available for end-user evaluation, it is reported that the product does not fulfil the requirements that the users now have for it. The GedankenExperiment that we discussed earlier, of the end-user apparently ticking-off requirements on a long list and then measuring Quality as the number of ticks that the product receives, gives us a crude measure. Often this measure is low when a large IT project is delivered. The reasons are many and various, as we shall elaborate in the next section. But primary among them is that the requirements as understood now by the end-user are some way from those that were agreed at the outset.

Formally, the difference may be small. In practice, it may be all that matters when it comes to reporting on the perceived quality of the eventual product.

2.2.4 Comments on Perception of Failure As we discussed above, the three perceptions of failure, respectively being too expensive, being too late or being of poor quality are interrelated. Often we have all three, but even having one of them would be considered a failure.

We will argue that it is an inadequate attention to requirements that leads to failure. There are two aspects of this. Of course, over the lifetime of a long-running project, the requirements will change.

Perhaps more significantly, the initial requirements will also “change” in the sense that, as they become more fully understood on the part of both supplier and customer, it is increasingly realised that the initial agreement was based on “weak” mutual understanding. What was perceived as agreement, is now seen as a basis for conflict. The supplier wants to deliver what they originally undertook to deliver, the customer wants that too, but disagrees as to the details of that initial agreement. The customer now wants something additional however, something more refined or more elaborate that the initially agreed requirements. This puts the customer in a weak position to negotiate a compromise.

2.3 Reasons why Large Projects fail

In the overview, we briefly described ten reasons why large IT project fail. Now we have some vocabulary with which to discuss those reasons. The order in which they are addressed is rather arbitrary. Since they are all interrelated, no order is perfect. Eventually we will show that the root cause is our failure to manage the requirements process adequately and, in particular, that requirements drift goes largely unnoticed.

2.3.1 Optimism

–  –  –

Both customer and supplier expect more than is realistically possible. The customer expects that the product will solve all their problems. The supplier sells that dream. Both may well believe that the agreed requirements can be delivered for the agreed cost and that those agreed requirements will actually meet the customer’s need. They are too optimistic.

2.3.2 Investment There is too little investment at the beginning.

This optimism leads to a confidence in the estimated cost which results in an initial investment that is far too small. The investment is likely to be related to a spending forecast that anticipates an unfaultering project plan. Something like 25% is added to cope with “unforseen” circumstances.

The reality is that there was never really any prospect of delivering the project for 200% of the estimate, let alone 125%. The Size and Complexity have been underestimated. The Quality of existing components (in the sense of their ability to nearly match some of the requirements) has been misjudged, and hence the rework necessary has been underestimated. This is true even when Open Systems components implementing open standards have been used. The work required to actually understand how these components work, and in particular how they interoperate with others, is usually much more difficult than is anticipated.

2.3.3 Procrastination Sufficient investment is made eventually, but is too late.

So reality dawns. More investment is needed. This is the first of what might eventually be a number of “stumbles”. Cynically, we might say that, for all large projects, one or two stumbles are required as the organisation (the suppier and the customer) learn about the complexity of the task they have embarked upon.

However, had the initial investment been larger, the project would probably not be so far behind.

This is something that our models show. Anticipating a more distant objective can accelerate progress. So having an initial establishment that makes more distant objectives possible, means that the eventual cost of delivering a given function to a given quality will actually be less than that which will be achieved with insufficient initial investment, even if that is eventually “topped-up” to an adequate amount.

2.3.4 Technical Know-how There is not enough technical know-how in the project team.

Of course, making sufficient investment probably assumes that the staff that the supplier uses for the project are of sufficient technical quality at the outset. Optimism sets in here too. We all assume that we are able to achieve more in a given time than in fact we are capable of achieving.

We usually over-estimate our own technical ability. Experienced project managers allow for this.

There are generic technical skills which can be established and allowed for at the outset. But 10 Why Large IT Projects Fail - http://www.ecs.soton.ac.uk/˜ph/LargeIT.pdf there are specific technical skills, knowing the capabilities of the components we are building from, knowing the application domain sufficiently well that the requirements can be understood, which are likely to be misjudged. We are optimistic. We expect the supplied components to be “better” than they eventually prove to be. We believe we understand the customers’ requirements at least as well as the customer understands them. The reality is that the components are not nearly as fit-for-purpose as we anticipate (even when they adhere to open standards) and what we understand about the requirements is far from what the customer intends, even when they reach agreement and sign the contract.

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

This is a large topic, and many writers will suggest that solving project management problems is the single most important aspect of delivering Quality on Schedule and for an agreed Cost [Brookes 1979, Petroski 1992, Grey 1995, BCS 2004, ACM, Neumann 1995]. These claims are of course valid. A poorly managed project, without an appropriately organised team structure and without continual reassessment of the risks ahead, will not deliver on any of the three measures of success. However, many large IT projects are managed correctly in these respects and yet they still fail [Intellect 2003, Sauer 2003, Xia 2004, Humphrey 2004]. So, while getting the “people” issue sorted is necessary, it is not sufficient.

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

A project that introduces new technology into an organisation incrementally is more likely to eventually be seen as successful. There are two reasons for this. The first is simply that each increment is the product of a smaller project. The second is that, where there are problems that are related to misunderstandings between supplier and customer, these problems will be encountered earlier and have smaller consequences.

A component-based solution, using commodity off-the-shelf components (COTS) can make incremental delivery possible, especially where these components adhere to open standards as expected in an Open Systems approach. There are many benefits to introducing these new components incrementally, not least that problems are encountered early, even if it is only problems of perception

- understanding what the components actually do and how they actually match (or fail to match) the customers requirements.

2.3.7 Inertia

–  –  –

IT offers a business more efficient and more effective ways of running their business processes. But where, as is usual today, the project to introduce new IT starts with an existing software solution (e.g for ERP or CRM) much of the engineering that is involved is specialising the IT to the business processes of the customer. Where the customer insists on continuing to run the business as before, these engineering changes can be overwhelming. One suspects that for many projects they are actually impossible.

The IT packages that are built upon will have built-in generic business process models. Where the customer is willing and able to change their business practices to more nearly match those generic processes, then the amount and complexity of the engineering that will be required is reduced, often substantially.

Pages:     | 1 || 3 | 4 |

Similar works:

«GUIDELINES FOR THE MANAGEMENT OF SEPSIS (INCLUDING NEUTROPENIC SEPSIS) Procedure CP38 Version: 2.2 Reference: Document Accountable Dr P Haji-Michael Acute Oncology Group Owner: Committee: Date Approved: 15/05/2013 Review date: Jan 2019 Greater Manchester & Cheshire Cancer Network Target audience: All clinicians Guidelines for the management of sepsis (including neutropenic sepsis) Doc Ref: CP38 Version 2.2 Page 1 of 22 CONTENTS 1. ASSOCIATED DOCUMENTS 2. INTRODUCTION 2.1 Purpose 2.2 Scope 3....»

«380 Alien Intrusion prove a pet theory. Masquerading angels have also concocted a pseudophilosophy to closely parallel the texts for their own evil aims. The Bible has become “fair game” for those with their own agenda. I recall an investigator at a UFO meeting glowingly using the passage in Ezekiel to say that “even the Bible mentions UFOs.” When I challenged his comment, pointing out that nowhere does Ezekiel use the term “ship,” “craft,” or any other word to describe a...»

«ANTIQUITAS • BYZANTIUM • RENASCENTIA X. Investigatio Fontium EÖTVÖS-JÓZSEF-COLLEGIUM ELTE Investigatio Fontium Antiquitas • Byzantium • Renascentia X. Herausgegeben von Zoltán Farkas László Horváth Tamás Mészáros Eötvös-József-Collegium Budapest 2014 Investigatio Fontium Griechische und lateinische Quellen mit Erläuterungen Beiträge der Tagung Klassisches Altertum Byzanz Humanismus der XI. Ungarischen Konferenz für Altertumswissenschaft Herausgegeben von László...»

«Philippine Institute for Development Studies Surian sa mga Pag-aaral Pangkaunlaran ng Pilipinas Linking Poverty and the Environment: Evidence from Slums in Philippine Cities Marife M. Ballesteros DISCUSSION PAPER SERIES NO. 2010-33 The PIDS Discussion Paper Series constitutes studies that are preliminary and subject to further revisions. They are being circulated in a limited number of copies only for purposes of soliciting comments and suggestions for further refinements. The studies under the...»

«UNREPORTED IN THE COURT OF SPECIAL APPEALS OF MARYLAND No. 1162 September Term, 2015 _ TIMOTHY REEVES v. MARIA MILLER Meredith, Nazarian, Thieme, Raymond G., Jr. (Retired, Specially Assigned), JJ. Opinion by Meredith, J. Filed: March 15, 2016 * This is an unreported opinion, and it may not be cited in any paper, brief, motion, or other document filed in this Court or any other Maryland Court as either precedent within the rule of stare decisis or as persuasive authority. Md. Rule 1-104. —...»

«MONITORING PLAN PROJECT NO. TV-18 (XTV-30) FOUR-MILE CANAL TERRACING AND SEDIMENT TRAPPING July 19, 2004 Project Description The Four Mile Canal Terracing and Sediment Trapping (TV-18) project is from the 9th priority list of the Coastal Wetlands Planning, Protection, and Restoration Act. The project is located approximately 4 miles (6.44 km) south of Intracoastal City in Vermilion Parish, Louisiana, and includes Little White Lake and the portion of Little Vermilion Bay immediately west of...»

«The Making of the Zo: The Chin of Burma and the Lushai and Kuki of India through Colonial and Local Narratives 1826 – 1988 Bianca Son Suantak School of Oriental and African Studies, University of London 1 Declaration for PhD thesis I have read and understood regulation 17.9 of the Regulations for students of the SOAS, University of London concerning plagiarism. I undertake that all the material presented for examination is my own work and has not been written for me, in whole or in part, by...»

«Greyhound Friends for Life Newsline June 2016 GFFL Reunion Marked your calendars for the 2016 GFFL Reunion!Inside This Issue: Sunday, October 2nd 11am – 3pm 1 GFFL Reunion Miller-Knox Regional Park in Point Richmond 1 Tucson Closing Stay tuned for more information in August. 2 Do’s & Don’ts 3 Greyt Info Buddies 4 Sit! Tucson Track Closing 5 Companion Dogs 6 2018 Calendar Many of you have seen the news that Governor Doug Ducey has signed a bill to ban dog racing in the state of Arizona. As...»

«Volume  37(1)     Spring/printemps  2011     Digital  Learners  in  Higher  Education:  Generation  is  Not  the  Issue   Apprenants  numériques  en  enseignement  supérieur  :  la  génération  n’est  pas   en  cause   Mark  Bullen,  British  Columbia  Institute  of  Technology   Tannis  Morgan,  Justice  Institute  of  British  Columbia   Adnan  Qayyum,  University  of  Ottawa   Abstract  ...»

«Surveys of the Marine Fish Resources of Peninsular Malaysia June-July 1980 Reports on surveys with the R/V Dr Fridtjof Nansen. by A. Aglen, L. Føyn, O.R. Godø S. Myklevoll, O.J. Østvedt Institute of Marine Research, Bergen September 1981 «Dr. Fridtjof Nansen» The fishery research vessel «Dr. Fridtjof Nansen» belongs to the Norwegian Agency for International Development (NORAD). It was designed and built for scientific and exploratory investigations of fishery resources of developing...»

«L’ÉGLISE SAINT-LOUIS DE LORIENT AU XVIIIe SIÈCLE Chronique d’un projet inachevé Erwann Le Franc Peu d’études ont été réalisées sur les monuments religieux du XVIII e siècle. Cette remarque vaut particulièrement pour la Bretagne où l’empreinte médiévale demeurée très forte a en quelque sorte éclipsé les monuments postérieurs. On ne s’étonnera donc pas que l’église Saint-Louis de Lorient, édifice disparu durant la seconde guerre mondiale n’ait jamais été...»

«ANNUAL REPORT APRIL 2013 MARCH 2014 INTRODUCTION The Singapore Hockey Federation (“ the Federation “) is a society registered in Singapore with the Registrar of Societies (“ROS”) under the Societies Act (Chapter 311) and has its registered office at 57 Anchorvale Road, #02-08 Seng Kang Sports & Recreation Centre, Singapore 544964. The mission of the Federation is to encourage, promote, develop and manage the game of Hockey in Singapore. The Federation was registered as a Charity under...»

<<  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.