IT PROJECTS: FAILING

In the1970s in the era of mainframecomputers the waterfall, or cascade,methodology of systems developmentwas employed. This methodologymeant (developers, quality, security andoperations) and users were jointlyresponsible for the development of newcomputer systems or major enhance-ments. It was a structured methodologyconsisting of seven stages, each with areview point and agreement level toprogress to the next stage. Admittedly,it was a less time pressured age; a timewhen the waterfall still had seven levels.And yet even then there were some well

publicised major computer systemdevelopment failures – over budget,over time and not providing the costsavings or functionality the businessand users wanted, assuming, and that isa very big assumption, that the usersknew what they wanted.

There have been numerous reportsabout computer systems developmentfailures. They all seem to re-confirm themessages from previous reports thatsenior management do not really under-stand IT; that they do not effectivelycarry out risk assessments; that they donot effectively control or monitor the

development process; and that they donot invest properly in the training of thestaff developing the systems or in theprospective users. New computer systemsare not looked at in risk assessmentterms as they may affect the whole orga-nization. Considerations should includethe risk of developing the system; therisk of not developing the system; therisk of failure to develop the computersystem with the required functionalityand control in the required timescale;the risk of failure at implementationtime etc..

What a difference adecade makes!Despite the publicity surrounding thefailures, especially the public sector ones,the lessons don’t seem to be learned, butrepeated ad nauseum in perpetuity.

I do not want to give the impressionthat this is just a public sector problem –it is just that their failures are often big-ger and always publicised. According to

January 2005 Computer Fraud & Security 15

Why do so many major IT projects fail?Steven Hinde, Bupa

This article focuses on IT project failures and why they often gowrong resulting in missed deadlines and budget overspend.

Reasons for recent Government IT project failuresKey causes of IT failures as reported by the UK National Audit Office2004 based upon a review of 250 government IT projects in the twoyears before March 2004.

Suppliers over-promising on what can be delivered to win contracts.Poor understanding of the IT industry in the public sector.

Lack of a clear link between the project and the changes departmentsneed to make in the way they do business.

Lack of clear ownership of the project at both ministerial and seniorresponsible officer level within the civil service.Failure to engage with those who will use the new systems, and otherstakeholders.

Serious shortages of staff with the project and programme management skills to deliver big programmes.

Departments seeking “bespoke” solutions unnecessarily rather thanusing more standard software.Failure to break big projects into manageable steps.

Reasons for Government IT project failures a decade agoThe UK Public Accounts Committee’s review of 25 government projectsfrom the early 1990s concluded that basic errors have been repeatedtime and time again but the lessons were not learned, despite the factthat many of the failures and lessons have been published in individualpost-project reports published during the period.

Greater scrutiny of external contracts is required to ensure that theyare free from ambiguity and sufficiently cover the terms applicable inthe event of failure (the committee had criticised some joint projectswith the private sector for failing to impose high enough penalties forfailure).

Project specifications should take into account the business needs ofthe organisation and the requirements of the user.

Senior management should champion and drive projects through,ensure the clarity of aims and objectives and set clear criteria againstwhich the success of the project can be judged.

Skilled project managers are required to manage projects and there is aneed to develop such skills.

Careful consideration is required of the scale and complexity of projectsto ensure that they are achievable and the use of a step-by-stepapproach using linked projects is advocated where suitable.There is a need to manage risk by ensuring that there are contingencyplans to provide adequate service in the event of computer failure.

Table 1.

Sir Peter Gershon, former head of theUK Office of the GovernmentCommerce, “The public sector was noworse than the private.” – in November2004 J. Sainsbury, the UK supermarketchain, wrote-off a £260 million ITinvestment in its supply chain. A recentreport by the Standish Group ofMassachusetts covering more than13,000 US IT projects found that onlyone in three were delivered on time,budget and specification. Only a halfdelivered all the required features. Costoverruns averaged at 43% and time over-runs were at 82%.

As the technology of processing hasprogressed from batch to online to real-time; from sequential files to manyflavours of databases; and the size andcomplexity of computer systems haveincreased the only constant seems to besystem development failure. Failuresinclude:

• Delivery on time and within budget. • Acheivement of the sign-off claimed

benefits.• Production of a system with the

functionality or the useablity needed.

Change has always been difficult tomanage. Indeed, Niccolo Machiavelliwrote in The Prince over four centuriesago, “There is nothing more difficult toplan, more doubtful of success, nor moredangerous to manage than the creationof a new system.” With computer sys-tems there is not just one new systembut many, and they are all built around anew technology that is alien to many ofthe participants. There is the computeritself and the environment in which itoperates; there is a new system for devel-oping systems; the application systemsthemselves are all new; the work patternsof all involved with computers changes,often beyond recognition; and there arenew control systems. And increasinglynow we are seeing enforced change intimescales that compromise developmentstandards, control and security. The rea-sons for such quick change are manifold:Government Legislation introduced overa very short timescale; the launch of anew business product which needs to be

launched to the public yesterday toobtain competitive advantage; a newInternet offering; or a take-over / mergerwhere the two organizations’ systemsneed to be merged together over a veryshort timescale. Each of these scenarioscould, and often do, lead to inadequatesystems that are lacking in controls andsecurity.

Organizations are becoming more andmore dependent upon their computersfor the very survival of their organiza-tion, yet management seem oblivious tothe risks and threats. The use of IT aspart of an organization’s strategy forcompetitive advantage, or even survival,is badly mishandled by many organiza-tions. Major information technologyimplementations are time-consumingand typically difficult. The problem ismanagement - line and computer - oftenunderestimates the complexity of design-ing, writing and implementing a newcomputer system and virtually alwaysunderestimate how long it will take.

Unfortunately with technology on theone side and the business requirementon the other added to time pressures andlack of effective project and change man-agement results in an explosive cocktailof poorly controlled, insecure and inade-quate systems that are late. Managementimpatience and time pressures often leadto inadequate testing and the droppingor postponing of the control and securityelements of the system until after imple-mentation. That is assuming manage-ment had actually included them in thefirst place. Systems are often developedwith little or no security and that securi-ty is retro-filled when the risks areunderstood. Even when controls andsecurity are designed into systems, it isnot unusual to see them ignored by linemanagement or, worse, deleted from thesystem for expediency sake such as sav-ing time on inputting data or becausethe function has never been controlled.But you get what you pay for. If man-agement are prepared to invest in pro-ducing quality, well controlled systemsand in implementing them effectivelythey will ultimately enhance the manage-ment of the business. If not, then man-agement will find that much of its time

and resources are diverted to sorting outthe mess.

System development failures are in the news againRecently, system development failureshave hit the headlines again. There seemto be two types of failure – failures inthe development of major new systemsand of enhancements to existing systems.The former seems to be caused by adearth in project management skills andof project management practitioners.Project management is well establishedover millennia and yet we still have fail-ure after failure in major systems beingdeveloped.

In the 250 reviews conducted in thetwo years leading up to March 2004 bythe UK National Audit Office, morethan a quarter of projects were rated red,that is at serious risk of going wrong.About a half were classified as amber –with important issues still to beaddressed. Although a number of pro-jects have improved as a result of thereviews some eight projects have receivedsuccessive red ratings. The list of IT fail-ures includes a benefit swipe card, aban-doned at a cost to the public and privatesector of almost £1 billion; chaos at thePassport Agency when a new systemcame in, and a national insurance (statepensions and National Health Servicetaxation) computer that produced hugebacklogs.

The National Audit Office reportedthat the UK Government informationtechnology projects are being handledbetter but that there is no guarantee thatthere will not be a repeat of past disas-ters. There were serious shortages of staffwith the project and programme man-agement skills needed to deliver large ITenabled projects that affected, inter alia,benefit payments, driving licences andthe National Health Service. A report bythe British Computer Society calculatedthat only 16% of government IT pro-jects were truly successful.

The National Audit Office reviewshave identified the same endemic prob-lems as previous reports on government

IT PROJECTS: FAILING

Computer Fraud & Security January 200516

THE WHOLE PICTURE

IT systems from the 1990s, includingfailure to engage those who will use thesystem – a charge levelled at theNational Health Service IT programme– shortages of both quantity and qualityin the public sector of the key projectmanagement skills needed and lack ofclear ownership of the project in departments.

Enhancement failuresA computer failure at the UKDepartment for Work and Pensionswiped out the use of 80% of their desk-top computers. A routine update of soft-ware left staff hot desking. According tothe Department, the failure did notimpact current benefit payments, butone or two days delay for some newclaims.

Customers of Cahoot, the UK Internetbank, were able to view other people’saccounts after an upgrade to the servicewent wrong, although, according toCahoot, it was not possible to transfermoney from these accounts without also

knowing the password of potential vic-tims. In a statement, the bank said:“This problem has arisen as a result of achange Cahoot made to its IT system.As soon as we discovered it, we closedthe site while we did testing and sortedout a solution. It has now been fixed andthoroughly tested.” What a pity they didnot do system testing before the upgradewas made live.

The bank stressed that no customerlost money as a result of the loophole,but it was faced with calls from peopleconcerned about the safety of their cash.Security concerns are one of the issuesconstraining online banking growth. Arecent survey by RSA Security and Morishowed 40% of people would be morelikely to use online banking if securitymeasures were improved. Industryobservers say Cahoot is not the onlybank to have suffered from securitybreaches such as this, although most donot reach the media.

IT penetration testing companySecureTest said the security breach at

Cahoot is just one example of a grow-ing category of application securityproblems. “The network, the hardwareand the infrastructure can all be as closeto 100% secure as is possible, but ifapplications contain flaws this is all use-less,” said SecureTest’s managing direc-tor. “In many cases ‘hacking’ is almosttoo strong a word. Five minutes spentonline, reading-up on input validationand session management attacks, wouldallow most people to access sensitiveinformation on many of these websites.Or in the case of Cahoot, after a poorlymanaged upgrade to an application,people can even stumble on informa-tion by accident.”

Major developments, minor enhance-ments. Different ends of the develop-ment spectrum, but the same basic fail-ures. Basic failures that have plaguedcomputer systems developments fordecades. Failures that have been wellreported and analysed. Each report hasidentified the lessons to be learned. Allwe need to do is to learn them.

January 2005 Computer Fraud & Security 17

We have pointed out that one importantkey to managing incidents is under-standing and managing risks. We iden-tified the elements of risk as threats, vul-nerabilities, impacts, countermeasuresand interdomain communications chan-nels. Interestingly, we can manage

incidents similarly. By knowing the riskelements that can make up an incidentwe can apply, more effectively, the fourstages of incident control: interdiction,containment, recovery and analysis.

For example, by knowing where vul-nerabilities exist in a system, and by

understanding the interdomain commu-nications that impact those vulnerabili-ties, we may find it easier to isolate andcontain damage as well as interdictingthe ongoing incident. This, especiallythe notion of interdomain communica-tion channels, is analogous to havingwater tight doors and bulkheads on aship.

When a catastrophe, such as a fire onboard, or a breach of the ship’s hulladmitting water, occurs, closing watertight doors contains the problem andallows repair or fire fighting crews todispense with it on a smaller scale thanif the problem spread to the entire ship.This analogy is especially applicable tovirus outbreaks.

Incident scenarioWe will use as our example a contrivedvariation on the SQLSlammer outbreakwe have discussed in previous columns.Recall that we determined that the out-break was a result of the worm entering

Managing an IncidentPeter Stephenson

Last month we discussed the nature of incident management andcontrasted the pro-active management approach with the older, morecommon reactive response approach. It will always be true, unfortu-nately, that we will have to respond on occasion – something alwaysgets past the best of defenses and preparations. But our objectivesare to create a pro-active environment where we have as few inci-dents as possible, the ones we have are of significantly lower severi-ty, and we have more time to respond in a controlled, effective man-ner. This month we will apply our approach to a mock incident andsee how it works in practice.

Gettingthe

whole picture