Post on 20-Jan-2016
Embed Size (px)
DESCRIPTIONSystems MPP. Ross Anderson. Aims. Introduce students to why building, and evolving, complex administrative systems is hard Illustrate what goes wrong with case histories Understand why many IT projects are late, or fail altogether (and public sector particularly bad) - PowerPoint PPT Presentation
AimsIntroduce students to why building, and evolving, complex administrative systems is hard Illustrate what goes wrong with case historiesUnderstand why many IT projects are late, or fail altogether (and public sector particularly bad)Study basic ideas from software engineering, project management and information economics as a guide to how mistakes can be avoided
ObjectivesBy the end of the course you should appreciate why policy implementation often involves the construction, outsourcing or or modification of complex information systems, and frequently fails as a result. You should also be aware of some of the ways in which changing technological possibilities can change the regulatory landscape.
Objectives (2)You should appreciate the leading causes of IT project failureYou should understand the waterfall, spiral and agile models of system developmentYou should appreciate the reasons why outsourcing information systems can be complex, including technical lock-in, contracting practices and the diseconomies of scale.
ResourcesRecommended reading:SW Thames RHA, Report of the Inquiry into the London Ambulance ServiceA King, I Crewe, The Blunders of our GovernmentsC Shapiro, H Varian, Information RulesAdditional reading:FP Brooks, The Mythical Man MonthH Thimbleby, Improving safety in medical devices and systemsR Anderson, Security Engineering 2e, ch 256,
AssessmentAbout 6 groups of about 4 people will each analyse a system problem and come up with a detailed report This will give you the experience of working in a team with colleagues not of your choosing to produce a complex deliverable to a rigid timescaleYou will be expected to divide up the work into units manageable by team members, conduct the research, and maintain good enough communication that the individual members contributions can be combined into a coherent report
Assessment (2)In addition, each student will separately write a one-page briefing for the minister that summarises the contents of the report and sets out options for decision. You will receive a group mark out of 60 for the report (of which 40 marks will be allocated for the paper and 20 for the presentation).You will also get an individual mark out of 40 for the briefing paper.
Topics The DWP programme to introduce Universal CreditThe introduction of smart meters, in the UK and elsewhereThe implementation of Obamacare The regulation of medical device safety
Topics (2)The care.data fiasco over medical record privacyThe regulation of autonomous vehiclesThe implications of the Snowden leaksPreferences by email to me today please; teams will be allocated tomorrow and reports are due by noon on February 18th
Outline of CourseInitial lecture: Jan 15Guest lectures:Veronica Marshall, ex-NAO, Jan 22Harold Thimbleby, Swansea, Feb 5Philip Sinclair, Cabinet Office, Feb 12To be announced, Feb 19Present your own project work: Mar 5th
The Software CrisisSoftware lags far behind the hardwares potential!Many large projects fail in that theyre late, over budget, dont work well, or are abandoned (LAS, NPfIT, DWP )Some failures cost lives (medical devices) or cause large material losses (NPfIT)Some cause expensive scares (Y2K)Some combine the above (LAS)
The London Ambulance Service SystemCommonly cited example of project failure because it was thoroughly documented (and the pattern has been frequently repeated)Attempt to automate ambulance dispatch in 1992 failed conspicuously with London being left without service for a dayHard to say how many deaths could have been avoided; estimates ran as high as 20Led to CEO being sacked, public outrage
Original System999 calls written on paper tickets; map reference looked up; conveyor to central pointController deduplicates tickets and passes to three divisions NW / NE / SDivision controller identifies vehicle and puts note in its activation boxTicket passed to radio controllerThis all takes about 3 minutes and 200 staff of 2700 total. Some errors (esp. deduplication), some queues (esp. radio), call-backs tiresome
Project ContextAttempt to automate in 1980s failed system failed load testIndustrial relations poor pressure to cut costsPublic concern over service qualitySW Thames RHA decided on fully automated system: responder would email ambulanceConsultancy study said this might cost 1.9m and take 19 months provided a packaged solution could be found. AVLS would be extra
The Manual Implementationresource mobilisationcall takingresource identificationresource managementControl AssistantMapBookResource ControllerIncident FormResource AllocatorsAllocationsBoxRadio OperatorDespatcherIncident form'IncidentForm''
Dispatch Systemcall takingresource mobilisationresourceidentificationresource managementdespatch domaindespatchworksystem Large Real-time Critical Data rich Embedded Distributed Mobile components
Bid processIdea of a 1.5m system stuck; idea of AVLS added; proviso of a packaged solution forgotten; new IS director hiredTender 7/2/1991 with completion deadline 1/9235 firms looked at tender; 19 proposed; most said timescale unrealistic, only partial automation possible by 2/92Tender awarded to consortium of Systems Options Ltd, Apricot and Datatrak for 937,463 700K cheaper than next lowest bidder!
First PhaseDesign work done July Main contract signed in AugustLAS told in December that only partial automation possible by January deadline front end for call taking, gazetteer, docket printingProgress meeting in June had already minuted a 6 month timescale for an 18 month project, a lack of methodology, no full-time LAS user, and SOs reliance on cozy assurances from subcontractors
The Goalresource mobilisationcall takingresource identificationresource managementOperatorComputer-based gazetteerAVLS mapping systemCAD systemResource proposal system
From Phase 1 to Phase 2Server never stable in 1992; client and server lockupPhase 2 introduced radio messaging blackspots, channel overload, inability to cope with established working practicesYet management decided to go live 26/10/92CEO: No evidence to suggest that the full system software, when commissioned, will not prove reliableIndependent review had called for volume testing, implementation strategy, change control It was ignored!On 26 Oct, the room was reconfigured to use terminals, not paper. There was no backup
LAS Disaster26/7 October vicious circle:system progressively lost track of vehiclesexception messages scrolled up off screen and were lostincidents held as allocators searched for vehiclescallbacks from patients increased causing congestiondata delays voice congestion crew frustration pressing wrong buttons and taking wrong vehicles many vehicles sent to an incident, or noneslowdown and congestion leading to collapseSwitch back to semi-manual operation on 26th and to full manual on Nov 2 after crash
Collapse Entire system descended into chaos: e.g., one ambulance arrived to find the patient dead and taken away by undertakers e.g., another answered a stroke call after 11 hours, 5 hours after the patient had made their own way to hospitalSome people probably died as a resultChief executive resigns
What Went Wrong SpecLAS ignored advice on cost and timescaleProcurers insufficiently qualified and experienced No systems viewSpecification was inflexible but incomplete: it was drawn up without adequate consultation with staffAttempt to change organisation through technical system (3116)Ignored established work practices and staff skills
What Went Wrong ProjectConfusion over who was managing it allPoor change control, no independent QA, suppliers misled on progressInadequate software development toolsDitto technical comms, and effects not foreseenPoor interface for ambulance crewsPoor control room interface
What Went Wrong Go-liveSystem commissioned with known serious faultsSlow response times and workstation lockup Software not tested under realistic loads or as an integrated systemInadequate staff trainingNo back upLoss of voice comms
NHS National Programme for ITLike LAS, an attempt to centralise power and change working practicesEarlier failed attempt in the 1990sThe February 2002 Blair meetingFive LSPs plus a bundle of NSP contracts: 12bnMost systems years late and/or dont workChanging goals: PACS, GPSoC, Inquiries by PAC, HC; Database State report Coalition government: NPfIT abolishedSee case history written by 2014 MPP students!
Next Universal CreditIdea: unify hundreds of welfare benefits and mitigate poverty trap by tapered withdrawal as claimants start to earnSupposed to go live Oct 2013! Problems General: big systems take 7 years not 3They hoped agile development would fix it Specific: depends on real-time feed of tax data from HMRC, which in turn depends on firms Now descended into chaos; NAO report
Smart MetersIdea: expose consumers to market prices, get peak demand shaving, make use salientEU Electricity Directive 2009: 80% by 2020Labour 2009: 10bn centralised project to save the planet and help fix supply crunch in 2017March 2010: experts said we just cant change 47m meters in 6 years. So excluded from specCoalition government: need big deployment by next election in 2015! So we must build central system MarSep 2013 (now: Sep 2014 )Contracts tendered while spec still fluid
Medical device safetyUsability problems with medical devices kill about the same number of people as carsBiggest killer: infusion pumps, which have many different, confusing interfacesRadiology kit still kills people tooRegulators are incompetent / capturedN